Interesting. Thanks.
If analogue were really better, we wouldn’t have software defined radio and suchlike.
The critical bit is
so as long as the digital system can run twice as fast (plus a bit for luck) it will get the same answer.
(Posted mainly to reduce Robert’s % 
)
True, and some filter functions that are possible in software are not realisable in analogue form.
And coming back to post no.57, obviously Dan’s never had to fight an analogue integrator.
(Not posted mainly to restore Robert’s % 
)
That’s right. 
I’d already lost the fight after 4 seconds when I tried using that thing imagination.
Probably too busy COUNTING THE SECONDS.
(Not the best excuse.)
This article from this thread highlights another benefit of continuous sampling. In continuous sampling the conversions are triggered by a h/w clock, so regardless of what the f/w is doing that sampling is going to occur as regular as clockwork. If f/w is in charge of kicking off each conversion, then you introduce jitter into the sampling.
It’s important to note, that if you want low noise and good frequency resolution from your ADC, you will need to sample at a very consistent rate. To do this, you can use first conversion mode, free running mode, or an interrupt that is a multiple of your ADC clock. All other modes will have 1/2 ADC clock jitter. This will cause your samples to not line-up in time, and slowly wander back and forth, effectively causing a frequency modulation of your signal.
That paragraph is not exactly misleading but misses that important bandwidth thing again.
A software sampling approach will basically work if it’s consistently orders of magnitude greater than the target.
I think the main problem with a software approach is at such and such an interval the data must be processed. If there’re a bunch of hungry devices going off in between the time sampling stops and starts that would mean at least two things… Inaccuracy over time, and bad luck. In low-power situations where each 0.1 of Watt counts it’s going to matter, so yeah I’d say it depends on the context and aims, how ‘good’ the method turns out to be.
Can you explain exactly what you mean there? Conventional wisdom is that the sampling frequency must be at least twice that of the highest component of interest in the waveform being measured, and if I understand you correctly, that’s significantly less than “orders of magnitude” - an ‘order of magnitude’ usually being taken as a factor of 10.
And if sampling is continuous, as per the title of this thread, where does
come into it? 
Yeah orders of magnitude is fine.
I’ve been following this thread for some time.
Around 2013 i’ve written myself a lib for Atmel that perform continuous sampling.
Back than i tried some approaches to deal with jitter. Main issue was that while trying to maximize sample rate, sometime calculations inside the interrupt routine toke longer than next ACD read, so jitter was introduced arbitrarely.
First tried to use a software PLL to lock on the cross to zero so i get the same number of ADC readings per AC cycle. It was discharged as the PLL induced minimal delays when not locked and occasionally lost the lock.
After investigation i discover that TIMER B can be used for automatically program the timing that the ADC is read and the value put to the ADC register that can be read at any time before the next read without having to worry about timing the ADC read from software. This fixed the jitter.
With additional math i was able to add “auto sample rate” feature by adjusting ADC reads automatically at boot to the maximal attainable sample rate for the available free cpu time.
It’s usable now at 50 and 60hz without requiring recompile and perform precise frequency measurement.
Been using it for 6years now on multiple installations without a problem measuring few watts ~20 up to 4kWs accurately.
The lib is fully customisable to support different number of voltage and current sensors. Reports Voltage, Frequency, Current, Active Power, Aparent Power and Power Factor.
If interested, take a look:
1 Like