Re: [time-nuts] Determining Allan Deviation From Interpolated Peak Frequency Readings

[Mark Goldberg]

On Sat, Dec 16, 2017 at 7:36 AM, Gerhard Hoffmann  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
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Determining Allan Deviation From Interpolated Peak Frequency Readings

[Mark Goldberg]

On Sat, Dec 16, 2017 at 3:57 AM, Attila Kinali  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
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Determining Allan Deviation From Interpolated Peak Frequency Readings

[Gerhard Hoffmann]

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




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Determining Allan Deviation From Interpolated Peak Frequency Readings

[Attila Kinali]

On Fri, 15 Dec 2017 10:08:29 -0700
Mark Goldberg  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/


-- 
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Determining Allan Deviation From Interpolated Peak Frequency Readings

[Mark Goldberg]

Thanks for the detailed response.

On Fri, Dec 15, 2017 at 5:42 AM, Attila Kinali  wrote:

> Hey Mark
>
> On Wed, 6 Dec 2017 15:43:49 -0700
> Mark Goldberg  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
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Determining Allan Deviation From Interpolated Peak Frequency Readings

[Attila Kinali]

Hey Mark

On Wed, 6 Dec 2017 15:43:49 -0700
Mark Goldberg  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.

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
-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.