RFM69 + RadioHead issue

Not open for further replies.


Well-known member

I'm trying to make 2 Teensy LC communicate using the RFM69 chip (using the Sparkfun breakout board): https://www.sparkfun.com/products/12775

I was able to have the 2 libraries communicate but as soon as I'm 6-12 inches away I seem to start loosing a lot of packets. I'm using the examples from the RadioHead Library (client and server).

Any ideas what could be wrong ?

Hmm. I've used many RFM69s and with just short-wire antennas and they provide 100m+ non-line-of-sight in 433MHz, and about 25% less in 900MHz band.
Not using the sparkfun board, but rather, I used the RFM68 version, with radio+Arduino-compatible microprocessor+RealTimeClock+SPI flash data memory, on one board:

Some possibilities
  • 3v3 Power source inadequate current capability ... these boards take many tens of mA in transmit mode (you can't see that current spike on a multi-meter).
  • 1/4 wavelength wire antenna correct
  • DIO lines on radio module connected correctly: there are jumpers on the DIO lines that control the antenna transmit/receive switch chip on the board. If these aren't right, the receiver will not be switch to the antenna and the range will be inches. The RADIO's DIO outputs control the switches. The mating microprocessor does not. I've seen this done incorrectly.

Someone on the radiohead forum might be using that sparkfun board.

I couldn't find a schematic for Sparkfun's breakout board to verify the above.
Last edited:
I've been playing with the settings for the Radiohead library but I'm not sure what would be the best.
My application is that I want someone to press a button on one of the unit and receive the signal on a computer with the less latency possible. Any suggestions on which settings should be best for that use case ? (low data, low latency) thanks !
The RFM69 and Radiohead are a big overkiull for the app you describe, but being two-way, and having the option in Radiohead for reliable datagrams (ACK w/retransmission), allows that button-push to be assured of receipt.

Low latency, like what?
Narrower the channel width (channel bandwidth), the less chance of errors, some of which radiohead will correct with retransmission (if you use reliable datagrams). Narrowed channel bandwidth leads to lower data rate (bps) which gives longer latency due to the transmission time. But your message is just a byte or two, plus the radiohead packet header. So we're talking maybe 10mSec of latency.

You can config the radio to use less that full TX power and perhaps get down to < 100mA.
Anything under 50ms should be fine. I just figured I will need it to be bi-directional too so perhaps it's not that overkill. I'll need to be able to send a message from the computer to the device too.
I monitored the server sketch instead of the client and the server seems to receive more reliably, it's the answer that the server sends back to the client that doesn't seem to be reliable for some reason.
Reverse how the radios are placed and connected to see if the problem follows the radio hardware or if not, the problem is the software and how it configs the radio
Reverse how the radios are placed and connected to see if the problem follows the radio hardware or if not, the problem is the software and how it configs the radio

Indeed, I swapped the radios and if I put the 2 radios next to each other I get an RSSI of -55 on the server, if I re-swap I get an rssi of 0 on the server...
Does this mean the radio is broken or is there something else I could check ?
Not open for further replies.