Thanks! I am reading that code now and trying to understand the state machine. I got stuck on a couple things.

// checks if a packet was received and/or puts transceiver in receive (ie RX or listen) mode
bool RFM69::receiveDone() {

Does “packet was received” mean a packet inbound from the airwaves? Or a packet inbound from the SPI bus?

Similarly, does RF69_MODE_RX imply that the transceiver is receiving from the SPI bus or the airwaves?

This is good to know. I have now been able to test an ATMega328 with no connection from D2/INT0 to IRQ on the transceiver, and confirm that it works.

This also makes me think that I’m on the wrong track trying to get the AVR128DB28 working with the RFM69_LPL OEM fork. I now understand the interrupts are not coming from an external pin connection. Also, nothing in the polling-style state machine code looks specific to the 48-pin part – at least not to me. So last question is: any other areas of the code you’d suggest I look at?

Further update: Is there any reason that RFM69_LPL would be more sensitive to wiring than JeeLib? Here’s why I ask. It is always difficult to know with these transceivers if the problem is the breadboard/Dupont wiring. They are very sensitive to it. As a sanity check I did the following.

  1. Start with my known-to-work Uno shield and a known-to-work JeeLib test sketch. Confirmed. Working.
  2. Move the shield off the Uno and connect the shield to the Uno using male-female Dupont wire. This didn’t work.
  3. Use some higher-quality, slightly shorter, Dupont wires to do the same thing. I got four of these from the LowPowerLab shop. This worked. So we know that (a) the transceiver+Uno+JeeLib is working through this wiring and (b) the quality of the wiring makes a difference, but slightly better wiring is good enough.
  4. Switch the sketch in the Uno to my RFM69_LPL test sketch. Make sure to power down the radio long enough to reset the registers. This did not work. Is it the wiring or the sketch?
  5. Put the transceiver shield back on the Uno, directly mounted with the headers. This worked. So it was not the sketch, it was the wiring.

(I made the shield used in this test because I am so sick of wiring being the problem when testing and prototyping with these transceivers. But I don’t have a shield (or even a breakout board for the MCU) for the AVR128DB28.)

Back to my question. Tests (3) and (4) had identical wiring and JeeLib worked. So is JeeLib more resilient in the face of operating on a breadboard, with all the challenges that brings?