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

[Hal V. Engel]

On Saturday 22 November 2008 17:03:33 Cirilo Bernardo wrote:
> 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.

There are 4 lines in a USB cable, 5V (to power devices), Gnd, Tx and Rx.

Looking at the specs for the motherboard in this unit 
http://www.compulab.co.il/iglx/html/iglx-sb-datasheet.htm it appears that the 
COM ports are Rx/Tx only (bummer).  But it also appears that the motherboard 
always has 8 GPIO pins (IE these are not optional) and that at least 4 of 
these are available for user applications.  There was another person here who 
connected the DCD output from this GPS to a GPIO pin to setup LinuxPPS on an 
inexpensive router so it is possible to slave the PPS interrupt handler code 
to a GPIO pin and then use the Rx/Tx lines on the com port to handle the rest 
of the communications with the GPS.  Have a look at the archives for the gory 
details.   In his case the DCD signal was TTL (he was using a Motorola OnCore) 
but I think in your case the the DCD signal will be RS-232 levels and it will 
need to be converted to TLL levels before you can connect it to a GPIO pin.   

It appears that there are 4 available GPIO pins on the motherboard (P18 pins 
4, 6. 8 and 10).

>
> 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
>
> _______________________________________________
> LinuxPPS mailing list
> LinuxPPS at ml.enneenne.com
> http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
> Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support