LKM Timemark Driver

[MLewis]

Gary,

On 27/08/2018 6:38 PM, Gary E. Miller via devel wrote:
> Yo MLewis!
>
> On Mon, 27 Aug 2018 18:24:01 -0400
> MLewis via devel <devel at ntpsec.org> wrote:
>
> The key thing I, and others, want from the Lukas patch is the
> PPS out when the kernel detects the PPS.  Without out, nothing much
> else matters.

The PPS becomes irrelevant.
The PPS has all of the interrupt lag. Why introduce all that variable error.

The thesis confirmed what I suspected, that the best results are from a 
kernel timestamp of the outgoing trigger that has the ublox generate its 
Timemark timestamp. Their difference is your offset.
The critical part is in the kernel, in order, GPIO high, then timestamp.
That's easy. It's all of the overhead for safe multi-port LKM.
Then hitting the target times reliably and with what precision is 
available.
And a stream of timestamps back to user space.

> What is your definition of "Timemark"?  I thought that was the
> time stamp from the u-blox on receipt of  the PPS out from linux?
The Timemark timestamp returned in the next TM2 if triggered in an M8, 
specifically M8T's EXTINT0 or EXTINT1.
>   From user space, various commands, including: open port, High, Low,
> Toggle, Pulse is Positive, Pulse is Negative, Pulse, Pulse at ms past
> TOS, Pulse every ms, and pulsing available specifying nanoseconds.
> Interesting.
 From user space people can send commands to the LKM and thereby grow 
their own trigger/pulse actions in user space by sending high, low, 
toggle, etc.. Or use the predefined Pulse At or Pulse Every.
>
>> Send commands from user space or load it with a param of
>> "OPN017Tm1;PPS017;OPN018Tm2;PPS018;PAT017.165.250;PAT018.165.580;"
>>
>> Open GPIO 17 as "Tm1"
>> GPIO 17 use positive pulses
>> Open GPIO 18 as "Tm2"
> What is "Tm1" and "Tm2"?
Arbitrary names/labels give to an open output GPIO port. Allocation 
devm_gpio_request(gpio, label) wants a label.
Since I'll be using my ports for timemarks, I'm using Tm1 and Tm2 for 
the timemarks generated by EXTINT0 and EXTINT1.
>
>> GPIO 18 use positive pulses
>> PAT017.165.250 will pulse GPIO 17 at 250 ms from tos, width 165 ms
>> PAT018.165.580 will pulse GPIO 18 at 580 ms from tos, width 165 ms
> Which 'tos'?
System time, specifically clock_gettime(CLOCK_REALTIME, &tv_current);
This aligns the times timemarks are triggered with system time.

If a PPS feature was added, the GPS PPS could trigger the next "timemark 
cycle", and the timemark trigger times could be aligned with GPS UTC. No 
real benefit.

As I'm implemented it, as system time is disciplined, then the repeating 
pulse cycles will align with the disciplined system time, as the timing 
runs (msleep, usleep, udelay, spins) until the next target time (the 
time for the next pulse rise or fall) is recognized, comparing against 
timespec tv_current.
>
>> Then something in user space to receive the TM2 messages and the
>> LKM's timestamps and match up the Timemarks with the triggering
>> timestamps.
> How does a daemon get the LKM timestamp?  In the base case, as
> Lukas had it setup, no need for such a thing.
But that gave not so good results.

I had it as a char LKM, but I like a stream better, so the repeating 
pulses work as a fire and forget. Working out the best way to do that.
> I already have a private UBX-TIM-TM2 decoder.  Something I hope to
> release soon.  Adding a TM2 decoder to gpsd, and using it to adjust the
> KPPS would not be too hard.
>
> Right now gpsd sends a SHM() message with the KPPS timestamp as soon as
> it gets it.  gpsd would have to delay, hoping to get a TM2, then
> send the timestamp deleayd.
>
> RGDS
> GARY
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> 	gem at rellim.com  Tel:+1 541 382 8588
>
> 	    Veritas liberabit vos. -- Quid est veritas?
>      "If you can�t measure it, you can�t improve it." - Lord Kelvin
>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel