# Moving existing installation to new native RFM69 format? **URL:** \ **Category:** Hardware\ **Tags:** emontx\ **Created:** [8 December 2022 10:06 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084 "2022-12-08T10:06:02Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![whitecitadel](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/w/d26b3c/32.png) [@whitecitadel](https://community.openenergymonitor.org/u/whitecitadel)\ **Post date:** [8 December 2022 10:06 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084/1 "2022-12-08T10:06:02Z")
Ok so I have a EmonPi running successfully since 2015, with EmonTX3 sending data as well. I have read the posts from Robert on the new format, and it seems that it will allow the EmonPi to do CM like the EmonTX3? Is it as simple as flashing the EmonPi and the EmonTX over to the new RFM69 format so they can all talk to each other - is this now the default going forward? I am adding an EmonTX4 this morning, but its USB connected to the Pi and I ordered with the legacy FW anyway on it - so does not really affect the main topic of the EmonPi and EmonTX3 moving to new radio format. Stability is more important to me than the EmonPi doing CM, so if its more robust to leave it alone I will just retain the old format radio. If there are advantages to making the change I can switch over while I am doing changes. Thanks for any pointers/tips from those that have made the change. ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [8 December 2022 11:59 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084/2 "2022-12-08T11:59:11Z")
As the release post says, if you don’t want CM on your emonPi, there’s no need to change. If you do, then you must use the native message format because this allows almost all of the radio reception processing to be done inside the RFM69CW. Running emonLibCM on an emonPi with JeelIb ‘Classic’ resulted in about 15 - 20% (from memory) _ **success** _ rate for data from a single emonTx. Do you really think I’d have released the software if it didn’t work??? ---
**Author:** ![whitecitadel](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/w/d26b3c/32.png) [@whitecitadel](https://community.openenergymonitor.org/u/whitecitadel)\ **Post date:** [8 December 2022 12:36 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084/3 "2022-12-08T12:36:32Z")
Hi Robert, not questioning in anyway if it works or the quality of the implementation! I read some posts that say after reboot the FW is reset to the old version etc - but of course I am trying to absorb a few years of changes and things change over time - I guess phrased better if I write the new library format to the EmonPi and change my EmonTX’s over is this bleeding edge or now “standard”? CM on the EmonPi would be favourable, as it has the house CU and the solar on it at present. ---
**Author:** ![TrystanLea](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/trystanlea/32/31_2.png) [@TrystanLea](https://community.openenergymonitor.org/u/TrystanLea)\ **Post date:** [8 December 2022 12:55 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084/4 "2022-12-08T12:55:24Z")
Hello Paul, just a note to say that there are 3 formats, in order of date of firmware release: 1. JeeLib Classic (shipped as standard on all our units up to November this year) 2. JeeLib Native (thanks to Robert Wall, developed to enable continuous monitoring on the emonPi) 3. LowPowerLabs (latest available with the emonTx4, adopted to make use of acknowledgment and retry mechanism). Robert posted a useful comparison of these here: [Emon Tx V4 and 433MHz Radio Formats](https://community.openenergymonitor.org/t/emon-tx-v4-and-433mhz-radio-formats/22085) and there’s more on them in the docs too: [Technical Guide — OpenEnergyMonitor 0.0.1 documentation](https://docs.openenergymonitor.org/emontx4/technical.html#rfm69-radio) JeeLib Native and LowPowerLabs are very similar in that they use the RFM69 native functionality - but they are not compatible due to different settings. I will be releasing emonPi and emonTx3 firmware that works with the LowPowerLabs format soon, so I might advise waiting for that. ---
**Author:** ![whitecitadel](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/w/d26b3c/32.png) [@whitecitadel](https://community.openenergymonitor.org/u/whitecitadel)\ **Post date:** [8 December 2022 14:17 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084/5 "2022-12-08T14:17:40Z")
Ok thanks, that helps! So I have classic on my vintage emonpi, Robert’s CM firmware is with Jeelib native? And the Lowpowerlabs is just for emontx4 at present and new hw, I would not want to run that yet as there is no emontx3 fw for that radio format, I think I got it now. I will leave my EmonPi alone, I ordered my EmonTx4 from the shop with the legacy fw so it’s reporting OK to the emonpi over radio (although I will direct usb it to power the emontx4). ---
**Author:** ![Simsala](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/simsala/32/11730_2.png) [@Simsala](https://community.openenergymonitor.org/u/Simsala)\ **Post date:** [5 February 2023 10:05 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084/6 "2023-02-05T10:05:09Z")
> [@TrystanLea](#): > > I will be releasing emonPi and emonTx3 firmware that works with the LowPowerLabs format soon, so I might advise waiting for that. Hi Trystan, is there already a LPL version for the emonPi to test? I’m just setting up my system completely new after moving to a new location, so it would be nice to be able to switch everything to LowPowerLabs right away… ---
**Author:** ![alandpearson](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@alandpearson](https://community.openenergymonitor.org/u/alandpearson)\ **Post date:** [11 February 2023 20:43 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084/7 "2023-02-11T20:43:52Z")
This (LPL) is a very interesting development and very welcome. LPL has an established ecosystem and this allows integration of it with emon\*, particularly as mentioned moteino, but also STM32 (although in fairness STM32 with RFM69 native was quite an easy port already as OEM & JCW already did the groundwork). Will you also revise firmware for the older OEM devices (TH, GLCD - happy to help with that one) ? Will the emonpi firmware LPL version be based on Robert’s CM firmware ? The only downside of this for me is I have a bunch of RFM12B based devices which can’t run LPL, but could do RFM69 native, so I guess I’ll have to ‘bridge’ (should be easy enough with a USB jee node). I’ll also be interested to know does this change at all the serial protocol (historically based on JCW RFDemo )? ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [11 February 2023 21:44 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084/8 "2023-02-11T21:44:44Z")
No further work will be done by me on the RFM69 ‘native’ library. It was developed specifically to allow continuous monitoring on the emonPi (the “emonPiCM”) and sketches for all the previous emonTx and emonTH variants, including notes for converting the emonGLCD sketches, were produced. However, it was never formally adopted and the sudden appearance of LPL instead was a complete surprise. @alandpearson - you are correct about the RFM12B devices and the LPL library, but it’s probably not correct to assume that this means the RFM12B cannot transmit a radio packet conforming to the LPL data format; but I think it is probably true to say that it’s not feasible to modify or rewrite JeeLib to receive the LPL data format. See the emonPiCM release documentation in this forum for more details, which might be helpful, because it will obviously be much more economical and much more efficient to transmit in the appropriate format, rather than adding a relay in the signal chain. I think it would be a comparatively trivial exercise to convert the code for transmitting from the RFM12B in RFM69 ‘native’ format to the LPL format, data rate and frequency. Encryption would be possible - it’s included in the JeeLabs documentation - but subject to processor load and memory availability. But I shall not be embarking on that exercise. ---
**Author:** ![alandpearson](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@alandpearson](https://community.openenergymonitor.org/u/alandpearson)\ **Post date:** [11 February 2023 23:19 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084/9 "2023-02-11T23:19:44Z")
Thanks Robert, interesting points. As soon as I saw the work done to move to RFM69 native, I made the switch on my ecosystem (around 10 RFM12B and 7 or 8 OEM RFM69 devices). As you know I also made GLCD work again with the latest PHP code in emonhub. The switch was a no-brainer due to the better behaviour of the RFM69 devices in native mode (an end to going deaf for example & the re-init every 60 secs in some cases), and a parallel project I had going with STM32 & RFM69 made all of it align nicely. So I’m fairly wed to RFM69 jeelib. You make a great point. Both RFM69 native (Jeelib packet format) and Low Power Labs operate the RFM69 in it’s native mode, it is simply the packet format that is different. Your original analysis went into great detail on it on the thread where you released CM. For me, I’ve got 3 choices for my non-OEM devices (sadly the majority - Roller Blind controllers on nearly every window with RFm12 Jeenodes) 1. The relay approach. I think this is the easiet. I’ve already got a minimal emonhub only install on a piW for a heatmeter. Plug a JeenodeUSB in it and it can receive the RF12’s ‘RFM69 native’ packets and push them via MQTT into emonpi / openhab. Heck, thinking about it, they don’t need to go near emoncms at all anymore, that was just a side affect of receiving them on emonpi to get them exposed via MQTT. 2. There was back in the day a LPL implementation for RFM12. I might look at that. I may also be brave/stupid enough to see how hard it would be to change the packet format in JeeLib RF69m to match LPL, but I doubt I have the patience/skills/time. 3. Desolder all the RFM12Bs and replace with RFM69s… not likely ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [11 February 2023 23:53 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084/10 "2023-02-11T23:53:09Z")
> [@alandpearson](#): > > There was back in the day a LPL implementation for RFM12 I can’t recall ever seeing that. > [@alandpearson](#): > > I may also be brave/stupid enough to see how hard it would be to change the packet format in JeeLib RF60m to match LPL, but I doubt I have the patience/skills/time. RF60m? As I wrote above, inside RFM69nTxLib.cpp are two quite separate sections - one for the '69 and one for the '12B. It’s just a matter of swapping a few bytes around for the format change and checking/changing a few bytes in the set-up for the data rate etc. The hardest part would be finding what the values you need are inside LPL - and there the '69 section will help, having all the register numbers to look for. > [@alandpearson](#): > > Desolder all the RFM12Bs and replace with RFM69s… not likely I’ve thought about that. I considered making a ‘U’ shaped soldering iron bit about 15 mm wide and spanning something like 15 mm to desolder all 14 joints at the same time. Then I quickly gave up on the idea. Robin Emley’s Mk2 PV Router is the best for that - he set his pads very wide apart and uses jumper wires to reach to the RFM. Dead easy to desolder one at a time. ---
**Author:** ![alandpearson](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@alandpearson](https://community.openenergymonitor.org/u/alandpearson)\ **Post date:** [12 February 2023 00:06 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084/11 "2023-02-12T00:06:48Z")
> [@Robert.Wall](#): > > > [@alandpearson](#): > > > > There was back in the day a LPL implementation for RFM12 > > I can’t recall ever seeing that. > **[GitHub - LowPowerLab/RFM12B: RFM12B library](https://github.com/LowPowerLab/RFM12B)** > > RFM12B library Full disclosure, I did not look at it to see if it is compatible with RFM69 LPL. ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [12 February 2023 00:13 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084/12 "2023-02-12T00:13:52Z")
> [@alandpearson](#): > > [GitHub - LowPowerLab/RFM12B: RFM12B library](https://github.com/LowPowerLab/RFM12B) That explains it. I gave up trying to understand Github. I won’t live long enough to learn. ---
**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\ **Post date:** [12 February 2023 12:14 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084/13 "2023-02-12T12:14:48Z")
I’m going to be honest here, I have completely lost track of the different RFM combinations against the different hardware. I have a feeling there was a table @TrystanLea did for it, but I can’t find it. Could a table be done that lists the OEM HW, the Firmware Options, and the recommended Firmware? I’m sure I am not the only one for whom this is a completely opaque subject! ---
**Author:** ![rupert](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/r/f14d63/32.png) [@rupert](https://community.openenergymonitor.org/u/rupert)\ **Post date:** [12 February 2023 12:42 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084/14 "2023-02-12T12:42:13Z")
see: > [@Emon Tx V4 and 433MHz Radio Formats](https://community.openenergymonitor.org/t/emon-tx-v4-and-433mhz-radio-formats/22085/14): > > For information, I have tried, to the best of my knowledge, to put together a table of device vs radio format which may be of interest. My apologies in advance for any errors! The table is a snapshot in time, as things will probably change in the future. I have included the Mk2 PV Router by @calypso_rae as it is a very popular device. Any corrections or comments are welcome. The table was made on 19/12/2022 so it may not be completely up to date now ---
**Author:** ![alandpearson](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@alandpearson](https://community.openenergymonitor.org/u/alandpearson)\ **Post date:** [14 February 2023 19:26 UTC](https://community.openenergymonitor.org/t/moving-existing-installation-to-new-native-rfm69-format/22084/15 "2023-02-14T19:26:55Z")
Lighting up this topic again. I’d also take a look at radiohead, which seems to be even better than LPL, and works across a much broader range of systems and hardware. It has many of the key features (retries etc) and may prove to be more reliable than LPL implementation, which doesn’t seem to have been actively developed in the past few years, and limited to RFM69 as far as I can see. While it may be frustrating to even think about changing mid-stream to yet another protocol format, a serious look at [radiohead](http://www.airspayce.com/mikem/arduino/RadioHead/) is merited. It is simple, small, highly portable and built for this purpose. It seems to be much very well architected and has been about since 2014, while still actively developed. [Go on, take a look.](http://www.airspayce.com/mikem/arduino/RadioHead/) Heck, it even works with motedino, stm32, esp8266 and pi Pico - no porting required.