The importance of continuous sampling

(dBC) #1

I got a chance to put a scope current probe on a 2200W induction hob recently to see for myself why it’s often quoted as an example of a load where true continuous sampling is required for decent accuracy. You can see just how much the current draw changes from cycle to cycle here:

There’s close to 7% variation in cycles in this snapshot of 25 cycles, with the lowest having a peak of 11.658A and the highest a peak of 12.462A. If you’re doing true continuous sampling then this is a pretty unremarkable load to measure; it has very little distortion and almost no phase shift giving it a unity PF to two decimal places. It’s as easy to measure as a 2200W resistive load.

If on the other hand you’re doing “round robin” sampling, whereby you intensively sample one channel for 2 or 3 cycles, and then assume the signal is the same for the next half-second or so as you sample the remaining channels, you run the risk of some significant errors creeping in, all depending on the luck of which 2 or 3 cycles you picked up. And in this case it’s a significant load, the old motto of “big loads are easy to measure” doesn’t always apply if you’re not doing true continuous sampling.

In an ideal world you’d have a dedicated ADC for each channel, and that’s how the pro energy ICs work. If that’s out of reach then a close second is to step through the channels on each sample. Provided your sampling rate is fast enough for the job at hand, you’ll still get enough bandwidth out of each channel and you won’t have any half-second deaf periods where you’re not looking at the signal at all. I believe that’s how Emontx3-continuous and the new EmonLibCM V2 both work, and it’s also how the stm32 example code works. I think that’s a step in the right direction for improved accuracy.

By comparison, here’s the same set up as above but measuring a simple electric kettle of roughly the same wattage. In this case you can see each cycle is pretty much an exact replica of the cycle before it, so the assumption that the signal will be the same for the next half-second or so is a fairly safe one, regardless of which 2 or 3 cycles you measured.

Emontx3-continuous - New continuous monitoring firmware
(Robert Wall) #2

Your belief is correct. :smile: :+1:

(Trystan Lea) #3

The original comment here by Overeasy has been removed as it breached our code of conduct.

@dBC clarified below that this thread was not written in reference to IotaWatt, it was aimed to contribute instead to the application of continuous monitoring firmware on the EmonTx and continuous monitoring firmware development for the STM32 platform.

(dBC) #4

Actually, my motivation was to re-enforce continuous monitoring as a design goal in the stm32 stuff. I was originally going to post the pic in that thread, but then figured it was a generic enough topic that all meter designers might benefit. A secondary motivation was to commend EmonLibCM V2 for going that route.

Indeed… until your post now I would have assumed it does do continuous monitoring. Is there any reason why it can’t?

Since you raise it I think that makes for a very good case study in the point I was trying to make. The design decision here is how to best use an impressive 38,000 samples/sec sampling rate. You can either point it at all at one channel and then move onto the next, or you can share it amongst your channels on a sample-by-sample basis.

You seem to be operating under the mis-conception that the faster you sample a channel, the more accurate the result will be. In fact, the faster you sample a channel the higher your bandwidth will be. Regulations restrict how much energy can be in the higher harmonics. Typical revenue meters (and the energy ICs found inside them) have a bandwidth of around 2 kHz, yours is closer to 20kHz. If you point all of that sampling horsepower at a single channel, you’re doing a huge amount of maths for no change in the result.

As a general rule I think you’d get much better results if you spread that horsepower across your channels. Then all the maths would be doing something useful instead of doing something that adds up to ~0 (energy above 2kHz). I say general because I don’t know enough about your architecture to know if that’s feasible. If it is, you may want to consider it, if not keep it in mind for your next version.

(dBC) #5

To illustrate the “lots of maths that adds up to zero” point, I’ll dust off the pic of my most distorted channel made up of a boat load of CFLs:

My monitor measures that out to 2kHz:

Each of those blips represent a bit of energy that needs to be measured, although a lot less than it appears in the graph. That relatively large blip at 150Hz for instance gets multiplied by the equivalent 150Hz blip on the V signal which is much much smaller because V is typically much less distorted. So all those blips (bar the first) get seriously dampened once you multiply them by their corresponding V blip at that frequency.

With that V attenuation in mind (but not shown), you can see there really is not much to measure by the time you get out to 2kHz - even without the attenuation there’s bugger-all out there. With your 38000 samples/sec your equivalent graph goes all the way out to 19kHz, so you’re really just adding in a whole bunch of zeroes.

