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 -
ACK -aka ECHO beeing missed by Serial Gateway with RF24 radios. V2.3.2
Bug Reports • 15 Apr 2023, 06:27 • GaryStofer 21 Apr 2023, 17:34 -
sleep(0) in V2.1 doesn't sleep indefinitely anymore. Used to powerdown and sleep in V1.5
Bug Reports • 22 Nov 2019, 00:35 • GaryStofer 15 Apr 2023, 05:50 -
NRF51-52 PA not support ???
Bug Reports • 23 Feb 2019, 16:40 • berkseo 8 Jul 2021, 11:42 -
RFM95W sleep() directly after send() often doesn't sleep radio
Bug Reports • 1 Jan 2023, 18:41 • prawnpie 8 Jan 2023, 05:36 -
ESP32 + Signing fails after xxx msg as result of memory leak
Bug Reports • 6 Apr 2020, 18:43 • Technovation 7 Mar 2022, 10:37