[LinuxPPS] ktimer works with the PL-2303 USB to serial converter, but the ppsldisc utility doesn't

[Cirilo Bernardo]

On Sun, Nov 23, 2008 at 11:24 AM, Ron Wright <logiconcepts819 at gmail.com> wrote:
> Hi there,
>
> I was testing out LinuxPPS with the Prolific PL-2303 USB to serial converter
> using a patched version of Linux Kernel 2.6.27 under Ubuntu 8.10 Intrepid,
> and I loaded the ktimer module.  The time stamp showed up in the assert file
> under /sys/class/pps/pps0 without any problem.  However, I tried the
> ppsldisc utility, but all I see in both the assert and clear files in the
> pps0 directory was "0.000000000#0":
>

The "ktimer" is for testing the PPS module; it uses kernel timers,
*not* any external peripheral interrupts.  So loading the ktimer
module only demonstrates that the PPS module is working (and that the
kernel has a working interrupt timer).

>
> By the way, the computer is a fit-PC Slim; it has a built-in serial port,
> but it only uses the TX, RX, and GND lines.  The PL-2303 converter that I am
> using instead uses at least the DCD, TX, RX, and GND lines that I need to
> use, since the PPS signal is on the DCD line.  The GPS that I am using is a
> Garmin GPS-18-LVC.  PPS itself is enabled and working, since I made a device
> for the GPS comprising of one of two LEDs that confirms that the PPS signal
> works.
>
Does your USB gadget genuinely support the extra lines?  Some don't
and in fact only provide Tx, Rx, GND.

Now, assuming you *do* have a decent USB-serial converter, the trick
is to find out how to associate changes in DCD with a timestamp.  I
can't see how it is possible to do this in the same way that it has
been implemented for onboard UARTs.  An interrupt will be generated
and the USB subsytem will respond to it; if you're also using a USB
headset then numerous unrelated interrupts may be generated.  Somehow
the kernel has to be hacked to make a timestamp when the routine in
the USB serial module is called to handle an event; thanks to the way
USB works (and the fact that the USB serial port will usually register
for fairly low priority), this will result in fairly large jitter -
but the jitter may not be so bad; I guess you have to try it to see.

The basic problem is that LinuxPPS currently does *not* have a patch
to the usbserial module to retrieve a timestamp.  At the moment the
timestamp is registered at a very low level where the kernel responds
to interrupts and the technique, unfortunately, means you cannot share
interrupts. It is not obvious to me how you would do the same for the
usbserial module.  In the past, the timestamp was registered when the
serial port routines were called to process an interrupt (this should
be easy to implement in the usbserial code) but the problem with this
was that the interrupt could (I don't know if it actually is - I never
looked at that detail) be called through a 'tasklet' and this, at
best, would increase the jitter in the timestamp.

> The NMEA data does not come before the PPS signal; it comes after the
> signal.  AFAIK, there is no setting on the GPS to make the NMEA data come
> before the PPS signal, so this is why I need to use the clear file.  If
> anyone can find possible solutions to the problem, I will greatly appreciate
> it.
>
> Regards,
>
> Ron
>

This is the usual case; the timing signal has to be guaranteed so it
gets absolute priority.  It would be inconvenient to code so that the
NMEA message would be thrown out *before* a PPS signal - think about
it, there are numerous NMEA messages relevant to a GPS, they are
variable length, some messages may come in up to 3 lines (according to
spec), and you can select which set of messages to generate.   When
NTPD receives a time message (NMEA or what-not) it then uses the PPS
API to find the associated timestamp.  Now if the NMEA message came
*before* the timestamp you'll have this race between the timestamp
being available/unavailable at the time NTPD wants to check it, and
this results in seeing the correct timestamp at times and other times
you see the old timestamp.  If the NMEA message comes *after* the PPS
signal (which is the easy way to code anyway) then you have no such
problems - the timestamp will be available unless the PPS was somehow
missed.

What 'clear file' are you talking about?

- Cirilo