[time-nuts] Update on my Arduino GPSDO / NTP server - going atomic

Andrew Rodland andrew at cleverdomain.org
Fri Sep 5 15:07:48 EDT 2014

After some productive work, and some frustrating weeks spent fighting
weird flakiness and needlessly replacing components, only to find that
the problems went away after I reseated my main power connector, IT

Here's where I am now:

* Main board: Arduino Due (ATSAM3X ARM Cortex-M3 CPU @ 84MHz)
* Oscillator: Symmetricom X72.
* GPS: Trimble Resolution T with a cheap Gilsson puck antenna.
* Ethernet: Wiznet W5100.

The X72 is used to externally clock one of the ARM's hardware
timer/counters at 10MHz (I'm not multiplying it up and using it to
clock the CPU). The same timer timestamps the rising edge of the PPS
using capture mode, jitter free @ 100ns resolution.

All the PLL is done digitally using these values and the adjustment is
sent to the X72 over serial (DDS, 2 ppt resolution).

After about a day's solid running, the PPS phase stays within +/-
100ns as measured on the board itself, even out to a PLL tau of 1
hour, and the frequency adjust stays within <1 ppt when 5-minute
averaged. I'm collecting data against an outside reference now (PPS
generated by the board against the PPS of a Spectracom NetClock with
OCXO option). Too early for graphs, but it looks good.

On the Ethernet end, things are less good, but still respectable --
about 10us RMS added jitter. I think a lot of this is introduced by
the W5100, and I'm working on getting my hands on a board that uses
the same chip but actually makes use of the onchip Ethernet MAC that
the Arduino doesn't bother to route, which should help substantially.
Already it's better than conventional wisdom says NTP gets :)

Questions I still have:

1. Should I try using the analog EFC to zero out the amount of
correction I ask the X72's DDS for? Could reduce jitter in the
timebase, could just add noise. I suppose I can test this one easily

2. Is there any point in decoding the sawtooth correction from the
GPS, or in wiring up the PICTIC and using it to measure the GPS offset
more accurately, when my clock granularity is 100ns anyway? I suppose
at best I'd be improving my accuracy from +/- 1.5 ticks to +/- 0.5

3. Anything else I should consider?

If anyone is curious, code is at
https://github.com/arodland/Due-GPS-NTP-Server .

Thanks for following,


On Tue, Jul 29, 2014 at 12:42 AM, Andrew Rodland
<andrew at cleverdomain.org> wrote:
> Hi all,
> After a couple years not doing anything except letting it sit in my
> den and provide time for my home network, I've decided to start
> hacking on my hobby project again.
> For reference, what I've got right now is a Freetronics EtherMega
> (ATMega2560-based Arduino clone with integrated W5100 ethernet), wired
> up to a USGlobalSat ET-318-02 (a pretty cheap consumer SiRF-III
> module). It runs totally custom timekeeping, PLL, and NTP protocol
> code. The timebase is the onboard crystal, which I have no way of
> influencing directly, so it basically does DDS, adding or duplicating
> the occasional tick to keep lock. For such a ramshackle collection of
> equipment it does a pretty good job, tracking within around 10us of a
> Spectracom NetClock (and showing less Ethernet-induced jitter than the
> NetClock itself)
> I've been thinking for years about building a next-gen version, and
> sketched a few designs, but I could never quite find a board that I
> wanted to use as the core of it. Well, Freetronics sent me a product
> announcement for their EtherDue board (built around the ATSAM3X, which
> is an ARM Cortex-M3 chip from AVR), I read some specs, and decided to
> dive in.
> I've got a working, tuned-up LPRO-101, and I always figured that my
> next build would desolder the clock crystal and use the Rb as the CPU
> timebase, like most builds I've seen do. But I realized that the
> ATSAM3X is happy to run its timer/counters off of an external clock as
> long as it's less than 1:2.5 the CPU clock. 10MHz fits that bill. I
> lose a little bit on granularity by not letting the CPU multiply that
> up 8x for me, but probably no real change in accuracy. Just feed the
> Rb to a pair of pins and get a register that counts up every 100ns,
> seems simple!
> For locking to the PPS I could do the usual thing and use input
> capture on the timer clocked by the Rb, which would handily timestamp
> the rising edge of the PPS. But I have a couple of PICTIC IIs laying
> around, and I'm a bit tempted to instead use the timer to generate a
> PPS from my board and let the PICTICs compare. Since START has to come
> before STOP I figure I need two of them in parallel, only listen to
> the one that gives a report < 0.5 seconds, and which one gives me the
> sign. Does that make sense? Or should I just use one and lock to a
> nonzero offset? I've found surprisingly little material on the tricks
> of using a TIC in a digital GPSDO.
> Finally there's adjusting the Rb. It would be nice to be able to slew
> nice and gently by actually nudging the clock instead of
> adding/dropping them, especially if I have the PICTIC to give me
> precision offsets. I'm not sure whether the 12-bit DAC on the board
> stands any chance of being clean or accurate enough to drive the
> LPRO's C-field adjust, or whether I need something external, or
> whether I should just locate an Rb with digital adjustment (on a
> related note, has the price of surplus Rbs gone up a *lot* lately?
> Anyone know why? Can't be hobbyist demand, can it?)
> Got a lot of questions to answer, but I'm ready to start building and
> learning again. :)

More information about the time-nuts mailing list