measuring frequency

Started by Rob March 7, 2018
I would like to measure the line frequency (50 Hz) at good accuracy,
like 1ppm or better, using a soundcard.

I have a Linux system that is time-synchronized to GPS and consider
an approach like this:

- input the line frequency into a soundcard  (small transformer and
  resistive divider to get to acceptable level)

- in a software loop do:

- get samples from the soundcard (highest rate) including timestamps

- filter (software) via a bandpass at 50 Hz

- determine zero crossings

- measure time between two zero crossings of a many-cycle measurement

- average

I have experience with ALSA sound programming using the timestamp
feature (that returns timestamps of soundcard interrupts at 100ns
resolution).

Before I start coding this, is anyone aware of an existing program
that can do this?
On 07/03/2018 10:10, Rob wrote:
> I would like to measure the line frequency (50 Hz) at good accuracy, > like 1ppm or better, using a soundcard. > > I have a Linux system that is time-synchronized to GPS and consider > an approach like this: > > - input the line frequency into a soundcard (small transformer and > resistive divider to get to acceptable level)
It would probably make sense to low/band pass filter it in analogue electronics first to remove as much crossover distortion as you can. Mains waveforms are rather dirty with all this switchmode gear about.
> - in a software loop do: > > - get samples from the soundcard (highest rate) including timestamps
There probably isn't much point sampling so fast as all you will be seeing is ever more zero crossing noise.
> - filter (software) via a bandpass at 50 Hz > > - determine zero crossings > > - measure time between two zero crossings of a many-cycle measurement
You can do better than that iteratively tracking the blocks and only bothering to sample when the cumulative phase error is estimated to exceed 1 radian. You basically want a circular list of zero crossing timestamps and cycle counts that you can use to refine the result. Around 10000 cycles should be enough to get ppm accuracy assuming you can determine zero crossing times to about 1/100th of a cycle. After that it is down to how stable your nominal time reference source is. You will get glitches when your GPS reference disciplines your local system clock unless it can be phase locked somehow.
> - average > > I have experience with ALSA sound programming using the timestamp > feature (that returns timestamps of soundcard interrupts at 100ns > resolution). > > Before I start coding this, is anyone aware of an existing program > that can do this?
Might be worth taking a look at Daqarta - no idea if it will meet your 1ppm requirement but it will certainly measure frequencies fairly accurately using a soundcard input (and more besides). It also does FFT waterfall so you can see just how impure the mains waveform actually is! -- Regards, Martin Brown
Martin Brown <'''newspam'''@nezumi.demon.co.uk> wrote:
> On 07/03/2018 10:10, Rob wrote: >> I would like to measure the line frequency (50 Hz) at good accuracy, >> like 1ppm or better, using a soundcard. >> >> I have a Linux system that is time-synchronized to GPS and consider >> an approach like this: >> >> - input the line frequency into a soundcard (small transformer and >> resistive divider to get to acceptable level) > > It would probably make sense to low/band pass filter it in analogue > electronics first to remove as much crossover distortion as you can. > Mains waveforms are rather dirty with all this switchmode gear about.
Would it not be enough to sample the input at 48kHz and then do the filtering in DSP ?
>> - in a software loop do: >> >> - get samples from the soundcard (highest rate) including timestamps > > There probably isn't much point sampling so fast as all you will be > seeing is ever more zero crossing noise.
But the filtering using DSP techniques would work better, wouldn't it? Of course by sampling at lower freqency there will be some automatic low-pass filter applied by the sound card electronics (likely a switched capacitor filter) that performs some filtering.
>> - filter (software) via a bandpass at 50 Hz >> >> - determine zero crossings >> >> - measure time between two zero crossings of a many-cycle measurement > > You can do better than that iteratively tracking the blocks and only > bothering to sample when the cumulative phase error is estimated to > exceed 1 radian. You basically want a circular list of zero crossing > timestamps and cycle counts that you can use to refine the result.
Yes, but I cannot take a zero crossing timestamp in hardware. What I can do is get a block of samples and associated timestamp that can be used to calculate the time at the first sample in the buffer. I did that before. Then, I need to look for the zero crossings in the buffer and calculate their timestamp.
> Around 10000 cycles should be enough to get ppm accuracy assuming you > can determine zero crossing times to about 1/100th of a cycle. After > that it is down to how stable your nominal time reference source is. > > You will get glitches when your GPS reference disciplines your local > system clock unless it can be phase locked somehow.
It is. The clock is locked to GPS using chrony, and that will not simply jerk around the clock at each PPS pulse but rather will lock it using the kernel clock PLL.
>> - average >> >> I have experience with ALSA sound programming using the timestamp >> feature (that returns timestamps of soundcard interrupts at 100ns >> resolution). >> >> Before I start coding this, is anyone aware of an existing program >> that can do this? > > Might be worth taking a look at Daqarta - no idea if it will meet your > 1ppm requirement but it will certainly measure frequencies fairly > accurately using a soundcard input (and more besides). It also does FFT > waterfall so you can see just how impure the mains waveform actually is!
I got a hit on that when I initially googled for this but it appears to be a commercial package only available for Windows. As it is for Windows (which has lousy timekeeping accuracy), it likely uses the soundcard sample clock as its timing reference. My experience with accurate timing using soundcards on Linux/ALSA is that the sampling rate accuracy is typically not much better than 100ppm (5Hz at 48kHz). An alternative approach would be to do filtering in hardware so the zero crossing of the line voltage is converted into a digital edge that can issue an interrupt (e.g. via RS232 DCD) which can directly be timestamped and those timestamps processed in software for averaging. They too would have 100ns resolution. But that requires building hardware, and it all is mostly a toy to see what is going on at the moment (there apparently is some crisis in the European grid causing the frequency to be low and old clocks to run slow). Of course many clocks use a crystal or "atomic clock receiver" and are not affected by that. But it would be nice to plot some graphs to see how worse it is and how soon it is fixed.
On 07 Mar 2018 10:10:40 GMT, Rob <nomail@example.com> wrote:

