No longer receiving inputs from RFM12B

emonHub
1

Hi – this is going to be a blast from the past, so hoping someone somewhere might still be able to help….

I am running an RFM12B base station (with two EmonTx Transmitters) on a Raspberry pi, running Raspbian Wheezy. Emonhub collects the data and passes it to emoncms (version 8.4.0).

Everything has been working fine for years (at least six years !!!) until suddenly today, I stopped receiving temperature readings. I had not made any changes or updates. The ‘green’ led on the RFM12B flashes on power-up, but no longer flashes when a reading is received. I am assuming that this is not a problem with the transmitters, because both stopped at the same time. Emoncms appears to still be working fine.

I looked in the emonhub log, and there was a lot of HTML pages??? from several days ago, but not today. Anyway, I have changed the config to debug level. Here is my config file:

#######################################################################
#######################        Reporters        #######################
#######################################################################
[reporters]

# This reporter sends data to emonCMS
[[emonCMS]]
    Type = EmonHubEmoncmsReporter
    [[[init_settings]]]
    [[[runtimesettings]]]
        url = http://localhost/emoncms
        apikey = <my api key>

#######################################################################
#######################       Interfacers       #######################
#######################################################################
[interfacers]

# This interfacer manages the RFM2Pi module
[[RFM2Pi]]
    Type = EmonHubJeeInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 9600
    [[[runtimesettings]]]
        group = 210
        frequency = 868
        baseid = 15


#######################################################################
#######################          Nodes          #######################
#######################################################################
[nodes]

# List of nodes by node ID
# 'datacode' is default for node and 'datacodes' are per value data codes.
# if both are present 'datacode' is ignored in favour of 'datacodes'
[[99]]
        datacode = h
        datacodes = l, h, h, h,

and here is my logfile output (after a restart):

2019-06-12 21:33:39,045 INFO EmonHub Pre-Release Development Version (rc1.2)
2019-06-12 21:33:39,047 INFO Opening hub...
2019-06-12 21:33:39,048 INFO Logging level set to DEBUG
2019-06-12 21:33:39,049 INFO Creating EmonHubEmoncmsReporter 'emonCMS'
2019-06-12 21:33:39,050 INFO Set up reporter 'emonCMS' (buffer: memory | size: 1000)
2019-06-12 21:33:39,052 INFO Setting emonCMS url: http://localhost/emoncms
2019-06-12 21:33:39,053 INFO Setting emonCMS apikey: set
2019-06-12 21:33:39,054 INFO Creating EmonHubJeeInterfacer 'RFM2Pi'
2019-06-12 21:33:39,057 DEBUG Opening serial port: /dev/ttyAMA0 @ 9600 bits/s
2019-06-12 21:33:41,061 INFO RFM2Pi device firmware version & configuration: not available
2019-06-12 21:33:41,063 INFO Setting RFM2Pi frequency: 868 (8b)
2019-06-12 21:33:42,065 INFO Setting RFM2Pi group: 210 (210g)
2019-06-12 21:33:43,067 INFO Setting RFM2Pi quiet: 1 (1q)
2019-06-12 21:33:44,070 INFO Setting RFM2Pi baseid: 15 (15i)
2019-06-12 21:33:45,079 DEBUG RFM2Pi acknowledged command: > 8b
2019-06-12 21:33:45,286 DEBUG RFM2Pi acknowledged command: > 210g
2019-06-12 21:33:45,494 DEBUG RFM2Pi acknowledged command: > 1q
2019-06-12 21:33:45,702 DEBUG RFM2Pi acknowledged command: > 15i

Does anyone have any ideas please? Any help gratefully received.

2

I would say the 2 favourite things to check are whether the rfm2pi board has moved at all, the clearence between the underside of the rfm board and the top of the pi’s gpio pins is very small, the ariel solder joint is usually the first thing to short, causing rf blindness. Then there is “dry joints”, after six tears of faithful operation, it wouldn’t surprise me if a dry joint was surfacing, maybe worth checking with a magnifying glass.

restart of emonhub or the pi? Did you power cycle it?

The log shows the rfm2pi is alive and responding, but apparently not receiving any RF.

