Update: now with the colours matching in all graphs:
Time-series generated with colorednoise (following Kasdin&Walter), power-spectral-densities and Allan deviations computed with allantools, and compared to theoretical predictions in IEEE1139-2008.
The PSD lines and MDEV lines seem spot-on, but are the ADEV lines systematically a bit low?
Code here: example_noise_slopes.py
Update: a figure with more data points:
I've released AllanTools 2016.3 which now contains new mtotdev(), htotdev(), and theo1() statistics along with many other improvements. Here's a benchmark:
Compare to this one (from here):
See also: numpy vs pure python comparison from 2014 August.
Following on from modified total deviation mtotdev() the Hadamard total deviation htotdev() algorithm is very similar but instead of phase data takes frequency data. Now included in allantools.
Here's a comarison against Stable32 and the NIST SP 1065 table values.
There's no bias-correction for now, and apparently it is customary not to use htotdev(m=1) at an averaging-factor of 1, but instead use ohdev(m=1). This is why the 'raw' value from allantools at tau=1 in the plot below is a factor of 2 too low.
Both mtotdev() and htotdev() are very slow algorithms - help with making them faster would be appreciated!
I wrote a first rough (and very slow!) implementation of Modified Total Deviation mtotdev() for allantools.
mtotdev() combines the features of modified Allan deviation mdev() (being able to distinguish between white and flicker phase modulation) and Total deviation totdev() (better confidence intervals at large tau).
Here are some results. The Time Total Deviation ttotdev() follows trivially from this work also, since it is only a scaled version of mtotdev(). I used the "NBS14" 1000-point frequency dataset and compared my results against Stable32 and those in NIST SP 1065 (Table 31, page 108).
The figures show mtotdev() and ttotdev() from Stable32 runs and allantools. I've also added mdev() and tdev() traces to compare against. At first sight this looks strange, but mtotdev() is a biased estimator, and Stable32 applies a bias correction which explains the results.
Somewhat surprisingly Stable32 applies a bias-correction only when run in the "all-tau" mode. These numbers agree with those from the NIST SP 1065 table. For this dataset Stable32 is undecided on what power-law the dataset follows at large tau, which results in deviations that jump up and down (because a different bias-correction is applied at different tau, red datapoints).
When Stable32 is run in "octave-tau" or "decade-tau" mode no bias correction is applied. These numbers agree with the ones from allantools.mtotdev().
This figure shows the ratio of variances between allantools.mtotdev() (no bias correction) and a Stable32 all-tau run (bias correction applied). The lines correspond to the bias-correction values for different noise processes.
There also seems to be a misprint in NIST SP 1065 equation (28) page 26, where it says ttotdev() is scaled by tau-cubed (when tau-squared is correct). Who reads these things anyway - not many it seems 😉
I've looked at calculating phase-noise spectra with python - to be included in allantools. Here are some first results.
We got a new 53230A counter to the lab, so I decided to run some basic tests on it.
I collected time interval data using a 1-PPS source (H-maser through a SRS DG645), and wired this with a T-connector from CH1 to CH2 with a ~1 m (10 ns delay) cable. This should show the noise floor for time interval measurements as well as CH1/CH2 timing skew when measured the other way around (i.e. from CH2 to CH1). The 10 MHz external reference (at the back) was connected to a H-maser.
The results show standard deviations of 12 ps (CH1->CH2) and 11 ps (CH2->CH1) respecively, with a channel skew of 112 ps. Compare to the single-shot spec of sqrt(2)*20 ps = 28 ps and Agilent/Keysight's marketing video on youtube.
I also collected 10 MHz frequency counter readings on CH1 (source: H-maser) with gate times of 0.1 s, 1.0 s, and 10.0 s. I collected the data with a simple program that just calls the "READ?" function repeatedly, which does result in some dead-time between measurements.
Here are the results in terms of Allan deviation. I used allantools.
The time interval noise floor looks like white phase noise with an Allan deviation of 1.8e-11/tau. This is consistent with the 12 ps RMS value found above. It is left as an exercise for the reader to show that ADEV(1s) = sqrt(3)*RMS-time-interval-noise (correct??).
The frequency counting noise floor depends on the gate time, and I get 5e-12/sqrt(tau), 2e-12/sqrt(tau), and 6e-13/sqrt(tau) for gate times of 0.1 s, 1.0 s, and 10.0 s, respectively. This looks like white frequency noise. Enrico Rubiola has notes on frequency counters that may explain the numbers.
We got some White Rabbit Switches and I did an initial test of the pulse-per-second (PPS) output stability. In contrast to earlier measurements that showed 200ps or so of white phase noise, the PPS output on the WRS now seems a lot more stable. For various reasons the noise-floor (red data) of our 53230A time-interval-counter is at around 50e-12 @ 1s, and the WRS PPS output is at very much the same level of stability. Another 53230A counter shows about 13 ps standard-deviation for a cable-delay measurement - so I may redo these measurements with that counter. In any case a real evaluation of the short-term stability requires a DMTD measurement at 10 MHz.
Update: these slopes are both linear, or O(n), where n is the input data size.
However for the worst performing algorithm, MTIE, an O(n*log(n)) algorithm that uses a binary tree to store intermediate results is possible. This algorithm restricts the tau-values to 2**k (with k integer) times the data interval.
Danny Price has made a fantastic contribution to allantools by taking my previous pure python code (hacked together in January 2014, shown in red) and numpyifying it all (shown in blue)!
For large datasets the speedups are 100-fold or more in most cases!
The speedups are calculated only for datasets larger than 1e5, since python's time.time() doesn't seem suitable for measuring 1 ms or shorter running times.