RFM69HW RSSI reads wrong values

[fgomes]

I've just assembled 2 boards with RFM69HW (my previous ones have the RFM12B transceiver), and I'm observing a strange behaviour. I've flashed the 2 nodes with the node and gateway example from the library, changed to 868MHz (my RFM69HW are 868MHz) and uncommented the radio.setHighPower methode in the setup. What I found is that if I power only the node, it is always transmitting (seems ok), but if I power also the gateway, the node starts transmitting very slowly, the gateways sees the messages and acks them, but the node seems that losts the acks. After some debugging I found that if the gateway answers to the node (acking the message), after that the RSSI that the nodes sees is high (between -67db and -68db), so the node doens't transmit because it thinks that is  a carrier present, but it keeps reading this high RSSI value for more than 20 seconds, even if I disconnect the gateway! After more than 20 seconds it finally reads a low RSSI (between -104 and -106dB), and then is able to transmit again. Any idea of what could be the problem? It seems the RFM module gets in a strange state, reading the wrong RSSI value for a long time...

Thanks in advance

Fernando

Edit:

For the missing Acks, it was just a question of time, the example uses 15ms for timeout, after some tests I found that the ack arrives about 35ms after the message sent, so I have enlarged the ack timeout to 50ms.

I also noticed that the RSSI level in the messages received on the two nodes is very different, the gateway node report always an RSSI of about -27dB, and the node reports an RSSI of about -5 to -7dB. Both nodes are placed side by side, less than 10 cm from each other, is there any explanation for it? This link should be almost symmetrical, apart from some RF differences between modules and antennas, but that shouldn't explain more than 20dB difference.

[Felix]

Fernando, can you try getting the latest source for the library, I made some changes which might affect the ACK time.

[fgomes]

Hi Felix, thanks for your feedback. With the new library I had also to enlarge the retryWaitTime to 50 in the RFM69.h in order to make it work, with 30 it didn't get the ACKs. Is there any reason for needing a bigger timeout than you have in the library?
I'll let the system here running over night, tomorrow I'll have some statistics for the number of failures.

Fernando

[Felix]

30ms should be sufficient for short ACKs. If you send ACKs with a large payload then it takes longer to transmit those packets.

[fgomes]

Hi Felix, thanks for your message. I'm using the standard code for the node and gateway example, so there is no data associated with the ACK, the gateway simply calls radio.sendACK(), but I'm observing more than 30ms for the round trip time in the sending node, I've configured the timeout to 50ms and it is working.

Other issues I've observed:

- I left the system (2 nodes) running during the night, and after more than 80.000 messages sent by the node I've found that 12 messages completely failed (even with the retries). Since I've replaced the library for the new one, I've lost the debugging messages that I've added to the previous library version, so i'm not seeing the retries in the console, just the final failure after the retries. So 12 in 80.000 is not bad but it could not indicate the real failure rate since there could be many retries in the background that I'm not seeing.

- Observing the ACK TEST that the gateway make to the node (without retries) could be a better way to evaluate the message failure rate, for this I have around 28.000 ACK TEST messages, and I have 1820 failures, more than 6% failure rate, for two nodes that are side by side. This seems a bit high to me, do you have any idea of the typical failure rate for this scenario?

- When lowering the retryWaitTime to 30ms (acks failed because they arrive after the timeout) I have the problem I described first, the RSSI level seems to get stucked at about -67dB / -68dB for about 20 seconds, so the node don't transmit during that time because it thinks that there is a carrier present. This RSSI is stuck at that level even if I disconnect the gateway node, and have no other node in the same radio frequency (just a single node powered). This is also not the normal reception RSSI level (better than -20 dB) nor the idle level (lower than 104dB). It seems that the radio gets in some strange mode when there are some colisions, or there are some timing / racing issues.

If there are any additional test I can make to help to clarify this issues please let me know.

Fernando

[Felix]

I suspect some issues coming from some changes I made based on recommendations from some user(s). Would it be possible for you to test an earlier version of the library that I am attaching (from november 2013)?
If so please let me know if you see a difference, all other things/conditions/variables being the same. Thanks

[fgomes]

Hi Felix

Thanks for your help! Replacing the library for this older version seems to solve the problems previously reported. Even with the ack timeout at 15ms the ack doesn't take more than 3 to 5 ms to arrive. I wasn't able to reproduce the strange RSSI level until now, I'll keep on testing this version and I'll let you know if I notice some issue. Do you want me to make some specific test?

Best regards

Fernando

[Felix]

That's very interesting, thanks for providing this feedback. I think I might revert to that version. It's quite hard to test even small changes without running extensive tests. So thanks for putting the time into this. Please report back here if you have additional findings. I don't have any specific tests in mind, sounds like your tests are already doing a very good job.

[fgomes]

I've left the nodes communicating during the night, and put some debugging to detect when there are retries. After a full night I found that with this (older) library I had no message failures, but still had some retries. The number of retries were much less than with the previous version - Now I've about 1.7% of retries, with the previous library I had 6% of retries. From these retries, about 23% are second retries (so the first retry also fails 23% of the times there is a retry). The nodes are the same, and located at the same position (side by side).

Fernando

[Felix]

Ok I compiled a new version, combining that older variant with some newer changes that should not affect performance. Feel free to try this new one. In my own tests I did not see any issue, signal is strong and no lost packets. If all is well I plan to update the library with this version.