There were a couple of threads on audio recording a couple of years ago, see;
http://www.freebasic.net/forum/viewtopic.php?t=2294
http://www.freebasic.net/forum/viewtopic.php?t=2551
Let us know how you solve it.
Drift analysis is similar to ham radio coherent "QRSS" reception. Have you seen “Argo” type analysers, for example; http://www.qsl.net/dl4yhf/spectra1.html
Coherent analysis requires coherent data acquisition without any gaps or phase steps. The block size and method used to A-D convert input blocks will depend on the planned use. For example, how accurately do you need to measure the frequency? Over what period of time will you monitor one signal? What is equation verify?
Better way to emulate Oscilloscope display?
Thanks for the links - I'll test that, it sounds reasonably promising.
I have just 'opened the box' on fbsound, and have hit some bugs/quirks
already that I'll pop into another thread.
The target is to measure oscillators, or instruments, and chase temperature
drift effects. Materials may be tens of ppm/'C, so we need to get to ppm,
but are thinking of maybe 300ms/3s/30s sample rates.
Equation verify just means letting the user/student confirm that the frequency they predicted, is actually what they got!
Of course, that is less of a precision problem
I have just 'opened the box' on fbsound, and have hit some bugs/quirks
already that I'll pop into another thread.
The target is to measure oscillators, or instruments, and chase temperature
drift effects. Materials may be tens of ppm/'C, so we need to get to ppm,
but are thinking of maybe 300ms/3s/30s sample rates.
Equation verify just means letting the user/student confirm that the frequency they predicted, is actually what they got!
Of course, that is less of a precision problem
The crystal centre frequency that sets the sound card acquisition time is typically only set within +/-50ppm. The temperature coefficient can be expected to be another +/-50ppm. Seeing 1ppm frequency drift might just be possible in education but not in industry or scientific instrumentation. If the equation is wrong it will be by more than the initial tolerance of the oscillator components, say 10%, 50ppm will be much more than adequate to spot that.
Your frequency resolution is the reciprocal of your acquisition time, in effect the rise-time of a signal in a tuned circuit is determined by Q and therefore takes 1/bandwidth. With an FFT it takes 1 second of data to resolve 1Hz, 1 minute gives you 16.7mHz, 1 hour gives 277uHz, 1 day gives 11.6uHz, so to get 1uHz resolution you need about 12 days. Obviously you need to keep your signal frequency high, but below Shannon's sampling frequency of half the sample rate.
For a 1.0kHz signal you need 1000 seconds of data to resolve 1mHz which is 1ppm. A 10kHz signal could only be resolved by an FFT to 1ppm in 100 seconds of continuous data.
Reciprocal counting of a single signal in the absence of noise will give a faster and more precise frequency. Gather a block of data and then, still in the time domain, resolve where all the zero crossings are throughout that block. The time between the first crossing and the last crossing divided by the integer number of cycles will give the period to great accuracy. Likewise the average of the separation between similar crossings is statistically the wave period.
As an example, several cycles of a signal gathered at 10ksps for10 seconds would give a resolution of 1 in (10k * 10s) = 10ppm. With a sound card you might be able to squeeze 96kHz conversion for 10 seconds which gets you very close to the 1ppm resolution wanted.
There are PIC projects around that do reciprocal counting and display it as a frequency on an LCD. It should be easy to do it with FreeBASIC and a sound card, so long as thermal drift of the sound card crystal can be minimised. That can be checked and possibly corrected by measuring a known signal reference, maybe a good use for that stereo channel with a signal from a crystal oven or GPS derived reference.
Your frequency resolution is the reciprocal of your acquisition time, in effect the rise-time of a signal in a tuned circuit is determined by Q and therefore takes 1/bandwidth. With an FFT it takes 1 second of data to resolve 1Hz, 1 minute gives you 16.7mHz, 1 hour gives 277uHz, 1 day gives 11.6uHz, so to get 1uHz resolution you need about 12 days. Obviously you need to keep your signal frequency high, but below Shannon's sampling frequency of half the sample rate.
For a 1.0kHz signal you need 1000 seconds of data to resolve 1mHz which is 1ppm. A 10kHz signal could only be resolved by an FFT to 1ppm in 100 seconds of continuous data.
Reciprocal counting of a single signal in the absence of noise will give a faster and more precise frequency. Gather a block of data and then, still in the time domain, resolve where all the zero crossings are throughout that block. The time between the first crossing and the last crossing divided by the integer number of cycles will give the period to great accuracy. Likewise the average of the separation between similar crossings is statistically the wave period.
As an example, several cycles of a signal gathered at 10ksps for10 seconds would give a resolution of 1 in (10k * 10s) = 10ppm. With a sound card you might be able to squeeze 96kHz conversion for 10 seconds which gets you very close to the 1ppm resolution wanted.
There are PIC projects around that do reciprocal counting and display it as a frequency on an LCD. It should be easy to do it with FreeBASIC and a sound card, so long as thermal drift of the sound card crystal can be minimised. That can be checked and possibly corrected by measuring a known signal reference, maybe a good use for that stereo channel with a signal from a crystal oven or GPS derived reference.
You can avoid the 1pps message clock by using a 5MHz or 10MHz GPS derived oscillator that is locked to the internal receiver oscillator. Digital divide it down to audio for the stereo channel reference. I believe that the better GPS receivers have an external 5MHz output. There are also kits such as http://www.siliconchip.com.au/cms/A_108508/article.html
Hi all
This may seem totally out of context .....
Long time ago, I used a HP counter to count the accuracy of the 50hz power (in oz). Each time the counter overflowed, I used a connection to a calculator
to add a very small number. After counting for 24 hours the error was less then a couple of cycles. Dont know if the frequency is that accurate anywhere else.
It made a very reliable reference.
Regards
PS. When I brought that calculator into an exam room with a lead hanging out, I was promptly shown the door.
This may seem totally out of context .....
Long time ago, I used a HP counter to count the accuracy of the 50hz power (in oz). Each time the counter overflowed, I used a connection to a calculator
to add a very small number. After counting for 24 hours the error was less then a couple of cycles. Dont know if the frequency is that accurate anywhere else.
It made a very reliable reference.
Regards
PS. When I brought that calculator into an exam room with a lead hanging out, I was promptly shown the door.
I've looked at the SW at http://www.qsl.net/dl4yhf/spectra1.html and it is quite impressive. A good link.
It uses FFT for the frequency, and also averages, and so gives a useful comparison, and has one of the better FFT Digits/seconds I have seen.
FFT however has variable error vs frequency which makes it less suitable for our targets. The Link SW of course targets much poorer S/N then we have, so it is better suited for that task.
It uses FFT for the frequency, and also averages, and so gives a useful comparison, and has one of the better FFT Digits/seconds I have seen.
FFT however has variable error vs frequency which makes it less suitable for our targets. The Link SW of course targets much poorer S/N then we have, so it is better suited for that task.
@jmg
Amateur radio QRSS works more than 30dB below the noise floor. QRSS is usually transmitted as Morse code with a single dot being 30 seconds long. The software is also capable of showing transmitters drifting relative to reference signals over 24 hours.
For your project reciprocal counting is definitely the way to go. An FFT with power spectrum accumulation would only demonstrate harmonic content of the oscillators. I have some code that does that efficiently and could be used on the same data as your reciprocal counter if you need it.
@Dinosaur
In some Australian states the mains frequency used to be checked against a master 1kHz reference from atomic clocks at the Telecom Research Labs in Victoria. This was distributed over a single phone line pair as 2f and 3f, that is 2kHz and 3kHz sine waves. When they got to the end user they were applied to a diode that mixed them returning a 1kHz difference frequency that was then filtered to remove all the harmonics. This meant that the precise 1kHz reference could be distributed over frequency multiplexed trunk lines without problems. The power authority counted their 50Hz power cycles and subtracted the TRL 1kHz cycles (divided by 20). The operator turned a handle that adjusted the network frequency based on that difference. At the end of the day they aimed to have the right number of cycles to keep the clocks right. I guess if you counted mains cycles for 24 hours it would get pretty close to the atomic clocks at TRL.
TRL also produced the VNG time signals from Lyndhurst in Victoria on 4.5, 7.5 and 12MHz. Back in the 1970s I used VNG as a reference to measure the mains frequency, when it started to fall out of the normal window it meant something was wrong on the network, that sounded an alarm, the operator was woken up and could fixed it.
Amateur radio QRSS works more than 30dB below the noise floor. QRSS is usually transmitted as Morse code with a single dot being 30 seconds long. The software is also capable of showing transmitters drifting relative to reference signals over 24 hours.
For your project reciprocal counting is definitely the way to go. An FFT with power spectrum accumulation would only demonstrate harmonic content of the oscillators. I have some code that does that efficiently and could be used on the same data as your reciprocal counter if you need it.
@Dinosaur
In some Australian states the mains frequency used to be checked against a master 1kHz reference from atomic clocks at the Telecom Research Labs in Victoria. This was distributed over a single phone line pair as 2f and 3f, that is 2kHz and 3kHz sine waves. When they got to the end user they were applied to a diode that mixed them returning a 1kHz difference frequency that was then filtered to remove all the harmonics. This meant that the precise 1kHz reference could be distributed over frequency multiplexed trunk lines without problems. The power authority counted their 50Hz power cycles and subtracted the TRL 1kHz cycles (divided by 20). The operator turned a handle that adjusted the network frequency based on that difference. At the end of the day they aimed to have the right number of cycles to keep the clocks right. I guess if you counted mains cycles for 24 hours it would get pretty close to the atomic clocks at TRL.
TRL also produced the VNG time signals from Lyndhurst in Victoria on 4.5, 7.5 and 12MHz. Back in the 1970s I used VNG as a reference to measure the mains frequency, when it started to fall out of the normal window it meant something was wrong on the network, that sounded an alarm, the operator was woken up and could fixed it.
Yes, in OZ as far as I remember, the mains cycles per day is accurate because some clocks are locked to mains frequency. Mains can slow down during heavy peak load times, and catch up again at night when the load is low---but the total # of cycles in any 24hr period is very accurate apparently. With crystal clocks this is now not so important, but when clocks were commonly driven by little synchronous motors then it was much more critical to get it correct.
some updates: FMOD can read/record from the Sound channels.
I also found a quite nice looking Oscilloscope as a Delphi DLL,
http://brnstin.googlepages.com/
but have not quite nailed linking this into FB.
(see other post)
I can create & link a dummy FB_dll (.bas/.bi), but the
same .bi & Delphi_dll coughs...
I suspect a FB issue ..
I also found a quite nice looking Oscilloscope as a Delphi DLL,
http://brnstin.googlepages.com/
but have not quite nailed linking this into FB.
(see other post)
I can create & link a dummy FB_dll (.bas/.bi), but the
same .bi & Delphi_dll coughs...
I suspect a FB issue ..