From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by huchra.bufferbloat.net (Postfix) with ESMTP id 9E42620069D for ; Wed, 14 Mar 2012 05:58:52 -0700 (PDT) Received: from [192.168.83.5] (c-76-97-152-51.hsd1.ga.comcast.net [76.97.152.51]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M558A-1SXZFE2eDe-00yaQz; Wed, 14 Mar 2012 08:58:51 -0400 Message-ID: <4F609609.4040501@c3energy.com> Date: Wed, 14 Mar 2012 08:58:49 -0400 From: "Ron Frazier (NTP)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: thumbgps-devel@lists.bufferbloat.net References: <20120314104920.697EA40617@snark.thyrsus.com> <4F60954F.40703@c3energy.com> In-Reply-To: <4F60954F.40703@c3energy.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:sE5WS88IEHMwruLTt+ClR1GUlvPRfihQqosSnrDnGzy 17W0z9ymsPpuxQK3A1qQcoJIOtii/hp1P/+8lmXfIx/5C8wp0G rUyicXaDvuPmnSURm4ym31FKvATJNvYAe6ZYjNxA23y1hucnni wEHPg81fPfE+gLmDs+pvtyRH8QKN+T5eXhDGGifabfbhilTyX4 UTzDtnF0mANKcRrF4/ihjEXSRgCFKfqGUzLH+AcZZ44QIUY4AT JQnOR2FmxFiiAZj2o03zGcZ3sDh/IhznVnJOsyFnVsVMN6xru9 P0XrlqMBIffgEUzEuCyo3y98+QZkQ0qQTZN5vuce4z+AXn32U4 ZlnStyscsimawQ9TCFjki0TXro0vg6AtDBY2aXRar Subject: Re: [Thumbgps-devel] USB handshake signals and Linux X-BeenThere: thumbgps-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 12:58:52 -0000 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