Suddenly death of RFM69PI receiver

My home has six emonTH sensors that connect back to a Pi with an RFM69 and the emonhub software. It then forwards sensor readings via MQTT to emonCMS and Home Assistant.

All has been working fine for several years. Other than changing batteries, I’ve had no problems until last night.

At approx 8PM last night the Pi stopped receiving/decoding all but the closest emonTH senders. Initially, I thought it was just one, but over a period of about 12h four of them dropped off - those that are either in the same room as the Pi, or in the next (the Pi sits on a windowsill in a bedroom to give it good comms to all sensors). Two sensors are line of sight except for thin wooden walls (shed and home office), but they have dropped off. The other two are downstairs.

I’ve ordered a replacement RFM69 in the hope that it’s just a failing board, but I wondered if anybody else has seen anything like this.

UPDATE:
I’ve managed to implement a temporary solution by relocating the Pi and the missing sensors so the pressure is off; but I’m still curious to understand what happened.

I don’t have any emonTHs but …

The 433MHz received signal strength from the RFM69PI can vary considerably, depending on the path between the transmitter and the receiver. For example, obstructions that cause attenuation such as walls, full bookshelves, metal foil lined plasterboard etc, and reflections from metallic objects.

Also problems may be caused by other RF sources in the vicinity, such as unrelated 433MHz sources e.g. electronic key fobs, remote garage door openers, remote power switches etc. Other RF sources could also include interference from computers, monitors, televisions and anything with a switched mode power supply.

After working happily for several years, it seems unlikely that the RFM69PI has failed, as it isn’t a highly stressed component - but anything is possible.

Did anything else change at 8pm last night?

You can check the received signal levels at your emonPi by looking at the RSSI levels (received signal strength indicator) of your emonTHs on the Setup/Inputs page. I have ones working down to -85. Higher (e.g. -80) is is a stronger/better level.

On another note … When you say

I’m not sure if you mean a RFM69PI or RFM69SPI unit bought from OEM, or the 14 ‘pin’ RFM69CW radio module that is soldered onto the PCB of those units. If it is the RFM69CW radio module, then …

I have not tried it myself, but others have said that removing a RFM69CW module from the PCB it is mounted on is difficult, and needs great care to avoid damaging the pads on the PCB.
If you need to do it, I don’t know what the best approach would be - solder wick, solder sucker, hot air, ‘U’ shaped soldering iron bit to melt all the joints at once? Others could perhaps comment?

I concur.

Two maybe obvious points - have you checked the receiving antenna and the power supply?

After that, I think my money would be on an external in-band signal that’s interfering with reception, which I think is strengthened by your update.

As for de-soldering the RFM69CW module, a solder sucker doesn’t work - it can’t get the very thin film of solder between module and pad because you can’t seal the sides and get enough air from beneath the module to sweep the solder into the sucker. I’ve never got on with solder wicks, but I think it’s what Glyn & Trystan use. I’d be wary of hot air given the proximity of surrounding components, it may well work if you had two long narrow slots for nozzles, one for each side. I have thought about a U-shaped bit, you’d need either a very high-powered electric iron or a gas blowlamp - and it might well be a two-person job, one to control the iron and one to pull the module away the instant the solder melted.

While not viable for a production run, Robin Emley sidestepped the problem with his Mk2PVRouter boards by moving the pads further apart width-wise so that the module pad didn’t overlap the parent board pad, and spanned the gaps with short wire links (which you snip and remove the remains one at a time after).

That’s actually the preferred method. It’s what the “industry” uses.

BUT, they have the correct “tools” to do the job. The right “nozzle” keeps the adjacent components from getting “fried.”

When I worked at a USN electronics repair depot, (1985-88) one of the “newfangled toys” we received on a try-before-you-buy basis, was a SMD hot air solder/desolder station.
It worked like a champ.

The only problem was cost. The vendor wanted ~17k for it. A hefty price tag at the time. The Navy quietly told them thanks, but no thanks. A real shame, as it would have been a valuable addition to our shop.

