measuring frequency

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?

Reply to
Rob
Loading thread data ...

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.

There probably isn't much point sampling so fast as all you will be seeing is ever more zero crossing noise.

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.

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
Reply to
Martin Brown

Would it not be enough to sample the input at 48kHz and then do the filtering in DSP ?

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.

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.

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.

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.

Reply to
Rob

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.

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 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 ?

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.

Reply to
upsidedown

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.

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.

Not after bandpass filtering around 50 Hz!

Of course I would use only crossings in the same direction.

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.

Reply to
Rob

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.

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.

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.

OK. I don't know enough about chrony to comment.

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.

EU grid rate is available in realtime to 5 sig fig on GridWatch France

formatting link

The writing is a bit small though. Presently 49.988Hz and steady.

--
Regards, 
Martin Brown
Reply to
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.

Reply to
jurb6006

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.

Reply to
upsidedown

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.

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.

Reply to
upsidedown

That applies also to most of Continental Europe

A similar graph for the Scandinavian network:

formatting link

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.

Reply to
upsidedown

That seems to be flopping about +/-0.1% around a slightly high mean.

UK grid has a fairly stable frequency by comparison UK is also currently slightly fast at 50.137 on mid afternoon load sunny day. Steaming up for the early evening peak load.

formatting link

--
Regards, 
Martin Brown
Reply to
Martin Brown

+1. Doesn't need to be fancy--a three-section RC lowpass with a cutoff at around 60 Hz would work pretty well. Even just hanging a capacitor on the output of the resistor attenuator would help a great deal.

mains---* *---47nF--100k---*---100k---*---100k---*-----*---0 To 3 || 3 4.7 4.7 4.7 10 sound 3 || 3 nF nF nF k card mains---* *----------------*----------*----------*-----*---* 12VAC wall wart | GND

LTspice circuit at and frequency response at .

It's pretty simple. It gives you 30 dB attenuation at mains frequencies, cuts off any weird low frequency stuff from atmospherics and solar storms, and gives at least 100 dB rejection of switching power supply stuff > 20 kHz.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

Depends on the SNR. You can do it in one cycle if you have at least 101 dB SNR. A filter sure helps.

[rms phase error in radians = 1/(sqrt(2)*SNR)]

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

If you download the latest data from the "download" link in the upper left corner of the page, I get 12.9MB of data, every 15 minutes, in CSV format. Unfortunately, my antique spreadsheet (Office 2003) chokes on more than 65,000 rows, which gives me only data from 2014 to

2016. Oops. Office 2007 and later should do 1 million rows. I'll deal with that later, as plotting recent frequency excursions might be interesting to see what range of frequencies would be needed.
--
Jeff Liebermann     jeffl@cruzio.com 
150 Felker St #D    http://www.LearnByDestroying.com 
 Click to see the full signature
Reply to
Jeff Liebermann

Lowpass filter the waveform before applying it to the sound card. The AC line has all sorts of trash that will jitter the zero crossings.

There are better algorithms than using zero crossings, things that use the entire waveform not just the crossings. Those will be less sensitive to noise.

The 60 Hz AC line around here is usually accurate to a few 10s of PPM. Since the AC is noisy and the amplitude jumps around constantly, that's impressive.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

Can you explain why that is? Is it merely "old hat gut feeling" to sort of assume that a couple of resistors and capacitors will do a better job than that newfangled software junk? Until now I don't understand why filtering the line voltage in analog would be any different than digitizing it (of course with a low-pass at half the samplerate anti-alias filter) and then applying a digital bandpass filter optimized for the task.

I am quite used to seeing brick-wall bandpass filters at high frequency that outperform anything you could do in hardware. Is there any reason to believe it will be different at 50 Hz?

I was thinking about getting a lot more than one waveform in the buffer, more like 1000 or so.

Well, that info (and the other posting that indicates that historic data is available as well) makes this entire excercise a bit superfluous.

I think I just download that and look at it... that should be enough to satisfy the curiosity.

It is astonishing how many side-effects of the frequency error have already been noticed. I didn't expect that so many (critical) systems still use the line frequency as a time reference. Oldfashioned alarm clocks, OK. But critical infrastructure could have moved to more modern ways by now.

Reply to
Rob

Thank you! That is much easier (and more useful, due to the history) than trying to measure it myself.

Reply to
Rob

Sure, but so would a software filter on the digital data obtained by sampling the unfiltered rubbish, wouldn't it?

Reply to
Rob

I wasn't aware that it is jittering that much, and the recent publicity suggests that at the moment there is a -150ppm systematic error so the measuring at about 1ppm accuracy was just a first guess at what would be required to see the problem. My very old frequency counter can only directly count for at most 1 second so totally useless for this purpose as it would display either 49, 50 or 51. That is why I understand a different approach is required.

In the meantime I worked that out as well. Initially I beleived that there would just be some reference distributed by a weights and measures institude like PTB or BIPM and then everyone would just lock their generator RPM to that, but that is not how it works.

Reply to
Rob

I expected it to be like that here too.

But currently there is a problem, apparently political, and the entire west-european grid is slow. It has accumulated about 10 minutes of error on a grid-frequency referenced clock over the past 6 weeks.

This is starting to cause problems.

Reply to
Rob

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.