RFM69 library and Moteino R3

This is the library that I’ve been working on for the new RFM69 modules from HopeRF. I consider this an initial beta release and it surely is a work in progress, it may contain bugs, but the provided Gateway and Node examples should work out of the box and illustrate basic usage. Please let me know if you find issues. The syntax is a little similar to that of the RFM12B library, but I went with some new conventions on naming and overall structure to improve readability and overall code quality.

This is a video introduction to Moteino R3:

This is a new product and the library needs more testing and performance tuning. The library currently is tuned for fixed 433/868/915 Mhz frequencies, and a 50khz bitrate, 50khz frequency deviation. I am hoping others will contribute and test the library to find the best combination of these settings and power level vs range vs frequency vs bitrate, etc.

Here’s a comparison between RFM12B and RFM69:


Among others, this is a set of features implemented in this library:

  • easy to use API with a few simple functions for basic usage
  • 255 possible nodes on 256 possible networks
  • 61 bytes max message length (limited to 61 to support AES hardware encryption)
  • customizable transmit power (32 levels) for low-power transmission control
  • sleep function for power saving
  • automatic ACKs with the sendWithRetry() function
  • hardware 128bit AES encryption
  • hardware preamble, synch recognition and CRC check
  • digital RSSI can be read at any time with readRSSI()
  • other features like frequency hopping can be achieved by extending the library
  • interrupt driven
  • tested on Moteino R3 (ATMega328p) – see my other posts and youtube videos
  • works with RFM69W and RFM69HW, Semtech SX1231/SX1231H transceivers
  • promiscuous mode allows any node to listen to any packet on same network
  • The source code and examples are on GitHub: RFM69 Library


Promiscuous mode is a very desirable feature, to be able to listen to any packets on the same network. A decision was made to not use the hardware address filtering because promiscuous mode would not be possible while using AES encryption (hardware would automatically filter out packets with different addresses after decryption). RFM69 modules support packets 255bytes long, or even unlimited, however since AES hardware encryption must have all 64 encryptable bytes before encryption engine can do it’s work, this library was limited to 65 bytes total payload, including a 4 header bytes. The payload length is automatically controlled by hardware and is not encrypted. Only the DestID, SenderID and CTL bytes are encrypted. Hence 61 other encryptable bytes remain for data. This is more than sufficient for most situations and longer packets are not always desirable for several reasons but mainly longer packets take longer to transmit and increase the chance for collisions and interference/errors, and also longer packets will need larger RAM buffers to hold the received data. Longer packets can easily be achieved by chaining while retaining all of the desirable hardware features this transceiver has to offer.

