As they don’t fit my needs, I asked for clarification. The non-CM version shows the 3 nominal values for UK, EU and US.
Thanks, that actually answers my question.
One more thing I was wondering about this beta sketch which I am now pondering to use instead of the regular discrete sampling one. There are lines in it similar to the following:
if (analogRead(1) > 0) {CT1 = 1; CT_count++;} else CT1=0; // check to see if CT is connected to CT1 input, if so enable that channel
How does it reliably detect that there are CTs connected? I had the impression that the inputs are aligned to the center of the power rail using a resistor divider, so in effect the readout should be around 512, in other words, never zero. I admit I haven’t tested it yet as my EmonTX has its normal daily duty that I don’t want to interrupt (yet).
Look at the circuit diagram!
The socket has two “inner” connections that make contact with the tip and ring contacts only when a plug is not inserted. One of these is grounded, so when no plug is present (note: not quite the same as no c.t. is present), there’s a solid 0 V input to the ADC. It is that which is detected.
Those lines in the sketch are rather pointless anyway, in my opinion there’s no real need to disable scanning of unused channels - even when simultaneously handling 4 c.t’s, it runs at 1923 samples per channel per second, compared to about 2600 for the DS library. That’s only about 30% less samples per second than the DS library measuring just one c.t. And in any case, the library checks on every sample to see if the input is grounded, and if so, doesn’t process that channel, though this doesn’t affect the sample rate.
(1900 samples per second equates to the 19th harmonic of 50 Hz mains, and there should be very little energy at that frequency, according to the rules for harmonic injection into the supply.)
Indeed, I haven’t done my homework this time, sorry.
It’s cosmetic, I think. Having inputs in the system doing nothing and always showing zero (that also should have been a hint for me), pushing excess messages around the system just creates clutter.
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.