VRMS too high

Got my emonTX last year but only got it up and running today. Noticed that my VRMS reading is quite high. Is there any way to calibrate it without a UART programmer?

Here’s my setup:

5kw solar with Think-power inverter
EmonTX (v3.4 i think) + EU plug
EmonCMS on Ubuntu

The vrms reads 26922 while the inverter shows 243.5v.

In case a UART is required, can I use an RPi to flash the firmware? Any tutorial?

Follow up question. Have an arduino uno. Can I use that as a UART to the EmonTX? How?

Does vrms affect the readings from the CTs? The real time watts reading is also higher than what is displayed on my inverter.

  • Apologies if this is a noob question. Not an electrical engineer

Hi,
Yes/no. The CTs are reading current, and with the Vrms value, the software calculates the power.
So, if the Vrms is too high, you’ll read a power/energy that’s too high too.
I don’t know the software running on the EmonTx, but there should be somewhere a “calibration” value for Vrms.
Fred

Were you to look at the sketch, you would see that there are indeed calibration constants for voltage amplitude (for the a.c. adapter input), for current amplitude (for each current input) and for the combined phase error of the v.t. paired with each c.t.

But if @ishtangli’s emonTx is a year old, he will need to download the sketch, edit it and recompile before uploading it again to the emonTx. And for that, by far the easiest way is with a programmer from the Shop and Laptop computer. I use standard Arduino IDE, all the instructions are in the ‘Learn’ section.

1 Like

I checked the page calibrating emontx and also took a look at the latest source for EmonTXV3CM. The default set Vcal is 268.97 which is for the UK plug. Could that be the reason? If I change it to 260 which is what the document says for EU, will it be more accurate?

That means you’re most likely not using emonLibCM - that was only used in emonTx’s shipped after 18 October 2019.
But the principle is the same (and both the old emonLib and emonLibCM use the same calibration values for amplitude - but not for phase error correction). If you change the calibration from 268.97 to 260.0, then you will reduce the voltage reported in that proportion (260.0 ÷ 268.97 = 0.966)

The discrepancy you are seeing is much more than that - about 9.6%, so IF your inverter is accurate, the calibration value you want is 243.27
That will adjust the power and energy by exactly the same proportion.

How do I connect it to a programmer?

So after some fidling, I was able to get an arduino uno to act as a UART by shorting the reset and grd pins. Tested using putty and was able to get the output from the emonTX. Now the question is, how do I put the emonTX into programming mode without a programmer? Do I need to change anything on the ArduinoIDE (tools → programmer → ?)?

My setup:

Arduino UNO <-> emonTX
5v <-> 5v
tx <-> rx
rx <-> tx
gnd <-> gnd

Rst on Uno to Gnd on Uno

Flashed it by pushing the reset button when the IDE says uploading. Looks successful.

emonTx V3.4 EmonLibCM Continuous Monitoring V1.60
OpenEnergyMonitor.org
No EEPROM config
Settings:
Group 210, Node 15, Band 433 MHz

Calibration:
vCal = 243.27
i1Cal = 90.90
i1Lead = 4.20
i2Cal = 90.90
i2Lead = 4.20
i3Cal = 90.90
i3Lead = 4.20
i4Cal = 16.67
i4Lead = 6.00
datalog = 10.00
pulses = 1
pulse period = 100
temp_enable = 1
Temperature Sensors found = 0 of 1
Temperature measurement is NOT enabled.

RF whitened
RFM69CW only Node: 15 Freq: 433MHz Group: 210

POST…wait 10s
‘+++’ then [Enter] for config mode
NO CT’s detected
AC present

New problem. Now it just says AC present undefined on the emonESP and it’s not posting on the emonCMS anymore. No other inputs showing.

image

Dug further into the code. Looks like the reason it is not showing is because rf_whitening is set to a value.

the variable was initialed as

int rf_whitening = 2; // RF & data whitening - default = 2: RF is ON with whitening. See congig.ino for more.

On the display section,

if (rf_whitening)
{
  PayloadTX tmp = emontx;
  if (rf_whitening == 2)
  {
      byte WHITENING = 0x55;
      for (byte i = 0, *p = (byte *)&tmp; i < sizeof tmp; i++, p++)
          *p ^= (byte)WHITENING;
  }
  rfm_send((byte *)&tmp, sizeof(tmp), networkGroup, nodeID);     //send data
  delay(50);
}

// ---------------------------------------------------------------------
// Key:Value format, used by EmonESP & emonhub EmonHubTx3eInterfacer
// ---------------------------------------------------------------------
else
{
  Serial.print(F("MSG:")); Serial.print(emontx.Msg);
  Serial.print(F(",Vrms:")); Serial.print(emontx.Vrms*0.01);
  
  if (CT1) { Serial.print(F(",P1:")); Serial.print(emontx.P1); }
  if (CT2) { Serial.print(F(",P2:")); Serial.print(emontx.P2); }
  if (CT3) { Serial.print(F(",P3:")); Serial.print(emontx.P3); }
  if (CT4) { Serial.print(F(",P4:")); Serial.print(emontx.P4); }
  
  if (CT1) { Serial.print(F(",E1:")); Serial.print(emontx.E1); }
  if (CT2) { Serial.print(F(",E2:")); Serial.print(emontx.E2); }
  if (CT3) { Serial.print(F(",E3:")); Serial.print(emontx.E3); }
  if (CT4) { Serial.print(F(",E4:")); Serial.print(emontx.E4); }
  
  if (emontx.T1!=30000) { Serial.print(F(",T1:")); Serial.print(emontx.T1*0.01); }
  if (emontx.T2!=30000) { Serial.print(F(",T2:")); Serial.print(emontx.T2*0.01); }
  if (emontx.T3!=30000) { Serial.print(F(",T3:")); Serial.print(emontx.T3*0.01); }

  Serial.print(F(",pulse:")); Serial.println(emontx.pulse);  
  delay(20);
}

