Old system rebuild

Emoncms Installation
1

HI
Before I give up forever!.
I have had a pi3 system with and Arduino board running for years, its been fantastic. It uses an rfm69 and is suspect (amongst other things that’s gone wrong) and the whole thing has crashed and wont restart.

I have rebuilt the pi and the Arduino firmware, including using the update button in Admin and connected them via USB. I have set up the config file in emonhub to read the USB from the arduino.

The arduino is transmitting the following:
11:21:41.796 → ⸮⸮emonTx V3.4 Continuous Monitoring V2.4.0
11:21:41.796 →
OpenEnergyMonitor.org
11:21:41.796 → No EEPROM config
11:21:41.796 → Settings:
11:21:41.796 → Band 433 MHz, Group 210, Node 15, 7 dBm
11:21:41.796 → Calibration:
11:21:41.796 → vCal = 268.97
11:21:41.796 → assumedV = 240.00
11:21:41.796 → i1Cal = 90.90
11:21:41.796 → i1Lead = 3.00
11:21:41.796 → i2Cal = 90.90
11:21:41.796 → i2Lead = 3.00
11:21:41.796 → i3Cal = 90.90
11:21:41.796 → i3Lead = 3.00
11:21:41.796 → i4Cal = 16.67
11:21:41.842 → i4Lead = 6.00
11:21:41.842 → datalog = 9.85
11:21:41.842 → pulses = 1
11:21:41.842 → pulse period = 100
11:21:41.842 → RF on
11:21:41.842 → temp_enable = 1
11:21:41.842 → JSON Format Off
11:21:41.842 → RFM69CW Freq: 433MHz Group: 210 Node: 15
11:21:41.842 → USA Vcal active: 130.00
11:21:41.842 → Factory Test
11:21:43.343 → CT1 detected, i1Cal:90.90
11:21:43.577 → Temperature Sensors found = 0 of 3
11:21:43.577 → Temperature measurement is enabled.
11:21:43.577 →
11:21:46.155 → AC present - Real Power calc enabled
11:21:46.343 → MSG:1,Vrms:77.99,P1:0,E1:0,pulse:0
11:21:58.127 → MSG:2,Vrms:77.26,P1:1,E1:0,pulse:0
11:22:09.935 → MSG:3,Vrms:77.22,P1:1,E1:0,pulse:0
11:22:21.699 → MSG:4,Vrms:77.21,P1:1,E1:0,pulse:0
…(and so on)

All of which look very sensible

Emonhub logs the following:

OpenEnergyMonitor.org
2025-02-24 11:36:50,485 DEBUG USB No EEPROM config
2025-02-24 11:36:50,586 DEBUG USB Settings:
2025-02-24 11:36:50,690 DEBUG USB Band 433 MHz, Group 210, Node 15, 7 dBm
2025-02-24 11:36:50,792 DEBUG USB Calibration:
2025-02-24 11:36:50,894 DEBUG USB vCal = 268.97
2025-02-24 11:36:50,997 DEBUG USB assumedV = 240.00
2025-02-24 11:36:51,099 DEBUG USB i1Cal = 90.90
2025-02-24 11:36:51,201 DEBUG USB i1Lead = 3.00
2025-02-24 11:36:51,303 DEBUG USB i2Cal = 90.90
2025-02-24 11:36:51,405 DEBUG USB i2Lead = 3.00
2025-02-24 11:36:51,507 DEBUG USB i3Cal = 90.90
2025-02-24 11:36:51,609 DEBUG USB i3Lead = 3.00
2025-02-24 11:36:51,711 DEBUG USB i4Cal = 16.67
2025-02-24 11:36:51,813 DEBUG USB i4Lead = 6.00
2025-02-24 11:36:51,916 DEBUG USB datalog = 9.85
2025-02-24 11:36:52,018 DEBUG USB pulses = 1
2025-02-24 11:36:52,120 DEBUG USB pulse period = 100
2025-02-24 11:36:52,222 DEBUG USB RF on
2025-02-24 11:36:52,324 DEBUG USB temp_enable = 1
2025-02-24 11:36:52,426 DEBUG USB JSON Format Off
2025-02-24 11:36:52,530 DEBUG USB RFM69CW Freq: 433MHz Group: 210 Node: 15
2025-02-24 11:36:52,633 DEBUG USB USA Vcal active: 130.00
2025-02-24 11:36:52,735 DEBUG USB Factory Test

Over and over again
Nothing sensible seems to be happening anywhere else.

I would be grateful in anyone could point me in vaguely the right direction

Thanks
John

2

Welcome, John, to the OEM forum.

I’m not sure what you’re receiving from where. What you’ve written is inconsistent. You can’t be getting sensible output on the serial port

And having this

Which points to the watchdog firing because the sketch latched up somewhere.

So I think you’ve forgotten to tell me you did something in between.

3

Thanks, probably, I have tried so many things over the past 2 weeks I dont know where I am coming from and this is coupled with having forgotten more than I knew when I put it together as its been so reliable.
I connected the Arduino to the serial port reader on the Arduino IDE on a PC to read what it was producing.

I am reading the other message from the emonhub debug screen, with the Arduino re-connected via usb to the pi.

jJohn

4