25 thoughts on “RFM69 library and Moteino R3

  1. Wow, that was fast! Is the R3 size any different? I’ve been thinking of getting some RFM69W to keep up. I would love to test and help dev.

  2. Do you find the interrupts strange on the 69? I bought a bunch (to get a good price) to replace the rfm12 in a fairly new design, and have only put minimal time into my library so far, but it seems odd there are a ton of interrupt pins, rather than one, and then just check the status register to see what interrupt happened. I’m interested in looking at your code to see how you handled the interrupts. I think I could probably get away with only one pin, for Payload Available, and TX complete. In general, the design seems very strange to me.

    • Yes they are a bit unusual. But that could be a nice feature actually, it offers more granularity when you need it, I don’t mind all the interrupts. I only use 1 interrupt as before, for essential events, so nothing really changed.

    • It’s hard to put numbers to it. I tested it in a large 3 level building and I could find no spot with lost reception. Good enough? RFM12B performs OK in the same situation, but has spots where it doesn’t reach. It probably performs well in larger buildings. A user reported testing it at his home office and getting 300m+ from a transmitter that was taken away down the street.

      • That’s good enough numbers 🙂 I know it’s hard to put in numbers, but some numbers for an idea is enough for me :), Thanks!

        And btw, awesome job on these.

  3. Great work! Was considering using this in my project but couldn’t find a library until today. I spoke with a HopeRF sales rep recently and she told me the unit price for large quantities (>1Kpcs) of these is significantly lower than RFM-12B.

  4. Received shipment quick and well packed. After a short while soldering and getting the libraries in place, my first tests show good transmission even at 50m through 3 thick granite walls. Good so far.

    [ Had a false start where a bad USB cable seemed to be missing proper ground: reception would only work when touching the aerial. Works fine with different USB cable ]

    • Chris – good to hear, I believe you’re the one suggesting some fixes on github, good cathes, thanks for submitting those

  5. Well, I have ordered a few and I will be using your library as I cannot write one of my own… so will keep you posted.. let’s first hope that I get em soon enough..

  6. Hi Felix,
    Really nice job on this ! Do you know when the 868 Mhz version of the Moteino R3 will be available ? I am waiting for it… 😉

    • Not sure yet, might be in the future. For now you can use 915mhz units and run them at 868, they might be a few percent less range than those hardware tuned to 868. From signal strenght tests I could only see a signal degradation of 1-2dBm. For testing purposes they will run at 868mhz without an issue. The RF chips are the same and most of the BOM are the same, with a few minor different values, so it’s really up to software on how you use them.

  7. Felix, Since I ordered 4 Motenio’s a while back, and I am about to order 5 more, I am going to order two of the R3 with the RFM69’s to see how they play with the R2 Motenio’s and their RFM12B modules. I will let you know how things work out. Thanks for all your work with the Moteino’s. Such a great product.
    — Mike

  8. Hey, a couple of really simple questions:
    a) is the RFM69W FCC certified? The RFM22B modules are not, meaning you need to go back and get certs on your design. The data sheet seemed to skate this a bit, wondered if you knew?
    b) wouldn’t happen to have an eagle part library for it, would you?
    Really great stuff, looking forward to working with it…

  9. Hi Felix. Is there any chance that you can post some more code examples on the GitHub website. I’m having a hard time navigating through the Gateway/Node code you provided.

    Thanks in advance!

    • I have a bunch of other beta code that I am testing and using to improve the library but nothing is real solid right now so I’d rather not share and create more confusion at this moment. I am hoping to make good progress in the following weeks and post more code. Thanks

  10. Very nice work with all of this!

    How do you find the RSSI readability, and do you know how long readRSSI() takes to execute?

    The current project I am working on involves rfm12b’s, and heavily relies on reading the analog RSSI pin 6-8 times per byte _while_ bits are incoming, to estimate distance to other moving nodes.

    The transmit power on these things is extremely impressive… but the digital rssi might be a letdown, if it’s not as responsive/accessible as the rfm12b’s for a packet currently in progress.

    I manage 230-250 meters open-air with rfm12b’s & simple wire-monopole antennas as it is, so boosting that with these would be a dream.

    • RSSI reading is almost instant. It’s reading a register, so transferring 2 SPI bytes. It should be read as soon as you got a packet. I read it manually after the packet is dumped from the transceiver, so it might be slightly late, but you can always add a variable in the library that is read from the transceiver as soon as the reception flag is TRUE.
      I’ve gotten 350m in open air with the RFM69W, HW should be more. Working on getting that range extended MUCH futher 🙂

      • Hmm, this is very good to know, I’ve ordered four and will get to play with them soon ;p

        Thanks for the info, what’s the value ranges of the RSSI? I managed to oversample the rfm12b’s analog 180-220 up to 2500-3600 for more granular proximity estimation, I’m hoping the rfm69’s gives me enough granularity there too!

        • RSSI is only available on the RFM12B from an analog pin that is not broken out except you have to solder to it.
          On the RFM69 it’s a register that you read and calculate it from a formula. Basically anywhere between -100 to -10dBm.

  11. Just received a handful of these modules and have the example sketches ticking over nicely 🙂

    Will start porting the code I used for the rfm12b transponder range tests with the RFM69 library’s functions.

    Quick question about your example sketches, what are the SPI flash functions all about? I had to disable them meanwhile, since they all gave “does not specify a type” errors whenever they were used.

    Do these refer to flash chips that were only present in your environment, or is this some kind of flash memory available for settings on the RFM69 modules?

    • The SPIFlash is a library is for the chips that come optional with Moteinos. The library is in my github repo. You can strip all that out if you’re not using the FLASH chips.

  12. Pingback: FCC Part 15 RF Spectrum Compliance | GorillaBuilderzGorillaBuilderz

Comments are closed.