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

Bill Dailey docdailey at gmail.com
Sat Sep 6 16:06:50 UTC 2014


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.



More information about the Time-nuts_lists.febo.com mailing list