Could you add quiet = false to the [[RFM2Pi]] [[[runtimesettings]]] in emonhub.conf? That would show if there are any packets being discarded due to being incomplete or corrupted etc,

have you moved or added anything that could be a big source of interference?

3

SD Card? The failure of an SDCard sometimes manifests itself in weird ways. Is this a low write setup?

I’d pull the data off before doing much else (assuming it isn’t backed up anywhere else).

4

What sort of RFM12B is it? I’ve read somewhere that the “blob” sort - like the 868 MHz or SMT crystal versions illustrated here, are liable to fail after a time.

5

Thanks for the tips. I’ve done a restart and a power cycle. (The power cycle is the only time I see the green light on the RFM12B board.
Here is the log output with quiet = false

2019-06-13 19:56:43,996 INFO EmonHub Pre-Release Development Version (rc1.2)
2019-06-13 19:56:43,997 INFO Opening hub...
2019-06-13 19:56:43,999 INFO Logging level set to DEBUG
2019-06-13 19:56:44,000 INFO Creating EmonHubEmoncmsReporter 'emonCMS'
2019-06-13 19:56:44,002 INFO Set up reporter 'emonCMS' (buffer: memory | size: 1000)
2019-06-13 19:56:44,004 INFO Setting emonCMS url: http://localhost/emoncms
2019-06-13 19:56:44,005 INFO Setting emonCMS apikey: set
2019-06-13 19:56:44,007 INFO Creating EmonHubJeeInterfacer 'RFM2Pi'
2019-06-13 19:56:44,010 DEBUG Opening serial port: /dev/ttyAMA0 @ 9600 bits/s
2019-06-13 19:56:46,014 INFO RFM2Pi device firmware version & configuration: not available
2019-06-13 19:56:46,016 INFO Setting RFM2Pi frequency: 868 (8b)
2019-06-13 19:56:47,018 INFO Setting RFM2Pi group: 210 (210g)
2019-06-13 19:56:48,021 INFO Setting RFM2Pi quiet: 0 (0q)
2019-06-13 19:56:49,023 INFO Setting RFM2Pi baseid: 15 (15i)
2019-06-13 19:56:50,033 DEBUG RFM2Pi acknowledged command: > 8b
2019-06-13 19:56:50,241 DEBUG RFM2Pi acknowledged command: > 210g
2019-06-13 19:56:50,450 DEBUG RFM2Pi acknowledged command: > 0q
2019-06-13 19:56:50,658 DEBUG RFM2Pi acknowledged command: > 15i

Interestingly, since last night, I can see that there were four packets received at about 06:30 this morning, but nothing else. I’m thinking hardware fault?

Next thing to do is to check the solder joints.

6

Thanks - I’m using a hard drive, and everything gets backed up daily.

1 Like
7

Hi - it’s a blob sort - the fourth one down in the document.
I’m thinking that this might be a replacement?
https://www.ebay.co.uk/itm/RFM12B-868S2P-Module-RF-FM-transceiver-FSK-868MHz-SPI-105dBm/202693932317?epid=577023395&hash=item2f317ff51d:g:FJgAAOSwIXNc8Ajb

8

I think any RFM12B-868-S will be OK.
-S1 and -S2 relate to the crystal can size. The one you don’t want is the -D which is two rows of pins (see the data sheet, pp 39 & 40).

9

I’ve checked the solder joints, and re-soldered the pins on the header that connects to the Pi, but no better. On one occasion, I received two packets, but that was it. Interestingly, the packets I have received (only a handful) have all been from the transmitter that is furthest away - I’ve not received anything from the transmitter next to the Pi.

Anything else I can check to isolate the problem?

10

Did you resolder the joints between the RFM12B module and the RFM2Pi board - that’s where a dry joint is likely.

You’re assuming the problem is the receiver because you suddenly stopped getting data from both emonTx’s. I know it’s a long shot to suggest both emonTx’s (do you mean that, or are they emonTHs?) have failed simultaneously, but is there anything else that confirms that?

Do you have a programmer? (I’m thinking that you could load a ‘receive’ sketch into an emonTx/TH, that could prove that at least the other Tx/TH was transmitting.)

11

Another thing to consider is the power supply since the rfm module is the weakest link when it comes to voltage. How do you have this all powered? Does the hdd take it’s power from the pi? If you don’t have another known good PSU that can provide ample current for the pi, rfm2pi and hdd without a drop in voltage, what you could do as a quick test is shutdown the pi and hdd, disconnect the hdd and then just unplug and reconnect the rfm2pi add-on board (to reset it without starting the pi again), the rfm2pi doesn’t need a pi to receive rf and flash the led to indicate when it does receive. If you get some flashes when the hdd and pi are not drawing any current, it could well be the PSU. However, do you recall if the led does definitely flash on receipt? I seem to vaguely recall there was a few FW revisions that didn’t flash the led, unless you know that wasn’t the case with your rfm2pi and have previously seen it flashing for sure, it’s not a conclusive indication.

12

Hi Robert - I’ve now re-soldered the RFM12B module and the antenna but no difference.

Just occasionally, I have had a packet received (only a handful of times). Because of that, and because both transmitters failed at the same time, I don’t think it is the transmitters.

Thanks for your suggestions.

13

HI Paul - I’ve tried an official Raspberry pi power supply, with just the RFM12B board attached (no hard drive). Interestingly, I had a couple of flashes when I powered it up (after the normal power-up flash), but nothing since. (P.S. The firmware definitely makes the LED flash when a packet is received).
I’ve taken the plunge and ordered a new RFM12B board. I’ll post back when I’ve got it installed (annoyingly, they all seem to take at least a week to be delivered).

1 Like
14

The new RFM2Pi boards are fitted with rfm69cw not rfm12b modules, but we know what you mean.

You will need to change your emonhub.conf [[RFM2Pi]] [[[runtimesettings]]] com_baud = 38400 (your old unit was 9600).

I guess that depends on where you are, but I’ve always had good turnaround from the shop. I suppose it does’t help ordering on a Friday, if it missed todays post it won’t leave 'til Monday, that’s 3 days gone before it starts! Fingers crossed it’ll turn up tomorrow if you’re in the UK.

15

I had a similar problem. Old hardware (Emonbase RFM12Pi v2.6, EmonTX v3.2 RFM12B and first generation EmonTH). Although the radio seemed to be connected, I was not getting Temp and Humidity readings from the EmonTH. I pulled out the DHT22 module from the EmonTH and re-seated it a number of times. I visually checked all the soldering with a magnifying glass. I assumed the sensor moduel was broken and bought a new one. Still didn’t work. I got it working eventually…with switch cleaner and fine wire poking around into the connector receptacles. It had been sitting out under the porch for a few years and had developed some hidden residue or corrosion. I know your issue it not quite the same.

16

That’s interesting information. So there was no evidence of corrosion on the leads of the old sensor itself, but the problem lay within the socket?

17

Absolutely robert…I checked again and again pulling it out and reinserting the original module, I examined the PCB in detail (it looked fine), it was only after I tried the new module that I became suspicous. I was just about to give up and order a new V2 EmonTH (definately better on battery life that the V1 in my experience). Then I tried the switch cleaner in the socket, and that was it. Admittedly it hasnt been placed in the best environoment for some years. Semi-outdoor. The battery terminals are also corroded.

18

So my problem is now resolved - but I don’t really know how. I removed the IC from the socket on the RFM2Pi board (and nearly lost one of the legs in the process) and put it back. No luck. I left it, and at 04:13 in the morning, one of the sensors burst into life. (I can confirm that there was no one around at that time!). The second sensor still wasn’t working, but on inspecting the batteries, there was some corrosion (the batteries were not old). I replaced the batteries and the second sensor is also working now. So quite why both decided to stop at the same time, and why the first one suddenly started to work, is still a mystery. Anyway, I now have a spare RFM12B module if I need it.

19

These are the absolute worst.

This is a classic example of the law of natural perversity. The coincidence apparently fooled you. From what you’ve said, it does seem like a combination of corrosion and possibly still a dry joint or a faulty RFM12B. The only real advice I can give you is to expect it to happen again - and of course at the worst possible time.