Re: [Thumbgps-devel] USB handshake signals and Linux

Re: [Thumbgps-devel] USB handshake signals and Linux

[tz]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

Skytraq has a number of unique commands that identify the chipsets.  So do
MTK and Garmin.

Right now the udev for gpsd gets it wrong by including the generic FTDI
vendor id for one gps, so plugging in my ftdi arduino/breakout starts up
gpsd and it probes (same error in upowerd - I filed a bug report with
fedora).   It thought my SkyTraq was this unit.

I have the PPS hooked to the CTS pin, but gpsd has to be recompiled to
enable pps or change pins.  This should be configurable at runtime.

You still have the same problem using any other gps for bufferbloat - gpsd
will attempt to sync the time via ntpshm based on any NMEA stream at the
last sentence in a group.  You will need some tweaking to make it not do
this, or reject other gps units, or otherwise indicate that unless you are
using one of our 'blessed' units the time won't be accurate.  'Blessed'
might mean PPS, but how do we certify it?

How much of an issue will this be?  If we are going to require using one
specific hardware combo, it will have the right set for gpsd-ntpd-kernel.
If we allow any configuration of any hardware or software, we have no way
of verifying it has precise UTC time - when was the last PPS, has the
correction in adjtime caught up, etc. though that applies to ours too.

