[Thumbgps-devel] Raspberry PI on Piday; better yet, generate our own system tick with a PPS synced PLL

[Thumbgps-devel] Raspberry PI on Piday; better yet, generate our own system tick with a PPS synced PLL

[tz]

http://elinux.org/Rpi_Low-level_peripherals

http://www.raspberrypi.org/

Probably the cheapest linux embedded device, though it is a full GUI -
hook up your HDMI TV, a keyboard and mouse..0.  It doesn't have an
onboard real-time clock, but if the GPS has battery backup it might be
more than enough.  (I would swap the supercap for 3v in AA or larger
batteries for the Sparkfun SkyTraq module).

The ethernet port is USB based and has a USB connector, but also has a
console port and GPIOs which can generate interrupts.  It might be
possible to configure the other pins to provide a CTS interrupt input
but I don't see one based on the initial datasheet v.s. pins.

I don't think it does Power-over-ethernet, but if it did it could
become a box you could put outside.

A few thoughts:  1. It wouldn't route as such so we could throw away
lots of the Linux housekeeping daemons to reduce jitter.  2. It could
become a fairly precise NTP server if we pushed the software, e.g.
grabbing time in the kernel interrupt.  3. It might be a hybrid of my
"pingbot" model - if it is only responding to time requests it could
do so efficiently, both NTP and proprietary bufferbloat UDP/IGMP
packets.

There appears to be no direct way to have the timer tick (or other
output compare) interrupt from the system clock set a GPIO pin.  If it
could, then a simple microcontroller could measure the error between
the tick and the PPS edge and provide direct feedback with ZERO jitter
error.  There might be internal kernel latencies to use the info, but
we could put the tick interrupt right at the PPS edge if we could see
it.  A second-best woudl be if the tick interrupt is highest priority
and interrupts other interrupts so would have a very low latency so it
could toggle the GPIO pin.  It would be easy to see it working (or
not) on an oscilloscope.

One of the Atmel chips with USB has two input captures  (one of
sparkfun's new Pro arduinos, but Aargh, it only has one input capture
going out to a connection).

One hardware hiccup when we get very precise - both the existing
system timer tick and the PPS are both interrupts, so unless there is
a dual core, one will block the other.

Better yet, we can move the system tick itself off to a GPIO pin
causing an interrupt, and use a PLL frequency multiplier that syncs
exactly to 100x (or 1000x) the PPS.  The PPS could be a second
interrupt if there was no other easy way to indicate the UTC boundary
from the other pulses.  The GPIO interrupt can sample the internal
clock and do what it needs for the sub-tick timing.  I don't know
which other peripherals, but maybe they could read the sub-tick or
even the "time of day in microseconds" from our system over I2C or
SPI.

This could be a fairly simple circuit (worries about noise, drift...),
or there's a chip...

http://www.analog.com/en/clock-and-timing/clock-generation-and-distribution/ad9548/products/product.html?ref=ASC-PR-142
http://www.analog.com/static/imported-files/application_notes/AN-1002.pdf

Re: [Thumbgps-devel] Raspberry PI on Piday; better yet, generate our own system tick with a PPS synced PLL

[Patrick Maupin]

On Wed, Mar 14, 2012 at 12:59 PM, tz <thomas@mich.com> wrote:

> The ethernet port is USB based and has a USB connector,

Hm, yet more latencies to characterize.  If one of the USB ports is
OTG, maybe we could just use a Linux gadget device interface and have
this connect to the router through USB?

> Better yet, we can move the system tick itself off to a GPIO pin
> causing an interrupt, and use a PLL frequency multiplier that syncs
> exactly to 100x (or 1000x) the PPS.  The PPS could be a second
> interrupt if there was no other easy way to indicate the UTC boundary
> from the other pulses.  The GPIO interrupt can sample the internal
> clock and do what it needs for the sub-tick timing.  I don't know
> which other peripherals, but maybe they could read the sub-tick or
> even the "time of day in microseconds" from our system over I2C or
> SPI.
>
> This could be a fairly simple circuit (worries about noise, drift...),
> or there's a chip...

Yes, there are lots of chips available for this sort of thing.
Probably don't need anything too fancy.

Re: [Thumbgps-devel] Raspberry PI on Piday; better yet, generate our own system tick with a PPS synced PLL

[Ron Frazier (NTP)]

These links also look potentially interesting.

http://www.fxitech.com/products/
http://blog.laptopmag.com/usb-stick-contains-dual-core-computer-turns-any-screen-into-an-android-station
http://beagleboard.org/

Sincerely,

Ron

On 3/14/2012 1:59 PM, tz wrote:
> http://elinux.org/Rpi_Low-level_peripherals
>
> http://www.raspberrypi.org/
>
> Probably the cheapest linux embedded device, though it is a full GUI -
> hook up your HDMI TV, a keyboard and mouse..0.  It doesn't have an
> onboard real-time clock, but if the GPS has battery backup it might be
> more than enough.  (I would swap the supercap for 3v in AA or larger
> batteries for the Sparkfun SkyTraq module).
>
> The ethernet port is USB based and has a USB connector, but also has a
> console port and GPIOs which can generate interrupts.  It might be
> possible to configure the other pins to provide a CTS interrupt input
> but I don't see one based on the initial datasheet v.s. pins.
>
> I don't think it does Power-over-ethernet, but if it did it could
> become a box you could put outside.
>
> A few thoughts:  1. It wouldn't route as such so we could throw away
> lots of the Linux housekeeping daemons to reduce jitter.  2. It could
> become a fairly precise NTP server if we pushed the software, e.g.
> grabbing time in the kernel interrupt.  3. It might be a hybrid of my
> "pingbot" model - if it is only responding to time requests it could
> do so efficiently, both NTP and proprietary bufferbloat UDP/IGMP
> packets.
>
> There appears to be no direct way to have the timer tick (or other
> output compare) interrupt from the system clock set a GPIO pin.  If it
> could, then a simple microcontroller could measure the error between
> the tick and the PPS edge and provide direct feedback with ZERO jitter
> error.  There might be internal kernel latencies to use the info, but
> we could put the tick interrupt right at the PPS edge if we could see
> it.  A second-best woudl be if the tick interrupt is highest priority
> and interrupts other interrupts so would have a very low latency so it
> could toggle the GPIO pin.  It would be easy to see it working (or
> not) on an oscilloscope.
>
> One of the Atmel chips with USB has two input captures  (one of
> sparkfun's new Pro arduinos, but Aargh, it only has one input capture
> going out to a connection).
>
> One hardware hiccup when we get very precise - both the existing
> system timer tick and the PPS are both interrupts, so unless there is
> a dual core, one will block the other.
>
> Better yet, we can move the system tick itself off to a GPIO pin
> causing an interrupt, and use a PLL frequency multiplier that syncs
> exactly to 100x (or 1000x) the PPS.  The PPS could be a second
> interrupt if there was no other easy way to indicate the UTC boundary
> from the other pulses.  The GPIO interrupt can sample the internal
> clock and do what it needs for the sub-tick timing.  I don't know
> which other peripherals, but maybe they could read the sub-tick or
> even the "time of day in microseconds" from our system over I2C or
> SPI.
>
> This could be a fairly simple circuit (worries about noise, drift...),
> or there's a chip...
>
> http://www.analog.com/en/clock-and-timing/clock-generation-and-distribution/ad9548/products/product.html?ref=ASC-PR-142
> http://www.analog.com/static/imported-files/application_notes/AN-1002.pdf
>    


-- 

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com