I don’t think you can have had the same settings in your emonTx V3 to produce those two lists of numbers. I think you have a fault in the RFM69CW as you suggest, and you got the serial output with voltage, power etc reported by disabling the radio.

When you enable the radio, it gets as far as printing “Factory Test” at line 231 and then locks up - maybe because the RFM69CW fails to respond, the watchdog fires and it resets the processor and starts again.

When you disable the radio, the RFM69CW is not involved and the main loop runs, continually resetting the watchdog and reporting values every 10 s or so.

I don’t recommend trying to unsolder the RFM69CW, you will almost certainly damage the p.c.b. in the process unless you have the necessary skills and tools.

If it’s practical to continue with the programmer handling the conversion from serial on the FTDI connector to USB serial connection to the emonPi, then that’s what I would recommend. Otherwise, although it’s not advertised, it’s probably worth asking The Shop if an ESP8266 Wi-Fi module is still available. This would at least allow you to continue using your emonTx V3. If it’s not, the new Adafruit Huzzah module is totally different, and it would need investigation to determine if it would be suitable.

If you can’t do a serial or Wi-Fi connection, then it looks like you’re going to have to go down the emonTx4 + emonVS or emonPi + emonVS route, which unfortunately is a complete re-equip.

5

Thank-you that explains a lot.
I do have the skills to remove the radio module and I might look at that or the options you suggested. I built up another pi from scratch and that seems to work after a fashion, it voltage reading and vrms are off by about 1/3 so I suspect somewhere along the line it thinks its 3 phase and the Arduino is refusing to update from the admin menu, it keeps sating its not in sync. I will rebuild the Arduino and probably go for a direct serial connects as they are pretty much next to each other anyway.

Thanks again
John

6

That will be the cheapest and simplest option, but if the two are close, serial will be easy too. Basically, you could strip all the radio code out of the sketch (but keep the rf data struct as the serial output is too deeply embedded in it).

I’m afraid I can’t help with the serial monitor - I just issue the commands by hand from a laptop.

Post again (if you can find this Topic) if you need any more hints.

7

Just an additional note which may help, before you take a soldering iron to the RFM69 module…

I’m not completely clear on how your original system was configured,

but …

if it was an emonTx3 (Arduino) for measurement, connected wirelessly (radio) to a raspberry Pi3 for emonCMS/emonHub data collection (i.e an emonBase)

and

Then as your system has has been running for some years, there have been 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 Jeelib 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.

So basically if the firmware on the Pi3 and emonTx3 have been updated to different versions of the radio protocol (JeeLib vs LPL), they will not be able to talk to each other.

When updating, the radio protocol is a choice box at :
Admin/Update/Update Firmware Only/Radio Format

There is some background information on radio formats etc at

I don’t know if this helps or is an irrelevant complication!

8

How does that explain the watchdog firing? Remember

If it’s a RFM69CW, it will run whichever protocol is used. It might not communicate, but it won’t latch up and fire the watchdog.

9

It doesn’t explain the apparent watchdog firing.

As you say, the two logs seem inconsistent.
In the first log (‘The arduino is transmitting the following:’) the emonTx3 seems to boot up ok and happily start making measurements. The log says

So it seems to have successfully completed the Factory Test with RF on, so presumably the RFM69CW is working ok?. However Vrms looks incorrect? Perhaps this could be something to do with

The second log (‘Emonhub logs the following:’) seems to be stuck in a loop, ending at

So I’m not sure what’s happening here.

However, I am not clear on the original configuration of the system, the current firmware used in the Pi3/Arduino system, or the diagnostic methods used, so I thought @Clockmender should be aware of the change in the default radio protocols in case it is relevant.

10

@Clockmender
Assuming that you are using an emonTx3 (arduino), and it is in the same firmware and hardware state that produced the log in the first post ('The arduino is transmitting the following:’) with

Then from

you might wish to check the setting of the emonTx3 DIP switch 9, see
https://docs.openenergymonitor.org/emontx3/configuration.html#dip-switch
This switch sets whether the emonTx3 calibration is for use on US voltages (sets USA Vcal active) or UK voltages.

Lots of ‘ifs’ and assumptions here!

11

As @Clockmender wrote that he’d completely reloaded both the emonTx V3 and the Pi software, is this not irrelevant, and all that matters is the two ends have the same radio protocol loaded - which is fairly simple to recognise?

I’ll drop out of this topic, we don’t want to confuse John too much.

12

@Robert.Wall
I’ll be very sorry if you leave this topic, with your comprehensive knowledge of the OEM hardware, firmware and history. In my view, the more guesses and ideas of what is causing an unknown problem the better, so that in the end, the problem (hopefully) gets solved!

A bit off topic - I’m not sure how easy it is for the user to determine what radio protocol is being used by a particular device?

For example, on the emonTx3, the protocol is set by a #define statement in the source code but the firmware version number is the same for all protocols. Unless I have missed it, the protocol doesn’t seem to appear in the boot messages, or in the ‘list the settings’ command for serial configuration. Perhaps it should.

As people add newer hardware to older systems, this may become a problem.

13

No, it already is. And that’s because the only way to tell is if the message doesn’t get through.

Trystan appears to be in charge of the default sketches. Long ago, I suggested that it’s something which really ought to be in the boot message - but that suggestion was ignored.