Can RFM12B talk to RFM69?

I was asked this question a lot of times. Didn’t have a clear answer because in my early attempts to make them talk to each other I didn’t have success. I didn’t spend a lot of time on that since my interest has leaned towards RFM69 transceivers since they are much nicer and feature-rich overall (nicer packet engine, hardware AES encryption, digital RSSI etc).

Forum user timw has forked my RFM12B and RFM69 libraries and modded them to make them compatible, see this forum post for details. Turns out these mods makes communication possible between RFM12B and RFM69 transceivers. This is great news!

I was able to load his version of the libraries in my Arduino/libraries folder (I had to move/remove my original libraries because of conflicts), and using the examples that come with the two libraries (Struct_receive example on the RFM69 side, and Struct_send on the RFM12B side) I was able to see data coming through the RFM69 end. Seems very stable too. The signal strength (RSSI) fluctuates a little more than if I had RFM69 radios on both ends but it’s great to actually see a signal strength for a RFM12B transmitter:

The caveat is that the encryption must be turned off on both ends with the current version of the libraries. That’s because RFM69 uses hardware AES encryption and RFM12B does not support hadware encryption but uses a software XXTEA algorithm instead. The two are not compatible. One workaround would be to port/duplicate the XXTEA encryption on the RFM69 side, probably a little slower but worth it if encryption is important.

So anyway this should help folks that are trying to salvage their RFM12B nodes and make use of them while moving towards RFM69 based nodes. For me personally I will likely just upgrade everything to RFM69 moving forward but still this is a great development. Thanks timw for sharing your work!

Temperature and RC-Calibration for RFM69

I added two new functions to the RFM69 library: readTemperature() and rcCalibration(). Thanks to John for contributing.

  • readTemperature() function reads the internal CMOS 8bit temperature value, it’s fairly useful for situations where temperature varies a lot and RC calibration would be needed.
    The Gateway example has been updated to reflect its usage.
  • rcCalibration() will trigger a calibration of the internal RC oscillator. This is automatically performed at power-up according to the Semtech SX1231 datasheet section 4.3.5. But it can be triggered with this new function, as John has mentioned in the forum that when temperature changes, the RC oscillator will be affected, and a dramatic temperature shift will result in a frequency shift as well, causing a link to possibly be broken (for instance when your receiver is inside your house at room temperature and the transmitter is outside in bitter cold winter).

With the combination of these two functions, you can now recalibrate the RC based on temperature change, and also report a rough ballpark of what the temperature is. If you need more accuracy, a separate temperature sensor like the DS18B20 should be used.

 

RFM69HW transceiver now available

Finally it’s here, the high power version of the RFM69W FSK transceiver is now available in the store!

This is a relatively new transceiver from HopeRF, suggested replacement for RFM12B, RFM22B going forward. Some rumors have gone around that those transceivers might be phased out, but HopeRF has told me there are no such plans, however they do “recommend the RFM69 in place of RFM12B/RFM22B for new designs”.

Based on my range tests, and on some feedback, these might be an ideal RF platform for RC controlled drones, even the RFM69W should give you a pretty long range, especially in open air.

RFM69HW

The RFM69HW is a 20dBm output power transceiver. In my open-air range tests I ran out of space at around 370m with this one. So potentially these will go significantly farther. The tests were done with my Gateway/Node example sketches, at 55.5kbps air bitrate, 50khz frequency deviation. If someone has better results with other settings please let me know.

They are powerful but will need more current to work, 130mA in transmit mode (for a short few milliseconds while the packet is modulated/transmitted), and the same 16mA in receive mode. So far the Moteinos in their current configuration seem to handle the high current spikes just fine.

HopeRF has suggested that 868Mhz units can be replaced with 915Mhz units that are loaded with 868Mhz settings. I have verified this myself with range tests and I don’t see any significant difference when using 915Mhz units at 868Mhz. Hence if you need 868Mhz units please get 915Mhz units and initialize them with settings for 868Mhz.

Wireless programming Moteino R3

It works!

The last few weeks I have spent a lot of time tweaking the RFM69 library and trying to get the wireless programming to work. I believe the RFM69 library is now more stable and ready for some prime time and also the wireless programming is working nicely for Moteino R3. If you think about it, being able to reprogram a mote that is 200m away, or somewhere in a tree, underground, in your attic, or on the bottom of your pool, is a pretty cool thing.

I reorganized the Github repository a little, moved some files and now the classes for wireless programming are in their own repository to avoid conflicts with the SPIFlash lib:

https://github.com/LowPowerLab/WirelessProgramming

If you have a Moteino R3 (or R2) with the onboard FLASH chip, you are ready to try programming it wirelessly, go ahead, it’s pretty neat.

The examples for Moteino R2 and R3 are in the directories for their libraries: RFM12B and RFM69.

More great stuff is coming, I got a lot of ideas for Moteino R3, I am thinking of migrating my home wireless sensor network to R3 and implementing a lot more home automation on these.

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.

Continue reading →