How to make RFM69 work on Photon? [SOLVED - new library RFM69-Particle]


Sorry about that. I am trying to keep this all organized. Regardless, I am back working again. [quote=“bloukingfisher, post:60, topic:26497”]
So it looks like the RX is receiving everything? And it also returns an ACK so the TX should know that the message went through

Yes, I would agree. I am confused by Failed to Send on the TX side. What is that telling me? Why am I only getting occasional Ok, send with retry? Again, what is that telling me?

I made the changes to the RX code, flashed it and no real difference that I see. Here is a copy of RX serial and you can see where I reset the TX board

and here is the TX serial

Thanks for the link BTW Ill start reading it


I see. Perplexing.

I would (in addition to reading the link):

  1. Again, swap the RX and TX hardware. It looks like the TX side is having an issue with receiving, but yet sending fine. You want to test and make sure both can units can receive equally well.

  2. Add code to the TX side to print out the RSSI of the ACK that it seems to receive 1/10 times. The RSSI strength should very closely match the RSSI the RX is reporting. But if it is much lower (say RX reports -52 or -86 and TX reports -96 or -110) it’s telling you the TX unit is not receiving the way it should.


Well this is getting a bit above me but here is what I attepted with adding the RSSI portion to the TX code

void loop() {

  Serial.print("."); //THis gives us a neat visual indication of time between messages received

  char radiopacket[20] = "Hello Photon #";
  itoa(packetnum++, radiopacket+13, 10);
  Serial.print("Sending "); Serial.println(radiopacket);
  //send the message
    // Uncomment below and comment out above if you want to send with retry (which will look for an ACK message or resends)
    if (radio.sendWithRetry(RECEIVER, radiopacket, strlen(radiopacket))) { //target node Id, message as string or byte array, message length
     Serial.println("OK, sent with retry");
      Serial.println("Failed to send");  
    //send message to Particle console if not using serial
    String TXMessage = "[NODE: " + String(NODEID) + "]  " + String(radiopacket) + " ";
    Particle.publish("Message transmitted",TXMessage,360,PRIVATE);    
    radio.receiveDone(); //put radio in RX mode
      //print message received to serial
    Serial.println(" ");
    Serial.print('[');Serial.print(radio.SENDERID);Serial.print("] ");
    Serial.print("   [RX_RSSI:");Serial.print(radio.RSSI);Serial.print("]");
    //send message to Particle console if not using serial
    String RXMessage = "[" + String(radio.SENDERID) + "]  " + String((char*)radio.DATA) + " [RSSI: " + String(radio.RSSI) + "]";
    Particle.publish("Message received",RXMessage,360,PRIVATE);

  delay(2000);  //wait 2 seconds between transmits

} //end loop

If that is correct, then my TX board is not RX at all because I am seeing [RX_RSSI:0]

Changed roles on the hardware and the results are the same.
Thank you


OK, with hardware swapped with the same result that minimizes a hardware issue.

Because with failed to send you never received an ACK you also will not have an RSSI, thus the 0. You will need to look for the odd “OK, sent with retry” to see if it reports the RSSI.

Maybe try the example code from the Sparkfun link (with the correct #include for particle libraries), or example code from RadioHead examples. I know the code worked for me (primarily on non-HW versions, although I briefly tested 1 HW unit on the TX side but may not have used sendWithRetry).

Do me a favor if you can - comment out all the particle publish lines from both RX and TX and test again.


Ah, makes sense

Ill do it and let you know]


results are the same. RX_RSSI:-82, TX_RSSI:0


I’m not sure where to go other than starting with the RadioHead or Sparkfun examples.

You can try lastRssi() instead - but still, you need to receive at least one message to obtain the value.


Ok, well thanks again for your help


I changed the delay in the last line of the TX code to this

delay(300);  //wait 2 seconds between transmits

and have now achieved more reliable “Ok,sent with retry” results. Still no RSSI though :tired_face:


The RFM95w radio modules are working if you want something that works now :slight_smile:


My lack of getting radio modules to work is taking me up the ladder to increasingly more expensive modules! Do you have a link to an RFM95w you would recoomend? The other to note is that I would eventlually like to run these radios on a system that uses an Electron with xyz radio as a server and up to 6 pro mini’s with xyz radio as nodes. Cost is important of course but making a reliable system is also important
Thanks @RWB


There are tons of different RFM95w Radios or Radios + Processors that you can pick from. Adafruit carries all you would need.

Here is the thread with the info you need to get them working.


Hi @bloukingfisher
I tried to compile RFM69-PARTICLE for a Xenon with OS 1.1.0 and it fails:

lib/RFM69-Particle/RFM69-Particle.cpp:501:64: ‘A7’ was not declared in this scope

However it is compiling with OS 0.9.0.
It is also compiling with OS 1.1.0 on a Photon.

Do you have any idea what are the changes in 1.1.0 impacting your library?


Not really a surprise that this throws an error since there actually is no A7 pin on Gen3 devcies.
The fact that it was compiling on 0.9.0 just shows that the non-existend pin was nevertheless “defined” which now got corrected.

This is the code part in question which should be filed as a GitHub issue in the library repository

  #elif defined(SPARK)
    // IRQ authorized on spark core are
    // D0, D1, D2, D3, D4, A0, A1, A3, A4, A5, A6, A7
    // see
    if ( (newIRQ>=D0 && newIRQ<=D4 ) || (newIRQ>=A0 && newIRQ<=A7 && newIRQ!=A2) )
      _interruptPin = newIRQ;
      _interruptNum = _interruptPin;

The list of interrupt capable pins needs to be adapted for all platforms. As is it only is valid for the Spark Core (Gen1).


Thanks. I modified manually the library, and it compiles.
However the board initialisation fails and return FALSE. I can successfully read the registers using the library RFM69::readAllRegs() and they are all to default value. It seems I can’t write, but I can read. I wonder if I missed something.

For more context, I am trying to read the RF messages send by an EmonTX from a Xenon, through an RFM69HCW.


I’ve updated that code in the repository. Thanks @ScruffR for determining that. I’ve not tested the change or worked with this hardware for a long time so unfortunately can’t be of more help @Fabien


I apologize for even asking, being that you’re saying that you haven’t been using the hardware in some time (I’m interested in what you moved on to), but do you remember which version of the Lowpowerlab arduino library you were using when you had success on post #16? I have really struggled and have tried multiple platforms (Uno, Pro Mini, even Moteino) and none have successfully sent a message to my Photon (running the hello-photon-rx-rfm69 example).

My use case requires wireless battery-powered sensors and I’m just exhausted with trying to figure this out.


I don’t think there’s a library version number from Lowpowerlab. However, what was working for Photon is in my repository.

Have you tested Photon to Photon transmission/receive? That will at least confirm that your radios are wired up correctly and code is working between the 2 photons.

Also, check troubleshooting tips in my earlier post about power settings, etc.

The version of the RFM-69 library in my arduino folder you can download from here. The Arduino side of the code I posted before.

But I would first try to make sure you can do Photon to Photon. Plus, Felix and the community have updated that library significantly in the interim so for the Arduino side I would try the latest before falling back on this version (or try this and if it works, switch to the latest version…)

Also, post your serial output or other troubleshooting information which would make it easier to suggest approaches to get it working.


@benbarnard FYI I moved onto an Anaren module which is FCC certified. It is 5X the cost of RFM69 but incorporating it in my commercial planned product saves future hassle around FCC certification.


I actually only own one Photon, so I will order a second to confirm that the wiring is correct. I’m positive I’ll find a use for it anyway. I will start over with your advice and report back - again, thank you for being so generous with your time.

Anaren looks very interesting! Do you use this Atmosphere IDE that I’m seeing? Looks very different than Arduino.