AVR-DB: emonTx V4, new hardware in progress

OK. Thanks.
Sounds like I’m best off relocating the emonPi to the airing cupboard where I can get a cable to the heat monitor for the m-bus signal, and then put an emonTx where the emonPi used to do the sensing the emonPi used to.

1 Like

Yes that’s a good idea!

I think the firmware update needs a whole lot of explanation to help users.

I’m really not comfortable with the Firmware update being included in the ‘Full Update’ as there are so many options - are the currently selected items in this part used? I’d definitely like that broken out into a separate page on EmonCMS.

Can you update the EmonPi to match the new version on the TX4? Obviously (to us) all devices need to be on the same type of RFM format.

Using the wrong firmware on the wrong port (How do you check) will be disastrous. I think the ttyS0 port is the EmonPi daughter board. If selected there really needs to be a warning to that effect!

As I say, I sort of know what is happening, but I’m always a bit scared when I hit ‘Full Update’!

Its relatively robust, I think I did that once in error when trying to update an EmonTX via USB and had the EmonPi board selected in error - it survived anyway not sure if it presented an error or just didn’t flash but it is very easy to do. Not sure how many really use EmonPi to update EmonTX though?

It is more the fact there are multiple options. It just always makes me nervous and it is updated so rarely, I think splitting it out would simplify things :slight_smile:

I’ve added a Adding an emonTx4 to an existing installation page to the documentation. It details both the USB direct link option and the radio option, including how to switch the firmware.


We have also added an option to the shop entry to select either the standard firmware (default) or the version that is compatible with the existing hardware radio format. This should hopefully make it a little easier for existing customers who want this to work out of the box using the original JeeLib radio format:


We will also be releasing a new set of firmware’s for existing hardware soon that can use the new LowPowerLabs radio format which offers hardware encryption and a packet acknowledgment/retry mechanism to minimize packet loss. The EmonTH2 and emonBase firmware for this are already ready here and here, both of which are available in the emonPi/emonBase upload tool already. I just need to do the emonTx3 and emonPi versions.

Yes I think your right, I will remove it from the full update and move the firmware update tool to its own page.


First Im going to do a documentation page on the voltage sensor options for the emonTx4 and get the emonVs mini in the shop :slight_smile:

1 Like

waits patiently counting money

1 Like

Hello @whitecitadel a little late in the day but here it is :slight_smile:

and an initial page on the different voltage sensor options, I want to add some more detail to this soon but hopefully gives a good overview for the time-being: Voltage sensors — OpenEnergyMonitor 0.0.1 documentation

1 Like

Hello, quick question about the emonvs-mini. Can it also be used for the emonpi voltage input at the same time ?

Not until the ‘new’ emonPi, which will use the same AVR-DB processor as the emonTx V4, appears.
The reason: The output voltage of the emonVS is a nominal 0.333 V rms, not the 11 V rms that comes from the Ideal a.c. adapter. It would “work” after a fashion after recalibration, the resolution would be pathetic. It would also need a splitter to provide the necessary d.c. barrel jack.

1 Like

That’s great thanks, quick question is EmonTx4 with the emonvms going to be more accurate than the EmonPi?

It’s a CT question, as at the moment the EmonPi has the house CU and solar on its two CT, but I am wondering if moving the Solar to the EmonTx4 may give a more accurate reading.

What I monitor where with what affects what CT I buy now we have the 20/50/100A options.

Thanks @whitecitadel

Yes, The largest source of improvement in accuracy is coming from the combination of the higher accuracy voltage sensor and higher accuracy CT current sensors. Both the original ACAC adapter and the YHDC CT sensors had a tolerance or maximum error of ±3% (adding up to ±6% for the sensors alone - though with good calibration and likely spread of component tolerances, the likely error e.g a monte-carlo analysis was much less than the maximum possible). The new emonVs has a tolerance of 0.4% and the new CT sensors 0.5% (adding up to 0.9%).
The emonTx4 itself adds about 0.3% on top of that bringing the total maximum error in component and sensor tolerances to ~1.2%. Which is a pretty substantial improvement.

On top of that the support for a wider range of current sensor ratings with the emonTx4 means that you can select a CT sensor that is better suited for the current range of your solar. If the solar is on a 16A or 20A circuit you can select a 20A CT sensor, which will then make better use of the analog to digital (ADC) converter resolution on the microcontroller.

Next the ADC has 4x the resolution of the Atmega328, it’s a 12-bit ADC vs the 10-bit original. The sample rate is also 3 times higher.

The firmware running on the emonTx4 is currently almost identical to the firmware that we were using for the emonTx v3.4. It implements continuous sampling and basic phase calibration. The next area @Robert.Wall is working on to improve things further is to implement dynamic phase calibration. We currently do phase calibration in quite a simple way with a single fixed value, the voltage sensor and CT sensors in reality have a varying phase error based on voltage and current and so the idea is to adjust this phase calibration dynamically. The intention is to provide this as a firmware update sometime next year.

Edit: Following some useful input from Robert, I’ve decided to drop the default sample rate a little on the current firmware. The sample duration is now down to 2.6x the original this gives slightly better zero value performance (v1.5.3). The sample rate for a full set of 1 voltage and 6 CT sensors vs 1V and 4CT sensors on the emonTx4 is 1.9x which is really the more relevant comparison. The sample rate is very much firmware implementation related so is likely to change in future.


I’d cut and paste this into the docs!

1 Like

Thanks that’s interesting.

Can the new CT be extended with twister pair or mic cable like the old ones, or do we need a “pioneer” or test it?

My solar is on a 32A circuit as I have 5kW inverter, so 50A CT needed, I had to make adjustments in Emoncms to match the measurement to what the SMA inverter is really producing (pulled in via Bluetooth) so more accuracy would be welcome.


Yes, @Robert.Wall’s original documentation for this has got voltage output CT sensors covered as well: https://docs.openenergymonitor.org/electricity-monitoring/ct-sensors/extending-ct-cable.html

Just to check, in this para Voltage sensors — OpenEnergyMonitor 0.0.1 documentation you say, “The emonTx4 will require a separate power supply/source when used with this voltage sensor.

I note your installation photo is just using the Mini and I’m happily running a TX4 with just the Mini (and and ESP8266). Is your statement belt and braces?

My installation is the full emonVs-psu (voltage sensor and power supply). I sent you both the emonVs-psu and the emonVs-mini so you must be using the larger one unless there’s some magic going on! :slight_smile: there’s no power supply components in the mini…

Ha, no, I wasn’t doing what I thought I was doing - sorry. It was that I was just plugging in the RJ11 plug and not the USB as well :frowning: Confused by the fact you only have one wire coming out of the EmonVS :slight_smile:

So on the full VS the RJ11 is providing power and AC sensor and the EmonVS-Mini just provides the AC sensor. Correct? If so, good to understand that :slight_smile: