emonTx4, emonPi2, emonTx5 14th May 2024 firmware release

With the upcoming release of the emonTx5 I found myself creating another set of AVR-DB firmwares that were mostly identical to the firmwares running on the emonTx4 and emonPi2. The number of firmware variants would have grown to ~18 firmwares and it was getting cumbersome to use a file compare tool to make sure that the firmwares stayed mostly the same.

I decided to bite the bullet and try to rationalise the available firmwares by creating a common set of base firmwares for all three hardware units, with #define compile options to apply specific hardware variant changes among other options.

This works is now done and the new set of firmwares have been released. The emoncms pre-compiled firmware upload tool and the command line emonupload.py tool have also been updated.


If you already have a working emonTx4 or emonPi2 system, there is NO NEED TO UPDATE your existing firmware. While there are changes to serial configuration, if you already have a calibrated system and dont need to use this tool then there is no rush to update.


The available firmwares and descriptions of capabilities are listed on the firmware page for each hardware variant:

These list the pre-compiled firmwares available via the update tool and reference the base firmwares that each firmware is built from. To give an example, the standard emonPi2 1phase 6CT firmware: emonPi2_DB_6CT_1phase is built from the base firmware emon_DB_6CT.

This table gives a good overview of the available pre-compiled firmwares for each hardware variant and their capabilities:

Hardware Firmware CT’s Channels Temperature Sensors Pulse
EmonTx4 emonTx4_CM_6CT_temperature 6 3 (6 optional) 1
emonTx4_DB_6CT_1phase 6 0 1*
emonTx4_DB_6CT_3phase 6 0 1*
emon_DB_12CT (1-3 phase) 12 0 3*
EmonTx5 emonTx5_CM_6CT_temperature 6 3 (6 optional) 1
emonTx5_DB_6CT_1phase 6 0 1*
emonTx5_DB_6CT_3phase 6 0 1*
emon_DB_12CT (1-3 phase) 12 0 3*
emonPi2 (Zero) emonPi2_DB_6CT_1phase 6 6+ (Pi) 1*
emonPi2_DB_6CT_3phase 6 6+ (Pi) 1*
emon_DB_12CT (1-3 phase) 12 6+ (Pi) 3*
emonPi2_CM_6CT (current only) 6 6+ (Pi) 1
emonPi2 (Pi4) emonPi2_DB_6CT_1phase 6 6+ (Pi) 1*
emonPi2_DB_6CT_3phase 6 6+ (Pi) 1*
emonPi2_CM_6CT (current only) 6 6+ (Pi) 1

These are built from 3 base firmwares in the avrdb_firmware repository:

Emoncms Serial Config tool

As part of this firmware update, there is also an update to the Emoncms Serial Config tool used to set CT sensor calibration values among other settings. If you need to use this tool please update Emoncms to the latest version (currently 11.5.4).

This is what the new version of this tool looks like:

When used with the latest firmware loaded to the device, it now shows the hardware variant, base firmware, firmware version, 1phase/3phase, emon library etc. This information is all printed clearly by the new firmware so that it can be picked up by the serial config tool.

It is also possible now to change the pulse period, datalog period and serial data format from the user interface. Radio settings can also be changed on the emonTx4 and emonTx5 but are hidden when an emonPi2 is connected as the Pi handles these separately via emonHub.

I’ve also updated the serial configuration calibration format for emonLibCM based firmwares to use the same approach as emonLibDB. E.g to calibrate CT1 to be a 20A CT sensor with phase correction of 3.2 degrees, the underlying serial command for both emonLibCM and emonLibDB based firmwares now looks like this:

k1 20.0 3.2 

If you are used to entering these manually this is just something to watch out for. The serial config tool handles this for you otherwise.

The serial configuration tool has also been updated at Serial Monitor.


If anyone has any questions about the above, please feel free to ask!

Thanks for the updates and all the work involved.

Taking up the invitation to ask a question :blush:

I see that the emon_DB_12CT firmware link above does not have a corresponding
emon_DB_12CT_config.ino file, so does the Emoncms Serial Config tool work on a 12CT unit?

Thanks @rupert

This update doesn’t include adding serial configuration to the 12 CT firmware. Im going to try and look at that over the next week :slight_smile:

Reasons to update firmware to the latest release (if you don’t need any of these then there is no immediate need):

  • To change the datalog period on the hardware e.g change from 9.8s to 5s data (this is a bug fix)
  • To change the pulse sensor min period.
  • To use the analog input port on the emonPi2 /Tx5 for pulse counting with ease.
  • To change CT sensor or voltage sensor calibration if you have recently updated emoncms, the new interface requires updated firmware.

Hope that helps.

Thanks for the answer :+1:

1 Like

Is the serial config tool backward compatible? Can you fully define ‘latest’ - release date/version? Does this just add UI functionality that was previously available via the CLI?

Ah, that isn’t good IMHO.

The alternative is a whole load of messy code unfortunately. My rationale here was that folk who have already setup their systems on a particular firmware won’t need to use this tool. The times this tool is used is during significant reconfiguration and these points are a good time to update firmware.

The tool still allows fallback to written command configuration, which is also documented.

The command format is mostly the same, there are just a few small differences in what is printed, il post and example shortly

I think this should be very clearly stated at the top of the page, that the UI tool only works with Firmware and Hardware X otherwise the CLI interface must be used.