[-- Attachment #2: Type: text/html, Size: 1338 bytes --]

Re: [Thumbgps-devel] USB handshake signals and Linux

[Ron Frazier (NTP)]

I have a question about GPSD.  I have nothing against it, but why is it 
necessary to use it at all?  I have NTPD running on both Windows and 
Linux, and reading my GPS.  GSPD isn't available on Windows as far as I 
know.  What does using GPSD get me that running without it does not?

Sincerely,

Ron

On 3/15/2012 10:37 AM, tz wrote:
>
> Skytraq has a number of unique commands that identify the chipsets.  
> So do MTK and Garmin.
>
> Right now the udev for gpsd gets it wrong by including the generic 
> FTDI vendor id for one gps, so plugging in my ftdi arduino/breakout 
> starts up gpsd and it probes (same error in upowerd - I filed a bug 
> report with fedora).   It thought my SkyTraq was this unit.
>
> I have the PPS hooked to the CTS pin, but gpsd has to be recompiled to 
> enable pps or change pins.  This should be configurable at runtime.
>
> You still have the same problem using any other gps for bufferbloat - 
> gpsd will attempt to sync the time via ntpshm based on any NMEA stream 
> at the last sentence in a group.  You will need some tweaking to make 
> it not do this, or reject other gps units, or otherwise indicate that 
> unless you are using one of our 'blessed' units the time won't be 
> accurate.  'Blessed' might mean PPS, but how do we certify it?
>
> How much of an issue will this be?  If we are going to require using 
> one specific hardware combo, it will have the right set for 
> gpsd-ntpd-kernel.  If we allow any configuration of any hardware or 
> software, we have no way of verifying it has precise UTC time - when 
> was the last PPS, has the correction in adjtime caught up, etc. though 
> that applies to ours too.
>
>    

-- 

(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

Re: [Thumbgps-devel] USB handshake signals and Linux

[Eric S. Raymond]

Ron Frazier (NTP) <timekeepingntplist@c3energy.com>:
> I have a question about GPSD.  I have nothing against it, but why is
> it necessary to use it at all?  I have NTPD running on both Windows
> and Linux, and reading my GPS.  GSPD isn't available on Windows as
> far as I know.  What does using GPSD get me that running without it
> does not?

For timing purposes the GPS emits two things we're interested in: time
report sentences and 1PPS state changes on the DCD or RI line (since
it's a USB interface that would actually be USB events emulating those
changes).

Something has to interpret those. GPSD can already do that and is well
tested.  If we drop GPSD, then we have to write our own dedicated
service daemon or in-kernel support.  That would be seriously
complicated and involve a lot of headachy debugging.

Also, we'd then probably be stuck with supporting only a single device type.
By the time you've upgraded a non-GPSD service daeomon so it can handle either
NMEA or (say) SiRF binary, you'll have rewritten most of GPSD.

The way the time-delivery pipeline works under Linux is that GPSD uses the
GPS take to write on a shared-memory segment that NTPD reads.  The GPSD
code that handles 1PPS interpretation and the handoff to shared memory
is complicated and nasty, without question the most obscure part of the
GPSD codebase.  Trust me when I tell you that you do *not* want to try 
to duplicate this - debugging it is a stone bitch.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] USB handshake signals and Linux

[Eric S. Raymond]

tz <tz2026@gmail.com>:
> Skytraq has a number of unique commands that identify the chipsets.  So do
> MTK and Garmin.

That is true and fortunate.
 
> Right now the udev for gpsd gets it wrong by including the generic FTDI
> vendor id for one gps, so plugging in my ftdi arduino/breakout starts up
> gpsd and it probes (same error in upowerd - I filed a bug report with
> fedora).   It thought my SkyTraq was this unit.

Alas, this can't be fixed, due to lossage in the USB standard.  I'll explain.

In an ideal world, there would be a USB device class for GPSes and GPSD
would key on that, ignoring all other devices.

The root of the problem is that there is no USB device class for GPSes. There
isn't even one for USB-to-serial adaptors.  So the USB class that GPSes report
is the catch-all 0F = vendor-specific, same as your Arduino widget.

As a workaround, GPSD picks up devices that report USB vendor-id/product-ID
pairs associated with USB-to-serial adapters like the PL2303 that are
commonly used for GPSes.  Because this is in fact the overwhelimingly 
most common use for USB-to-serial adapters, this bodge works for almost
everyone almost all the time.

You happen to be one of the 1% exceptions.  Sorry about that.  It means 
you have to start GPSD by hand and can't use udev.  There isn't a better
solution, the information to implement one is just not there.

> I have the PPS hooked to the CTS pin, but gpsd has to be recompiled to
> enable pps or change pins.  This should be configurable at runtime.

GPSD has no runtime configuration.  Even the use of command-line switches
is minimized. There is exactly one that sets an operating mode, and that is
only because without it certain broken Bluetooth devices would be bricked.

GPSD has no runtime configuration because my design philosophy is that
it should autoconfigure itself to meet conditions.  It autobauds and 
automatically recognizes the packet protocols it supports.  I removed
the command-line switches for device type and baud rate in 2005 and they
are not coming back.

For the bufferbloat deployment, GPSD will be compiled with 1PPS enabled.
I might change that to be the default - it's hard to imagine circumstances
under which that could go wrong.

> You still have the same problem using any other gps for bufferbloat - gpsd
> will attempt to sync the time via ntpshm based on any NMEA stream at the
> last sentence in a group.

Not the last sentence. GPSD detects the start of cycle sentence of your
device by watching a couple of cycles go by.  thereafter, it knows to 
associate current GPS time with the saved arrival time of the first character
in the start packet of the current reporting cycle.

>         You will need some tweaking to make it not do
> this, or reject other gps units, or otherwise indicate that unless you are
> using one of our 'blessed' units the time won't be accurate.  'Blessed'
> might mean PPS, but how do we certify it?

The current logic is simple.  If GPSD sees 1PPS, then it feeds NTPD.  
Otherwise not.  I don't think it needs to be more complicated than this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] USB handshake signals and Linux

[Patrick Maupin]

On Thu, Mar 15, 2012 at 1:31 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> As a workaround, GPSD picks up devices that report USB vendor-id/product-ID
> pairs associated with USB-to-serial adapters like the PL2303 that are
> commonly used for GPSes.  Because this is in fact the overwhelimingly
> most common use for USB-to-serial adapters, this bodge works for almost
> everyone almost all the time.

For what it's worth, FTDI will give you a free PID to use with their
VID with justification.  So we could have a VID/PID that uniquely
identifies our dongle, and/or a VID/PID that we can allow other
manufacturers to use for any dongle using an FTDI chip and meeting the
right specifications.

I don't know if Prolific has a similar program or not.

Re: [Thumbgps-devel] USB handshake signals and Linux

[tz]

On Thu, Mar 15, 2012 at 2:31 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> tz <tz2026@gmail.com>:

> You happen to be one of the 1% exceptions.  Sorry about that.  It means
> you have to start GPSD by hand and can't use udev.  There isn't a better
> solution, the information to implement one is just not there.

The problem is that if I hook up an Arduino (on most Distros including
gpsd or even gpsd installed new), gpsd fires up and tries probing.

My argument is not with the others with unique ids (vendor/product)
but the one with the plain, default vendor/product ID that is on by
default in udev (instead of commented out with a note).

>> I have the PPS hooked to the CTS pin, but gpsd has to be recompiled to
>> enable pps or change pins.  This should be configurable at runtime.

> For the bufferbloat deployment, GPSD will be compiled with 1PPS enabled.
> I might change that to be the default - it's hard to imagine circumstances
> under which that could go wrong.

It would also be nice if it would autoconfigure which pin/pins were
used.  You could enable it and then use something to figure out which
pin (or enable change on any of them?).

Re: [Thumbgps-devel] USB handshake signals and Linux

[Eric S. Raymond]

Patrick Maupin <pmaupin@gmail.com>:
> On Thu, Mar 15, 2012 at 1:31 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> 
> > As a workaround, GPSD picks up devices that report USB vendor-id/product-ID
> > pairs associated with USB-to-serial adapters like the PL2303 that are
> > commonly used for GPSes.  Because this is in fact the overwhelimingly
> > most common use for USB-to-serial adapters, this bodge works for almost
> > everyone almost all the time.
> 
> For what it's worth, FTDI will give you a free PID to use with their
> VID with justification.  So we could have a VID/PID that uniquely
> identifies our dongle, and/or a VID/PID that we can allow other
> manufacturers to use for any dongle using an FTDI chip and meeting the
> right specifications.

Oh, that's nice.
 
> I don't know if Prolific has a similar program or not.

I don't know either.  Might be difficult to get the vendors to implement
it if they did - their focus on cost-cutting is pretty brutal, and leads
to chop-shop engineering with results you've already seen in the Xucai
dongle.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] USB handshake signals and Linux