I thought this was the case, but lacked the detailed knowledge to assert this. Thanks for confirming.

I had a vision of someone taking a hot air paint stripper gun to the pcb. The result wouldn’t be pretty.

My standard response has always been: Don’t attempt to remove the RFM12B/RFM69CW without the proper professional equipment and experience in using it.

1 Like

As you would say, “seconded.” thumbs_up thumbsup

Thanks, Rupert
To clarify: I’ve ordered a replacement addon board from the shop. It arrived today, so I’ll see if it makes a difference.

I’m not sure about the longevity of these boards. I have reported elsewhere about problems with the board appearing to lock up (i.e. red led stuck on) and requiring to be reset. I have a script that runs every 10 mins to recover from this. It will be interesting to see if the problem disappears with the replacement board.

I can’t ascertain if there are interfering signals, but I can assert that nothing has changed in the house. We were out at the time.

When working properly, RSSI fluctuates between -30 for the sensor in the same room, and -54 for the one at the bottom of the garden.

Your RSSI values look very good. I don’t know why your your radio boards lock up.

As your system has has been running for several years, there have been some changes that you might not be aware of:

1) There are now two main radio protocols used. They are not compatible. I am guessing that the changeover between the two was about February 2023
a) The older one is called Jeelib Classic format.

b) The newer one is called the LPL (Low Power Labs) radio format, and is the default now.

2) There are now two radio modules for the emonBase.
a)The older RFM69PI module has a RFM69 radio module and an atmega 328 controller. It talks to the Pi via the Pi AMA0 serial port. The atmega 328 controller can be programmed to receive either LPL or Jeelibs protocol. The atmega 328 firmware can be changed from the Admin > Update page.

b) The newer RFM69SPI module just uses the RFM69 radio module, and talks to the Pi via the Pi SPI port. The decoding of the radio format is done in the Pi. The SPI decoder in emonHub is only for the LPL protocol. The RFM69SPI module is the default sold by the shop now.

for more details see

From the age of your system I would guess that you are using the Jeelib Classic format and the
older RFM69PI module. That is, unless you have upgraded the emonCMS software, emonHub configuration, RFM69PI firmware and all your emonThs’ firmware to convert to LPL format…

You need to check if you have bought by default from the shop an RFM69SPI module. It is NOT a direct plug in replacement for the RFM69PI as

  1. it can only receive LPL format with the present emonHub interfacer
  2. It needs a different interfacer in emonHub
  3. It connects to different pins on the Raspberry Pi 40 pin connector.

Hope my explanation is clear!

Thanks for the heads-up Rupert.
I was aware of the change, but there’s no problem being reminded.

It looks like I’ve been sent the SPI board, which is no use. I thought I’d ordered a RFM69PI, but now that I look again, it’s not listed. I’ll have to send it back.

If I can’t get the proper board, and the problem recurs, I’ll probably ditch openergymonitor as a solution as the cost to replace all the emonTH units would exceed what I can buy other sensors for.

I think you may have to email the shop to ask if they have any RFM69PI boards in stock. I have a feeling they said they would keep some in stock for replacements, but I might be wrong … fingers crossed!

As an aside, if necessary the emonTh units can be re-programmed to use the LPL protocol, using an emonBase and a USB to UART adapter. This would allow the use of a RFM69SPI board.

see
https://docs.openenergymonitor.org/emonth2/firmware.html

There shouldn’t be a problem* reprogramming the emonTH’s to use the LPL protocol. If you don’t have one, you’ll need a programmer Programmer - USB to serial UART - Shop | OpenEnergyMonitor and you should have the USB lead for one end, the other end plugs straight into the header on the emonTH. Check ‘Docs’ FTDI Programmer — OpenEnergyMonitor 0.0.1 documentation for pictures and details of the programmer if you’re unsure. (“Assembly” means soldering just one connector.)

*(Unless you have a very old emonTH with the RFM12B radio module. That can’t be used with LPL and encrypted data packets.)