>I would like to measure the line frequency (50 Hz) at good accuracy, >like 1ppm or better, using a soundcard.
What is the point of measuring the mains frequency to 1ppm accuracy ? It takes a while to get 1 ppm accuracy. During that time, the mains frequency has varied several times. Power companies typically publish the line frequency with only two decimals (about 200 ppm) and the last decimal varies quite often (every few seconds). Thus, it is very unlikely that the mains frequency remains stable within 1 ppm long enough to take measurement to 1 ppm accuracy.
> >I have a Linux system that is time-synchronized to GPS and consider >an approach like this: > >- input the line frequency into a soundcard (small transformer and > resistive divider to get to acceptable level).
The problem is the short and long time purity/accuracy of the sound card sampling clock. One way to compensate for this is to feed a known higher frequency (say 10 kHz sine) to the other channel of a stereo sound card. The reference should be derived from a good quality known crystal (OCXO). This can then be used to determine and compensate for the sound card sample clock jitter and drift.
> >- in a software loop do: > >- get samples from the soundcard (highest rate) including timestamps > >- filter (software) via a bandpass at 50 Hz > >- determine zero crossings
The line is really dirty, so there can be multiple zero crossings. Filtering and/or transformer crossing can inject some DC bias, shifting the zero line, if the line signal contains even harmonics. So how are you going to determine the zero crossing between two cycles in the long run ?
> >- measure time between two zero crossings of a many-cycle measurement > >- average > >I have experience with ALSA sound programming using the timestamp >feature (that returns timestamps of soundcard interrupts at 100ns >resolution). > >Before I start coding this, is anyone aware of an existing program >that can do this?
One idea would be to convert into frequency domain with FFT, but the huge number of bins required would be impractical. Since we are interested only on a very narrow frequency band, the DFT would be more practical with fewer calculations. However the measuring time would be long for 0.95 mHz (milliHerz) bins.
upsidedown@downunder.com <upsidedown@downunder.com> wrote:
> On 07 Mar 2018 10:10:40 GMT, Rob <nomail@example.com> wrote: > >>I would like to measure the line frequency (50 Hz) at good accuracy, >>like 1ppm or better, using a soundcard. > > What is the point of measuring the mains frequency to 1ppm accuracy ? > It takes a while to get 1 ppm accuracy. During that time, the mains > frequency has varied several times. Power companies typically publish > the line frequency with only two decimals (about 200 ppm) and the last > decimal varies quite often (every few seconds).
The point is that historically the line frequency was kept within some margin of the exact frequency and there was even some "averaging" going on so when it had been too low for some period of time it was then deliberately set too high for a while, so that long-term it was quite accurate. But at the moment there apparently is some crisis in the European grid causing the frequency to be low and old clocks to run slow. I am interested to see what is going on and if the attempts to correct the error (e.g. at night when the load is lower) have stopped, or if they simply fail to reach the target.
> Thus, it is very unlikely that the mains frequency remains stable > within 1 ppm long enough to take measurement to 1 ppm accuracy. >> >>I have a Linux system that is time-synchronized to GPS and consider >>an approach like this: >> >>- input the line frequency into a soundcard (small transformer and >> resistive divider to get to acceptable level). > > The problem is the short and long time purity/accuracy of the sound > card sampling clock. One way to compensate for this is to feed a known > higher frequency (say 10 kHz sine) to the other channel of a stereo > sound card. The reference should be derived from a good quality known > crystal (OCXO). This can then be used to determine and compensate for > the sound card sample clock jitter and drift.
The sampling rate of the soundcard is not important as I use the real time clock which is synchronized to GPS as a timebase. The frequency of the soundcard sampling clock can be measured by evaluating the interrupt timestamps that occur on every block transfer (of a known number of samples) from the card to the computer. I have done that before in another application where I achieved output timing accuracy better than the sample rate.
>>- in a software loop do: >> >>- get samples from the soundcard (highest rate) including timestamps >> >>- filter (software) via a bandpass at 50 Hz >> >>- determine zero crossings > > The line is really dirty, so there can be multiple zero crossings.
Not after bandpass filtering around 50 Hz!
> Filtering and/or transformer crossing can inject some DC bias, > shifting the zero line, if the line signal contains even harmonics. So > how are you going to determine the zero crossing between two cycles in > the long run ?
Of course I would use only crossings in the same direction.
> One idea would be to convert into frequency domain with FFT, but the > huge number of bins required would be impractical. Since we are > interested only on a very narrow frequency band, the DFT would be more > practical with fewer calculations. However the measuring time would be > long for 0.95 mHz (milliHerz) bins.
That is another way to approach it. It would also be possible to make some kind of PLL that is locked to the signal and measure that.
On 07/03/2018 12:29, Rob wrote:
> Martin Brown <'''newspam'''@nezumi.demon.co.uk> wrote: >> On 07/03/2018 10:10, Rob wrote: >>> I would like to measure the line frequency (50 Hz) at good accuracy, >>> like 1ppm or better, using a soundcard. >>> >>> I have a Linux system that is time-synchronized to GPS and consider >>> an approach like this: >>> >>> - input the line frequency into a soundcard (small transformer and >>> resistive divider to get to acceptable level) >> >> It would probably make sense to low/band pass filter it in analogue >> electronics first to remove as much crossover distortion as you can. >> Mains waveforms are rather dirty with all this switchmode gear about. > > Would it not be enough to sample the input at 48kHz and then do the > filtering in DSP ?
I think you need to look at the zero crossings of a real mains waveform on a scope to understand how noisy the data really are. It is better to analogue filter to something more amenable to sampling than sample like crazy and digitally filter out the mush.
> >>> - in a software loop do: >>> >>> - get samples from the soundcard (highest rate) including timestamps >> >> There probably isn't much point sampling so fast as all you will be >> seeing is ever more zero crossing noise. > > But the filtering using DSP techniques would work better, wouldn't it?
It could also work against you since a noise glitch will move the zero crossings about unless you filter with a very large kernel. This is easier to do in analogue electronics with a tuned bandpass filter since you are not expecting the mains to fluctuate more than about 1Hz.
> Of course by sampling at lower freqency there will be some automatic > low-pass filter applied by the sound card electronics (likely a switched > capacitor filter) that performs some filtering. > >>> - filter (software) via a bandpass at 50 Hz >>> >>> - determine zero crossings >>> >>> - measure time between two zero crossings of a many-cycle measurement >> >> You can do better than that iteratively tracking the blocks and only >> bothering to sample when the cumulative phase error is estimated to >> exceed 1 radian. You basically want a circular list of zero crossing >> timestamps and cycle counts that you can use to refine the result. > > Yes, but I cannot take a zero crossing timestamp in hardware. What I can > do is get a block of samples and associated timestamp that can be used to > calculate the time at the first sample in the buffer. I did that before. > Then, I need to look for the zero crossings in the buffer and calculate > their timestamp.
You need a buffer for the waveform and another one for list of zero crossing times and cycle counts in the recent past. You may not be able to get to 1ppm much of the time as the mains frequency is always shifting as the load varies. I have seen displays to 20ppm. It used to annoy astronomers in the old days of synchronous mains motors because the grid would speed up in the small hours to catch up.
>> Around 10000 cycles should be enough to get ppm accuracy assuming you >> can determine zero crossing times to about 1/100th of a cycle. After >> that it is down to how stable your nominal time reference source is. >> >> You will get glitches when your GPS reference disciplines your local >> system clock unless it can be phase locked somehow. > > It is. The clock is locked to GPS using chrony, and that will not > simply jerk around the clock at each PPS pulse but rather will lock > it using the kernel clock PLL.
OK. I don't know enough about chrony to comment.
>>> Before I start coding this, is anyone aware of an existing program >>> that can do this? >> >> Might be worth taking a look at Daqarta - no idea if it will meet your >> 1ppm requirement but it will certainly measure frequencies fairly >> accurately using a soundcard input (and more besides). It also does FFT >> waterfall so you can see just how impure the mains waveform actually is! > > I got a hit on that when I initially googled for this but it appears > to be a commercial package only available for Windows. > As it is for Windows (which has lousy timekeeping accuracy), it likely > uses the soundcard sample clock as its timing reference. > My experience with accurate timing using soundcards on Linux/ALSA is > that the sampling rate accuracy is typically not much better than 100ppm > (5Hz at 48kHz).
Give it a try under Wine if it will run. ISTR the evaluation period is 30 days and after that you can use the signal generator mode forever. It is quite cute and it might even do what you want with no real effort. My AV sometimes gives a false positive on his website but AFAICT it is a genuine site with a helpful engineer behind it. I have no connection with him other than as a satisfied customer. It is great for lectures about sound, music and frequency with a realtime spectrum display.
> But that requires building hardware, and it all is mostly a toy to > see what is going on at the moment (there apparently is some crisis > in the European grid causing the frequency to be low and old clocks > to run slow). Of course many clocks use a crystal or "atomic clock > receiver" and are not affected by that. But it would be nice to plot > some graphs to see how worse it is and how soon it is fixed.
EU grid rate is available in realtime to 5 sig fig on GridWatch France http://www.gridwatch.templar.co.uk/france/ The writing is a bit small though. Presently 49.988Hz and steady. -- Regards, Martin Brown
Why not start with a reference frequency derived from the GPS and divided down, or
use the GPS time as a gate for an event counter ? Some frequency counters have that
ability. 

