December 2013 – anderswallin.net

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!

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

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:

I have been testing this AD9912 DDS evaluation board:

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

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:

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

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.

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.

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.

Optics adapter plate

Mechanical design for an optics assembly:

I made an adapter plate between the XYZ translation stage and the 2"/1" lens-rings. The XYZ stage has a 50 mm x 50 mm M6 thread pattern, and the optics are mounted on a straight line with M4 screws through the adapter plate. M6 countersink is 12mm diameter 7mm deep, while the M4 countersink is 8mm diameter and 5mm deep.

In real life this looks almost like the CAD model: