Possible flaw in RFM95 driver
-
Hi everybody,
I'm writing a driver for the CubeCell series. Looking at the code for the RFM95, I think there might be a little flaw here in line 599 of RFM95.cpp. Here we are waiting for a Timeout or some data. But in fact, we should wait for a timeout or a ACK, as we sent a frame we want to have an acknowledge for. It's not big of a deal, because when we go into timeout, normaly the ack should still be there. We only waste some 100ms. Worst case, some other node or the controller sent data to us an we overwrote the ack.
Or am I wrong?
Regards, Edi -
Hi everybody,
I'm writing a driver for the CubeCell series. Looking at the code for the RFM95, I think there might be a little flaw here in line 599 of RFM95.cpp. Here we are waiting for a Timeout or some data. But in fact, we should wait for a timeout or a ACK, as we sent a frame we want to have an acknowledge for. It's not big of a deal, because when we go into timeout, normaly the ack should still be there. We only waste some 100ms. Worst case, some other node or the controller sent data to us an we overwrote the ack.
Or am I wrong?
Regards, Edi@eiten I'm not familiar with the RFM59 code, but quickly reviewing the indicated loop shows it is in fact testing for ACK as long as the timeout did not occur and data was not received: https://github.com/mysensors/MySensors/blob/d04e7513877598dd2d039b0e544d45a05ee1f3fa/hal/transport/RFM95/driver/RFM95.cpp#L561
But then again, I too might be wrong ;-)
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login