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

Andrew Rodland andrew at cleverdomain.org
Wed Sep 10 20:48:18 EDT 2014


Since I accidentally let the smoke out of my Due, and I just *happen*
to have an UDOO Dual sitting around, I decided to play with it while I
wait for a replacement board to come around.

UDOO ships an ARM version of Arduino IDE 1.5.4, which is a little bit
too old to compile my code properly (I built against 1.5.7), but
compiling the project on another machine with 1.5.7 and shipping the
.bin to the udoo to upload with bossac works just fine. I removed the
call to ether_init() since of course there's no W5100 Ethernet on the

On the i.MX side of the UDOO I have Debian installed (UDOObuntu would
work just fine, but it comes with loads and loads of unnecessary
crap). First I tested using http://vanheusden.com/time/rpi_gpio_ntp/
which is a user-space daemon that listens for events from a Linux
/sys/class/gpio device (Due pin 13 maps to Linux gpio40) and writes to
an SHM segment compatible with the ntpd/chrony SHM refclock. That
worked just fine, with about 5us jitter most of the time, but you
could see that it was occasionally quite a bit higher.

Then I worked on getting PPSAPI working. This requires rebuilding the
kernel, but turned out to be relatively easy: there's a "pps-gpio"
driver in Linux 3.2 that was easily backported to 3.0 just by applying
the patch from LKML, and then it was just a little bit of work to init
the device in the UDOO-specific board init function. My changes can be
found at https://github.com/arodland/Kernel_Unico/compare/ppsapi if
you're interested.

With that in place, and the Rb sufficiently warm (I think) I'm seeing
between 600ns and 1200ns RMS jitter on the PPS refclock as reported by
chrony on the UDOO (pretty good!) and between 3us and 7us RMS jitter
on the UDOO as measured over NTP from my desktop with 64-second
polling, which is 4 or 5 us better than what I could get with the
Due+W5100 combination. I bet at this point half of that figure is
coming from instability on the desktop machine itself and
nondeterministic ethernet switching delay.

I still like the appeal of the "bare metal" approach, and when I get
my new board (Taijiuino, a Due-alike board that routes the SAM3X's
Ethernet MAC pins) I'm going to keep going with that, but this is
pretty good performance for Linux, I'd say.


On Sat, Sep 6, 2014 at 12:06 PM, Bill Dailey <docdailey at gmail.com> wrote:
> Will add it to my list of projects.  Will touch bases when I get close.
> Sent from my iPad
>> On Sep 6, 2014, at 10:18 AM, Andrew Rodland <andrew at cleverdomain.org> wrote:
>> Yes, the source is at http://github.com/arodland/Due-GPS-NTP-Server .
>> It should be able to run just fine on the Due part of an Udoo, but
>> you'll have to come up with a different arrangement for the Ethernet.
>> One way would be to use chip-to-chip SPI to make the i.MX side of the
>> Udoo act more-or-less like the W5100, translating between serial and
>> Ethernet and interrupting the SAM3X when it gets packets.
>> Another way would be to run regular ntpd on Linux (or FreeBSD?) on the
>> i.MX side but give it a custom refclock driver that syncs to the Due
>> (either by locking onto the generated PPS, or by asking the Due to
>> timestamp events and reading the timecode back). If this works well,
>> it could outperform my setup, since the i.MX is clocked quite a bit
>> faster and has its Ethernet MAC on-chip :)
>> Andrew
>>> On Sat, Sep 6, 2014 at 12:08 AM, Bill Dailey <docdailey at gmail.com> wrote:
>>> I was wondering if a board like the udoo would help your ntp performance.  I have one and would be willing to try this configuration.  Have you posted your source?   I think I got confused as to who was doing this.  I don't have a rubidium but I have a 6T on a breakout and a couple of very good ocxo's (mid 10-13 at 1s) that I could use.  I have about 100 projects going on but a project like this has been on the back burner for awhile.  I have a couple of furies I could test it against also.
>>> Bill
>>> Sent from my iPad
>>>> On Sep 5, 2014, at 2:07 PM, Andrew Rodland <andrew at cleverdomain.org> wrote:
>>>> 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
>>>> WORKS!
>>>> 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
>>>> enough.
>>>> 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
>>>> ticks.
>>>> 3. Anything else I should consider?
>>>> If anyone is curious, code is at
>>>> https://github.com/arodland/Due-GPS-NTP-Server .
>>>> Thanks for following,
>>>> Andrew
>>>> 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. :)
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts at febo.com
>>>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>> and follow the instructions there.
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts at febo.com
>>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

More information about the time-nuts mailing list