White Rabbit DIO vs. FDELAY PPS output test

I ran a test to compare the quality of PPS outputs from a DIO (used as GM) and an FDELAY (used as slave) White Rabbit SPEC/FMC combinations. Here is the phase data measured with a Time-interval-counter. The nice clean traces are derived from a H-maser. We then lock a BVA (internally 2x multiplied to 10MHz) to this PPS signal. The GM node is locked to this 10MHz signal.

The average of each trace was removed, and the traces are offset for clarity.

fdelay_gm_pps_time-series_2014-01-29

The Allan deviations look like this. Both the DIO and FDELAY PPS outputs have allan deviations about 5x worse than the BVA used as input clock for the GM.

fdelay_gm_pps_ADEV_2014-01-29

AD9912 DDS Test

Update: it turns out the PLL filter components were not connected at all during the first tests I did 🙂 Here's a picture that compares the schematic against the actual board. When I changed the 0R resistor from position "R3" to position "R5"  the PLL started behaving much more nicely. If anyone from AD is reading - please update your documentation!

ad9912_eval_board_pll_schematic

With this change, and a 66x PLL multiplier giving a 10MHz x 66 = 660 MHz SYSCLOCK I get quite nice output:

Fout100M_Span50M Fout100M_Span400M Fout100M_Span500k

The output is set to 100 MHz and has an amplitude of ~0 dBm. There are -60 dBm spurs at +/- 50 kHz (not sure why?), -70 dBm spurs at +/- 10MHz, and a -65 dBm second harmonic at 200 MHz.

If I activate the "2x Reference" setting which detects both rising and falling edges of the input clock, and use that with a 40x PLL for a 10MHz x2 x40 = 800 MHz SYSCLOCK I still get very strong spurs at 10 MHz:

Fout100M_Span400_PLL_2x40x

I have been testing this AD9912 DDS evaluation board:
ad9912_evkit_pcb_text

So far the results are a bit strange, with output as advertized only when no external input clock is supplied. Strange.

dds_test_2013-12-30

Comparing GPS PPP solutions

Update3 on 2014-02-20: by popular demand, screenshots of options (at least roughly correct...) used in RTKPOST to get the results shown:

rtklib_settings_2014-02-20

Update2: gLAB data now at 30s intervals, and an error-plot that compares CSRS to gLAB clock offset.

ppp_2013-12-25_glab

 

Update: using the latest RTKLib from github on Ubuntu, I now got this, with the lat/lon/height results between CSRS-PPP and RTKLib in better agreement. There is still a 4ns offset between the clock results - which curiously is about 0.5*ZTD, but this may be just a coincidence.

ppp_2013-12-25

GPS based Precise Point Positioning is used worldwide to compare clocks against each other and maintain UTC.

The idea is to connect your clock to a dual-frequency GPS receiver that collects data (in RINEX format). The RINEX data is then post-processed by using satellite orbit and clock information available (with delay) from the IGS. While normal GPS has a precision of maybe 1-10 meters (~10 ns clock offset/noise), PPP can achieve <1 cm precision (<1 ns clock offset).

I tested a few of the PPP algorithms I found by running them on the same datafile (KAJA2900.13O) and got the results shown below.

If anyone wants to try this at home you will need from the IGS (I used RTKGet, a tool that comes with RTKLib to download these): clock data CLK file igs17624.clk, orbit data SP3 file igs17624.sp3, NAV file brdc2900.13n, antenna correction ANTEX file igs08.atx, earth rotation parameters ERP file igs17627.erp, and possibly also an ocean tide loading BLQ file available from Onsala Space Observatory.

ppp_solutions_2

The CSRS-PPP and ESA-gLAB clock offset solutions agree reasonably well, but the clock offset of the RTKLib/JPL-APPS solutions differ by  3-4 nanoseconds - which is a lot if we are using this for monitoring/steering an atomic clock. I'm not sure why this happens - if anyone knows how to reproduce the CSRS-PPP results with RTKLib please let me know!

  • CSRS-PPP is an online web-based tool that returns results by e-mail. AFAIK the same code is used by the BIPM to maintain UTC.
  • JPL-APPS is a similar web-service by NASA.
  • ESA gLAB and RTKLib are open-source software packages for GPS/GNSS processing.

See also: A Comparison of Free GPS Online Post-Processing Services

 

Strontium ion(s) trapped!


A major milestone towards the ion clock was reached today: we trapped the first Strontium ions!

