search

jgromes / RadioLib

Universal wireless communication library for embedded devices
https://jgromes.github.io/RadioLib/
MIT License
1.54k stars 384 forks source link

[RF69] (aka RFM69) truncates last Bit in TX process. Fix included. #805

Closed ramaza closed 1 year ago

ramaza commented 1 year ago

I'm testing Adafruit Feather M0 boards which consists of Atmel SAMD21 microcontroller and HopeRF RFM69HCW radio. My goal is a communication between two such boards at a bitrate of 1200bps.

The issue is that not every packet gets through without corruption. I tried the same FSK settings of 1200bps with the RF69 library from https://github.com/lowpowerlab where the problem never happened. With the help of an SDR and a FSK demodulator the problem became obvious. During transmission the very last bit is truncated to about half of its original symbol length. Accordingly this last bit can no longer be sampled reliably by the receiver. The packet error rate was roughly 10% to 20%.

After many hours of investigation the fix for this bug seems quite clear. According to the datasheet from HopeRF this lines in RF69.h

#define RADIOLIB_RF69_SEQUENCER_OFF                             0b00000000
#define RADIOLIB_RF69_SEQUENCER_ON                              0b10000000

should be

#define RADIOLIB_RF69_SEQUENCER_OFF                             0b10000000
#define RADIOLIB_RF69_SEQUENCER_ON                              0b00000000

I'm wondering why nobody so far took notice of this severe issue. My explanation is that with a significantly slower MCU than this 48MHz Cortex M0 it might not happen. After all an artificial delay of a few hundred microseconds at the right place in the code is enough and the last bit is no longer truncated. With a higher bitrate than 1200bps it might also not happen because the symbol time is anyway shorter.

jgromes commented 1 year ago

Thanks for figuring this out! Would you be willing to send a pull request to fix this?

ramaza commented 1 year ago

I will send a pull request. There's one or two other things in the code for RF69 that caught my attention while debugging this problem. Like overwriting ALL interrupt flags to clear them although only a few interrupt flags support this with RF69. Should I create separate issue?

jgromes commented 1 year ago

Yes please, if there's something else create new issue(s). It's possible that there are more copy/paste errors (as was the likely case for the sequencer configuration).