RFM69Pi rapidly flashing LED

rearden · 3 January 2018 18:40

I recently got my EmonBase working and moved the EmonTxV3 from the test location to the permanent one. I received about 4 days of good data. On the way out the door this morning I glanced at my EmonBase and the RFM69Pi was rapidly flashing, instead of its previous periodic (10s or so) flashing. I did not have time to debug, but I logged on remotely and noticed that something happened to the reported data yesterday. I noticed that the emonhub log was updating rapidly and the values posted did not look accurate. Power 1-4, vrms and temp, should have values. Here is the tail from the log:

2018-01-03 13:34:41,728 DEBUG    RFM2Pi     18874 Sent to channel(end)' : ToEmonCMS
2018-01-03 13:34:41,811 DEBUG    MQTT       Publishing: emon/emontx3/power1 10
2018-01-03 13:34:41,812 DEBUG    MQTT       Publishing: emon/emontx3/power2 0
2018-01-03 13:34:41,813 DEBUG    MQTT       Publishing: emon/emontx3/power3 0
2018-01-03 13:34:41,814 DEBUG    MQTT       Publishing: emon/emontx3/power4 0
2018-01-03 13:34:41,815 DEBUG    MQTT       Publishing: emon/emontx3/vrms 0
2018-01-03 13:34:41,816 DEBUG    MQTT       Publishing: emon/emontx3/temp1 0
2018-01-03 13:34:41,816 DEBUG    MQTT       Publishing: emon/emontx3/temp2 0
2018-01-03 13:34:41,817 DEBUG    MQTT       Publishing: emon/emontx3/temp3 0
2018-01-03 13:34:41,818 DEBUG    MQTT       Publishing: emon/emontx3/temp4 0
2018-01-03 13:34:41,818 DEBUG    MQTT       Publishing: emon/emontx3/temp5 0
2018-01-03 13:34:41,819 DEBUG    MQTT       Publishing: emon/emontx3/temp6 0
2018-01-03 13:34:41,820 DEBUG    MQTT       Publishing: emon/emontx3/pulse 0
2018-01-03 13:34:41,820 INFO     MQTT       Publishing: emon/emontx3/rssi -56
2018-01-03 13:34:41,821 INFO     MQTT       Publishing: emonhub/rx/8/values 10,0,0,0,0,0,0,0,0,0,0,0
2018-01-03 13:34:41,822 INFO     MQTT       Publishing: emonhub/rx/8/rssi -56
2018-01-03 13:34:41,832 DEBUG    RFM2Pi     18875 NEW FRAME : OK 8 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-56)
2018-01-03 13:34:41,834 DEBUG    RFM2Pi     18875 Timestamp : 1515004481.83
2018-01-03 13:34:41,835 DEBUG    RFM2Pi     18875 From Node : 8
2018-01-03 13:34:41,835 DEBUG    RFM2Pi     18875    Values : [10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
2018-01-03 13:34:41,836 DEBUG    RFM2Pi     18875      RSSI : -56
2018-01-03 13:34:41,836 DEBUG    RFM2Pi     18875 Sent to channel(start)' : ToEmonCMS
2018-01-03 13:34:41,836 DEBUG    RFM2Pi     18875 Sent to channel(end)' : ToEmonCMS
2018-01-03 13:34:41,939 DEBUG    RFM2Pi     18876 NEW FRAME : OK 8 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-56)
2018-01-03 13:34:41,941 DEBUG    RFM2Pi     18876 Timestamp : 1515004481.94
2018-01-03 13:34:41,941 DEBUG    RFM2Pi     18876 From Node : 8
2018-01-03 13:34:41,941 DEBUG    RFM2Pi     18876    Values : [10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
2018-01-03 13:34:41,942 DEBUG    RFM2Pi     18876      RSSI : -56
2018-01-03 13:34:41,942 DEBUG    RFM2Pi     18876 Sent to channel(start)' : ToEmonCMS
2018-01-03 13:34:41,942 DEBUG    RFM2Pi     18876 Sent to channel(end)' : ToEmonCMS

I rebooted the EmonBase. After the reboot it continued to update rapidly and did not display good data. Any ideas on where I should start with troubleshooting?
Thanks!

Robert.Wall · 3 January 2018 20:17

I can only see two transmissions from your emonTx, but they appear to be only 109 ms apart. That’s showing a good signal, but no voltage, one power, no temperatures and no pulses. The puzzling thing there is voltage - it should show either mains voltage or the battery voltage, and it’s showing zero. So I think your emonTx is faulty. Have you tried cycling the power (or the reset pushbutton) on your emonTx?

pb66 · 4 January 2018 00:01

It looks to me like the emonTx is failing to get past the factory test at startup and resetting, that’s the only time you would expect to see power1 at 10w and every other value at 0, but then the next payload should show power = 9w. The fact the “10w” payload is sent (at least) 3 times at 107ms intervals (give or take a ms or two) suggests a reset loop (assuming a stock FW).

What power supply is being used? Has it been changed as part of the re-location?

What is the emonTx LED doing? I’m guessing it might be on (almost continually) or flashing in time with the RFM69Pi.

rearden · 4 January 2018 13:50

I did some troubleshooting last night. The powersupply is the same one I received in my order and which was used in the test. As predicted the EmonTx was flashing rapidly. I tried a power cycle and it did not change the RFM69Pi flashing, but leaving it unplugged did, so the problem was the EmonTx not the RFM69. I unplugged all the inputs one by one without a change. Because the EmonTx is outdoors inside a metal NEMA box I have the antenna routed outside the enclosure using a 30cm SMA extension cable. The rapid flashing stopped when took this cable out of the loop and plugged the antenna in directly. I assume the included antenna is tuned to 433mhz, a 1/4 wave needing a ground plane. I tried another cable with the same result. I figured that not having a good ground plane may give a high SWR, so I alligator clipped a pigtail to the outer shield of the antenna connection at the base of the antenna (to create a dipole) and then to the ground rod just because it was right there. That has seemed to fix the issue. It has been running all night and sending data. Now I need to figure out how to make it all weatherproof, safe, permanent and fit.

rearden

I do get a fair amount New Log output:
2018-01-04 08:44:41,783 DEBUG 2018-01-04 08:44:41,783 DEBUG 2018-01-04 08:44:41,784 DEBUG 2018-01-04 08:44:41,784 DEBUG 2018-01-04 08:44:41,968 DEBUG MQTT 2018-01-04 08:44:41,970 DEBUG MQTT 2018-01-04 08:44:41,971 DEBUG MQTT 2018-01-04 08:44:41,972 DEBUG MQTT 2018-01-04 08:44:41,974 DEBUG MQTT 2018-01-04 08:44:41,975 DEBUG MQTT 2018-01-04 08:44:41,976 DEBUG MQTT 2018-01-04 08:44:41,978 DEBUG MQTT 2018-01-04 08:44:41,979 DEBUG MQTT 2018-01-04 08:44:41,980 DEBUG MQTT 2018-01-04 08:44:41,981 DEBUG MQTT 2018-01-04 08:44:41,983 DEBUG MQTT 2018-01-04 08:44:41,984 INFO MQTT 2018-01-04 08:44:41,986 INFO MQTT 2018-01-04 08:44:41,989 INFO MQTT 2018-01-04 08:44:42,006 DEBUG 2018-01-04 08:44:43,733 DEBUG 2018-01-04 08:44:44,898 DEBUG 2018-01-04 08:44:44,899 INFO 2018-01-04 08:44:45,544 DEBUG 2018-01-04 08:44:45,545 DEBUG 2018-01-04 08:44:45,546 DEBUG 2018-01-04 08:44:45,546 INFO 2018-01-04 08:44:48,368 DEBUG 2018-01-04 08:44:48,476 DEBUG 2018-01-04 08:44:50,740 DEBUG of “unreliable content” messages, but I do have an Acurite weather station on the other side of the house which I assume is on the same or close frequency.
RFM2Pi 1200 Values : [1170, 1503, 38, 42, 106.01, -3.6, 300, 300, 300, 300, 300, 0]
RFM2Pi 1200 RSSI : -78
RFM2Pi 1200 Sent to channel(start)’ : ToEmonCMS
RFM2Pi 1200 Sent to channel(end)’ : ToEmonCMS
Publishing: emon/emontx3/power1 1170
Publishing: emon/emontx3/power2 1503
Publishing: emon/emontx3/power3 38
Publishing: emon/emontx3/power4 42
Publishing: emon/emontx3/vrms 106.01
Publishing: emon/emontx3/temp1 -3.6
Publishing: emon/emontx3/temp2 300
Publishing: emon/emontx3/temp3 300
Publishing: emon/emontx3/temp4 300
Publishing: emon/emontx3/temp5 300
Publishing: emon/emontx3/temp6 300
Publishing: emon/emontx3/pulse 0
Publishing: emon/emontx3/rssi -78
Publishing: emonhub/rx/8/values 1170,1503,38,42,106.01,-3.6,300,300,300,300,300,0
Publishing: emonhub/rx/8/rssi -78
RFM2Pi Discarding RX frame ‘unreliable content’? 7 166 49 104 231 217 193 53 234 111 1 143 110 254 188 215 234 253 109 122 5 (-88)
RFM2Pi Discarding RX frame ‘unreliable content’? 29 57 247 102 224 155 8 15 228 53 114 237 121 70 234 239 174 219 255 223 22 (-88)
emoncmsorg Sending bulkdata, length: 3
emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1515073461.923624,8,1179,1502,40,43,105.96000000000001,-3.6,300,300,300,300,300,0,-78],[1515073471.829024,8,1173,1504,44,44,105.94,-3.6,300,300,300,300,300,0,-78],[1515073481.778493,8,1170,1503,38,42,106.01,-3.6,300,300,300,300,300,0,-78]]&sentat=1515073484
emoncmsorg acknowledged receipt with ‘ok’ from https://emoncms.org
emoncmsorg Sending bulkdata, success: True
emoncmsorg Current queue length: 0
emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y
RFM2Pi Discarding RX frame ‘unreliable content’? 25 25 113 206 241 114 23 148 252 90 121 150 41 177 51 251 13 91 177 108 62 (-90)
RFM2Pi Discarding RX frame ‘unreliable content’? 18 254 127 167 165 212 116 235 136 80 197 129 140 212 178 60 223 109 170 77 227 (-85)
RFM2Pi Discarding RX frame ‘unreliable content’? 6 88 237 68 46 205 29 249 93 208 173 142 176 128 30 109 26 102 190 245 160 (-87)

