[Thumbgps-devel] USB handshake signals and Linux

[Ron Frazier (NTP)]

My GlobalSat BU-353 has an internal Prolific serial - USB converter.  It 
pretty much worked out of the box in Ubuntu 11.04 without installing any 
drivers, although some drivers are available on the GlobalSat website.  
And, I'm only communicating with it, at the moment, using NTPD, not 
GPSD.  I'm running windows at the moment, so I cannot look at that 
config file.  However, I think it appears as /dev/ttyUSB0 or something, 
then I had to make a symbolic link to /dev/gps5 (which is equivalent to 
running on COM5 in windows).

I have a sure electronics GPS demo board on order.  I have to solder a 
wire on the board to get PPS to the DCD pin, and hopefully not kill the 
board.  Once that's done, I'm going to be testing PPS through an 
external Prolific based adapter, the Trendnet TU-S9.  The packaging 
specifically says it passes signals on all pins of the DB9 connector.  
The reviews on this adapter on Amazon.com are good, some of which 
mention linux.  My first testing will be on windows, then linux.

For those of you who may not be familiar with the NTP Questions list, 
there is a good bit of discussion on this list about GPS, perhaps more 
so since I've been asking questions about problems I've been having.  
While not specific to your project, the info that comes across the list 
might be helpful.

http://lists.ntp.org/listinfo/questions - NTP Questions List
http://lists.ntp.org/pipermail/questions/ - archives

Sincerely,

Ron

On 3/14/2012 6:49 AM, Eric S. Raymond wrote:
> Since the Plane Jane design concept depends on the host system being
> able to see USB events corresponding to serial handshaking state
> changes, I went looking for information on which handshake signals
> from which serial-to-USB adapters actually propagate these signals
> through. I focused on Linux becase that's the kernel for the
> bufferbloat deployment.
>
> My list of adapters is taken from the gpsd udev rules file. This
> enumerates all the USB-to-serial chips we've observed in the wild
> since 2005. Note that the PL2303 is by far the most common, with
> 15 of 20 device types for which we know the USB chip using
> it. Weighted by device volume the PL2303's share would be far higher.
>
> PL2303: From source/linux/drivers/usb/serial/pl2303.c in 2.6.11.8,
> there are defines UART_DCD, UART_RING, UART_CTS and UART_DSR and code
> to implement looking at these signals in the TIOCMGET and TIOCMIWAIT
> ioctl handlers.  A bug fix for TIOCMIWAIT was merged in 2006.
>
> FTDI SIO: (8U232AM / FT232): There is a comment in the kernel source
> file drivers/usb/serial/ftdi_sio.c from 2.6, in the implementation of
> TIOCMIWAIT, that specifically says "Wait for any of the 4 modem inputs
> (DCD,RI,DSR,CTS) to change". I found no bug reports or fixes relating
> to this feature.
>
> Cypress M8/CY7C64013: Like the FTDI; TIOCMIWAIT is implemented for
> all four handshake lines.  I found no bugs relating to this feature.
>
> Cygnal Integrated Products, Inc. CP210x: Like the FTDI and Cypress M8;
> TIOCMIWAIT is implemented for all four handshake lines. The code was
> reworked in 2010.
>
> Note: there is a known TIOCMIWAIT bug in the *device-independent* part
> of the serial-device layer: speed or other serial-parameter changes
> during a TIOCMIWAIT call will hang it. GPSD has had to work around
> this.
>
> Conclusion: if we can get 1PPS to the input side of any of these
> adapters, the Linux host will be able to see it.
>    


-- 

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com