From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by huchra.bufferbloat.net (Postfix) with ESMTP id E7C0D20069D for ; Wed, 14 Mar 2012 12:47:41 -0700 (PDT) Received: from [192.168.83.5] (c-76-97-152-51.hsd1.ga.comcast.net [76.97.152.51]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MgKcw-1RwGdR1j6s-00NKzd; Wed, 14 Mar 2012 15:47:40 -0400 Message-ID: <4F60F5A6.3090009@c3energy.com> Date: Wed, 14 Mar 2012 15:46:46 -0400 From: "Ron Frazier (NTP)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 CC: thumbgps-devel@lists.bufferbloat.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:pRRVYRTn1DFRxrfxF4Tq+vKazo6J9pa0lpCn6CNUEX3 xv7+lV63Gh9eNKMYL4JBYiqfAtJgVwaF5Ddig8dejEKp0ibsFq 0nQW+rq19rDEYksHMUuDsPQ61Wyt7Msqqo7SK3d0cq8V439Py1 B69HwkMveNYACVtOf5cPCh7vyBOKOg5taNxBJ673LLwlf22Scq mputrk8jahYnBkJ+m/RH4dnOsA6bkzPvbOGBMEh5mK3fEaHyCJ MrzaKHTm9saE0y4OGLS43RaMeFJzHubz3iE+DMXXNC530oy78U y+6pTHIVWm+oWSQUphlLfPgy79e+fl06GfVrj9C1SWWeOsaBtR fjLZfVpMujHzvTk3Av8Sq/fhN+ZFvX3Rst+u7J0Rx Subject: Re: [Thumbgps-devel] Raspberry PI on Piday; better yet, generate our own system tick with a PPS synced PLL X-BeenThere: thumbgps-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 19:47:42 -0000 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