EmonTxV4 firmware - Current and PF calibration printout incorrect

[jrbloom (Jon Bloom)]

Apologies if this has been reported already. I couldn’t find anything when I searched the forums.

I’m finally bringing up my customized emonTx4 board, and while debugging, noticed that the latest firmware (1.5.7) does not correctly output the I and PF values when the “c1” command is issued over serial .

The conversion from physical to logical channel numbers uses values 1-6, instead of the ADC channels numbers (3,4,5,6,8,9) provided in setup.

i.e. I think the code starting at “EmonTxV4.ino:461” should read:

// to show voltage, current & power factor for calibration:
Serial.print(F(",I1:")); Serial.print(EmonLibCM_getIrms(EmonLibCM_getLogicalChannel(3)),3);
Serial.print(F(",I2:")); Serial.print(EmonLibCM_getIrms(EmonLibCM_getLogicalChannel(4)),3);
Serial.print(F(",I3:")); Serial.print(EmonLibCM_getIrms(EmonLibCM_getLogicalChannel(5)),3);
Serial.print(F(",I4:")); Serial.print(EmonLibCM_getIrms(EmonLibCM_getLogicalChannel(6)),3);
Serial.print(F(",I5:")); Serial.print(EmonLibCM_getIrms(EmonLibCM_getLogicalChannel(8)),3);
Serial.print(F(",I6:")); Serial.print(EmonLibCM_getIrms(EmonLibCM_getLogicalChannel(9)),3);
  
Serial.print(F(",pf1:")); Serial.print(EmonLibCM_getPF(EmonLibCM_getLogicalChannel(3)),4);
Serial.print(F(",pf2:")); Serial.print(EmonLibCM_getPF(EmonLibCM_getLogicalChannel(4)),4);
Serial.print(F(",pf3:")); Serial.print(EmonLibCM_getPF(EmonLibCM_getLogicalChannel(5)),4);
Serial.print(F(",pf4:")); Serial.print(EmonLibCM_getPF(EmonLibCM_getLogicalChannel(6)),4);
Serial.print(F(",pf5:")); Serial.print(EmonLibCM_getPF(EmonLibCM_getLogicalChannel(8)),4);
Serial.print(F(",pf6:")); Serial.println(EmonLibCM_getPF(EmonLibCM_getLogicalChannel(9)),4);

Also, there is no implementation for the ‘a<xx.x>’ command to set the assumed Vrms. It should probably either be removed from the help text, or implemented. Not a big deal as it was trivial to hack in locally, but I thought it worth mentioning in case someone wants to tweak the mainline code.

[Robert.Wall]

I’m not sure why you’re quoting a sketch called “EmonTxV4.ino” that appears to use emonLibCM. The correct library to use with the emonTx4 is emonLibDB.

The emonLibCM used the concept of “logical” inputs so that it was possible for the application sketch to define the order in which the physical channels were measured. The additional complication of the possibility of three phases and 12 power channels meant that it became impractical to continue this and so the order in which the channels are read is fixed and emonLibDB refers now only to the physical channels.

Again, it was impractical to implement the additional code to operate without the voltage reference (the only reason for needing an assumed supply voltage) because the emonTxV4 is designed to work with the emonVS, and so the mains sample voltage should always be available while the general power supply is present, hence the true rms voltage should always be known. (And if it isn’t, the emonTx4 will stop working very very soon.)

[jrbloom (Jon Bloom)]

Hi Robert.

Thanks for the reply. I am following the instructions here:

https://docs.openenergymonitor.org/emontx4/firmware.html#how-to-compile-and-upload-firmware

This indicates that the correct firmware is EmonTxV4. And the EmonTxV4 sketch at that location #includes EmonLibCM.

Am I following the wrong instructions?

Re Vsense - Yes, I do intend to use voltage sensing (which is integrated into the same pcb on my setup). But I am starting with the CT’s on their own. I am just testing the board at this stage. Vs is next on my list.

Thanks

Jon

[Robert.Wall]

EmonLibDB was released in May, so the documentation clearly hasn’t been updated.

[jrbloom (Jon Bloom)]

Please can you point me at the correct git branch if EmonTxV4 is now defunct.

Thanks

Jon

[Robert.Wall]

Sorry, I don’t know about Git branches.

The emonLibDB library was published here in the forum, and full documentation and example sketches showing the use of the API calls are included in the download zip file.

EmonLibDB - Version 1.0.2

EmonLibDB is a Continuous Monitoring library specifically for the EmonTx4 energy monitor. It is able to monitor continuously 3 voltage channels and 12 current/power/energy channels, three pulse inputs (or two pulse inputs and one low voltage analogue input). It has has not been possible to include temperature measurement. Like emonLibCM, emonLibDB will always give an accurate measurement of the average over the reporting period of the voltage, and for each current/power channel the current, r…

[jrbloom (Jon Bloom)]

Ok, I saw that post, but it seemed to be oriented around 12 channels, and it doesn’t support temperature probes. So I don’t understand how it can replace the CM based firmware. Isn’t it one of the firmware options, with the CM based (EmonTxV4) firmware still required for those that need temperature, but have fewer CT’s?

In any case I think we’ve strayed from the point of my original post, which is to highlight that the EmonTxV4 firmware, which surely is the more dominant firmware right now, has a bug in the Current and power factor output. Per Github this firmware is “latest”, precompiled, and uses EmonLibCM (I also checked EmonTxV4_6X_temperature which is essentially the same). So, anyone using ‘latest’ 6Chan precompiled firmware will not get valid results from the ‘c1’ command.

It seems strange that you don’t want to at least check the code to confirm whether I’m having a brain-fart moment (entirely possible), but my intention was only to let you know about the bug. I’ve fixed it locally so am not affected by this. Prior to my fix, I got garbage out. Now my Current values correlate with my Fluke.

[Robert.Wall]

That sketch is not mine, I’d need to study it and replicate the problem, and when I’d done this, I still cannot make any necessary change.

I’m sorry I wasted my time trying to help you.

[jrbloom (Jon Bloom)]

@Robert.Wall - I am very sorry if my post came over as an attack. It honestly wasn’t meant to. I DO appreciate you responding, and I wasn’t trying to be difficult.

The problem with text based communication is that it’s very hard to convey emotion - even with emoticons. And technical types like myself can be poor communicators at the best of times, making text doubly perilous.

That said, I did wrongly assume that since you replied, and are clearly a major player on the project, you were authoritative on the firmware, which is why it seemed strange that you were concentrating on the library, rather than what I believe to be the source of the bug.

From your replies, and more digging on my part, I think the bug report is still valid, and probably should be looked into. But I am happy with the progress I am making since fixing the bug locally, making this post simply an FYI.

Again, I am sorry for my poor communication.

Jon

[TrystanLea]

Sorry @jrbloom this should really be on me to reply. https://github.com/openenergymonitor/emontx4/tree/main/firmware/EmonTxV4 is still an active firmware for single phase 6CT sensors (with temperature sensing support, emonlibDB firmwares are newer but this is still actively used).

Now I thought I had fixed this issue with the I and PF channel allocation, i will check this on an emontx4 tomorrow and get back to you

[jrbloom (Jon Bloom)]

Thanks @TrystanLea, and as mentioned, no urgency here. Noone else seems to have noticed (Or I really have pulled the wrong branch somehow).