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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> <[email protected]> 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 -- [email protected] >>> To unsubscribe, go to >>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >> _______________________________________________ >> time-nuts mailing list -- [email protected] >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