This involves first heating a dispenser that contains Strontium atoms with about 4-5 W (4 A and 1 V). The atoms that fly out of the dispenser are then photoionized using two blue lasers, one at 461 nm and another at 405 nm (we use a laser from a blue-ray drive for this!). We now have Sr+ ions that can be trapped in a Paul trap. A high-voltage (300 Vpp) ~10 MHz sine-wave is applied to the electrodes of the trap. Another blue laser at 422 nm is then used both for laser-cooling and as a means to detect the ion. What we see in the video is the ion fluorescence at 422 nm when it jumps down to the ground state from an excited state. The excited state can also decay into a dark state and we need a re-pump laser at 1092 nm to keep the ion in the Doppler cooling cycle. The fluorescence emitted from one or a few ions is very weak, and we used an image-intensifier and a CCD camera with 500 ms to 1 s exposure time for this video.

The camera software produces FITS frames as output. I used these commands to make the video:

On the last line "3" is the desired frame-rate of the output. I then concatenated a few of these videos together with

Strontium 461nm absorption/fluorescence revisited

This is the same experiment we did back in April, but now "in-situ" in another vacuum system that houses our RF endcap trap. The thin ray of light that slowly switches on and off is a 461nm blue laser-beam that excites Strontium atoms that fly in from the lower right corner of the picture. The on/off switching happens because we slowly scan the laser frequency back and forth and as a result different parts of the atom-stream absorb and emit.

Next stop: ionizing the atoms and trapping a single ion in the RF trap.

See also:

NTP shared-memory refclock driver for White Rabbit SPEC

ntp_graph

I've been playing with White Rabbit hardware at work. White Rabbit uses a combination of SyncE and PTP to perform very precise (<1 ns) time-distribution.

The standard low-precision way to distribute time is NTP. I hacked together a very experimental "Type 28" NTP refclock driver that reads the WR-time from SPEC shared memory and writes it to another location in shared memory where NTP expects it. Code over here: https://github.com/aewallin/ptp2ntpd

The graph shows system clock variations compared to WR-time (which we assume is very accurate) for a computer with the WR-refclock driver enabled (blue trace, minpoll 16 s), and another computer where the system clock is kept on time using standard NTP (I just added some servers to ntpd.conf, no other settings changed from default Ubuntu 12.04LTS). The WR-disciplined clock stays within maybe 50 microseconds with no net drift during the ~9 hour measurement, but the trace is quite jumpy. The NTP-disciplined clock wanders around much more (300 us) but the trace is smoother.

NTP time measurement

NTP_time_2013jul26

Here's a plot of the time error between the standard unix system-time, kept on time using NTP, and a much more accurate PTP-server based on White Rabbit that runs on a fancy FPGA-based network-card.

Note that without NTP a typical computer clock will be off by 10 ppm (parts-per-million) or more. This particular one measured about 40 ppm error in free-running mode (no NTP). That means during the duration of this 16e4 s measurement we'd be off by about 640 milliseconds (way off the chart) without NTP. With NTP the error seems to stay within 3 milliseconds or so. The offset of -16 milliseconds is not that accurately measured and could be caused by a number of things.

freerunning_vs_ntp_2013jul26

A White Rabbit test

Update3: Here's what happens if you disconnect the master from the switch. The slave clock runs off on its own, with about 5ppm drift compared to the reference clock. Once the fiber is connected again it takes a few seconds to re-sync and lock on to the master clock.

wr_master_kuitu_irti

Update2: two different measurements, on the left with a short 2m fiber, and on the right with a few hundred meters of fiber to a WR-Switch, and a few hundred meters back.

wr_gm_test_csc_2013apr19

Update: an improved measurement now shows some promise:

wr_gm_test_2013apr19

Testing White Rabbit at work. These are fancy network-cards connected by optical fiber which allow synchronization between the cards at better than 1 nanosecond level. My first results are a bit strange:

wr_grandmaster_short_fiber_slave-pps_stats

This is in "grandmaster" mode where we input a 1 PPS and a 10 MHz signal to one of the cards:

13040007

A second result in "free-running" master mode:

WR_freemaster_pps_stats

 

Strontium Blues

We've been playing with a blue laser at 461 nm in the lab lately. If tuned to just the right frequency (wavelength) neutral Strontium atoms will strongly absorb the laser light. Shortly (5 nanoseconds) after that the atoms emit at 461nm also, allowing us to see them:

strontium_461

The atoms originate from a hot "oven" at the right. It glows dark red because it's heated by driving a 5 A to 7 A current through it. The cloud of absorbing atoms glows at 461nm in the centre of the picture.

We can scan the laser frequency by adjusting the current through the diode-laser that produces the light. If the frequency is too low or too high we'll see nothing as the light will just pass through the cloud of atoms without interacting. On each side of the correct absorption frequency we'll see different parts of the atom cloud light up. This happens because the atoms stream out of the oven in slightly different directions, so they experience a different Doppler shift and will react to light with a wavelength slightly to the blue or red from the centre of the absorption-line at 461nm.

When slowly scanning the laser frequency over the absorption-line we got these nice videos. One with a narrow beam and one where the laser beam was expanded.

