[time-nuts] GPS for ntp

Iain Young iain at g7iii.net
Tue Oct 21 15:06:37 UTC 2014


Hi Simon,

Ah, slightly different question :)

  I'm afraid I didn't write the code, so I can't really answer that
question. What I can say is that it does  appear to be as good as Ian
(Lepore's) ntpq output shows.

To be honest, I just use the code :)


Iain
On 21/10/14 15:39, Simon Marsh wrote:
> Sorry, I wasn't clear.
>
> The /dev/pps0 devices output a timestamp corresponding to when the event
> happened.
>
> The GPIO driver does this very simply by waiting for an interrupt event
> and then asking what (current) time it is. This leads to the problem
> that there is a non-deterministic time between the event and when the
> code gets to ask 'what time is it ?'
>
> With HW capture, you can get an accurate view of when the event took
> place but only relative to the counter in the particular timer/capture
> unit that is being used. You have to synchronise between the counter
> value and what the OS understands is 'system time' in order to create a
> retrospective timestamp for when the event occured. Whilst you've solved
> the problem with the interrupt approach, you've created a different one
> of needing to synchronise counters.
>
> My question is how do you convert between the timer value and system
> time to get the timestamp ?
>
> Cheers
>
>
> Simon
>
>
> On 21/10/2014 15:14, Iain Young wrote:
>> It just turns up as /dev/pps0 like any other PPS source, so you
>> configure ntp in the same way you would for any other PPS source,
>> or build ppsapitest to test it manually
>>
>> (Although be aware you -may get a Invalid argument error from
>> ppsapitest after running it more than once. Reboot solves it,
>> and since the BBB's don't do anything else, and I don't restart ntp
>> too often, its not a big deal for me.)
>>
>>
>> Iain
>> On 21/10/14 14:58, Simon Marsh wrote:
>>> Iain,
>>>
>>> How do you map the timer counter value in to a PPS timestamp ?
>>> (that is, how do you turn the HW counter value in to what the OS thought
>>> the time was when the event occured ?)
>>>
>>> Cheers
>>>
>>>
>>> Simon
>>>
>>>
>>> On 21/10/2014 13:54, Iain Young wrote:
>>>> It's been done on FreeBSD. See:
>>>>
>>>> http://lists.freebsd.org/pipermail/freebsd-arm/2013-February/004769.html
>>>>
>>>>
>>>>
>>>> Patch is now in recent FreeBSD releases/snapshots
>>>>
>>>> And yes, it's far superior to than using the GPIOs, or UARTS
>>>>
>>>> There was some work done on Linux, but I'm not sure it was ever
>>>> finished
>>>> or published.
>>>>
>>>> All of my "Timing" Beaglebones run FreeBSD, with the exception of the
>>>> TIC stufff I wrote for the PRUSS's. As soon as the userspace bits of
>>>> that work on FreeBSD, I'll probably switch that to FreeBSD as well.
>>>>
>>>>
>>>> All the Best
>>>>
>>>> Iain
>>>>
>>>> On 21/10/14 13:33, Neil Schroeder wrote:
>>>>> Andrew-
>>>>> I'm actually referring to using either the eCAP function or one of the
>>>>> integrated dmtimer triggers - which are, from some accounts, more
>>>>> accurate
>>>>> than a gpio.
>>>>>
>>>>> Google beaglebone dmtimer pps.
>>>>>
>>>>> NS
>>>>>
>>>>> On Mon, Oct 20, 2014 at 11:56 PM, Andrew Rodland
>>>>> <andrew at cleverdomain.org>
>>>>> wrote:
>>>>>
>>>>>> On Mon, Oct 20, 2014 at 10:50 PM, Neil Schroeder <gigneil at gmail.com>
>>>>>> wrote:
>>>>>>> The one thing that hasn't yet happened is making the beaglebone
>>>>>>> timestamp
>>>>>>> on the linux side in a way that works for ntp.
>>>>>>>
>>>>>>> Custom code no problem. Freebsd PPSAPI no problem. Linux, nothing
>>>>>>> there
>>>>>>> yet.
>>>>>>>
>>>>>>> I have been working on it but if anyone has some insight its
>>>>>>> appreciated.
>>>>>>>
>>>>>>
>>>>>> It appears to support gpio class devices, with interrupts, so the
>>>>>> pps-gpio driver (in-tree since 3.2) should work just fine. The only
>>>>>> thing that's needed (other than building the driver) is a bit of code
>>>>>> in the board support file to register the device. Various folks have
>>>>>> done it for the rpi (http://ntpi.openchaos.org/pps_pi/ for example),
>>>>>> and I've done it for the UDOO Dual
>>>>>> (https://gist.github.com/arodland/518f037e4f24b1984286). The BBB is
>>>>>> probably about as easy.
>>>>>>
>>>>>> I'm not sure if there's other hardware that lets you do better than
>>>>>> grabbing an interrupt, but that will get you in the microsecond range
>>>>>> or a bit better, anyhow.
>>>>>> _______________________________________________
>>>>>> time-nuts mailing list -- time-nuts at febo.com
>>>>>> To unsubscribe, go to
>>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>>>> and follow the instructions there.
>>>>>>
>>>>> _______________________________________________
>>>>> time-nuts mailing list -- time-nuts at febo.com
>>>>> To unsubscribe, go to
>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>>> and follow the instructions there.
>>>>>
>>>>
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts at febo.com
>>>> To unsubscribe, go to
>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>> and follow the instructions there.
>>>
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts at febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.




More information about the Time-nuts_lists.febo.com mailing list