Sorry the post was directed @ursi since he continued to refer to “sinusoidal interpolation”.
As for the paper, the delay is an integral number of samples accurately timed (shouldn’t be a problem).
My idea was to calculate the synthesized PF by calculating V*Vd.
Anyway we are crossing posts and I am confused worried about how to reasonably calculate (and agree) on the phase shift of your sample waveform, do you have a longer sample?
I tried calculating the frequency/period of the two waveforms by form fitting 2 sine waves (least squares error) and got slightly different periods and a phase shift of 6.0°. I also sample shifted the two waveforms and did a least squares and got a 4.74°/4.76° phase shift (depending on line frequency chosen).
And of course given that we are talking about calculating power factors - I tried calculating the “PF” of the two waveforms and got a phase shift of 4.1° and PFs with (Mains in and …) the two sine waves and got a phase delta of 3.7°
I don’t have a longer sample. The way I obtain the phase shift is to do a discrete Fourier transform on each wave separately, using LibreOffice Calc, and take the difference - for the fundamental only of course. This method is due to Martin Roberts (MartinR on the old forum - I don’t think he’s registered on the new). I’ll look again at your method.
For what it’s worth, I’ve incorporated a ‘gain trim’ in the new emonLibCM that effectively corrects the gain change in the FIR filter, but it uses calibration rather than the cosine calculation on the angles to determine the gain. The result has to be the same. But it doesn’t alter the need to get the correction right.
One thing I suggest you do, if you haven’t already done so - draw out to scale the range of phase error for both v.t. & c.t. and put them in the correct relative positions due to the time delay between reading V & I samples. It’s a sobering realisation - or it was for me.
And thanks for the clarification. I can already see it makes a lot more sense now.
You can calculate the correct gain by calculating the unshifted RMS value - the RMS of the shifted wave has to be the same! (+/- various sampling, rounding, etc errors).
I thought that is fundamentally the correct procedure by definition. I will have to try librecalc, I have just been using Gnumeric and its Fourier transform only works on blocks of 2^n.
Regardless, I will have to ponder some more and research some, but I would have thought the sample shift and least squares error would be accurate answer, if not the most accurate.
I would have thought form fitting the waveforms to a sine wave would likewise result in an accurate determination of the phase and period of the fundamental component.
Of course it has been almost 45 years since I studied real analysis
You’ve got the advantage. I was never taught it formally, and I graduated at about the same time - 1972. Ouch!
If you want a longer sample, try copying it. It is not quite a complete cycle, as the frequency was obviously not exactly 50 Hz, but copying and looking across the join at an enlarged scale, I can just see a slight wiggle.
Done properly, and ignoring the correct artefacts, all the results should come to the same. What we’re worrying about is the difference between theory and reality.
The way I look at it is this: There shouldn’t be much power in the harmonics - according to the rules anyway, so you’re really only interested in the fundamental. If it’s a resistive load, then barring distortion in the transformers, the current wave and voltage wave are the same shape.
What power there is in the harmonics I can estimate knowing the levels in my distorted voltage. They are:
3rd : 1.39%
5th : 1.92%
7th : 0.65%
9th : 0.56%
11th : 0.24%
13th : 0.19%
and together account for about 0.25% of the total power. I don’t really care if there’s even a gross error in that. So finding the phase shift of the fundamental is really all we’re interested in.
emonLib sample rate is approx. 354 μs per sample pair, using calcVI(…) and an emonTx. That equates to 56.44 sample pairs per 50 Hz cycle.
To calculate this, I recorded the duration and number of sample pairs for 20 crossings, and again for 120 crossings, and took the difference, so as to remove the initial wait for a zero crossing and the subsequent processing to obtain the averages.
So I loaded Libre Calc and found a FFT macro that was not limited to 2^n blocks and I got the same results as Andries, so I’m not sure what you mean by your measured and “true” phase shift.
I was looking for a longer sample to be able to accurately determine the frequency. A DFT assumes a period of the number of samples given so it isn’t much use. I estimated the frequency to be just below 50 Hz and synthesizing 1 and 2 new values, reran the DFT. the results were a minor (<1%) shift in the phase difference of the fundamentals.
After looking more closely, I see that my form fitted sine waves were quite a few samples longer and more grossly distorted the phase difference.
With both inputs fed from the same signal, the two channels showed a -2.79° phase shift - presumably the different stray capacitances of the different (ratio) voltage dividers, multi-turn trim pots and cables.
So getting the same result as Andries shows that you were indeed getting the same numbers from the same data, as did I (well almost: I got 3.456, but I wouldn’t argue 3.46 against 3.45)
I’d need to choose the time of day carefully to do anything about that! The controllers allow the frequency to droop at times of high demand, and rise at times of low demand, so that the count of cycles over 24 hours is correct. The statutory limit is ±1%, but they aim to keep it much closer with operational limits at 49.8Hz - 50.2Hz. It is 49.90 Hz and coming up to the evening peak demand as I write this.
OK I got 3.456 as well (and 3.466 when I manufactured an additional sample).
The point of the estimate of just below 50 Hz was that the recording was about 1 - 1 1/2 samples short of a complete wave form, not that the precise frequency matters!
I forgot to mention, when I constrained my form fitted sine waves to 50Hz (the same as the DFT), the results for phase only differed in the 10th decimal place!, which despite being of no concern gave me great satisfaction nonetheless.
The version you refer to is being tested by Trystan Lea, so it’s release (or otherwise) is in his control. However, recently I incorporated some further improvements that should remove the need for the adjustment you mention, but I’ve not yet checked the performance, and for various reasons that’s not likely to happen very soon, if at all.
In the meantime, I believe the version on Github still produces incorrect data, and should not be used.
In any case, neither it nor the version under test, nor its potential successor, include the energy diversion logic.
Reporting the mains frequency is no problem, but I’m not sure how you intend to measure THD with an emonPi. Don’t forget that in general, the mains is not a pure sine wave (mine shows harmonic components in the order of 2½%), so you need a signal generator capable of supplying several amps in order to make meaningful measurements.
Understood re: Trystan etc. I’m hoping to avoid reinventing the wheel so I’m looking closely at what you guys have already achieved.
I’m not looking for the diverter logic, just using that as a starting point for continuous sampling, PLL and the other goodies you used in it.
As far as the THD, I’m thinking to stream the data back to the Pi and run an FFT on it (possibly on the GPU) and use the magnitude of the harmonics to calculate the THD. It may be too off the rails to work and the sampling rate may be too low to get anything respectable. The emonpi having the CT and VT connections all in a nice package is making me want to do everything in it. However, If it works but I get mediocre results I’ll build a board and move it to a ChipKit WiFire at 200MHz as a next step which should increase the sampling rate.
Opinions more than welcome, especially if I’m missing something!
I don’t think it is off the rails in principle, but practically - yes. What you’re missing is the performance of the Atmega and the difficulty of getting the data out of it.
The free-running ADC takes 104μs to get a 10-bit sample, so the raw data rate for two channels would be 4800 samples (19200 bytes) per second, or 96 samples per cycle. That’s good to the 48th harmonic in theory. You won’t need that much, so all depends on what sample rate you think you need, bearing in mind the emonPi front end has no anti-alias filters. Then you must either process it in the ATMega, or get it down a serial bus while the processor is handling timing and one interrupt per sample. It might be possible, certainly worth looking carefully at what you need to do, but I wouldn’t guarantee success.