Achim
On 20/08/2018 4:04 PM, Achim Gratz via devel wrote:
MLewis via devel writes:
Agreed. Except possible benefit with alignment, as described above.
You don't need any alignment either way (for NTP that is), just
reasonably equal-spaced pulses to correlate system w/ GPS time. It's
not even
MLewis via devel writes:
> Exactly! It's been on my todo list for a couple of years, but I wasn't
> motivated to get into a LKM to get to kernel space to make it
> worthwhile. Although I suspected that even from user space, the result
> would be better than some PPS.
Well, it sure avoids the inter
Achim,
On 20/08/2018 1:35 PM, Achim Gratz via devel wrote:
.. Unless I'm missing something, your implementation would do
something I proposed a few weeks ago, namely skip dealing with PPS in
altogether and correlate kernel and GPS time via timestamping on the GPS.
Exactly! It's been on my todo
Udo van den Heuvel via devel writes:
> What else could we do with the timemark functionality?
> See what is suggested at
> https://lists.ntpsec.org/pipermail/devel/2018-August/006447.html ?
Well, actually this suggestion was highly rasPi specific: The hardware
PWM is clocked directly off the cryst
MLewis via devel writes:
> I believe it should be a driver as a Loadable Kernel Module.
Yup.
> I'm working on one now. Selectable triggers of Timemark 1, rising and
> falling, and Timemark 2, rising and falling, providing up to four
> timestamps for calculating four offsets, observing noise, etc.
Udo van den Heuvel via devel writes:
> I'd see a setup with a USB connection for the data part of the setup.
> PPS goes to LPT (ack pin).
> LPT strobe could be used to send pulse to the ublox(*1).
Yup.
> At the ntpd level I could use the pps driver for pps reception, this
> should work with LPT p
Udo van den Heuvel via devel writes:
> On 19-08-18 18:22, Achim Gratz via devel wrote:
>> The trouble with GPIO is that it's either only
>> available on a few boards that aren't very widespread and PCI(-e) cards
>> (aside from the LTP cards)
>
> So LPT cards would be acceptable, usable?
> If so: ar
Repeat. Didn't go out in text format.
On 20/08/2018 10:22 AM, MLewis via devel wrote:
Udo,
On 20/08/2018 9:43 AM, Udo van den Heuvel wrote:
Michael,
What else could we do with the timemark functionality?
See what is suggested at
https://lists.ntpsec.org/pipermail/devel/2018-August/006447.html
Repeat. Didn't go out in text format.
On 20/08/2018 9:35 AM, MLewis via devel wrote:
I believe that a kernal patch is not the correct way to do that. It's
too specific as it's only for some ublox modules.�
I believe it should be a driver as a Loadable Kernel Module.
This also allows people to
Udo,
On 20/08/2018 9:43 AM, Udo van den
Heuvel wrote:
Michael,
What else could we do with the timemark functionality?
See what is suggested at
https://lists.ntpsec.org/pipermail/devel/2018-August/006447.html ?
With k
Michael,
On 20-08-18 15:35, MLewis via devel wrote:
I believe that a kernal patch is not the correct way to do that. It's
too specific as it's only for some ublox modules.�
Weirder hardware has a driver in the kernel.. :-)
But I see no problem in the Loadable Kernel Module approach:
I'm wor
I believe that a kernal patch is not the correct way to do that.
It's too specific as it's only for some ublox modules.�
I believe it should be a driver as a Loadable Kernel Module.
This also allows people to easily modify the source to their own
needs, without needin
On 20-08-18 04:33, Udo van den Heuvel via devel wrote:
On 19-08-18 18:22, Achim Gratz via devel wrote:
The trouble with GPIO is that it's either only
available on a few boards that aren't very widespread and PCI(-e) cards
(aside from the LTP cards)
So LPT cards would be acceptable, usable?
I
13 matches
Mail list logo
