Using an SCT-013 to calculate "low overhead" instantaneous power monitoring, is this method missing something?

Bill.Thomson · 2020-07-21T00:40:52.678Z

jonpcar:

hanks for pointing out that post/thread.

YVW,S!

jonpcar:

is there a way in this board’s options to “line through” deleted text?

Indeed there is.
To do it, prefix the text you want struck through with [s] and postfix it with [/s]

e.g. [s]strikethrough[/s].

yields: strikethrough.

borpin · 2020-07-21T06:16:53.213Z

or
~~text~~

~~text~~

Have a search for ‘markdown cheatsheet’ on Google.

jonpcar · 2020-07-21T12:05:51.895Z

dBC:

Is there anyway you can turn that off? It would be better if you were in control of how you space your sampling, rather than have it occur in clumps of 5.

There is a way to do that…Particle.io has an open OS. But I’ve looked at a couple examples that make calls to the firmware and the code is very confusing to me, haha. Object Oriented Programming/Classes/etc are steps beyond my “easy to read” & understand concepts…if I need to do it, I probably could, but I’m in a test and see approach at the moment. I’d prefer to stick with the “user” instructions.

dBC:

which gives a PCLK2 of 60 MHz, and you can see in the ADC configurator above the ADC clock is PCLK2/2, which is 30 MHz… a very good correlation with your timings above. So I think you can safely assume your ADC clock is running at 30 MHz.

Thanks for figuring all that out. I have only seen the numbers “batted around” over on the Particle.io forum and was never positive that they were legitimate. It’s good to know that there is some basis in reality. You know your A2Ds!

dBC:

(*) EDIT - actually, if you’re measuring a noisy signal, a longer than otherwise necessary sampling period might help smooth things out by effectively using the S&H cap as your LPF, but there are potentially better ways to do that.

Let’s see how my next set of “experiments” come out. I’m going to fiddle with the sampling rate, different values for the ADC’s S&H, averaging periods. Based on the data so far, I don’t think I’ll run in to any roadblocks to find something I’m happy with, but we will see.

dBC:

That’s very promising. Did you try different speeds?

Darn…didn’t see this note until after I dragged my setup back in. The problem is that currently, I have no way to grab data from my “test Photon” without a computer directly connected to it. That will change soon.

I only tested a few spots while my In-Floor-Cleaning-System (IFCS) was running at high RPM. I don’t expect to have any problems getting good power numbers at other times because everything in the system runs at a steady state during non-IFCS operation. BUT, I didn’t think about the fact that there still might be some interesting waveforms when the VSP pump is running at low RPMs.

jonpcar · 2020-07-23T21:10:10.356Z

I’ve been doing some experiments. When I started this project and was using the “somewhat flawed peak-to-peak Apparent Power” measurements, I noticed that for resistive loads (apparent power = real power), I could get pretty accurate measurements using that peak-to-peak strategy…even when my sampling was on the order of only a couple samples per second…but only if those sample were made at very specific timings…kind of like @Robert.Wall described in his post a few back (4 samples per cycle)…but spread out over many, many more cycles:

Using an SCT-013 to calculate "low overhead" instantaneous power monitoring, is this method missing something? Hardware