Robert.Wall · 4 January 2018 14:35

I don’t understand how what you think you’ve done could have cured the problem I thought you had (if that makes sense?).

I can’t see how an inefficient antenna - because basically that’s what you are describing - can cause the emonTx to rapidly reset - unless the power supply is critically low and the extra current required to transmit is causing the 3.3 V rail to drop out of regulation. And even that seems unlikely.

R.F. ground is also d.c. ground. It sounds to me much more like a grounding and power supply issue where you have a spurious ground connection in addition to the antenna ground via the extension cable to the metal box. I’d suggest you look for something that’s pulling the power supply down.

If those transmissions are received, then not obeying the same protocol and thus having an incorrect checksum will mean they do get rejected. The problem comes when both devices transmit at the same time, when neither is likely to get through.

rearden · 4 January 2018 15:00

OK. I will take a look. The power supply is the one which came with the system. The inputs into the box are the 4 CTs, Temp sensor, power and antenna. The key seemed to be screwing the antenna directly into the EmonTx or grounding shield with the pigtail when the coax extension was used. I did not test the non grounded pigtail with coax extension version. Maybe there is something additional and unintentional I am doing. The EmonTx is outside and around back, the EmonBase in the basement and the monitoring desktop is on the second floor so, my permutations were only tried once. I will check the GFCI outlet the power supply is plugged into.

The voltage which is being reported is around 110v, my volt meter and my Sense are reporting something much closer to 120v. Sense is currently reporting 118.5vac. I take it there is a calibration routine or adjustment factor I need to discover in the documentation?

Robert.Wall · 4 January 2018 15:15

The a.c. adapter from the shop does give you an isolated output, the output voltage needs to be significantly above the nominal 9V (which is the full-load voltage) for the internal power supply in the emonTx (before V3.4.4) to work correctly. I can’t remember the exact figure given a worst-case set of components, but it should be OK with the nominal supply voltage of 120 V, at which you should see 12 V a.c. out. So I think you’re looking at one of the other connections.

If you want to do the full calibration, instructions are in ‘Learn’, under “Current & Voltage”. If you want to do a rough-and-ready calibration instead, you can adjust the scales = factors in emonHub for your emonTx node. Bear in mind there’s no interaction, so correcting the voltage doesn’t correct the power by the same amount.