Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic
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 docdai...@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 and...@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 docdai...@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 and...@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
Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic
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. Bill Sent from mobile On Sep 10, 2014, at 7:48 PM, Andrew Rodland and...@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 docdai...@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 and...@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 docdai...@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 and...@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:
Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic
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 and...@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 docdai...@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 and...@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 docdai...@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 and...@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
Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic
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 docdai...@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 and...@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 and...@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
Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic
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 and...@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 docdai...@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 and...@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 and...@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,
Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic
On Fri, Sep 5, 2014 at 3:07 PM, Andrew Rodland and...@cleverdomain.org wrote: 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. Update on this: well, it works just fine, and I have a usable driver in my code that integrates the digital correction and pushes it to 0 by adjusting a DAC connected to the X72's EFC. But, reading the X72 manual a little closer it mentions that the analog EFC is sampled and has a resolution that happens to be identical to the resolution available using the digital commands. So, most likely, this is no C-field adjust at all, but another way of controlling the DDS, provided for LPRO compatibility and analog designs. So there's no possible gain for me in doing indirectly what I can do directly more easily. Andrew ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic
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 and...@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
Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic
Andrew, My only comment, since I’m working on something very similar myself (just a GPS frequency standard that will be able to have the OCXO shut off, and just output 1PPS for an NTP system), would be to not output any signal/pps/ntp timing unless you have a solid GPS lock, since before that, I would assume your PLL loop is sweeping. But I’m sure that’s already in your code… just didn’t look through it all. =) Cool idea though. I’ve found very few (none) instances of people actually running NTP servers from arduino hardware… most use Raspi or the like. Thanks! -Ryan Stasel On Sep 5, 2014, at 12:07 , Andrew Rodland and...@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 and...@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
Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic
On Fri, Sep 5, 2014 at 2:28 PM, Ryan Stasel rsta...@uoregon.edu wrote: Cool idea though. I’ve found very few (none) instances of people actually running NTP servers from arduino hardware… most use Raspi or the like. Note the Arduino Due has an ARM based CPU inside. It's not jet the old AVR chip. It is more than enough for NTP. Arduino is now a WIDE range of products all the way for from this is the tiny $3 Chinese versions. -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic
On Sep 5, 2014, at 17:34 , Chris Albertson albertson.ch...@gmail.com wrote: On Fri, Sep 5, 2014 at 2:28 PM, Ryan Stasel rsta...@uoregon.edu wrote: Cool idea though. I’ve found very few (none) instances of people actually running NTP servers from arduino hardware… most use Raspi or the like. Note the Arduino Due has an ARM based CPU inside. It's not jet the old AVR chip. It is more than enough for NTP. Arduino is now a WIDE range of products all the way for from this is the tiny $3 Chinese versions Oh sure, I know. Still hadn’t seen any NTP servers on the Arduino platform in general… clients yes, but no servers. So anyway, very cool. =) Thanks! ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic
Well, my *previous* clock was on the Mega 2560 (an AVR chip, although admittedly one with more code space and IO than usual). I made some mention of it back in 2012. It had 500ns timer granularity and no Rb (just DPLL of a timer running off of the onboard crystal) but it still managed well enough :) On Fri, Sep 5, 2014 at 8:34 PM, Chris Albertson albertson.ch...@gmail.com wrote: On Fri, Sep 5, 2014 at 2:28 PM, Ryan Stasel rsta...@uoregon.edu wrote: Cool idea though. I've found very few (none) instances of people actually running NTP servers from arduino hardware... most use Raspi or the like. Note the Arduino Due has an ARM based CPU inside. It's not jet the old AVR chip. It is more than enough for NTP. Arduino is now a WIDE range of products all the way for from this is the tiny $3 Chinese versions. -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic
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 and...@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 and...@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
[time-nuts] Update on my Arduino GPSDO / NTP server - going atomic
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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
