From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <34994d01ee44c5a5102bcea63e1e7e46@mikro> References: <35A33F66-EF03-4659-ABA1-F25082DBFE41@gmail.com> <4657D0DD-A119-4E19-B50D-EBCE5861F9F8@gmail.com> <821cb256954ce0bf4ad389ffe5eafa50@mikro> <34994d01ee44c5a5102bcea63e1e7e46@mikro> Date: Wed, 1 Jan 2014 09:17:04 +1100 Message-ID: From: Shane Morris To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=f46d041826f69313d804eedbebc4 Subject: Re: [9fans] "gpio device" for Plan 9 Topicbox-Message-UUID: aa50e138-ead8-11e9-9d60-3106f5b1d025 --f46d041826f69313d804eedbebc4 Content-Type: text/plain; charset=ISO-8859-1 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 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 > > --f46d041826f69313d804eedbebc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 su= ggested to me, and I acknowledge its place, certainly. However, I do not wi= sh to tie up network resources in terms of clocking, and GPS provides me wi= th 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 1= PPS 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 wis= h to dedicate the network wholly and solely to requisite control data traff= ic, 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 interrelate= d, 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 R= Pi
> forums. This will be a constant signal (an output of a GPSDO, with
> potentially a rubidium oscillator backup). So while the 10kHz is const= ant,
> the users input is not, and I wish to correlate in time the users inpu= t 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 motivati= on is
> to extend the syncfs module to correlate precisely in time. The exampl= e
> system used by the Indiana University had no synchronisation across th= e
> network - presumably the only synchronised filesystem was the local > filesystem on the cart robot? I will also be writing some kind of memo= ry
> bounding for the ramfs. So, the events themselves are asynchronous and=
> non-deterministic, however the clock source against which the events a= re
> placed in time is deterministic, and allows for easy reference and aud= iting.
>
> 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 bett= er
> suggestions.

it seems that the system timer is already 1mhz. =A0but i suppose the = issue is
that there is no external reference. =A0do you think you could get .1 ppm time resolution with ntp between raspberry pis? =A0if not, i don't thin= k i know
enough about your setup to say much of use other than to note frequency
is not directly related to precision. =A0if 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. =A0the bbc does this with the tone at the top=
of the hr.

- erik


--f46d041826f69313d804eedbebc4--