Indeed - the “fixed in stone” data packet that always includes all powers, 6 temperature measurements and a pulse count is an example. I can see that this approach should work for everybody, but in the olden days before OEM became “plug and play”, everybody customised everything to their own needs - and it seemed to work.
For some reason I missed that you had updated the EmonLibCM library @Robert.Wall. I’ve now updated the version on github and the EmonTxV3 firmware above is now working great! Thanks a lot @Robert.Wall for your work on the update.
Should be ready for you to test now @djh @electrojim unless you beat me to it?
Note: I had to update my copy of the OneWire library as it have an error about a missing onewire.begin function
1 Like
Hi @TrystanLea, @bazscuba1 and I have both been running for a while, looks to be working well, even down to 0.5 seconds update rate for our crazy solar energy diversion/control projects.
Thanks for the heads up though!
Best regards,
James.
3 Likes
I’ve changed the default nodeid to 15 so that EmonTxCM units do not conflict with existing emonhub node decoders. change default node to 15 · openenergymonitor/EmonTxV3CM@5799b73 · GitHub
Running emonpi update on emonSD systems will also install the node decoder automatically on update.
Troubleshooting: If after uploading the latest firmware the node does not appear under the expected node 15 id, check that the nodeid has not been set manually in the EmonTx EEPROM, see +++ [enter] at startup.
I’m happy to announce that we are now shipping the EmonTxV3CM continuous monitoring firmware as the default firmware on EmonTx units from our shop.
I have updated the EmonTx product page here accordingly:
emonTx - Energy Monitor Transmitter - Shop | OpenEnergyMonitor
and added a note to the top of the discreet sampling firmware repository here:
emontx3/README.md at master · openenergymonitor/emontx3 · GitHub
If the 3x AA battery holder option is selected when ordering an EmonTx through the shop we upload the discreet firmware rather than the continuous monitoring firmware (which is not compatible with battery powered operation as the EmonTx does not go to sleep). I’ve added a note to the EmonTx product page to explain this.
Thankyou again to @Robert.Wall for all of your hard work on EmonLibCM.
1 Like
Excellent.
Is the hex file in the release page a pre-compiled binary that can just be uploaded? If so, could this be referenced in the readme please plus some instructions on how to upload it (although I suspect this can be referenced from elsewhere)?
1 Like
From emontx3/README.md at master · openenergymonitor/emontx3 · GitHub
“the new firmware provides better results by sampling continuously for the entire 10s measurement window rather than in discreet chunks.”
Is that not a little confusing? Wouldn’t it be clearer to say that the sampling is continuous, the resulting data is averaged over 10 s periods and that average is reported every 10 s?
And the chunks are discrete (separate), not discreet (confidential).
Thanks Robert, does the following work:
The default EmonTxV3 firmware is now the EmonTxV3CM Continuous Monitoring firmware, the new firmware provides better results by sampling continuously with the average reported at the end of each 10s period. This differs from the discrete sampling firmware which takes 0.3s long snapshots for each CT channel in every 10s period. Continuous sampling increases power consumption by a very small amount as the EmonTx cannot go to sleep and so is not compatible with battery operation. For battery operation use the discrete sampling firmware below.
That’s fine, except of course the discrete sample snapshot is 30 half-wavelengths long, which is 0.3 s in the 50 Hz world, but 0.25 s in the 60 Hz world, and approximately 0.3 s if you aren’t using the a.c. adapter.
So maybe it’s best to write “…which takes 0.25 – 0.3s long snapshots…” and avoid being specific here, the exact details of the workings of emonLib would be more properly presented in GitHub - openenergymonitor/EmonLib: Electricity monitoring library - install in Arduino IDE's libraries folder then restart the IDE
1 Like
Has anyone else had issues where their emonTx seems to stop transmitting data since using this firmware? Power cycling brings it back up for a few days but it’s now happened 3 times since the 22nd October.
It’s an emonTx 3.4 with the provided UK AC-AC adaptor to power it. There are 3 CT’s (SCT13) and no other items connected. All bought together from the shop in July 2019.
I built the firmware from commit 2c95e19 using pio. The only difference being iCal2/iCal3 values were divided by 4 to account for the CT’s having 4 loops of wire through them.
Any tips on how I can help debug this?
What is your mains voltage around the time it stops?
I don’t and cannot use platformio, so all my tests were done with the standard Arduino IDE build. The longest continuous run I have a record of is 10/7/18 to 27/8/18, I don’t think I ran many continuous tests for that length of time, and I didn’t experience any unintended stoppages.
I was also using my own sketches, not the one published very recently.
When it stopped sending data, the last recorded voltages were 247.5, 247.5 and 248.5. The minimum and maximum recorded levels are 245.8 and 254.2 although I’ve never checked or calibrated the voltage input.
I’ll see if I can get my head round the standard Arduino IDE build as it’s not something I’ve tried previously.
I can now build the firmware using Arduino IDE, are there any suggested versions of the various libraries?
EmonTxCM.ino states it was “Tested with JeeLib 10 April 2017” which I guess would tally with commit 9b5537f?
EmonLibCM points to DallasTemperature_LATEST.zip but gives no actual version number.
I’m currently have the following versions:
EmonTxV3CM - 2c95e19
EmonLibCM - d4dd94d
dallas-temperature-control - latest (3.7.2 BETA)
jeelib - 741e8e3
OneWire - 0fa5e7a (2.3.5)
edit:
For reference, platformio appears to be using:
EmonTxV3CM - 2c95e19
EmonLibCM - d4dd94d
dallas-temperature-control - 3.7.7 ← different
jeelib - c057b5f ← different
OneWire - 2.3.5
I’m not aware of any recent problems with particular versions of the libraries. I’m probably using quite old versions.
Dallas: 11 Dec 2011 (V.7.2 Beta)
Jeelib: 10 June 2018
OneWire: 10 June 2018
emonLibCM: 25 Oct 2019
My test sketches are bundled in the zip file with the library & documentation.
@langers2k
I’m looking for a possible cause of your stoppage. Can you tell me exactly what hardware you have;
a.c. adapter model no, which model emonTx (probably V3.4.4) or when it was purchased, and whether you have anything else connected apart from c.t’s.
From what I’ve been able to determine so far, there’s not a single obvious cause.
As I mentioned above, it’s an emonTx 3.4 with the provided UK AC-AC adaptor to power it. There are 3 CT’s (SCT13) and no other items connected. All bought together from the shop in July 2019.
I’ll confirm the exact part number on the AC adaptor tomorrow or Monday when I’m home. I assume the emonTX PCB will have 3.4.4 (or similar) on it somewhere?
I built the firmware using the Arduino IDE and the same library versions as you have, or at least it was the last commit in each library before the date you mentioned, and it survived about 3 days before it stopped broadcasting.
Does it provide any useful logs as default as I should be able to connect a serial port if it’s helpful.
I think that’s enough. If bought in July, it’s almost certain to be a 3.4.4 (though it says 3.4.3 on the silk screen).
Connecting to the serial port won’t help, all it sends is the same data that’s broadcast. There’s not enough memory for logging and such, and it wouldn’t survive the reset anyway unless written to EEPROM (and there’s precious little of that).
What I’ve found so far is it doesn’t appear it’s voltage on its own, nor temperature on its own, but it does look very much like a power supply issue. I set one up for test powered only by the a.c adapter, and it failed twice, the first time in the wee small hours, the second time within 45 mins. But with a 5 V d.c. supply and at an ambient going down from 8.5 to 6.5 °C, it’s run for 24 hours and still going. And it ran for 5 weeks during July and August on the a.c. only power. For the last few days, it’s also had a temperature and an optical pulse sensor attached.
The AVR will almost certainly still be running and is probably stuck in a loop waiting for some external h/w to complete some transaction that’s never going to happen. I had a very similar situation a few years back (on different h/w) when a Vcc glitch was causing the BOD that monitors the Wiznet ethernet chip to reset it, while the internal BOD monitoring the AVR was set to a much lower threshold so wasn’t resetting. The Wiznet driver was in an indefinite loop waiting for the Wiznet to indicate a transaction had completed but that was never going to happen because the Wiznet had been reset mid-transaction. I’d start with the Jeelib code to see if there are any SPI polling loops that wait forever. If you can probe up the SPI bus while it’s hung, you may see lots of activity.
Increasing the AVR BOD threshold might help - that will at least cause the AVR to reset… assuming you can set it higher than the BOD in the RF module. How successful that will be depends on whether or not a freshly reset AVR can soft reset the RF module (in case it didn’t reset). Ideally you want the CPU BOD to be the most sensitive (have the highest V threshold) and for it to have a GPIO pin it can use to hard reset all external devices.
The AVR’s h/w wdog can also break you out if it is a loop as in the case described above. It has a mode where it generates an interrupt first - allowing you to capture state into non-volatile storage - and then generates a /RESET. Or you can even just stay in the ISR, continuously printing out state and patting the wdog to prevent the second stage /RESET.
Of course all of this only helps in the recovery, it doesn’t solve the root cause. But it can help determine the root cause.
Any variables you put in the .noinit section will be unmolested by the zeroing of .bss at start-up, so they’re somewhat non-volatile but they obviously won’t survive a full power fail. Just a single variable reflecting which bit of code you were in could be a good starting point. Here’s what I do in one of my sketches…
void loop () {
while (1) {
last_pid = 0xdead0001;
process_wdog();
last_pid = 0xdead0002;
process_energy_monitors();
last_pid = 0xdead0003;
process_pulse_counters();
last_pid = 0xdead0004;
process_tank_inputs();
last_pid = 0xdead0005;
process_leds();
last_pid = 0xdead0006;
process_temp_sensor();
last_pid = 0xdead0007;
process_network_layer();
last_pid = 0xdead0008;
process_host_requests();
last_pid = 0xdead0009;
process_ram_monitor();
last_pid = 0xdead000a;
process_uptime();
last_pid = 0xdead000b;
process_waveform_data();
last_pid = 0xdead000c;
process_maintenance_requests();
}
}