> You make me curious. Any specific issue you're having?
>
> I haven't tried doing any programming to the SR620 yet, but I have some
> plans to do it.
>
> Cheers,
> Magnus
Hi Magnus,
Thanks for asking. Here's an update.
I was curious why time interval or period measurements give slightly different
results than frequency measurements on a SR620. Maybe the 5370 too. We often
advise people to use time interval mode and not frequency mode. Volker's
posting got me to dig further. His frequency-data ADEV plots looked too
different from his phase-data ADEV plots.
It's not just that frequency introduces dead time, but frequency also gives
less precise results. But why is this. Ignoring other sources of noise, the 620
interpolator has 2.7 ps numerical granularity (1 / 90 MHz / 4096). It seemed to
me that regardless of time interval, period, or frequency mode selection, the
identical quantization and noise levels should be evident regardless how one
measures an external source(s).
So there are two tempting commands to explore. One is BDMP (binary dump) which
avoids ascii conversion and gives raw 64-bit binary values. Some people use it
to dramatically increase measurement speed over GPIB. The other is EXPD (x1000
expanded resolution). My plan was to use two different exceptionally pure but
drifting 10 MHz sources and see to what extent the 620 could measure/compare
them.
The bad news is that EXPD is not allowed with frequencies above 5 digits (>= 1
MHz) so it doesn't apply to 10 MHz inputs. That experiment waits while I make a
clean <1 MHz source (e.g., 10 MHz/12 = 833.3333 kHz).
In a true time-stamping counter one continuously counts events and continuously
counts time. The 620 isn't continuous but it does have two registers, which the
manual refers to as the event or cycle counter and the time interval counter.
Better yet, page 97 also refers to them as the "top" and "bottom" counter.
Hint, hint.
The binary dump data matches my expectations for period and interval. But for
frequency, the 620 does not return the binary values of either the top or
bottom counters. Instead it does a fixed point division and returns a scaled
top/bottom binary quotient.
The net effect is that the ideal BDMP value for a 1 second 10 MHz measurements
would be 0x001C71C71C71C71C. (note 0x1C7 / 4095 = 455 / 4095 = 10 / 90, as in
90 MHz). But you never actually get this hex value with a 10 MHz input. With a
couple hundred 1-second measurements I saw only one of three values each time:
0x1c71c71c721bf3 = 8006399337569267 = 10000000.000027126 Hz
0x1c71c71c7270c9 = 8006399337590985 = 10000000.000054251 Hz
0x1c71c71c72c5a0 = 8006399337612704 = 10000000.000081379 Hz
The delta among these values is 21718 or 21719 counts. So the lower ~16-bits
isn't really "noise", it's just deterministic quantized residuals from the
long-division. And that explains why when the scaled binary values are
converted to decimal Hz you get the odd-looking values above. The granularity,
or resolution is 27 uHz / 10 MHz = 2.7e-12 = 2.7 ps. Nice, yes?
Of hundreds of samples, they were all +1 +2 and +3 times 2.7 ps above nominal.
A +0 would give 10000000.000000000 Hz.
These BDMP readings have (much) greater resolution that what you get with plain
strt;*wai;xall? values. What one normally sees over RS232 or GPIB are ascii
readings like:
1.00000000000E7
1.00000000002E7
1.00000000001E7
1.00000000001E7
1.00000000000E7
Note these readings are 0, 100, or 200 uHz from nominal; that is, the
granularity is 100 uHz / 10 MHz = 1e-11.
Using XREL exposes an additional digit of resolution. Set XREL to 1E7 and then
you get ascii readings like:
1.E-4
-6.E-5
2.E-4
-1.4E-4
.0E-6
-1.9E-4
So not only does XREL give you an extra digit of precision but it also
transmits fewer bytes. The granularity in this case is 10 uHz / 10 MHz = 1e-12.
The hope is that XALL, XREL/XALL, and BDMP agree. But each has different
truncation, rounding, and granularity rules. My recommendation is that when
making high-precision SR620 10 MHz frequency measurements to use XREL to gain
back that least dignificant digit otherwise lost to truncation. Over
RS2332/GPIB that's "xrel1e7" but you can also do it from the front panel.
I'll try this again with EXPD turned on to see what effect that has. I'll also
adjust the interpolator calibration tables.
The code I used to grab and decode the SR620 binary data is at
http://leapsecond.com/tools/620bdmp.c
Let me know if you want to jump into this too, or have any corrections/comments.
Thanks,
/tvb
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
