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


@benbarnard I don’t and haven’t looked at it. I use to just work in the Arduino IDE when I used the RFM module. Since then I have switched to Visual Studio with Visual Micro extension for Arduino based development.


Update: The other Photon came in - it turns out that I’d wired the original Photon loosely somewhere (to the RFM69 breakout) to cause the failure. I now have two Moteinos communicated successfully with the Photons and am I working on modifying the example code to accommodate the sensor data I need. Thank you again for your advice. One last thing - what microcontroller platform are you using with those anaren modules? I have some commercial ideas too and had no idea that FCC certification was such a headache. Visual Micro looks fantastic.


Happy to hear @benbarnard! Few things as frustrating as a hardware wiring issue to waste your time with software. I’m using the Anaren radios with Arduino sensors and Photon controllers.


I have been a Moteino fan for several years. I have also integrated RFM69H and HW radios into both the Photon and ESP32. They work great for creating networks with both wireless access and large numbers of RF sensors. The library mentioned above worked without issue and the wiring is straightforward once you see it. The only issue I had going between Moteino’s and Photons using the RFM69 radio was that I had to surround my structures on the Photon side for any wireless packets with the following:

#pragma pack(push, 2)
#pragma pack(pop)

Once I did that, data flows like wine.


Fabien - were you ever able to figure this out (3rd Gen -> RFM69)?

I’ve been working on just connecting an Arduino + RFM69 and taking the messages from that and forwarding them through a serial connection to my Boron. It’s a silly way to sidestep the issue, but it doesn’t add to the footprint so much that it’s a problem for me. Really need the LTE.


I could compile the library but my application was not working. I was trying to read data send by an emonTx. I couldn’t get the data so I read it from the UART and publish it trough an Argon. It’s a bit dirty but it works.

I didn’t try with bloukingfisher latest library since the new version does not appear in the Particle Web IDE and I didn’t take the time to compile it locally.


@Fabien I’ve updated the library to version 0.0.3 in Github. I’m assuming on some schedule Particle will pull in that version on for the Web IDE. I’ve lost track of the library process so if I need to do something to push it into the Web IDE let me know.


Nope, revisions are never pulled in automatically. You need to reupload it via particle library upload and particle library publish.


@Fabien I’ve published the updated RFM69 v0.0.3 library for the Web IDE. Thanks @ScruffR, I keep forgetting the processes with libraries as you can tell. I had to convert it from V1.


Super excited that you took another look! Here’s my attempt.
I started with this message when trying to compile the new version, after which I removed the “RFM69-Particle/” from the prefix of the includes
hello-photon-rx-rfm69.ino:1:43: RFM69-Particle/RFM69-Particle.h: No such file or directory
I then commented out the Wifi line for my second compilation error (I’m on a Boron). And I ended on this one:
lib/RFM69-Particle/RFM69-Particle.cpp:501:64: 'A6' was not declared in this scope
Just providing feedback - if I’m doing something stupid, please let me know.


@bloukingfisher, with Libraries 2.0 the library folder is not required in the #include statement anymore, but if you “want” to stay consistent with the legacy syntax, you can add a subfolder ./src/RFM69-Particle and add a “stub” header file that in turn includes the correct header.

#include "../RFM69-Particle.h"

Also the check whether a pin is interrupt enabled should be changed to cater for all Particle devices
This is only true for Spark Core

    if ( (newIRQ>=D0 && newIRQ<=D4 ) || (newIRQ>=A0 && newIRQ<=A6 && newIRQ!=A2) )

I would even put the responsibility to pick an interrupt enabled pin entirely onto the user but use the return value of attachInterrupt() inside of RFM69::initialize() to return an error condition (with a clarifying comment about possibly picking a wrong pin).

BTW, you may want to change #if defined(SPARK) to #if defined(PARTICLE) and #include "application.h" to #include "Particle.h".


@ScruffR will this be sufficient?

  #elif defined(PARTICLE)
    // For Photon interrupt pins see:
    // D5, D6, D7, A2, WKP, TX, RX ,D1, A4, D2, A0, A3, D3, DAC, D4, A1
    // Pins that cannot be used (Photon/Electron/P1): D0, A5, D7, C1, C2
    //"All A and D pins (including TX, RX, and SPI) on Gen 3 (mesh) devices can be used for interrupts"
    //Original that worked for Photon: if ( (newIRQ>=D0 && newIRQ<=D4 ) || (newIRQ>=A0 && newIRQ<=A6 && newIRQ!=A2) )
    //Set the pins to what the user specified
      _interruptPin = newIRQ;
      _interruptNum = _interruptPin;

    //Alert the user if the pins MAY not be interruptable
	  if !((newIRQ >= D1 && newIRQ <= D4) || (newIRQ >= A0 && newIRQ <= A4 && newIRQ != A2))
       #error WARNING Confirm RFM69 is using an interrupt pin for IRQ


That #error directive would be processed at compile-time while the condition would be tested at run-time, so there is some logic inconsistency.

I’d just drop that pin check completely but add

  // picking an non-interrupt enabled pin will prevent proper initialization
  if (!attachInterrupt(_interruptNum, RFM69::isr0, RISING)) return false;

in RFM69:initialize().


@benbarnard Thanks for the feedback, can you test now again? @ScruffR was instrumental in identifying a number of items. The part about A6 has now been changed up. You need to make sure you connect IRQ to an interruptable pin (A6 should be fine from the docs). Not all the pins are the same across Particle devices so that caused some issues for users.


I loaded the new .5 version, brought up the RX example, tried to flash and got this:

hello-photon-rx-rfm69.ino:1:28: RFM69-Particle.h: No such file or directory


This could be a known issue with Web IDE.
Try changing the include statement to either use <....> instead of "...." or vice versa.
That sometimes helps.


ScruffR was right about the <> vs “”. That fixed it. It looks like it compiled and flashed successfully. I grabbed a proton to use the TX sketch and I’m not getting anything on the receiving Boron (just “…”) on the serial console. I have the interrupt tied to D2 on the Boron per the sketch default (I didn’t change a thing except the includes and commenting out the wifi line) - I’m under the impression that D2 is interruptable on the Boron, right? I’ll keep playing with it.


I can’t tell for sure from the datasheet. Not a definitive answer but you could try D4 on the basis it’s the interrupt pin for ethernet. Plus, with .5 you should get a message that initialization failed if you picked a non-interruptable pin.

First, my advice is always to first confirm you can do Photon to Photon TX/RX because that’s solidly proven and doesn’t introduce variables of different pins, additional onboard radios, etc. That way you can confirm that your radios are wired correctly, the power supply is sufficient (the radio can draw up to 130 mA during transmission), correct antenna, etc.

At the end of your setup throw in a radio.printDetails(); for both transmitter and receiving side and see on the serial if anything is amiss.

#define RFM69_IRQ     4
#define RFM69_IRQN    4 //On Photon it is the same unlike Arduino

Should RFM69_IRQN follow the convention for Photon? I’m Googling this but not finding anything.

Also - Photon to Photon is working correctly as expected with the .5 version (watching the messages come through right now). Just having trouble with the Boron.


hello-photon-rx-rfm69.ino:119:9: 'class RFM69' has no member named 'printDetails'


For all Particle devices the IRQ-number is the same as the pin number - however, we encourage people not to use anonymous pin numbers but rather use the pin labels (e.g. D4 instead of 4).