But then if you are hell bent on using the PC my point is moot.
On 07 Mar 2018 10:10:40 GMT, Rob <nomail@example.com> wrote:

>I would like to measure the line frequency (50 Hz) at good accuracy, >like 1ppm or better, using a soundcard.
<clip>
>- determine zero crossings
Since this appears to be in Europe, in which all feeds are more or less three phase, there are some other thing causing errors when the measurement is taken between Live L1 and Neutral N. In a _balanced_ three phase system, the N-current is supposed to cancel out and zero crossings are clean. In an unbalanced 3-p system (as most systems are in practice) some current is flowing in the N wire causing voltage drop in it. If the load current in L2 and L3 varies, the phase of theN-current varies and changes the voltage between L1 and N used for frequency measurement, varying the zero crossing. In the modern world with a lot of rectifier loads, even with balanced single phase loads in all phase, there will be a 150 Hz (and harmonics) current in N-wire, which may contaminate the L1 to N measurement. Measuring frequency with moderate accuracy is easy, but going for 1 ppm, all kinds of error sources will appear.
On 07 Mar 2018 13:47:33 GMT, Rob <nomail@example.com> wrote:

>upsidedown@downunder.com <upsidedown@downunder.com> wrote: >> On 07 Mar 2018 10:10:40 GMT, Rob <nomail@example.com> wrote: >> >>>I would like to measure the line frequency (50 Hz) at good accuracy, >>>like 1ppm or better, using a soundcard. >> >> What is the point of measuring the mains frequency to 1ppm accuracy ? >> It takes a while to get 1 ppm accuracy. During that time, the mains >> frequency has varied several times. Power companies typically publish >> the line frequency with only two decimals (about 200 ppm) and the last >> decimal varies quite often (every few seconds). > >The point is that historically the line frequency was kept within some >margin of the exact frequency and there was even some "averaging" going >on so when it had been too low for some period of time it was then >deliberately set too high for a while, so that long-term it was >quite accurate. >But at the moment there apparently is some crisis in the European grid >causing the frequency to be low and old clocks to run slow. >I am interested to see what is going on and if the attempts to correct >the error (e.g. at night when the load is lower) have stopped, or if >they simply fail to reach the target.
There are several grids in Europe, all nominally at 50 Hz, but the phase drifts independently. The largest synchronous net is UCTE (Continental Europe), the CIS (Russia etc.), Scandinavia and the UK net. The convention may vary from network to network.
> >> Thus, it is very unlikely that the mains frequency remains stable >> within 1 ppm long enough to take measurement to 1 ppm accuracy. >>> >>>I have a Linux system that is time-synchronized to GPS and consider >>>an approach like this: >>> >>>- input the line frequency into a soundcard (small transformer and >>> resistive divider to get to acceptable level). >> >> The problem is the short and long time purity/accuracy of the sound >> card sampling clock. One way to compensate for this is to feed a known >> higher frequency (say 10 kHz sine) to the other channel of a stereo >> sound card. The reference should be derived from a good quality known >> crystal (OCXO). This can then be used to determine and compensate for >> the sound card sample clock jitter and drift. > >The sampling rate of the soundcard is not important as I use the real >time clock which is synchronized to GPS as a timebase. The frequency >of the soundcard sampling clock can be measured by evaluating the >interrupt timestamps that occur on every block transfer (of a known >number of samples) from the card to the computer. I have done that >before in another application where I achieved output timing accuracy >better than the sample rate.
IIRC, the x86 Linux NTP implementation used the 64 bit TSC (Time Stamp Counter) which is clocked directly from the CPU clock (possibly divided by 2 or 4). The TSC stability is quite bad and very temperature depended. Not an issue when disciplined by NTP or directly from GPS (IRIG), but the short time spectral purity may be a problem.
On Wed, 7 Mar 2018 13:55:57 +0000, Martin Brown
<'''newspam'''@nezumi.demon.co.uk> wrote:

> >EU grid rate is available in realtime to 5 sig fig on GridWatch France >http://www.gridwatch.templar.co.uk/france/
That applies also to most of Continental Europe
> >The writing is a bit small though. Presently 49.988Hz and steady.
A similar graph for the Scandinavian network: http://www.statnett.no/en/Market-and-operations/Data-from-the-power-system/Nordic-power-balance/ Not much point in measuring with 1 ppm accuracy :-) It should be noted that the power delivered from a synchronous generator depends of the phase shift between the generator and the network. When the load changes, the phase shift (and hence frequency) will change to supply more/less power into the network. When the generator spin rate has reached new stability, the phase shift drops. The phase (and frequency) jumps are essential when connecting multiple generators in parallel at different sites.