That’s what I need to establish. Clearly, the phase correction - based as it is on the Atmel application note for the '328P - is wholly inappropriate for the Due. So I’m thinking in terms of storing the voltage samples so as to align them more closely before interpolating between samples. As it is, it’s doing extrapolation 3 times outside the range of the samples being used. That’s theoretically OK until the voltage wave gets the slightest distortion, when it all gets horrible.
I am thinking along those lines too. Taking the last part first, that’s the simplest, the most costly and though it will reduce the problem significantly, it’s very unlikely that it will remove it completely. But it might be good enough. You need to evaluate what’s available to you (and as it looks as if your firm is paying, that might be cheaper than your time developing software).
Taking now the first part, that implies not using emonLib at all. If you’re happy developing your own code, then I think that will be possibly the hardest route but you’re less likely to fall into traps set by assumptions or knowledge about how the '328P works.
The other route I thought of - I’d hardly advise it but I’m throwing it into the air - is to insert delays in appropriate places to slow the loops down where necessary so that emonLib works.
Given the sorts of speed that @Greebo mentions, I’d suggest that the “discrete sample” approach of emonLib isn’t necessary, you can easily take the “continuous monitor” approach even though it might not be necessary to let the ADC free run, and you might not actually monitor totally continuously - you will pause occasionally to calculate the averages and send the data. But you could go for the fully continuous monitor if you wished.
So, I’m suggesting:
- Read and store the voltage in an array.
- Read all the current values consecutively.
- Use the appropriate delayed voltage to do minimal maths and accumulate the values to get the data that will allow you to calculate average values.
- Repeat for the duration of the averaging/reporting period.
- Use the accumulated values to remove offsets, calculate the phase correction, the averages, etc and send the data.
- Start from the top again.
Reading one voltage and 10 current values spread over roughly 140 µs, allowing the same time to do some processing, will give you in the order of 60 sample sets per mains cycle, which should give plenty of resolution - theoretically you will read up to the 30th harmonic.
You will of course have a circular array for the voltage, you only need to store enough values to cater for the worst phase error difference that you see - plus the different time shifts that reading all 10 currents introduces. If you don’t like that, you could do two batches of “V+5I”
Putting those numbers into perspective, 1° of phase at 60 Hz equates to 46.3 µs, 60 sample sets per cycle means each sensor is read every 6°.
We know how to do the maths so that everything done per sample is done with integers (not like emonLib), and all the slow floating point stuff is done only when processing the numbers to send them off to wherever. So my estimate of 60 sample sets per cycle might be pessimistic - all I know is that with emonLibCM and the '328P, the processor spends about half the time processing each sample, about 50 µs, and it’s idle for about the same.
(I think your times might be pessimistic too, because you’ve got a bit of timing overhead in there as well.)
2 Likes
Thank you Robert, I really appreciate the help. I plan to take a look at the continuous monitoring library after I do my best to test the hardware that I have for phase error and replace anything that is horribly bad.