From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-gy0-f171.google.com (mail-gy0-f171.google.com [209.85.160.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 53C7B200DD8 for ; Thu, 15 Mar 2012 07:37:11 -0700 (PDT) Received: by ghbz17 with SMTP id z17so4981669ghb.16 for ; Thu, 15 Mar 2012 07:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YfvQhV1EQ3pK6BXd47lP9Da3MqUmaE7pm11XvClEmso=; b=wTW1kRKpZkOzTymcFZwBIp6N+WZGTQpzXsnutBPOB/dVU+tEqGOVB6G1tBHPSguSZz NsjE9a5Eh/YMy2wyBiNi3NsrFUY395381zRlnDEGrWGxpB/PuQmbEs3JVDigGkTrvJI2 /Q+5qsBAHrnEdg7TfpcQ/SkRaLxrqN5QI2EAP0GSCTHidH4QUGo6bfR9aDcPQ9kKJ2Ik Pxw01nbHHnWC+o9DT/r9BokwLxexuwwGY5WHuSedDR5SUOXLKRNJJ40pFNJOyUxNoCNi qCLJqQ9xEexmhuef7Z2pnSKxYHSOYCpO0bnzGpx4vl89vKmmJiyxtTCfh6NS0zcWf5lQ AOYA== MIME-Version: 1.0 Received: by 10.182.147.35 with SMTP id th3mr6571686obb.29.1331822227889; Thu, 15 Mar 2012 07:37:07 -0700 (PDT) Received: by 10.182.68.164 with HTTP; Thu, 15 Mar 2012 07:37:07 -0700 (PDT) Received: by 10.182.68.164 with HTTP; Thu, 15 Mar 2012 07:37:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Mar 2012 10:37:07 -0400 Message-ID: From: tz To: esr@thyrsus.com Content-Type: multipart/alternative; boundary=f46d04440054cc1e0c04bb49066e 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 14:37:12 -0000 --f46d04440054cc1e0c04bb49066e Content-Type: text/plain; charset=ISO-8859-1 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. --f46d04440054cc1e0c04bb49066e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Skytraq has a number of unique commands that identify the chipsets.=A0 S= o 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 gp= sd and it probes (same error in upowerd - I filed a bug report with fedora)= .=A0=A0 It thought my SkyTraq was this unit.

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

You still have the same problem using any other gps for bufferbloat - gp= sd will attempt to sync the time via ntpshm based on any NMEA stream at the= last sentence in a group.=A0 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.= =A0 'Blessed' might mean PPS, but how do we certify it?

How much of an issue will this be?=A0 If we are going to require using o= ne specific hardware combo, it will have the right set for gpsd-ntpd-kernel= .=A0 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 c= orrection in adjtime caught up, etc. though that applies to ours too.

--f46d04440054cc1e0c04bb49066e--