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

Bill Dailey docdailey at gmail.com
Wed Sep 10 23:06:52 EDT 2014

Cool. I have an udoo quad but am using it as a small mysql server for a medical project that is ongoing.  I could just try another sd card.  My biggest problem is time.  I have about 5 simultaneous official work project, a new company that I am coding on an embedded jetson tk1 (computer vision) and a huge all digital phased array project that is on the back burner until we move (nov1) and get settled.  Crazy life here.  

Keep up the good work... I will let you know when I catch up.

Sent from mobile

> On Sep 10, 2014, at 7:48 PM, Andrew Rodland <andrew at cleverdomain.org> wrote:
> Bill,
> 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
> udoo.
> 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.
> Andrew
>> 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.
> _______________________________________________
> 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