Emonlib Voltage reading offsets

Greetings everyone,
In tbe past I have used emonlib for a DIY project, and I more or less familiar with what it does.

There was a request to add the functionality to measure the main frequency using emonlib. Then I came across to the following link - [Measuring frequency from the EmonLib | Archived Forum]that someone has written in the past, and having some small modification I managed to get it work. ( Just want to add that I am using exactly the same configuartion for the voltage and current sensor proposed by openenergymonitor. )

Now it is a bit different story. My voltage sensor is made of one fullwave rectifier, a really small, about 1nF capacitor, and a voltage divider - 750K to 10K. The reason to use such a small capacitor is to have full sine wave rectifired not to smooth it, and to use the same approach as in the previous example for measuring frequency. However, I am really close to getting 50Hz reading all the time, but when I look into the .cpp file from Emonlib, and printing sampleV out on the serial plotter I can see some periof offsets in between some of the rectifired waves.

Please see the attached pictures for better understanding.

Are these “offsets” prodused by the emon library or can sameone give me an idea why the input signal looks like that? If this is what my Arduino Nano ADC input sees then frequency measurement is lost.

The measurements were captured without any load!


Welcome, Max, to the OEM forum.

I’d recommend you switch to using emonLibCM. You can dispense with the rectifier and revert to the plain voltage input straight into the ADC (suitably reduced of course), because emonLibCM can report frequency.

That will have a desirable side effect too - you’ll have the direction of real power available once more, which you’ve lost. (You could have done the rectification in software of course, after the signed value had been used in the power calculation.)

I suspect what you’re seeing there is an artifact of using a Serial.print statement after each sample - because that’s a notoriously slow process.

Hello Robert.Wall,
Thanks for the quick replay. I will try to switch to EmonLibCM. Is it compatible with the arduino nano (Atmel328pi) platform with its 10 bit resolution ADC? And does this solution ( having fullwave rectifier as input) will require some software modification in order to get the frequency or should be ok like it is?

Thanks in advance!

Read again what I wrote above - you must not use a full-wave rectifier on the voltage input. You will have incorrect voltage readings because of the way the d.c. offset is removed in the software, which also means the power readings will be incorrect, and you will lose the ability to know the direction of power flow.

Both libraries were written for the ATMega 328P. But you will need to change some default settings as these are specifically for the emonTx.

That’s okay! “You will have incorrect voltage readings because of the way the d.c. offset is removed in the software” would you please explore more, if we are considering Emonlib. I am interesting just for my information how the dc offset is manipulated into the code and what you mean actually.

I was assuming that the offset is required by the atmel328 adc since it simply cannot read negative values. Having full wave rectifier how this affects the normal voltage reading, from software side?

I will for sure remove it when testing the emonLibCM library.

Thanks again!

That is correct. But as soon as the value exists in digital form, the offset need to be removed so that you have once more a signal that is centred on zero and swings equally positive and negative. You should be able to subtract 511 from the number, but in practice this won’t work because the offset is never exactly 511 (because the resistors are never exactly equal), therefore (in emonLibCM) we assume the wave is symmetrical so the offset is actually the average value, this is very easy and quick to calculate and we subtract it after calculating the rms value and the power (instead of the much slower process of subtracting or filtering each sample individually). If you have a full-wave rectified wave, the average value is not the number you need, so all the calculations are using the wrong numbers.

Also, if you have a full-wave rectified waveform, your power calculation will be wrong. How power is calculated is explained here: An Introduction to AC Power — OpenEnergyMonitor 0.0.1 documentation and the next few pages.

Great! Great! Got it!
Hey, may I ask you for a conformation. For one of my application I am usign the “.cpp” file of the original emonLib. I am usign “analogRead(inPinV)” function to get the already shifted input voltage that swings around 512. The question is, if I just use the variable available in cpp emonlib file, for reading the i put of adc, this fariable is not filtered somewhere in emonlib, correct? Because i assume that this is just the raw values, and it it is not filtered out.

If that is the case, I am planning of designing a software filter to fitler inPinV.

sampleV is the variable which receives the voltage sample. you should not, and there is no need, to sample the voltage again with another analogRead(inPinV);

You are correct, 'sampleV` is not filtered, but it is not necessarily swinging about 512 - due to resistor tolerances, it might be centred on 508, or 515, or maybe even further from 512, It depends on the two resistors in the bias chain being exactly equal - to within 1 in 500, and this is not likely to be the case. This is why we must use a filter of some sort, otherwise the offset is an error. Provided the current offset is removed accurately, a voltage offset won’t affect the power, but it will affect the rms value of voltage, and you might see an error. I cannot say the same about current: because the smallest current you are likely to measure is about the same magnitude as the possible offset error, you will have a very significant error in low current readings.

Why? - there is already a filter - its output is in filteredV.