Re: [time-nuts] Determining Allan Deviation From Interpolated Peak Frequency Readings
Thanks for the detailed response.
On Fri, Dec 15, 2017 at 5:42 AM, Attila Kinali attila@kinali.ch wrote:
Hey Mark
On Wed, 6 Dec 2017 15:43:49 -0700
Mark Goldberg marklgoldberg@gmail.com wrote:
https://sites.google.com/site/perseusmods/
and
https://sites.google.com/site/spectrumlabtesting/
using wide FFT bins and Spectrum Lab's peak frequency interpolation
function. I would appreciate comments as to the effectiveness of this
approach. I have a thick skin, so any criticism is welcome if it improves
the process.
The approach using FFT works, but just using the peak frequency, you throw
away half of the data (the phase) and also limit yourself in precision
to the bin width. It's not 100% clear that estimating the frequency
using an FFT is unbiased in this case, thus you might get worse (or better)
results than what the oscillator actually does.
Since I do not know the exact algorithm used to interpolate peak frequency,
I don't know the effect on precision. They do claim that the peak frequency
determination precision is much smaller than the bin width, which seems to
be shown by the data.
The results are good enough to discern between "bad" and "good" units under
test, but I have no way to compare my results to any other method of
measurement. This is all I have access to.
What you are trying to do is spectral estimation from a limited number of
samples. You want to have some kind of continuity, that might allow you to
track minute changes from block you are processing to the next block.
The easiest way to do this would be to downconvert the signal on the PC
to zero Hz and take the phase information (simplest way: use a NCO as a
reference, then pass the reference and signal into a CORDIC to get the
phase
difference). Recording this phase difference should give you a lower floor
for *DEV than your FFT method. It will also alow you to track small phase
changes (aka small frequency fluctuations) that happen over long periods.
Sherman and Jördens[1] describe the approach in more detail.
Other than that, the general approach looks ok.
Attila Kinali
[1] "Oscillator metrology with software defined radio",
by Sherman and Jördens, 2016
https://arxiv.org/abs/1605.03505
I have seen this paper before. Unfortunately, it is a lot more work to
implement than what I have already done. I am really a hardware engineer,
with decades old education in control systems that has not been used in a
long time. It would take getting my brain back in gear and re-studying, not
a bad thing actually!
The other issue is the Perseus drivers have issues under Windows 10 that
may or may not be solved. I was able to get it to work with Spectrum Lab,
but it does not work with many other tools that would be able to implement
this algorithm.
That said, I may look into it further in the future.
Mark
On Fri, 15 Dec 2017 10:08:29 -0700
Mark Goldberg marklgoldberg@gmail.com wrote:
The approach using FFT works, but just using the peak frequency, you throw
away half of the data (the phase) and also limit yourself in precision
to the bin width. It's not 100% clear that estimating the frequency
using an FFT is unbiased in this case, thus you might get worse (or better)
results than what the oscillator actually does.
Since I do not know the exact algorithm used to interpolate peak frequency,
I don't know the effect on precision. They do claim that the peak frequency
determination precision is much smaller than the bin width, which seems to
be shown by the data.
The results are good enough to discern between "bad" and "good" units under
test, but I have no way to compare my results to any other method of
measurement. This is all I have access to.
If all you want is to discern good and bad units, this is good enough.
[1] "Oscillator metrology with software defined radio",
by Sherman and Jördens, 2016
https://arxiv.org/abs/1605.03505
I have seen this paper before. Unfortunately, it is a lot more work to
implement than what I have already done. I am really a hardware engineer,
with decades old education in control systems that has not been used in a
long time. It would take getting my brain back in gear and re-studying, not
a bad thing actually!
The other issue is the Perseus drivers have issues under Windows 10 that
may or may not be solved. I was able to get it to work with Spectrum Lab,
but it does not work with many other tools that would be able to implement
this algorithm.
That said, I may look into it further in the future.
Apparently the Perseus is supported by GnuRadio[1]. Which means you can
just click your control system together (similar to LabView). According
to [2] the driver uses libusb and works on windows as well.
If you want to use GnuRadio, I suggest you go to one of the many Hackfests[3]
they have and let them jump-start you (I started this way years ago).
Attila Kinali
[1] https://gnuradio.org/
[2] https://github.com/Microtelecom/libperseus-sdr
[3] https://www.gnuradio.org/event-type/hackfest/
--
<JaberWorky> The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
Am 16.12.2017 um 11:57 schrieb Attila Kinali:
[1] "Oscillator metrology with software defined radio",
by Sherman and Jördens, 2016
https://arxiv.org/abs/1605.03505
I have seen this paper before. Unfortunately, it is a lot more work to
implement than what I have already done. I am really a hardware engineer,
with decades old education in control systems that has not been used in a
long time. It would take getting my brain back in gear and re-studying, not
a bad thing actually!
The other issue is the Perseus drivers have issues under Windows 10 that
may or may not be solved. I was able to get it to work with Spectrum Lab,
but it does not work with many other tools that would be able to implement
this algorithm.
That said, I may look into it further in the future.
Apparently the Perseus is supported by GnuRadio[1]. Which means you can
just click your control system together (similar to LabView). According
to [2] the driver uses libusb and works on windows as well.
If you want to use GnuRadio, I suggest you go to one of the many Hackfests[3]
they have and let them jump-start you (I started this way years ago).
I'm about to buy a RedPitaya Stemlab 125-14. Cost is just €310 in .de,
seems to have respectable performance, can emulate the
GnuRadio hardware boards more or less right out of the box,
Win & Linux.
And it is a nice stepping stone to what I really want: a bigger ZYNC
with JESD204B support, AD9680/ADC32RF45 ADCs & AD9142 or
similar DACs for direct L-band digitizing. No more
phase-shifting preselector or IF filters.
There seem to appear better ADC/DAC chips every month for Gen5.
That could be a Timepod++ :-)
regards, Gerhard
< https://www.redpitaya.com/c96/stemsuplabsup-125-14 >
< http://pavel-demin.github.io/red-pitaya-notes/sdr-transceiver-hpsdr/ >
On Sat, Dec 16, 2017 at 3:57 AM, Attila Kinali attila@kinali.ch wrote:
Apparently the Perseus is supported by GnuRadio[1]. Which means you can
just click your control system together (similar to LabView). According
to [2] the driver uses libusb and works on windows as well.
If you want to use GnuRadio, I suggest you go to one of the many
Hackfests[3]
they have and let them jump-start you (I started this way years ago).
There are issues with the Perseus, Windows 10 and USB3. It is hit and miss
with various software. I am not sure it would actually work with GnuRadio
on the computer I use in my Ham Radio / Electronics lab. I do have three
computers running Linux but they are elsewhere. Simon Brown has posted some
positive messages about the cause of this being found on the Perseus Forum.
Hopefully it can be fixed. The creator of the Perseus has had to move on to
other things and can only provide limited help.
It would be a big project fro me though. I have lots of projects, but will
consider it. I do have a friend that is much more of an expert with
GnuRadio.
Thanks,
Mark
W7MLG
On Sat, Dec 16, 2017 at 7:36 AM, Gerhard Hoffmann dk4xp@arcor.de wrote:
I'm about to buy a RedPitaya Stemlab 125-14. Cost is just €310 in .de,
seems to have respectable performance, can emulate the
GnuRadio hardware boards more or less right out of the box,
Win & Linux.
And it is a nice stepping stone to what I really want: a bigger ZYNC
with JESD204B support, AD9680/ADC32RF45 ADCs & AD9142 or
similar DACs for direct L-band digitizing. No more
phase-shifting preselector or IF filters.
There seem to appear better ADC/DAC chips every month for Gen5.
That could be a Timepod++ :-)
You know you guys are going to wind up costing me more money! The RedPitya
looks like an amazing product for the price, dual ADCs and DACs and a Zync
for that price! And, they are available at Digikey in the US for pretty
good prices. Again, a project for the future possibly.
Thanks,
Mark
W7MLG