You might want to look at MartinR’s energy diverter. Learn→PV Diversion→PLL Diverter Not of course as an energy diverter, but the measurement is phase locked to the a.c. waveform. You need a voltage input for it to work. The principle is a sample close to the zero crossing is measured, and the amount it is away from zero adjusts the timing of the loop, so that you get an exact number of samples at exactly the same point on the waveform each time. You could have four samples per cycle (that’s t…

When @dBC showed some of the waveforms we might expect to see on some household appliances, I understood the problem that the experienced posters on this board were pointing out to me in regards to relying on a nice sine wave to calculate the RMS current using the .707 multiplier from peak-to-peak samples. But, I still believed that these ( I*V) readings could be obtained/summed with low frequency sampling, as long as the “timing requirements” for those samples are met. That’s what I have been playing with, and at least for what I have been checking, it seems to be working.

I don’t know the technical terms for this process, but I am sure it must be a standard technique in signal processing…and I am also sure that probably everyone else here understands it better than I do.

Anyway, when I looked at some of those weird current profiles that dBC has posted (and worried that my pool pump might be similar because it’s a VSP), I wondered what kind of sampling would be necessary to accurately capture those waveforms: 10 samples/cycle?…not likely…but I get the impression that 50 samples/cycle is an accepted number that gives accurate power readings. Now, how to spread those 50 sample points across multiple cycles so that it is infinitely repeatable/continuous.

Given any frequency (50Hz or 60Hz in my case), and a “single cycle sample rate” that evenly divides into that frequency, there seems to be only ONE solution for each multiple of that “single cycle sample rate” to accomplish this purpose.

This chart is an example for a 60Hz frequency in which the fastest sample rate is 333uSec (50 samples/cycle).

image366×782 10.5 KB

In the above graph, the 2nd column gives the sample rate (sample every ‘x’ mSec)
xCycle refers to an extended Cycle, this is a term I made up because I don’t know what else to call it…“Cycles per xCycle” refers to the number of actual (60hz) cycles it takes to complete an xCycle and complete the sample count.

I did simultaneous tests at six different sample rates. They are highlighted in RED. At the slowest level (index = 243), the samples were taken every 81mSec. To “complete” its xCycle of 50 samples, it actually takes 4.05 seconds of time. I wanted to compare the accuracy of the results for all six cases. I didn’t choose these sample rates because they were the “best”, I chose them because they were easy and represent a wide range of possibilities.

Nobody probably cares about test cases on resistive loads…that is just too easy and too consistent. So I found a couple special case “appliances” to run these on. One is an air compressor that draws about 1000 Watts, I figured that is about as close as I am going to get to my pool pump . According to my Watts-Meter, the Power Factor is about .91 or so and it has a sawtooth current profile. The other is my DeWalt battery charger…it has a current profile similar to some of the ones that @dBC posted, you’ll see the picture.

In the program, the Power reported for each case is averaged over the longest period (4.05 seconds). Once again, this was just convenient and is not what I will end up with for my project. So in the first case, 50 samples are taken EVERY cycle (every 333uSec). These power numbers were then summed and averaged over the 243 complete cycles (4.05 seconds).

For the case of the 1mSec samples, there were 81 complete xCycles completed (0.5 mSecs each)…the power numbers were summed and then divided by 81 to report the average power for the 4.05sec period.

For the case of the 27mSec samples, there were ‘3’ complete xCycles completed (1.35 secs each), summed and averaged (divide by only 3) for its power average.

The last case (81mSec) is not averaged at all. It is purely the reporting of the power for the 50 samples taken over the 4.05 second period. Just one complete “xCycle”.

Results are coming…

jonpcar · 2020-07-23T21:21:50.504Z

Here is the “current” profile for my air compressor. The results will show that the power requirements continually increase as the compressor has to work harder to “fill the the tank”. This graph doesn’t necessarily show that because it is only 10 cycles at 16.67mSecs each. But my sketch’s output will show the power increasing.

Here is the power reporting for all six cases (333uSec/sample to 81mSecs/sample) that I described in the last post. The timeline is on the left. During this test, I started out with no current and then turned on the compressor. You can see that even though I turned on the compressor mid 4.05sec sample, ALL the measurements account for it, even the case that is not averaged and only has 50 samples total (P243).

I let the compressor run for a number of seconds. The power continued to rise as the compressor increased it’s tank pressure. Then, you can see that I turned it off.

The other example will have to wait, my grandkids are up, haha.

jonpcar · 2020-07-24T04:18:38.710Z

So before I rerun that other example and record the results, here are a few comments. Most of these concepts are all new to me, and some of my thinking could be way off base…so feel free to burst my bubble.

A look at my numbers indicates that for the examples I have run, there is no need to sample 30-60 times a cycle to get an accurate power number. In fact, the P27 column indicates that with as little under 2 samples per cycle, an accurate power profile can be obtained. It’s even possible that the P81 (1 sample per 1.5 cycles) and P243 (1 sample per 5 cycles) columns will converge as well given a few more xCycles to average. As I said previously, these numbers were chosen for simplicity, I have some ideas about better choices for sample times (of course they must exist in the spectrum of possibilities).

For me, it’s obvious how I will apply this: I am probably going to choose a sample time of between 8ms (~2 samples/per cycle) & 30ms (~1 sample every 2 cycles), I believe that choice will give me an almost identical result to sampling 50 times a cycle. Of course I will check this assumption when I hook up my pool pump.

On the opposite end of the spectrum (high accuracy), here is an example that I think about: Suppose I have a 60Hz (16.67mSec per cycle) system in which the absolute fastest I can do my sample pair(s) is every 0.98mSec. I have a choice, am I going to sample 17 times every cycle with an effective resolution of 17 unique samples/cycle….OR should I choose to sample at EXACTLY 1mSec intervals over 3 cycles…and effectively TRIPLE my resolution to 50 samples/cycle. Yes, I know there is some information being lost there, but this call is not even close…I definitely would choose the 2nd option in order to effectively gain a finer resolution of sampling. At what point does this slippery slope not become slippery?

jonpcar · 2020-07-24T04:55:55.473Z

So here is the current profile for my DeWalt battery charger. Once again, I start my sketch with no current running through the wires and then turn the battery charger on. I let it run for a number of seconds before turning it off. My watts-meter gives me a Power Factor of 0.65 for this device.

image852×556 74.3 KB

A closeup:

And here are the measured power numbers out of my six test cases…once again, the first four (taken at widely different sample times) are, for all intents and purposes, identical.

Robert.Wall · 2020-07-24T12:55:42.408Z

As long as your load is steady, then pretty much any sampling scheme will be accurate over a period of time, with one notable exception of course: if you always sample at the same point or points on each cycle of the wave, you’d better be sure you sample enough points to get a sufficiently accurate representation of the wave.

Let’s construct a silly example to illustrate: If your line frequency is 60 Hz, and you sample at 120 samples/s, then depending on where you start in relation to the wave’s zero crossing, you can read zero on every sample, +max and -max on alternate samples, or anything in between.

But if you change that to sampling 121 samples/s, you’ll eventually, after a second, get the correct average power. This is what the 121 samples will look like (forget the vertical scale, and it’s a nice well-behaved resistive load):
Current:
Sample-121ps
Power:
Power
You must make sure you’re not synchronised with the mains you’re measuring.

Even so, a problem arises when your load isn’t steady. Suppose I turn it off after exactly ¾ second. The average power over the second should be 75%, but it’s clearly not going to be - it’s actually 86% in terms of current, or 91% power. If that’s “good enough”, then fine. But I can’t advocate the method as being generally good and giving accurate answers for everyone, because that’s clearly not the case - as we know from experience with emonLib (the discrete sample version) and loads like induction hobs, where it’s a matter of hit and miss as to whether the heating is on or off when the measurement is taken.

dBC · 2020-07-25T01:56:25.178Z

Robert.Wall:

and loads like induction hobs

It turns out even ceramic elements are pretty dynamic loads. In this post I reverse engineered the on/off times based on the 10 second true average energy readings.

jonpcar · 2020-07-26T11:56:11.894Z

Robert.Wall:

As long as your load is steady, then pretty much any sampling scheme will be accurate over a period of time, with one notable exception of course: if you always sample at the same point or points on each cycle of the wave, you’d better be sure you sample enough points to get a sufficiently accurate representation of the wave.

Thanks @Robert.Wall …I understand that. I guess what I didn’t expect, is that for my test cases, it seems like ALL loads are steady (obviously resistive loads like crock pots, compressor, hair dryer, fans)…and it seems like it is very easy to obtain accurate instantaneous power measurements at high sample rates AND at “lower than high” sample rates. My “sampling scheme” goal is to take a minimum number of samples necessary to get a TBD accuracy. But I think I jumped the gun in a couple of those previous posts and would like to back up a bit.

Robert.Wall:

You must make sure you’re not synchronised with the mains you’re measuring.

I didn’t explain that table I posted well at all. For the given sample rates, it actually provides the means to ensure this doesn’t happen. However, I didn’t post the entire table, and my explanation was terrible. But I will revisit that a bit later.

Robert.Wall:

Even so, a problem arises when your load isn’t steady. Suppose I turn it off after exactly ¾ second. The average power over the second should be 75%, but it’s clearly not going to be - it’s actually 86% in terms of current, or 91% power.

Robert, this is easily solved by ensuring the sampling is not done sequentially (which presents the problem you point out), but more intermittingly: consecutive samples spaced ~3/4 of a cycle apart (best), or various versions of that…even ~1/4 cycle spacing eliminates most of this. But this “example” leads to a question…

Is your concern over the inaccuracy based on a single occurrence of whatever waveform being measured is turned off at the 75% point of a particular “second” (which seems to be somewhat of a wash in a 10-second sample), or is the concern that a device being sampled will be operating consistently (harmonically?) in that fashion and you will accumulate error over a longer period of time?

How does the emonLIB deal with a case where it samples a signal for 200ms and then “something” turns off and is not recorded for the next 9.8 seconds?

Also, I have no clue as to the answer for this: for power monitoring, what is “good enough”? I know that “better” is always better, so more specifically…what are the tolerances/goals for emonLib and emonLibCM in accurately accumulating power usage?

Thanks again for your help, Robert…feel free to cut me loose at any time and let me flounder away, haha.

jonpcar · 2020-07-26T12:12:49.903Z

dBC:

It turns out even ceramic elements are pretty dynamic loads. In this post I reverse engineered the on/off times based on the 10 second true average energy readings.

@dBC, thanks…I read through that post. I had been planning to use the type of measurement you describe there (true average power over the last x seconds) in my pool pump project…but probably with “x” being 0.5-1.0 sec. The reason being is that I don’t think my pump’s GPM output resolution (that I eventually get) will be any finer than that.

Nice job on dissecting the waveform…I don’t see any problem there for getting accurate measurements of that kind of operation using my sketch, based on the results of my test cases. I don’t have a ceramic cooktop, so I am thinking about “inputting” that wave into my sketch in a “simulation” to see how it does based on my “sampling schemes”

Is there a nice example like that for an induction hob?

jonpcar · 2020-07-26T18:44:25.850Z

So I thought about dynamically changing loads and what I could use to test my sample schemes. After running an extension cord to my DeWalt chop saw and getting some samples, I figured out the obvious…use the hair dryer and dynamically/rapidly/slowly turn it on/off/high/low as randomly as humanly possible, for at least until my thumb got tired…which it did.

I’m pretty sure that I got multiple changes in there within a second (at times) in addition to the motor / heating element trying to ramp up and down to keep up with it. I suspect this case is much worse than an induction hob.

I tried to simplify things a bit this time, because I realize I did a poor job of explaining things in my prior posts. Bear with me though, I am probably going to screw up some terminology which is unfamiliar to me. I am also certainly going to mess up some numbers somwhere as I have been testing so many different cases. But here, we are going to test four cases.

The Base case is our golden ruler (50 samples/cycle)…to be used as a yardstick to judge our other three test cases. Test1 is a repeat of the Base, except with only 25 samples/cycle. To keep things “easy” the other two cases will also be limited to 25 samples/”cycle”.

“Cycle” is in parenthesis for a reason…Test2 & Test3 samples are not taken over one 16.67mSec cycle, they are equally spread out over multiple cycles. If you start sampling at a zero crossing (I don’t) the sample rate will determine how many cycles are necessary before another sample lines up at the zero crossing (starting a new sample “cycle”).

For example Test 3 has these parameters (from the table):

Column 1 indicates how many multiples of the Base sample rate are sampled…in this case, a sample must be taken at 1/36 the base rate: 36 * 16.67 = so every 12 mSec (column 2). Column 3 is simply the number of samples that must be taken to line up to a new starting point (zero crossing if that is your methodology). Column 4 shows the number of 16.67ms cycles it takes to line-up to that zero crossing again. Here is the relationship:

Col2 * Col3 = Col4 * 16.67 mSec = time for a complete “cycle”

12 mSec/sample * 25 samples = 18 cycles * 16.67 mSec/cycle = 300 mSec for a complete “cycle”

jonpcar · 2020-07-26T20:09:58.845Z

Here’s the results of my latest Dynamic Load testing, and based on the discussion we have, these might be the final tests I run before deploying to my pool controller, haha.

I’ve changed things around a bit to make this easier to look at and hopefully understand. I’m calculating Instantaneous Real Power (IRP, a new term for me, thanks @dBC) at every .25 second interval for all four cases.

For our base case, that means 15 complete cycles are sampled/multiplied/accumulated for each .25 second interval. For the base case only, we are also keeping a record of the lowest and highest IRP values (captured from among the 15) for each .25 second interval, just to get a feeling for how quickly the power numbers are changing. They are changing very quickly as you will see.

In addition, I’ve added a cumulative energy value for each test case. I hope that helps in judging the performance of these cases. It looks like the numbers are good to me, but I have no reference. It definitely worked a lot better than I expected it would. NOTE: there is an error in the labelling…Watts-sec should be labelled Watts-.25sec

As @Robert.Wall pointed out an earlier post, spacing out the sampling will make the results lag…that is clearly seen, does it matter for most applications? EDIT: trying to figure out how to make this readable…it’s from Excel

For now, I’ve copied to Google Sheets and here is the link…but I think I must figure out a way to do it more directly.

docs.google.com

Dynamic Power Test Results

Sheet1 BASE RATE,TEST2,TEST3,TEST4 (333uSec),(500 uSec),(4 mSec),(12 mSec) 50 samp/cycle,25 samp/cycle,25 samp/6 cycles,25 samp/18 cycles Time (sec),Instantaneous Real Power (Watts),Cum Energy (Wsec),Min IRP Cycle (Watts),Max IRP Cycle (Watts),IRP...

And before I have to go…I want to throw out a guess as to why this works as well as it does, although it’s just based on a low level understanding of what is going on. I’m going to be very busy this week.

All of these power calculations/signals are based on sine waves. Unfortunately, they are not “ideal” sine waves…but many of them are close. With an ideal sine wave, I believe it’s possible to recreate the entire cycle with a SINGLE sample…IF you know exactly where that cycle was taken in the sine wave. Thus the relevance of the tightly controlled sample points in these examples.

So, imagine the case where we are taking 50 samples spread out over 50 cycles, and each of those cycles changes in amplitude. Given sufficient computing power, you could recreate each of those cycles and do the math on them…we don’t have that. But, I believe that there must be an analog version of that occurring through the multiplies and summations.

It’s just a guess…

Robert.Wall · 2020-07-26T20:57:05.074Z

Sorry I’ve been silent for a while - the hinge on my laptop pulled the screws out of the moulding, so it’s been in pieces for 30 hours or so.

jonpcar:

I didn’t explain that table I posted well at all.

That’s very true. On a phone screen, I couldn’t make sense of it at all.

jonpcar:

this is easily solved by ensuring the sampling is not done sequentially (which presents the problem you point out),

What my speadsheet was doing was sampling at just less than half-cycle intervals, thereby showing the ‘beat’ effect you get. You’ll still get the same error (in absolute terms, it’ll reduce as a percentage) over any number of incomplete cycles. EmonLib(DS) reckons to average all those errors over an extended period of time - which is indeed what happens. So if you induction/ceramic hob happens to be switched on every time you sample today, it might not be tomorrow nor the day after.

jonpcar:

what is “good enough”?

It’s what is good enough for your purpose. If you don’t need the best accuracy, it’s pointless chasing it only to throw it away when you’ve got it.

jonpcar:

what are the tolerances/goals for emonLib

We have never claimed any. Forum reports indicated that emonLib(DS) could get within 1% of the billing meter over a month or so, I’ve had emonLibCM within 0.15% over a week or so - more by luck than anything else, but I’ve found I can tweak the calibration so that it’s accurate at low loads or accurate at high loads, which I put down to the varying phase error of the c.t.

jonpcar:

cut me loose at any time and let me flounder away

I don’t do that sort of thing when people are being sensible and trying to learn.

jonpcar:

I believe it’s possible to recreate the entire cycle with a SINGLE sample…IF you know exactly where that cycle was taken in the sine wave.

That’s indeed true, But a big ‘IF’. If you stop there, you have apparent power. And if it’s a reactive load, how the phase of that relates to the voltage to get to real power. A second big ‘IF’.

jonpcar:

But, I believe that there must be an analog version of that occurring through the multiplies and summations.

Indeed there is. It happens inside every (analogue) radio receiver, it’s how the broadcast frequency is lowered to an “intermediate frequency” to be amplified before the sound is extracted.

jonpcar · 2020-07-27T12:29:53.713Z

Robert.Wall:

It’s what is good enough for your purpose. If you don’t need the best accuracy, it’s pointless chasing it only to throw it away when you’ve got it.

Robert, this is obviously an expansion to my original project, haha. I am confident I can get the accuracy I need for my project. But, based on all my testing, I really think there is something to this “synchronized sampling scheme” and IF THERE IS, it could be applied to many cases…not just to mine.

I’ve read through quite a few posts on these boards and see that a “continuous sampling” methodology is the ideal solution, if it can be afforded. This methodology could make a poor man’s version affordable AND it also could have application at the high end.

So, I am hoping that you and the other smart people on this board can help determine IF this synchronized, sampling methodology is valid in general…here are a few of the reasons why I think is could be very useful (with the caveat, once again, IF it is valid):

I started down this path because I am cheapskate in dealing out my cpu cycles and A/D sampling bandwidth. This opens up the possibility for many similar projects to capture and calculate “accurate” instantaneous power readings…even using chips such as the ADS1115 (which happens to be another chip I really like and am using on my pool controller project)
Obviously, there could be a direct application to such projects as emonLIB where cpu cycles and A/D bandwidth could be divvied out continuously, over time, to do these calculation with a TBD impact on accuracy
I briefly touched on this before, and I am sure that it didn’t make any sense to you. But I am going to give it one more shot…once again, IF THIS METHODOLGY IS VALID, I think there is an application of this technique at the high end of the power metering spectrum. This is a “constructed example” just to make the point. Hopefully it will be understandable.

This example is for a 60Hz system. @dBC is currently involved in a project to increase the power sampling rate in a new project. Suppose the hardware that they are using is limited to taking & processing the samples on all phases to every .45mSec. But the original goal of the project is 100 samples/cycle in order to capture all the power harmonics, etc (I am making this stuff up, I hope it is relevant).

Below are the first few entries of a “100 Sample Chart for 60Hz” with dBC’s case thrown in.

So dBC’s project has a choice…do they take 37 samples every cycle to get a randomly scattered sampling of data points across each cycle to multiply and accumulate…OR do they reduce their sample rate to CASE2 and (IF THIS METHOD IS VALID) get a an “effective” sampling rate of 100 samples/cycle.

I don’t have the capability to measure the accuracy and difference of these two cases in my setup, but I am pretty confident that CASE2 would be the right choice.

Based on any “desired sample rate” and frequency (50Hz, 60Hz) a similar table can be constructed, all may not be useful/applicable though.

Robert.Wall · 2020-07-27T13:19:29.389Z

Your basic assumption is that everything is repeatable and relatively steady-state. And while that’s true, then I’ll readily agree that you can get whatever accuracy you need with the minimal need for samples and their resultant processing, with the result that you can free up processing power for other things. It’s when irregular things happen that you can miss that sparse sampling falls down. The question I’d put back to you is, why do all the metering i.c’s measure continuously, and not do it the way you propose? I’m sure the designers of those are a lot cleverer than I am.

You seem to be inferring that I’m saying “It’ll never work”. I’ve never written that. I’ve tried to point out the shortcomings and the limitations as I see them, and I’ve repeatedly said that if your use case means those either don’t apply or can be neglected, then that’s fine.
If you are content to miss (say) a spike of inrush, and trade that for doing something else, then it’s your decision as the designer. Engineering has always been and always will be a matter of balancing the compromises to achieve an acceptable result.

As you mention emonLib, here’s emonLibCM processing one voltage and two current channels on an Atmel ATMega328P:

CM1003×700 60 KB

The caption tells me that you’re looking at a digital output. It’s been driven HIGH in the code just before it drives the multiplexer to select the analogue input and LOW immediately that is done, then it’s driven high again as it starts to process the reading and low when it’s finished. The difference in the amount of processing of the voltage sample compared against the current sample is clear.

Just looking, the processor is only in the ISR and handling the current and voltage samples for about half the time (and if you add up the numbers it’s less than 40%, but it’d be slightly more with 4 current samples), for the remainder it’s free to do whatever the main loop calls for - like calculating the averages and transmitting them every 10 seconds or so. But for most of the time, it’s just cycling and waiting for the next measurement to be ready.

dBC · 2020-07-27T22:16:26.043Z

jonpcar:

@dBC is currently involved in a project to increase the power sampling rate in a new project. Suppose the hardware that they are using

There’s really no need to reference me in on your hypotheticals. I browse this forum as time permits and reply when I can. I got lost on your first spreadsheet post but decided I didn’t have the bandwidth (pardon the pun) to give it the attention it deserves or inquire further (and I still don’t). If you’ve got any specific stm32 ADC questions, feel free to @ me in to get my attention.

But for the record I’m not doing what you claimed in your hypothetical. I’ve always sampled at 8kSPS, every channel every cycle non-stop and that’s what is used to calculate all the power maths. That’s baked in silicon, there’s nothing I can do to change that. The only thing that’s being improved in my rev 2 is the scope-like display of the signal. Rev 1 only had enough horsepower to capture every second sample for the display, while rev 2 captures all samples… WaveView4K has become WaveView8K if you like, but the power and energy calculations are identical.

I think you’ve received nothing but encouragement here to take whatever measurement shortcuts work for you and your load, but if you want to be able to make accuracy claims across a specified bandwidth for unknown current waveforms there really is no substitute for continuous monitoring. Anything else is a game of whack-a-mole. I post the interesting waveforms I notice and you might be able to test against them and tweak your sampling to cope with them, but for every one I post there are a thousand different waveforms none of us have even imagined. Once you embrace continuous monitoring you simply don’t care what the waveform looks like. Choose your meter bandwidth (2kHz in my case), set your sampling speed appropriately and let her rip. Pure sinewaves are no easier or harder to measure than the most distorted signal you can come up with.

Now looking back at the washing machine for instance:

Screenshot from 2020-07-15 08-57-441135×186 26.4 KB

what if I were to ask you how much energy that load used for the 6 minutes from 10:01 to 10:07? You can scroll back to refresh your memory on how it looked in the msec range…every half cycle had a different amplitude. What if all your loads looked like that all the time? What accuracy claim would you make on your readings?

Some are so bold as to claim 1% say, but when pressed fall back to “1% agreement with the revenue meter over the long term”. That’s actually a surprisingly easy benchmark to meet. I’m constantly blown away by what can meet that benchmark. Even the old CurrentCost with just 2 D-cells and a CT - so just apparent power with no V reference can pull it off once you’ve calibrated its output for your average grid voltage, and your household’s average power factor. So I figure if you’re going to take shortcuts, you might as well take lots of them, and save yourself some money.

jonpcar · 2020-07-28T12:36:59.204Z

dBC:

There’s really no need to reference me in on your hypotheticals.

You/re absolutely right…sorry about that. The “high end” of this power monitoring detailed in your project is much different than the environment I imagined. The example I gave is totally irrelevant. Thanks for clarifying. And, believe it or not, I do agree that continuous monitoring is the way to go…I guess I am struggling with the definition of “continuous”. Thanks for the input!

jonpcar · 2020-07-28T12:58:00.725Z

Robert.Wall:

You seem to be inferring that I’m saying “It’ll never work”. I’ve never written that.

Robert, sorry if you got that impression…I have definitely appreciated all your feedback. The fact is, I am really struggling with WHY (if it does) this method seems to works at all. I understand that all my previous tests were on relatively stable signals.

Truthfully, I went into this latest hairdryer turn-off/turn-on experiment with the thought that it was going to fail spectacularly (I finally had what I thought was a “real” dynamic changing load to test). I was absolutely floored when those cumulative power results for all four test cases came back so close to each other.

Robert.Wall:

The question I’d put back to you is, why do all the metering i.c’s measure continuously, and not do it the way you propose?

I think there is probably an easy answer to this…it doesn’t really work OR it’s inaccurate for their purposes.

Robert.Wall:

here’s emonLibCM processing one voltage and two current channels on an Atmel ATMega328P

Thanks for posting the Atmel timings, I haven’t had a chance to look at it detail but I understand that you have plenty of bandwidth left after doing the power sampling/calculations.

We have four grandkids 24/7 this week and I only have a bit of time in the morning (before they get up)…the rest of the time I am utterly exhausted. One is getting up now, haha. Thanks again.

dBC · 2020-07-28T22:17:27.639Z

jonpcar:

Robert.Wall:

The question I’d put back to you is, why do all the metering i.c’s measure continuously, and not do it the way you propose?

I think there is probably an easy answer to this…it doesn’t really work OR it’s inaccurate for their purposes.

I think in order to meet their claimed accuracy specs, they have to assume totally arbitrary waveforms. Each half-cyle is a brand new day with no relationship to the one before it or after it.

The “1% agreement with the revenue meter over the long term” mob are really saying I’ve no idea how much energy your washing machine used during those 6 minutes but check back in a month and you won’t notice because it’ll have been swamped by all the loads I can measure.

The project I’m currently working on reports energy in WattSeconds and updates its user-facing registers every second so If I’m to have any chance of making any accuracy claims I really need to have measured all 50 (60 for you) cycles, I don’t have the luxury of assuming it’ll all come out in the wash (another lousy pun):

Screenshot from 2020-07-29 08-07-13643×634 61.2 KB