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

[Andrew Rodland]

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.