[Eric S. Raymond]

tz <tz2026@gmail.com>:
> The problem is that if I hook up an Arduino (on most Distros including
> gpsd or even gpsd installed new), gpsd fires up and tries probing.

Yes, I know.  There's no help for this short of disabling GPSD autostart
by udev.  That would hurt a lot more people (as in, everybody who wants
to just plug in a USB GPS and go) than it would help. 
 
> My argument is not with the others with unique ids (vendor/product)
> but the one with the plain, default vendor/product ID that is on by
> default in udev (instead of commented out with a note).

You apparently don't quite get it yet (no blame, this stuff is ugly
and obscure). There are *no* "unique" VID/PID pairs for GPSes. All the
VID/PID pairs in gpsd.rules do is recognize USB-to-serial adapters,
because that's all that can be done.  GPSD has no way to know what the
device on the other side of the adapter is - it starts on the premise
that the thing might be a GPS, then releases the device if it fails to
recognize GPS packets over the wire.

> It would also be nice if it would autoconfigure which pin/pins were
> used.  You could enable it and then use something to figure out which
> pin (or enable change on any of them?).

Hm, that's an interesting idea.  Enabling change on any of them would
fit our design philosophy.  ckuethe, are you listening?  Can you think
of any reason this might break something?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] USB handshake signals and Linux

[Patrick Maupin]

On Thu, Mar 15, 2012 at 2:36 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Might be difficult to get the vendors to implement [custom VID/PID]
> it if they did - their focus on cost-cutting is pretty brutal, and leads
> to chop-shop engineering with results you've already seen in the Xucai
> dongle.

May not matter.  In many cases the VID/PID are reprogrammable.  So the
user could be told to reprogram his dongle to this VID/PID, and GPSD
could pick it up more reliably, and other programs might more reliably
leave it alone.

Re: [Thumbgps-devel] USB handshake signals and Linux

[Eric S. Raymond]

Patrick Maupin <pmaupin@gmail.com>:
> The latency timer on the FTDI parts can be dropped to a millisecond.
> If we find a USB dongle that has a USB converter with similar
> capabilities and a GPS chipset that has rock-solid first-character
> timing, we might avoid needing the RS232 handshake altogether.

There's a reason I'm a bit wary of a non-1PPS design based on timing
the leading edge of the $GPZDA or whatever. That is this: unless the
device is self-identifying, there'll be no way to know when the time
information can be trusted.  Remember that the bufferbloat deployment
is planned to use GPSD and that we *cannot* assume that GPSD 
knows anything hand-configured about the USB devices it talks to.

By "self-identifying" that it ether (a) has a recognizable USB
vendor/ID pair, (b) ships a unique sentence type that GPSD can
recognize, or (c) there's a probe string GPSD can ship it that elicits
a unique response.  For reasons of history and vendor stupidity most
GPS-chip/adapter combos will fail all three tests.

One of the advantages of 1PPS is that it is self-identifying in this
way. If you're talking to a GPS, nothing but 1PPS produces DCD or RI
transitions, so when you see a 1PPS pulse you know what it is.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] USB handshake signals and Linux

[Patrick Maupin]

On Wed, Mar 14, 2012 at 1:42 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> I found a couple of hits on the search "PL2303 latency timer" that
> implies it has one too.  But I doubt the value of the latency timer
> will be relevant for handshake-line notifications; see below.

The latency timer on the FTDI parts can be dropped to a millisecond.
If we find a USB dongle that has a USB converter with similar
capabilities and a GPS chipset that has rock-solid first-character
timing, we might avoid needing the RS232 handshake altogether.

