[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