From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (static-71-162-243-5.phlapa.fios.verizon.net [71.162.243.5]) by huchra.bufferbloat.net (Postfix) with ESMTP id B8E0120027E for ; Thu, 15 Mar 2012 11:31:57 -0700 (PDT) Received: by snark.thyrsus.com (Postfix, from userid 1000) id E20D940617; Thu, 15 Mar 2012 14:31:33 -0400 (EDT) Date: Thu, 15 Mar 2012 14:31:33 -0400 From: "Eric S. Raymond" To: tz Message-ID: <20120315183133.GC3870@thyrsus.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) Cc: thumbgps-devel@lists.bufferbloat.net Subject: Re: [Thumbgps-devel] USB handshake signals and Linux X-BeenThere: thumbgps-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: esr@thyrsus.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 18:31:58 -0000 tz : > 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. -- Eric S. Raymond