These were shot with a Canon DSLR so be sure to view them in HD on youtube!

Measuring the thermal expansion of ULE glass

Here's an experiment I've done recently:


(Time-lapse of ca 18 hour experiment. Bottom left is a spectrum-analyzer view of the beat-note signal. Top left is a frequency counter reading of the beat-note. Bottom right is a screen showing the a camera-view of the output-beam from the resonator)

This is a measurement of the thermal expansion of a fancy optical resonator made from Corning "Ultra Low Expansion" (ULE) glass. This material has a specified thermal expansion of 0.03 ppm/K around room temperature. This thermal expansion is roughly 800-times smaller than Aluminium, around 400-times smaller than Steel, and 40-times better than Invar - a steel grade specifically designed for low thermal expansion.

Can we do even better? Yes! Because ULE glass has a coefficient of thermal expansion (CTE) that crosses zero. Below a certain temperature it shrinks when heated, and above the zero-crossing temperature it expands when heated (like most materials do). This kind of behavior sounds exotic, but is found is something as common as water! (water is heaviest at around 4 C). If we can use the ULE resonator at or very close to this magic zero-crossing temperature it will be very very insensitive to small temperature fluctuations.

So in the experiment I am changing the temperature of the ULE glass and looking for the temperature where the CTE crosses zero (let's call this temperature T_ZCTE). The effect is fairly small: if we are 1 degree C off from T_ZCTE we would expect the 300 mm long piece of ULE glass to be 200 pm (picometers) longer than at T_ZCTE. That's about the size of a single water-molecule, so this length change isn't exactly something you can go and measure with your digital calipers!

Here's how it's done (this drawing is simplified, but shows the essential parts of the experiment):

ule_resonator_drawing

We take a tuneable HeNe laser and lock the frequency of the laser to the ULE-cavity. The optical cavity/resonator is formed between mirrors that are bonded to the ends of the piece of ULE glass. We can lock the laser to one of the modes of the cavity, corresponding to a situation where (twice) the length of the cavity is an integer number of wavelenghts. Now as we change the temperature of the ULE-glass the laser will stay locked, and as the glass shrinks/expands the wavelength (or frequency/color) of the laser will change slightly.

Directly measuring the frequency of laser light isn't possible. Instead we take second HeNe laser, which is stabilized to have a fixed frequency, and detect a beat-note between the stabilized laser and the tuneable laser. The beat-note will have a frequency corresponding to the (absolute value of the) difference in frequency between the two lasers. Now measuring a length-change corresponding to the size of a single water-molecule (200 pm) shouldn't be that hard anymore!

Let's say the stabilized laser has a wavelength of \lambda_1 = 632.8 \,\mathrm{nm} (red light). Its frequency will be \nu_1 = {c \over \lambda_1} = 474083438685209 \,\mathrm{Hz} (that's around 474 THz). When the tuneable laser is locked to the cavity we force its wavelength to agree with \lambda_2 = {2L\over m} where m is an integer and L is the length of the cavity. I've drawn only a small number of wavelengths in the figure, but a realistic integer is m=948167. We get \lambda_2 = 632.7999181579 \,\mathrm{nm} and \nu_2 = {c \over \lambda_2} = 474083500000000 \,\mathrm{Hz}, very nearly but not quite the same wavelength/frequency as the stabilized laser. Now our photodiode which measures the beat-note will measure a frequency of \nu_{beat} = | \nu_1-\nu_2 | = 61.314 \,\mathrm{ MHz}.

How does this change when the ULE glass expands by 200 pm? When we heat or cool the cavity by 1 degree C the length changes to 300 mm + 200 pm, and the wavelength of the tuneable laser will change to
\lambda_3 = 632.7999185797\,\mathrm{nm}. Now our beat-note detector will show \nu_{beat} = | \nu_1-\nu_3 | = 60.998 \,\mathrm{ MHz}. That's a change in the beat-note of more than 300 kHz - easily measurable!

That's how you measure a length-change corresponding to the diameter of a water molecule!

Why do this? Some of the best ultra-stable lasers known are made by locking the laser to this kind of ULE-resonator. Narrow linewidth ultra-stable lasers are interesting for a host of atomic physics and other fundamental physics experiments.

See also: Janis Alnis playing with two ultra-stable lasers.

Update 2013 August: I made a drawing in inkscape of the experimental setup.

cte_setup_drawing

This figure shows most (if not all?) of the important components of this experiment. The AOM is not strictly required but I found it useful to shift the tuneable HeNe laser by +80 MHz to reach a TEM-00 mode of the ULE resonator. Not shown is a resonance-circuit (LC-tank) between the 2.24MHz sinewave-generator and the EOM. The EOM was temperature controlled by a TEC with an NTC thermistor giving temperature feedback.