Bit confused on how it works though. On Config.ino it says:

Serial.print(rf_whitening ? (rf_whitening ==1 ? “RF on”:“RF whitened”):“RF off”); Serial.print(“\n”);

Since the variable was initialized, the statement if(rf_whitening) will never return false right?

Changed the code a bit to force display the values. Noticed that this is how the old FW did it.

if (rf_whitening)
{
  PayloadTX tmp = emontx;
  if (rf_whitening == 2)
  {
      byte WHITENING = 0x55;
      for (byte i = 0, *p = (byte *)&tmp; i < sizeof tmp; i++, p++)
          *p ^= (byte)WHITENING;
  }
  rfm_send((byte *)&tmp, sizeof(tmp), networkGroup, nodeID);     //send data
  delay(50);
}

// ---------------------------------------------------------------------
// Key:Value format, used by EmonESP & emonhub EmonHubTx3eInterfacer
// ---------------------------------------------------------------------
//--else
//--{
  Serial.print(F("MSG:")); Serial.print(emontx.Msg);
  Serial.print(F(",Vrms:")); Serial.print(emontx.Vrms*0.01);
  
  if (CT1) { Serial.print(F(",P1:")); Serial.print(emontx.P1); }
  if (CT2) { Serial.print(F(",P2:")); Serial.print(emontx.P2); }
  if (CT3) { Serial.print(F(",P3:")); Serial.print(emontx.P3); }
  if (CT4) { Serial.print(F(",P4:")); Serial.print(emontx.P4); }
  
  if (CT1) { Serial.print(F(",E1:")); Serial.print(emontx.E1); }
  if (CT2) { Serial.print(F(",E2:")); Serial.print(emontx.E2); }
  if (CT3) { Serial.print(F(",E3:")); Serial.print(emontx.E3); }
  if (CT4) { Serial.print(F(",E4:")); Serial.print(emontx.E4); }
  
  if (emontx.T1!=30000) { Serial.print(F(",T1:")); Serial.print(emontx.T1*0.01); }
  if (emontx.T2!=30000) { Serial.print(F(",T2:")); Serial.print(emontx.T2*0.01); }
  if (emontx.T3!=30000) { Serial.print(F(",T3:")); Serial.print(emontx.T3*0.01); }

  Serial.print(F(",pulse:")); Serial.println(emontx.pulse);  
  delay(20);
//--}

image

Last question, why are P1 and P2 getting values even if they are not connected to anything?

Nice job getting it figured out. thumbsup

Most likely it’s noise generated by the digital electronics getting into the analog circuitry of your emonTx. A switching mode power supply can also produce the same effect, i.e. noise “injection.”

The values you’re seeing are quite reasonable. In fact they’re less than what’s typically seen (~5 to 15)
under no-load conditions.

Thanks!

I have to say, it was REALLY SCARY!

Had to do a lot of research on how to turn an Arduino Uno into a TTL and to take that leap of faith hooking everything up and hoping I dont fry the emontx (or the Uno).

Did I do it correctly? Is there anything else I need to set? Will the git code be updated with this fix?

Looking at the ‘+++’ config, it seems it would have been better if I did it this way instead of rewriting the code. Will reflash tomorrow then try this method.

If you set “whitening = 0”, then it will switch the transmitter off and automatically switch the serial output for the ESP8266 on by virtue of the ‘else’ that you commented out !

int rf_whitening = 2;            // RF & data whitening - 0 = no RF, 1 = RF on, no whitening, default = 2: RF is ON with whitening.

So there was absolutely no need to change anything else in the sketch.

[After checking, I see that comment, which is in the version I created, has not been carried forward into Github. I have no idea why.]

Are you not aware that in ‘C’ (and inherited in C++) zero is false and anything else is true?
Therefore, if (whitening) accepts any non-zero value as true and output goes via the RFM, while a zero value falls through to the else block, which prints the serial output.

whitening is a variable you set depending on the type of output you want. It’s done that way because if the serial output is required, the radio won’t be needed and so to prevent damage to the RFM69CW if there’s no antenna fitted, should the transmitter power get accidentally turned up above the default setting, it’s not used.

Was not aware of this. Learned a lot today.

1 Like

Unfortunately it does mean that if you have an emonGLCD and bought the emonTx/ESP to report power/ac to emoncms.org it will not work without code modifications such as above. The older v1.4 did allow this out of the box so IMHO it probably shouldn’t have been up-issued to v1.7 but up the major number to v2.0 (or alternatively have an additional override as a more formal way of reverting the behaviour to maintain backward compatibility).

I’ve raised it as a issue on the repo if there’s any interest/developments so as not to continue the divergence of this thread from the OP but just wanted to indicate it caught me out too.
Thanks

The reasoning is explained above - it’s to avoid destroying the hardware if somebody accidentally or in ignorance turns the power up on a RFM69CW when there’s not an effective antenna fitted.

I have nothing to do with “the repo”, neither do I control version numbers - you’re entitled to raise it with the powers that be if you’re so concerned about the matter.