I apologize. I didn't mean for that last post to go through the list. Sent from my iPad
> On Sep 10, 2014, at 7:48 PM, Andrew Rodland <[email protected]> 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 <[email protected]> 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 <[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. > _______________________________________________ > 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.