Thanks, both.
I thought it required a hardware upgrade. If it’s just a firmware upgrade then I can do that. However, I’ll have to check the actual hardware of the emonTH modules first to confirm they are upgradeable.

It will be a while before I can do that. We have visitors and I learned the lesson many years that it is foolhardy to do that “I’ll just change this before I head off to the hills for the weekend” stuff. I don’t tinker with stuff that is - as far as I’m concerned - live, without careful planning.

1 Like

Just to give you a heads-up and make sure that you have the correct kit …

From the OEM Docs in the above post from @Robert.Wall (nb programmer = USB to UART adapter):
Before connecting the programmer, ensure the jumper link on the programmer is set to the 3.3 V position for the emonTx, emonTH and emonPi Shield, or 5 V for the emonTx Shield. This sets the voltage levels on the data lines.

The USB to UART adapter from the shop is a FTDI LC231X. It has the required pin out/signals
1 GND
2 CTS
3 Vcc
4 TX
5 RX
6 RTS

The 3.3V jumper setting gives Vcc = 3.3V and 3.3V TTL levels for TX, RX etc

Hope this helps

All that is on the Programmer page in Docs. I know because I wrote that page.

Thanks, Robert.
A few questions as I finalise my plan.

  1. Given that I only have the one emonHub, is it likely that I would have a mix of RFM69 and RFM12B modules? I thought they were incompatible.
  2. If it is possible, how do I physically identify them?

I don’t want to commit to a big-bang upgrade to the LPL protocol, so

  1. Is it possible to run two “networks” simultaneously on different PIs without them interfering? (i.e. keep the existing network functioning; spin up a new Pi with the RFM69SPI board and migrate emonTH sensor over individually.)

Yes and no - it depends on when they were bought.

Yes they are - but also depending on how you use them, i.e, which radio protocol. You cannot use a RFM12B with LPL with encryption turned on, because the RFM12B cannot do the encryption, and encryption is not in the sketch. But I could change my transmit-only library for the RFM12B to send the same protocol as LPL but without encryption, and then they would be compatible (but limited - you’d need to turn off encryption everywhere).

Look in the Docs. There’s a section on Networking, it’s in there with photos.

Not ideal, because they use the same frequency band, and as far as I know, JeeLib doesn’t check for another transmitting before it transmits, so they can interfere. But both will ignore the others’ messages, so the interference between systems will be limited - maybe no worse than you had before.

But what’s your worry - is it accessing the emonTH’s? Once you’ve got your hands on one, it should only take a few minutes to change its ID and upload the new sketch.

As far as I know, the RFM12B and RFM69CW are pin compatible. Both can use the JeeLib protocol. However the RFM12B lacks the on board processing power to use the LPL protocol. The LPL protocol includes data encryption, and acknowledgement / retry of data packets.

From what you have said, you have one emonHub and six emonTH2s, so a total of seven radio modules. It seems that OEM changed to RFM69 radio modules from about May 2015 (see reference below). You could check when you bought the emonHub and emonTH2s to see which radio module module they should have.

If you need to visually check what radio module is in a particular OEM unit, then there are photos at:

https://docs.openenergymonitor.org/electricity-monitoring/networking/rfm12_69.html

When I was converting my OEM units from Jeelib to LPL, I did have both formats running at the same time. I used one emonHub with two receivers - an RFM69PI module (LPL format) and an USB JeeLink receiver (JeeLib format). This worked ok. So I think you should be ok, if you

I originally had two JeeLib emonHubs to backup my data. However, once all the sensors have been converted to LPL, you cannot have two LPL receivers (e.g. two LPL emonHubs), as it confuses the LPL acknowledgement / retry mechanism and gives occasional system lockups. This doesn’t happen with JeeLib format as there is no acknowledgement / retry mechanism.

Why did I bother?

1 Like

Apologies Robert - I was nearly finished writing my reply when you posted yours :blush:

1 Like

This is a red herring. Acks are not used with the emonTH due to battery life considerations.