I am experimenting with EmonTX on an ESP-WROOM-32 dev kit/board.
Everything is connected exactly like on the Wiki page here
Quite often I get that the Irms value has a short peak/spike while the ADC value of the ESP32 stays perfectely stable.
Here I plotted the raw ADC value (red) and the calculated Irms value (blue), together with the code on the left.
I wasn’t aware that a small amount of noise can result in such peaks in the output value of the software.
I am using an SCT-013-030 current transformer (1VAC/30A) with internal burnden resistor in the following schematic
Looking later at your example code, even that isn’t telling the whole story. What you are plotting is the rms current averaged over 1480 samples (I’ve no idea what time that represents on your ESP32 - you should evaluate the sample rate and make the number of samples fit as closely as possible to an integer number of mains cycles), but the red “perfectely stable” is a single sample taken at the end of those 1480 samples. So it’s hardly representative of what emonLib is measuring.
Anecdotally, the greater proportion of cases of noise (non-zero readings) have always come for breadboarded construction. If your c.t. is 1 V at 30 A, then 200 mA is 6.6 mV.
While this isn’t particularly small in absolute terms, it’s at the sort of level where quite a lot of care is needed. So a custom p.c.b. that has been carefully laid out with attention given to the advice in the application notes should give you an improvement.
What sum are you doing there to get 81 - 82 ns/sample? I think your maths are way out. I make it a little over 12 μs per sample, which is much more believable.
1480 samples in 18ms is 82222 samples per second. That is where your 82.2 came from: 82.2 k samples per second.
The reason for the difference is probably the time to start and stop the measurement, which will be constant. So I suspect the calculation should be: it takes (123 - 18) ms to measure (10000 - 1480) samples, so 12.32 μs per sample. You want to sample for 200 ms, so that’s 16234 samples.
I think the 200 ms sampling period came from the need (or desire) to be able to operate the emonTx from batteries. Clearly, working for 0.2 s and then putting the processor to sleep for 9.8 s significantly extended battery life. And over time, that approach can be surprisingly accurate.
However, if you have a rapidly switched load, an induction cooker for example, then if the cooker cycles at (or a sub-multiple of) the 10 s sample rate, then you’re likely to always be sampling during an ‘on’ period or an ‘off’ period, so a large error might result. emonLibCM adopts a completely different approach and samples continuously, so removing that problem.
If you have mains power to your ESP32, there’s no need to take discrete samples once every 10 s. The longer the sampling period, the better the accuracy is likely to be. Sampling only current, you aren’t able to synchronise to the mains wave, and to get an accurate average, you really need to measure over an exact number of complete cycle, although where you start on the cycle doesn’t matter. Because you are sampling a lot faster than the '328P, you can afford to sample fewer cycles. You could sample 1 cycle (1623 samples) if you wanted, because one 1623rd part of a cycle error will make no real difference to the reading.
Now you know your sample rate, it’s clear why 1480 samples was a bad idea - you were not even measuring over 1 cycle of mains, you were missing about 10% of the cycle each time you measured.