(dBC) #6

The other challenge it presents for monitors not doing continuous sampling is fairly rapid “thermostat” cycles. In this pic it’s Off for 2 seconds, ramping for 0.5 seconds and on for 4.5 seconds.

(dBC) #7

Like watching what the induction hob is doing. The problem with only looking at 1-in-25 cycles and relying on the law of large numbers to eventually get you to the right answer is that it assumes the signal is constant. In the case of an induction hob that’s not a safe bet.

(Robert Wall) #8

It’s been recognised for at least as long as I’ve been associated with OEM that the “discrete sample” method is adequate when conditions are changing relatively slowly, but there are serious limitations with loads that vary rapidly. And it is with the sort of load that you mention (and I include in that the halogen type of hob), that was foremost in my mind when advocating the concept of continuous monitoring.

Clearly one sample every half-second is a significant ( ×2 ) advance over 200 ms every 10 s taken over a long period, but even so, it’s a lottery as to whether the correct value is recorded during any half-second interval, or how much is under or over-recorded, especially when the switching rate converges towards the sample rate.

(dBC) #9

Yes, I’d often heard it quoted in here, but never quite knew the reason why. Nothing like a few scope pics to hammer the message home. It also revealed the cycle-by-cycle changes this particular one makes as it’s ramping.

These 4-burner hobs are getting pretty popular in these parts. I’m told that once you get one, your old electric kettle goes in the bin so these things get powered up every time you make a cuppa’, and end up a fairly significant contributor to your total energy bill.

(Robert Wall) #10

That came as a bit of a surprise to me. I guess the reason that’s done - and it must be deliberate - would be to minimise the perceived effect of any flicker that it induces on a weak supply.

(dBC) #11

I wonder if it might be doing some sort of pot-detection? There’s heaps of info in AN2383 if anyone wants to build their own. I’ve only scanned it briefly, but I did notice stuff like:

This causes the system to have an oscillating resonant frequency strongly dependent on the type of pot placed on the plate at different times.

Therefore the 9 working levels cannot be based on constant frequency levels. The PWM
frequency must be adjusted to the selected level in order to work with the pot placed on the
plate at that moment.

So each working level does not work on a constant PWM frequency, but a constant current.
By reading the I-CTRL feedback signal, the MCU smoothly adjusts the PWM frequency in
order to keep the current constant for the selected working level.

(Robert Wall) #12

Thinking about it, that’s probably wrong, because it would also need to ramp down to hide the effect of flicker.

(dBC) #13

The standby current on this thing is a shocker: 0.66A just sitting there waiting for someone to press a button. 3W Real and -165 VAR Reactive, PF of 0.018.

(Robert Wall) #14

No prizes then for guessing how they’re deriving the low voltage to run the bit that detects the button being pressed. I presume the h.f. mush on the current wave is what’s getting through what is effectively a high pass filter. It would be interesting to see how the Fourier analysis of that will look compared to the one in post no.5., and how far up the frequency spectrum it stretches.

But in fairness to the title of this thread, continuous or discrete sampling would make little difference in this case.

(dBC) #15

Well spotted, it does indeed go all the way out to 2kHz and potentially beyond. I vaguely recall that really low power devices (< 5W maybe?) are exempt from the harmonic rules.

(Robert Wall) #16

Yes, you’re right. Both here and in the USA, and I presume that’s common elsewhere.
Here, lighting equipment with power not greater than 25W is exempt. Otherwise, for the 3rd harmonic, its 3.45 A for portable tools, and 30 × power factor for lighting, and 2.3 A for almost everything else, but the limits fall with the harmonic order and are specified up to the 39th - near enough 2kHz.

I’d be surprised though if that (microwave?) device is actually generating those harmonics - I’d suspect that they’re on the supply and the capacitor dropper is acting as a low pass filter and allowing you to see them being conducted to neutral as a current wave. If you have a suitably rated capacitor and resistor, which could not possibly generate harmonics, to hang across the supply, that would be a revealing test.

(dBC) #17

This is still the same induction hob, which now well and truly replaces the microwave as my most current-hungry appliance in standby. Unfortunately I don’t have the bits required for your suggested experiment, but will try to remember to pick them up next time I’m ordering something.