Re: [9fans] "gpio device" for Plan 9

[Shane Morris <edgecomberts@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3106 bytes --]

So, in effect, a 1PPS signal would be sufficient to clock second to second?
I suppose it could be, there would be little drift in the oscillator per
the second.

As for NTP, this has been suggested to me, and I acknowledge its place,
certainly. However, I do not wish to tie up network resources in terms of
clocking, and GPS provides me with an independent reference - Navsync
CW12-TIMs can be had for $89, and do not tie up network resources. You
could then say "Ah, but you said a 1PPS is fine... now you're saying 1PPS
via the network isn't?" That is due to a mesh topology being used in the
eventual network, and the bandwidth, latency and propagation issues
inherent in such a network. I wish to dedicate the network wholly and
solely to requisite control data traffic, not superfluous traffic like
clocking, which may not get there in time. Certainly, mine is a complex
undertaking, but one I think can work.


On Wed, Jan 1, 2014 at 9:03 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > Of things interrelated, I wish to sample a 10kHz square wave into a GPIO,
> > which I am certain the RPi will do, see my earlier post with link to RPi
> > forums. This will be a constant signal (an output of a GPSDO, with
> > potentially a rubidium oscillator backup). So while the 10kHz is
> constant,
> > the users input is not, and I wish to correlate in time the users input
> to
> > the rising edge of the 10kHz signal, as it is then to be sent over a
> > network with the time data of the event.
> [...]
> >
> > I could be wildly off here Erik in my way of thinking, but my motivation
> is
> > to extend the syncfs module to correlate precisely in time. The example
> > system used by the Indiana University had no synchronisation across the
> > network - presumably the only synchronised filesystem was the local
> > filesystem on the cart robot? I will also be writing some kind of memory
> > bounding for the ramfs. So, the events themselves are asynchronous and
> > non-deterministic, however the clock source against which the events are
> > placed in time is deterministic, and allows for easy reference and
> auditing.
> >
> > Perhaps there is a better way of doing this, I am not sure. Remember, I
> am
> > an outsider to Plan 9 ways of thinking, although I am mostly unspoiled by
> > Linux ways of thinking. To be precise, my ways of thinking are MSDOS, if
> > that is at all possible in this day and age. I accept any and all better
> > suggestions.
>
> it seems that the system timer is already 1mhz.  but i suppose the issue is
> that there is no external reference.  do you think you could get .1 ppm
> time resolution with ntp between raspberry pis?  if not, i don't think i
> know
> enough about your setup to say much of use other than to note frequency
> is not directly related to precision.  if local timing can is stable to
> .1ppm for
> a longish period of time, then a low-frequency strobe of high precision and
> known timing could be enough.  the bbc does this with the tone at the top
> of the hr.
>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 3653 bytes --]