no worriers , was just a thought , since you said the ds18b20 took to long. and the NTC with probe and wire are even cheaper then DS’s costing between $0.25 - $3.00 each ( basic wire, silicon or armored)… and you can sample a heck of alot of NTCs in the time it takes to get one sample of DS18b20
The standard library for the DS18B20 commands the sensor to “convert” the reading, then waits until it has done so. That delay is dependent on the temperature resolution you ask for, at worst (12 bits - 1/16th degree C) it is 750 ms, halving for each bit of resolution you don’t want down to 9 bits (½ degree C). Then the One-wire bus must transfer the data, which takes around 30 ms per sensor.
By issuing the commands directly, you can get on with other things while the sensor is doing the conversion, but you still need the 30 ms to read the result.
Thanks for the advice on the 220v…l am not going to play around with that.
As far as the DS18B20s…I do have five in my system (currently four). I issue the start temp command to all at once and then go off executing until they are done. When I read them back…I only read one each time through the loop to try and minimize the latency time through the loop.
It’s actually 240 Volts.
Two hot legs which yield 120 VAC between either leg and Neutral, and 240 across both hot legs.
“220” is a holdover from many moons ago. 
1 Like
Or it may well hurt. Here’s a pic of the current draw of the variable speed DC brushless motor in my washing machine:
You might need to have a better idea of what your pump’s current signature looks like before you’ll know if any shortcuts are going to work.
I think the crest factor of that wave is a long way above √2 - which clearly demonstrates that measuring the peak, and hoping that gives the rms (“equivalent heating”) with peak / √2, is a long way from satisfactory.
Ouch, if my pool pump has similar characteristics, that would definitely present problems for the “peak detection” method that my sketch uses. Unfortunately I don’t have an oscilloscope so I’ll have to rely on some data collection to “see” the waveform.
I’ve been procrastinating on hooking up to my pumps themselves because I’ve been busy with family things, my code/setup is not ready to “drag” out to my pool equipment pad, and it has been really hot here in Phoenix…110 degrees Fahrenheit and getting hotter.
So Robert, is the standard use model for the emonLIB to do continuous samples/calculations for 10cycles (200ms) and then extrapolate that use out 10 seconds…Or Is it to sample/calculate for one cycle (20ms) every second during the 10 seconds. What is the method that is normally used? Something in between? (I hope I have my units right in those assumptions)
Also, based on your experience/knowledge (dBC, others?), what do you think would be a minimum number of samples per cycle (using both current and voltage) to “accurately for what you think I might need for my pool project calculate power for the waveform that dBC posted of his washing machine. emonLIB uses 55pairs/cycle, could it be significantly less? Probably not down to the absolute theoretical minimum “four” previously mentioned for a possible PLL solution, especially given this unusual waveform…10? 20?
Thanks…
Edit: so I have been reading through some other threads on this site and apparently I have blindly stumbled (with all your help of course) onto some of the issues faced in designing and using power monitors. So I went back and added this caveat to my number of samples question:
accurately ”for what you think I might need for my pool project”
Neither - but nearer the first than the second. It doesn’t extrapolate, it simply reports the 200 ms average that it measures every 10 s. It’s emonCMS (or something else - Grafana maybe) that will “join the dots” and give you pseudo-continuous curve which can be integrated over time to give the energy value.
From what you’ve written, 10 s might be too long - it certainly fails when you have something like an induction hob in the kitchen, or a burst-mode energy diverter - but it arose from the need to equitably share access to emoncms.org among many users.
I think an empirical approach would serve you well. Print that picture at a reasonable size, put some pencil dots (have an eraser handy) on the curve at the spacing you think outlines the curve with sufficient fidelity, and see how far apart horizontally they are.
1 Like
The other thing to note about that washing machine trace is it’s not particularly repetitive (at least at 50Hz). That second positive peak is about 3.6 divisions while the last negative one is about 2.6.
Sorry to keep asking questions but I’m working out some things, mostly my understanding, haha. So why not report it 50 times in 10 seconds…is there a limitation somewhere?
OR…why not calculate & sample for 10 seconds continuously and then report it?
Or possibly you can point me in a direction, if the use model is documented…
Thanks.
Yeah, I did notice that…another dagger for my “find the peaks” strategy…if my pool pump is operating in a similar fashion.
Taking the easy one first…
As far as I’m aware, the reasons aren’t documented. You need to know the history.
It wouldn’t be 50 times in 10 seconds. If you were using all four c.t. inputs, it would be 12–13 times in 10 seconds, because the channels are checked sequentially. And the limitation is emoncms.org, as I mentioned above. emoncms.org preceded emoncms on the Raspberry Pi by many years. Although some users had access to a “full-size” server, there was no standard way to have local storage before the emonPi was introduced.
That’s called emonLibCM, and it’s been the standard sketch for the emonTx since mid-October, 2019. You can get the latest release and documentation at EmonLibCM - Version 2.2.2
The Atmel '328P spends roughly half its time processing the interrupts from the ADC, which probably doesn’t - unless your processor is significantly faster - leave a lot of time to do other things. For example, it can use the RFM69CW radio as a transmitter because that has an internal buffer that can be filled as it wishes, it cannot use the RFM12B because that doesn’t have an internal buffer and the timing of each byte sent to the transmitter is critical. So the “classic” JeeLib library can’t be used with emonLibCM.
The particle.io Photon (at least the one I could find) uses the STM32F205 ARM Cortex M3 processor running at 120 MHz, so, significantly faster than the '328p 
Which might help, but…
emonLibCM lets the ADC free run, so it’s the balance between the time between ADC interrupts delivering the latest sample and the time to process the last one, that counts. If the Photon works the same way, and the ADC is the same speed pro-rata, then you get more samples per cycle and exactly the same proportion of time to do other things, and it’s no help. If the ADC is faster pro rata, you’re worse off. Either way, you probably need to trigger the ADC off a timer to keep it at around the 50 or so samples per cycle. That ‘feels’ a decent number and should be good to the 25th harmonic or thereabouts, where there should be very little power, and conveniently forgetting anti-alias filters.
When deciding parameters like this, you really need to start from the answer to “How much significant power is there above what frequency?” A good guide will be the rules and limits for harmonic injection where you live.
Thanks Robert, that post explains a lot! I might have been able to discover that info by digging around but it definitely would have taken a much looonger. I am over my head with single phase and hadn’t even thought about the larger picture, haha.
I did add the voltage testing to my “bench setup”…it’s actually pretty nice/clean. I really hadn’t thought about the slight changes in voltage (RMS) having much impact on the power calculation, but it does occasionally deviate more than I expected…I don’t know if that is “whole house deviation” or a local drop to my power center,etc. I have not yet implemented the RMS power algorithm on my samples because I am still figuring out what I want to do with sampling.
After a hitch with the interrupt (actually a bug in the Photon OS that we found a workaround for), I setup my code to use interrupts and it seems that I have some latitude there, of course depending on the sample rate. I do want to “look” at the actual pool pump current waveform but that is a ways out due to grandkids/covid.
About Sampling…
I know how tedious/laborious responding to newbies can get so I hope no-one feels obligated to answer these questions…I perfectly understand.
-
There appears to be an emphasis on starting sampling right at/after the beginning (zero crossing) of a cycle. It seems to me that if you sample for a full or half cycle, it doesn’t make any difference where you start. Is that incorrect?
-
I have been thinking about “single cycle reconstruction” (my made-up term, there probably is a standard term for this which I just haven’t found) by sampling over multiple cycles. From an intuitive level, it makes sense to me but I am unclear what the cost is (besides probably some accuracy). The simplest example of what I am thinking is if you want to take 50 samples/sec. What problems would be introduced by taking sample #s 1,3,5,7,etc on the first cycle and taking sample #s 2,4,6,8, etc on the 2nd to “piece together” a waveform. It seems that it is a poor-man’s method of “averaging”, to some extent.
I guess the goal is to lessen the performance impact to my code…haha @Greebo, I am not going to try to sample full speed (50/sec). That is an option that seems close (for single phase) with the Photon, but in that case it would probably be a stand-along program that I would use only to characterize, not as a permanent part of my pool controller firmware (too much impact).
Anyway, thanks again for the help.
It’s not incorrect, but the practical point is if you don’t fit an exact integer number of samples into an exact number of wavelengths, you get an “end effect” of a fractional sample. It’s best not to have that error, but if it’s unavoidable, it’s least bad to have that error where the amplitude is small.
You’re relying on the average coming good. That’s going to be questionable with your loads varying with the frequency you’ve talked about - only a couple of seconds before you change the load on the pump again? You wouldn’t actually need to “piece together” a waveform, because you’re only squaring each sample and adding them all together to get the rms average, so as long as your sample rate in not locked to mains and you start and finish as close as possible to a zero crossing, it might work out with sufficient accuracy for your needs.
I’d just point out that the Atmel '328P in emonLib samples at about 2500 samples per second, to you about 42 samples per cycle. In emonLibCM, you get one sample every 104 µs, so roughly 9600 samples per second.
1 Like
Here’s a fresh capture of that washing machine with V included. Given the motor is DC, maybe it’s a SMPS topping up its reservoir cap as much as required, each half cycle:
Over 15 consecutive cycles, the average power was 472W. If you calculate average power over each of the 30 half cycles the result varies from 246W to 589W. If you calculate it over each of the 15 cycles, the result varies from 409W to 536W.
Oops Robert, sorry about that mistype…my intent was to refer to an earlier remark by you that indicated 50 samples/cycle might be an ideal sample rate to account for all harmonics in the power calculations.
I think, for single phase calculations, the Particle.io Photon COULD do that, but would probably require calls to system functions directly (Photon has an Open OS) rather than to “user available functions” for such things as the analog conversions and interrupt timing. But, I won’t be doing that.
That is a very nice, CLEAN trace. I’ve actually looked at some oscilloscopes recently to see if there are any cheap ones that might be useful to me (for more than this one power calculation for my pool pump, haha). I don’t think I am going to justify the purchase.
But, I do have a question:
Is 472W (average over the 15 cycles) “constant” for the long term measurement? I imagine it would be really close…
That’s actually out of my energy monitor. It effectively gives you a scope on each circuit breaker. Once you’ve decided you’re only interested in 2kHz worth of bandwidth you can filter hard with LPFs and digital filters and you end up with a much cleaner picture than you would with a real oscilloscope that’s good for 100MHz or 1GHz.
It’s hard to say with any certainty because in this case the underlying load is so dynamic. As Robert mentions above, if you want to average your way to the correct result you really need the actual load to be very stable, and all too often they’re not. Here’s the big picture of that load above:
In that case, the power is averaged over 500 cycles with no gaps between samples (i.e. every cycle gets measured). I’m not sure where I was on that graph when I took the high resolution sample but it certainly passes through 472W. On almost any timescale (from 10 msecs to 10 seconds) it’s a very dynamic load, so hard to measure accurately by random sampling, but easy to measure accurately by continuous sampling.
[EDIT] correction: the logs show the high res trace was taken at 10:05 (to the nearest minute)