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
-
@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
-
Oh sorry, my fault. It was a bit late. We have a return true in there, where we exit the loop as soon as we got an ack. You are right!
Suggested Topics
-
Code for beta-testing?
Controllers • 24 Mar 2014, 20:48 • andriej 9 Aug 2014, 10:44 -
Missing "__libc_init_array();" wenn using samd without USB
Bug Reports • 6 Jul 2022, 08:36 • ltigges 7 Jul 2022, 22:43 -
RFM95W sleep() directly after send() often doesn't sleep radio
Bug Reports • 1 Jan 2023, 18:41 • prawnpie 8 Jan 2023, 05:36 -
Sensor presentation failure
Bug Reports • 31 Jul 2016, 19:23 • Sergio Rius 3 Mar 2021, 18:48 -
Making WiFiManager compatible with MySensors 2.3.2
Bug Reports • 12 Feb 2020, 21:43 • pihome 1 Jun 2022, 16:02 -
some differences between serial- and tcp-gateways.
Bug Reports • 15 Mar 2023, 09:26 • Branther 30 Mar 2023, 15:40