[time-nuts] Fwd: Homebrew frequency counter, need help

[Magnus Danielson]

Hi Bob,

On 12/15/2014 02:22 AM, Bob Camp wrote:
> Hi
>
> (yes, this is a bit confusing … it’s my replies to a forward from Magnus who got a bounce on submittal)

Whe're confusing Bob, I think they got that part now.

>> Begin forwarded message:
>>
>> Date: December 14, 2014 at 7:57:39 PM EST
>> From: Magnus Danielson <magnus at rubidium.se>
>> To: Bob Camp <kb8tq at n1k.org>
>> Cc: magnus at rubidium.se
>> Subject: Re: [time-nuts] Homebrew frequency counter, need help
>>
>> Hi Bob,
>>
>> Repost my email as I accidentally posted it with wrong from address.
>>
>> On 12/14/2014 08:26 PM, Bob Camp wrote:
>>>>> … and this is where it gets complicated. I would toss in the Hadamard deviation into that mix as well.
>>>>
>>>> The Hadamard deviation is a great tool as it is not sensitive to linear frequency drift as Allan deviation is. This would help to remove the systematic effect, just as a quadratic curve-fitting of the raw-data and ADEV of the residual.
>>>
>>> I like the Hadamard because it’s a bit better for mapping to the frequency domain. It’s what HP used to get phase noise from phase error data. I find that it gives a bit better detail on some types of problems.
>>
>> I use if regularly, but TimeLab unfortunatly does not have the MHDEV.
>
> The whole process of getting *correct* versions of things into a program is (unfortunately) much harder than simply tossing it in there. I’m glad that the stuff in TimeLab works correctly.

I do know that, and it's not the only culprit, John naturally wants one 
that works correctly in update form, and not batch form. He also does 
not want too many of these running in parallel.

>>
>>>>
>>>> Modified Hadamard deviation (MHDEV) is a good replacement for MDEV, with the same properties for drift. Similarly will Time Hadarmard Deviation (THDEV) replace TDEV. However, for longer taus you want better processing, so therefore you want to consider the TOTAL set of deviations, such that confidence intervals is better.
>>>>
>>>>> If I had to only use three, I would include it with modified ADEV (MDEV) and TDEV. All three are available in TimeLab with the click of a button. If you start getting lots of data (9,000 points per second) I would toss in a frequency domain (FFT) analysis as well. FFT on phase data is not (as far as I know) a feature of TimeLab.
>>>>
>>>> FFT on phase-data is only available in TimeLab when doing phase-noise measurements. FFT is the way to analyse systematic noise rather than random noise where ADEV and friends is being used. You need to separate them, and the ADEV plot is not good for both.
>>>>
>>>> There is a set of FFT based ADEV-style measures, which uses FFT, filtering of the various ADEV styles. There is a nice set of articles covering that approach, and actually the only style of ADEV processing that I haven't yet implemented, even if I have done most others.
>>>
>>> Stable-32 will take phase data and convert it to the frequency domain.
>>
>> Depending on what processing you are going to do, phase or frequency may be optimum.
>> Phase is better for normal deviations.
>> Frequency is better for modified deviations.
>
> Stable 32 is nice in that it will convert one to the other with the click of a button.

I'm sure it is fine, but it does not fit my needs in one way, it doesn't 
run on Linux. My milage with Wine on different applications vary. 
TimeLab works, but is free. For an application I pay for and not knowing 
it works would be strange. Besides, I try to minimize my dependence on 
Windows apps, as they tend to bite me. Stable 32 thus does not fit my 
needs very well, even if I'm sure it is a fine application.

>>
>>>>
>>>>> To start with, on all of these measures, you are looking for bumps and spikes. They are telling you that something is wrong. If you flip over to the phase plot in TimeLab, spikes and abrupt steps in it also are telling you the same sort of thing. Exactly what this or that bump is telling you may not be obvious at first. Posting plots to the list is a great way to get things sorted out.
>>>>
>>>> Bumps, spikes and slopes... ADEV isn't the only tool one should be using, FFT might be much better for systematic noises.
>>>
>>> Right, so when you see them, alarm bells should go off. Something is indeed wrong and further investigation is required.
>>
>> Maybe, ADEV is good at smoothing out things, so spikes in spectrum-analysis might not be as easy to spot in the ADEV form.
>
> A good reason to look at multiple data sets and analysis approaches

Which is what I am say, do not rely on ADEV alone, and move your 
analysis of systematics out of the ADEV plot and remove those effects 
fro the ADEV plot so it becomes better at modeling the random noises.

>>
>>>> In the end of the day, there is an overbeleife in ADEV both as a scale as well as a processing tool, to analyze deviations, without considering the separation of various systmeatic effect and systematic noises, while ADEV and friends is there to analyze random noise types, it does not handle systematics good. Seems like we have to kill ADEV as the universal measure. Ah well.
>>>
>>> It’s been around much longer than some of the others. It also has some nice convergence properties. That’s made it the spec of choice when describing the performance of a wide range of products. You could buy a box that had a “measure ADEV” button on it a very long time ago …. like back when I started doing this … Having a piece of gear to point at for a spec measurement is a real good thing. It eliminates a wide range of discussions. That goes at least double if it has the logo of a well known test gear outfit on it.
>>
>> That may be, but ADEV is often misused to be the only plot.
>
> Ok, so what gear with a major label on it would you use in the 1980’s and 1990’s to measure spec performance on a few million OCXO’s …..

You are off in a different track here. I'm discussing processing 
techniques and their missuses. I think you have a particular application 
in mind and a particular historic context in mind. We are not discussing 
the same thing.

Rather than saying "throw it through ADEV and be done with it" I say 
"analyse the phase FFT, ADEV and plot the phase, preferably compensate 
systematics out of ADEV". This is not saying "box A from vendor V is not 
going to do it".

>>
>> I actually got an old Timing Solutions
>
> At least up to the end of the 1990’s that name would get you a Timing Who? response from > 90% of the customers of OCXO’s.
>
>> test-set that does ADEV at 0.1, 1, 10 and 100 s using an offset rubidium at 5.000055 MHz. I've never been able to get the serial port to do anything useful. Love to pull the data out of that one and into TimeLab.
>
> They are good boxes. They just are from a very specialized outfit. That also makes getting them repaired a bit tough.

Being a DMTD setup in a box with a whooping 6502 processor doing 
real-time processing, presentation, front panel operation etc it's doing 
quite well.

Cheers,
Magnus