(We might need to drop the baud rate to avoid losing data, but that's
not a huge deal.)

Re: [Thumbgps-devel] USB handshake signals and Linux

[Patrick Maupin]

On Wed, Mar 14, 2012 at 1:57 PM, Dave Taht <dave.taht@gmail.com> wrote:

> In a private chat late last night andrew mentioned that the ftdi devices
> were extensively reprogrammable, in that they came as a usb device
> but were really, underneath, just a bunch of gpios...

Yes and no.  The bandwidth associated with using them as GPIOs is
relatively high compared to using them for serial ports.  They have a
lot of logic to support serial communication and also (in some cases
-- not all devices have this) some other modes like SPI, I2C, JTAG, or
CPU bus emulation.

I have personally used them in serial, parallel FIFO (a fast serial
emulation), GPIO, and JTAG modes.

Re: [Thumbgps-devel] USB handshake signals and Linux

[Dave Taht]

On Wed, Mar 14, 2012 at 11:42 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Patrick Maupin <pmaupin@gmail.com>:
>> The FTDI devices have a latency timer that allows you to control this
>> somewhat.
>

In a private chat late last night andrew mentioned that the ftdi devices
were extensively reprogrammable, in that they came as a usb device
but were really, underneath, just a bunch of gpios...

> I found a couple of hits on the search "PL2303 latency timer" that
> implies it has one too.  But I doubt the value of the latency timer
> will be relevant for handshake-line notifications; see below.
>
>>       But even better, if we're going to use the PPS signal, they
>> essentially guarantee that they will send ASAP on modem control signal
>> change.  We might need to characterize "ASAP" but I would hope that it
>> doesn't vary too much.
>
> Probably not.  Trying to buffer a handshake state change doesn't make
> any sense. I'm not surprised that the FTDI gives them realtime
> priority and I *will* be surprised if the PL2303 (or any other
> adapter) doesn't do likewise.
> --
>                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> _______________________________________________
> Thumbgps-devel mailing list
> Thumbgps-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/thumbgps-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: [Thumbgps-devel] USB handshake signals and Linux

[Eric S. Raymond]

Patrick Maupin <pmaupin@gmail.com>:
> The FTDI devices have a latency timer that allows you to control this
> somewhat.

I found a couple of hits on the search "PL2303 latency timer" that
implies it has one too.  But I doubt the value of the latency timer
will be relevant for handshake-line notifications; see below.

>       But even better, if we're going to use the PPS signal, they
> essentially guarantee that they will send ASAP on modem control signal
> change.  We might need to characterize "ASAP" but I would hope that it
> doesn't vary too much.

Probably not.  Trying to buffer a handshake state change doesn't make
any sense. I'm not surprised that the FTDI gives them realtime
priority and I *will* be surprised if the PL2303 (or any other
adapter) doesn't do likewise.  
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] USB handshake signals and Linux

[Patrick Maupin]

On Wed, Mar 14, 2012 at 5:49 AM, Eric S. Raymond <esr@thyrsus.com> 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.

There is another question, which is about the internal latency inside
the USB adapter.  In general (e.g. for character data) the USB
adapters will deliberately add some latency so as to make better use
of internal buffering resources.  (Once an adapter sends a packet of
characters up to the host, it has to wait for an ACK before it can
reuse that buffer -- it might need to resend for a NAK.)  So if the
host polls with an interrupt packet, and there is data at the USB
device but it reasonably expects that more data is coming, it might
not send the packet up right away.

The FTDI devices have a latency timer that allows you to control this
somewhat.  But even better, if we're going to use the PPS signal, they
essentially guarantee that they will send ASAP on modem control signal
change.  We might need to characterize "ASAP" but I would hope that it
doesn't vary too much.

I know nothing about the Prolific device; you might look for what they
have to say about latency.

Re: [Thumbgps-devel] USB handshake signals and Linux

[Ron Frazier (NTP)]

PS, I did have to issue some commands using stty, which I cannot 
remember at the moment.  Setting baud rate was one thing.  That wasn't 
all of it though.

Sincerely,

Ron

On 3/14/2012 8:55 AM, Ron Frazier (NTP) wrote:
> 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

Re: [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

[Thumbgps-devel] USB handshake signals and Linux

[Eric S. Raymond]

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.  
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Rifles, muskets, long-bows and hand-grenades are inherently democratic
weapons.  A complex weapon makes the strong stronger, while a simple
weapon -- so long as there is no answer to it -- gives claws to the
weak.
        -- George Orwell, "You and the Atom Bomb", 1945