Single-ion Sr+ trap.

#### CategoryResearch

Recently merged plotting-functions for allantools with a look and feel of Stable32 - thanks to yxie.

I should probably run python3 to get special characters like tau and sigma to work..

We got a 350 eur AIM-TTi TF930 frequency counter for less demanding frequency counting. Here's how it looks like on the inside.

See also discussion on the AD forum: https://ez.analog.com/dds/f/q-a/107510/ad9912-ftw-lsb-always-zero

We've tried to measure the frequency resolution of the AD9912 DDS, which when used with a 1 GHz SYSCLK should be 1 GHz / 2**48 = 3.55 uHz.

We tried an ARTIQ Urukul-board and an AD dev-board and got the following results:

In both cases the output frequency corresponds to an even frequency tuning word (FTW) although we step the frequency by one LSB. In other words the LSB appears to be zero in all cases, even when we write an odd FTW with '1' as the LSB. Instead of the expected 3.55 uHz frequency resolution we see double-sized steps of 7.1 uHz.

The Urukul measurement was done with a Microsemi 3120A phase-meter and the dev-board was measured using a PICDIV 1PPS-divider followed by a Keysight 53230A time interval counter. The even FTW frequencies agree with the predicted frequency to much better than 0.1 uHz.

Inspired by discussion on time-nuts, here's a revised noise-colour graph. There are a few updates: The PSDs (both phase and frequency) now cross at 1 Hz (with the relation between phase-PSD and frequency-PSD explicitly stated), and the ADEV/MDEV theoretical lines now include the formula for the pre-factor (the old graph only had 'proportional to' here).

Source: example_noise_slopes2.py

It is left as an exercise to the reader to properly explain the ADEV pre-factor for flicker-phase noise :).

An evolution of my PICDIV-board from 2016. Takes 10MHz input and produces 1PPS (one pulse per second). This one has a TADD-2-mini inspired sine-to-square converter on the input (far left), a PIC12F675 with Tom van Baak's PICDIV-code (right), an ICSP-header for programming, and output-buffers inspired by the pulse distribution amplifier. A 3-position DIP-switch (middle left) allows config-changes, and a blinking LED indicates 1PPS (middle right).

Fixed a few bugs in the first PCB-revision and will order boards for version two soon. Eventually to be published on github/ohwr - stay tuned..

By popular demand, AllanTools 2018.03 is now released under LGPL license.

Work with integrating noise-identification with downstream confidence-interval estimation and bias correction continues as time permits.

For AllanTools statistics both bias-correction and confidence interval calculation requires identifying the dominant power law noise in the input time-series.

The usual noise-types studied have phase PSD noise-slopes "**b**" ranging from 0 to -4 (or even -5 or -6), corresponding to frequency PSD noise-slopes "**a**" ranging from +2 to -2 (where **a=b+2**). These 'colors of noise' can be visualized like this:

I've implemented three noise-identification algorithms based on Stable32-documentation and other papers: B1, R(n), and Lag-1 autocorrelation.

**B1** (Howe 2000, Barnes1969) is defined as the ratio of the standard N-sample variance to the (2-sample) Allan variance. From the definitions one can derive an expected B1 ratio of (the length of the time-series is **N**)

where **mu** is the tau-exponent of Allan variance for the noise-slope defined by **b** (or **a**). Since **mu** is the same (-2) for both b=0 and b=-1 (red and green data) we can't use B1 to resolve between these noise-types. B1 looks like a good noise-identifier for b=[-2, -3, -4] where it resolves very well between the noise types at short tau, and slightly worse at longer tau.

**R(n)** can be used to resolve between b=0 and b=-1. It is defined as the ratio MVAR/AVAR, and resolves between noise types because MVAR and AVAR have different tau-slopes **mu**. For b=0 we expect mu(AVAR, b=0) = -2 while mu(MVAR, b=0)=-3 so we get mu(R(n), b=0)=-1 (red data points/line). For b=-1 (green) the usual tables predict the same mu for MVAR and AVAR, but there's a weak log(tau) dependence in the prefactor (see e.g. Dawkins2007, or IEEE1139). For the other noise-types b=[-2,-3,-4] we can't use R(n) because the predicted ratio is one for all these noise types. In contrast to B1 the noise identification using R(n) works best at large tau (and not at all at tau=tau0 or AF=1).

The **lag-1 autocorrelation** method (Riley, Riley & Greenhall 2004) is the newest, and uses the predicted lag-1 autocorrelation for (WPM b=0, FPM b=-1, WFM b=-2) to identify noise. For other noise types we differentiate the time-series, which adds +2 to the noise slope, until we recognize the noise type.

Here are three figures for ACF, B1, and R(n) noise identification where a simulated time series with known power law noise is first generated using the Kasdin&Walter algorithm, and then we try to identify the noise slope.

For Lag-1 ACF when we decimate the phase time-series for AF>1 there seems to be a bias to the predicted **a** (alpha) for b=-1, b=-3, b=-4 which I haven't seen described in the papers or understand that well. Perhaps an aliasing effect(??).

For fun I wrote a simple program that computes the SHA1 checksum for leap-seconds.list.

It turns out there's quirky convention of writing out the 40-character SHA1 checksum in 5 groups of 8 hex characters - **whith the special undocumented rule that leading zeros are suppressed**. This means the SHA1 check fails for some files where we happen to have a leading zero in one of the 8-character groups - unless you happen to know about the undocumented rule...

The output looks like this. "New" is the checksum computed by the program, "Old" is the checksum contained in the published file.

https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list read 117 lines New: 1e2613791c4627c2d0a34c872ece0ae428dfb714 Old: 1e2613791c4627c2d0a34c872ece0ae428dfb714 Identical ? True ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list read 220 lines New: 3f00425591f969f7252361e527aa6754eb6b7c72 Old: 3f00425591f969f7252361e527aa6754eb6b7c72 Identical ? True https://www.ietf.org/timezones/data/leap-seconds.list read 250 lines New: 5101445a69948b5109153e2b2086e3d8d54561a3 Old: 5101445a69948b519153e2b2086e3d8d54561a3 Identical ? False https://data.iana.org/time-zones/code/leap-seconds.list read 250 lines New: 5101445a69948b5109153e2b2086e3d8d54561a3 Old: 5101445a69948b519153e2b2086e3d8d54561a3 Identical ? False ftp://ftp.nist.gov/pub/time/leap-seconds.list read 250 lines New: 5101445a69948b5109153e2b2086e3d8d54561a3 Old: 5101445a69948b519153e2b2086e3d8d54561a3 Identical ? False

There's also another simple script for authoring a leap-seconds.list file. It might be used for adding an artificial leap-second, generating a leap-seocnds.list file, and testing how different devices react to a leap-second - without having to wait for a real leap-second event.

In other news IERS recently announced there will be no leap-second in the summer of 2018.

See also time-stamp for leap-seconds.list.

© 2019 anderswallin.net

Theme by Anders Norén — Up ↑

## Recent Comments