But you’re getting readings back more frequent than that? Your call, but if it were me I’d be wanting to get to the bottom of that. You might end up with all sorts of strange beat effects if you’re not sampling when you think you are or picking up the same reading twice.
Interesting. I wonder if you could have done away with the mid-rail and just used 0V as a mid-rail. That’s how most energy ICs work too, the V and I signals swing either side of GND.
Yes, I think the STM32F0 development board I got is about US$11, complete with Arduino headers. Alas, no wifi though so that’s a big plus there for your ESP8266. It’s all starting to make the old traditional Arduino stuff look as historic and folkloric as a black-and-white TV though.
Yes, when it comes to calculating the maximum (or minimum sub-zero) voltage you’re going to subject your ADC input pin to, it’s the peak that matters. In the case of I, your current signal might be a long way from a sinewave and very peaky so a simple root-2 multiplier is generally not enough. Robert has a rule-of-thumb multiplier he uses that takes into account some level of peakiness and component tolerances, but I can’t find it right now. You may be able to find it with a search.
Yes you have a valid point, I will experiment, and maybe adjust some timers. Right now it works in a mode they call “continuous”, you can poll as much as you want but the value doesn’t get updated as fast, that’s why sometimes I will get the same value twice. But as you can see the sine isn’t that bad. or is it?
UGH. I Why didn’t I think about that earlier. That’s a major change though, now I would have to remove the divider right?
Haha, I’m with you there, that’s actually what is running the CT now, an old UNO, the ADC is pretty good though (fast at least)
Ha! I didn’t get that in the Resource section, they are just using root2! Very good point!
Now that you mention it, and have encouraged me to zoom in, I think I can see kinks in your sine where it’s “slipped”. At over 1 msec per sample, I can see why you’ve taken the approach you have… you’re presumably trying to overlap your CPU processing time with the conversion time? My gut feel is you want to be sampling the signal at a constant rate and that can’t be faster than 860 SPS. I suspect going faster than that, and reusing previous conversion results will do more harm than good to your accuracy, although that’s more a gut feel than a serious calculation. Assuming your processing time is less than your conversion time, perhaps you could get the overlap by:
for required measurement time:
. wait for a conversion to complete
. do the processing
That way you’re being “clocked” by the ADC, and while it’s busy converting the next result, you’re processing the previous one and hopefully getting back to step 1 well before the next one is ready.
A very quick scan of the datasheet made me think you can’t feed it voltages below GND, so it probably makes sense to stick with what you have. It looks like you’ll only get negative readings in differential mode, but I haven’t studied it in detail.
Pffff… the STM32 can deliver 104 12-bit conversions right to my C array in the time it takes the Uno to do one 10-bit conversion, and it’s a $2 part! OK, OK, that’s probably not want you want to hear right now… I’ll stop …soon ;-).
It’s about now I usually dust off this pic of my lights circuit (compact fluros). This circuit was drawing 893mA RMS at the time and you can see the peak current exceeds 3A, so needs a multiplier of 3.36 there. While that is a real circuit, the numbers are still quite small. It’s unlikely anyone will have designed things so that they start clipping at 3A. With much bigger whole-house aggregate signals, you’re unlikely to see anything anywhere near that peaky (power factor regulations don’t allow it), but it illustrates the issue.
Here is a zoomed in view of the “blips” I get in the waveform.
The loop that samples is pretty fast in the Emon code as it’s not doing much, just a little bit of math with each iteration, I don’t think I should be concerned with with. I could just add a delay() with a value TBD to get reliable reading I think, I’ll probably do that.
OK, the rule of thumb is:
1.1 V rms for an emonTx or anything running off 3.3 V
1.6 V rms for an Arduino or anything running off 5 V.
Those numbers take into account tolerances on the transformers (voltage or current), the bias chain offset and voltage divider or burden resistor tolerances, plus a few percent for waveform distortion. The reasons for not allowing 3 times are (1) the voltage wave won’t be anywhere near that in its crest factor, and a high current load that approaches the peak design current is much more likely* to have a wave shape that is close to the shape of the voltage wave, and (2) most people require good accuracy at low currents, so throwing away a third (or whatever) of the resolution is for most people a bad idea.
If you are designing your system properly, and you know the current wave shape, then the right way to do it is to use the peak value that you know about, and add the circuit tolerances on top of that.
*[The high current load is likely to be well-behaved because of legislation regarding harmonic pollution of the supply.]
That’ll certainly help, but you’ll still have two asynchronous clocks (the ESP clock and the ADC oscillator) that will eventually slip past each other. If you can time the delay accurately enough it may happen so rarely you never notice. The idea behind the pseudo-code loop above was to eliminate one clock altogether (the ESP clock) and let the ADC dictate when things happen.
Hello
I appreciate it’s been a while since since this topic has been active but I have been finding it very useful. I opened another topic for my specific setup but the problem that I am facing at the minute is calibrating the readings (Power meter using Raspberry pi & SEN0211)
