[Thumbgps-devel] Raspberry PI on Piday; better yet, generate our own system tick with a PPS synced PLL
Ron Frazier (NTP)
timekeepingntplist at c3energy.com
Wed Mar 14 12:46:46 PDT 2012
These links also look potentially interesting.
On 3/14/2012 1:59 PM, tz wrote:
> 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
> 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
> This could be a fairly simple circuit (worries about noise, drift...),
> or there's a chip...
(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.)
timekeepingdude AT c3energy.com
More information about the Thumbgps-devel