Ah :slight_smile: I did think about this, the tool detects older firmware and gives a clear warning message and instructions to start the command line process if required:

1 Like

For reference this is an example print out from the original EmonTx4 firmware v1.5.7:

emonTx V4 CM Continuous Monitoring V1.5.7

OpenEnergyMonitor.org
No EEPROM config
Settings:
Band 433 MHz, Group 210, Node 17, 7 dBm
Calibration:
vCal = 807.86
assumedV = 240.00
i1Cal = 300.30
i1Lead = 3.20
i2Cal = 150.15
i2Lead = 3.20
i3Cal = 150.15
i3Lead = 3.20
i4Cal = 60.06
i4Lead = 3.20
i5Cal = 60.06
i5Lead = 3.20
i6Cal = 60.06
i6Lead = 3.20
datalog = 9.80
pulses = 1
pulse period = 100
RF on
temp_enable = 1
JSON Format Off
RFM69CW  Freq: 433MHz Group: 210 Node: 17 
RadioFormat: LowPowerLabs
Reference voltage calibration: 1.0265
Temperature Sensors found = 0 of 3
Temperature measurement is enabled.

No temperature sensors detected, disabling temperature
AC missing - Apparent Power calc enabled, assuming 240.00 V
MSG:1,Vrms:240.00,P1:433,P2:217,P3:217,P4:87,P5:87,P6:87,E1:0,E2:-1,E3:1,E4:0,E5:0,E6:0,pulse:0
MSG:2,Vrms:240.00,P1:11,P2:6,P3:6,P4:2,P5:2,P6:2,E1:0,E2:-1,E3:1,E4:0,E5:0,E6:0,pulse:0

and then the new emonTx4_CM_temperature firmware v1.6.0:

firmware = emon_CM_6CT_temperature
version = 1.6.0
hardware = emonTx4
voltage = 1phase
No EEPROM config
vCal = 101.10
assumedV = 240.00
iCal1 = 100.00, iLead1 = 3.20
iCal2 = 50.00, iLead2 = 3.20
iCal3 = 50.00, iLead3 = 3.20
iCal4 = 20.00, iLead4 = 3.20
iCal5 = 20.00, iLead5 = 3.20
iCal6 = 20.00, iLead6 = 3.20
pulse = 3, pulsePeriod = 100ms
RF = on, rfBand = 433 MHz, rfGroup = 210, rfNode = 17, rfPower = 25, rfFormat = LowPowerLabs
datalog = 9.80
json = off
vrefa = 1.0264
Temperature Sensors found = 0 of 3
Temperature measurement is enabled.

No temperature sensors detected, disabling temperature
temp_enable = 0
AC missing - Apparent Power calc enabled, assuming 240.00 V
MSG:1,Vrms:240.00,P1:432,P2:217,P3:217,P4:87,P5:87,P6:87,E1:0,E2:-1,E3:1,E4:0,E5:0,E6:0,pulse:0

There is now a bit more consistency in the format of the printed settings, including printed firmware and hardware details. Settings or configuration to be picked up by the tool needs to follow the format:

key = value

This is to distinguish from data that is passed through, which follows either:

key: value, 

or json:

{"key":value}

The actual serial commands are all the same, the change is only in the way the configuration are printed back from the device.

1 Like

12 CT firmware with serial config on the way! Compiled firmwares are uploaded and I’ve made a small update to the emoncms serial config module. Just need to update the documentation now.

Wow that was quick! Thanks for the update.

I think the inclusion of the information below

firmware = emon_CM_6CT_temperature
version = 1.6.0
hardware = emonTx4
voltage = 1phase
RF = on, rfBand = 433 MHz, rfGroup = 210, rfNode = 17, rfPower = 25, rfFormat = LowPowerLabs

in the serial start up will be really useful, especially during troubleshooting. When trying to help troubleshoot user’s problems on the forum, it is sometimes difficult to determine what hardware and firmware they are using. For example, what is thought to be an emonPi may turn out to be an emonBase!

In particular the rfFormat information will be useful as OEM transitions from Jeelib to LPL.

I wonder if this could be added to older products as and if / when new firmware is introduced for them?

1 Like

Thanks! yes good idea to introduce this on older firmware as and when they are updated.

And worse, some users don’t know the two are different. :exploding_head:

Allied to this, please can we have a readily accessible list of dates when the first of anything “new” (hardware or software) was shipped or otherwise became available – or for that matter became unavailable.
Given that, it would reduce the guessing game a bit more still - especially for the older items.

@Robert.Wall

The topic

provides some good information on the hardware …

Yes, that’s only part of the story.

If you look, I wrote the first response to that topic.

1 Like

Hi Trystan, For the pulse input I presume the period is in milliseconds? Can you indicate how one should use this value for a given pulse length - is it just the same value ? e.g. For my Linky meter the pulses are nice square 20ms duration, so value to enter is just 20? For the UK I guess the default is 100ms? Thanks

Do you mean the pulse minimum period in EmonLibDB_setPulseMinPeriod(uint8_t channel, uint16_t _period, [uint8_t _edge=FALLING]) ?

In short, NO! The full explanation of how the library uses the pulse minimum period value is in the emonLibCM or emonLibDB documentation (look at the library that your sketch uses). If you have an “electronic” output, which will of course not suffer contact bounce, you should use ZERO for the period.