Re: [gpsd-dev] ✘cgps

[Fred Wright]

On Thu, 31 Mar 2016, Gary E. Miller wrote:
> On Thu, 31 Mar 2016 18:58:34 -0700 (PDT)
> Fred Wright <address@hidden> wrote:

> > Actually, I just tried it again and it didn't choke (and setti=led on
> > the generic NMEA driver), so I'm not sure what was going on when I
> > tried it before, but this receiver is finicky enough about antenna
> > placement when running indoors that it's not the best choice for most
> > testing, anyway.

I happened to want to try this receiver again for another reason, and I
think I now see what the trouble is, and it has nothing to do with the
data.  When pointing GPSD at the Bluetooth serial device on the Mac, it
usually (but not always) thinks (based on the log messages) that it's
supposed to be a PPS source (even though the doc claims that there are
rather specific naming requirements for a PPS device).  Sanitizing it by
passing the data through nc and pointing GPSD at the TCP port gets around
it.

That's the opposite of the problem I have on my time server (BeagleBone
Black running Debian stable), where GPSD refuses to recognize my actual
PPS source (direct GPIO from the GPS cape).  The sysfs "path" value is
empty, and based on some code I saw I think it's expected to match the
associated serial port.  NTPd has no problem using it, though, so I'm
running it "split", with NTPd getting the coarse time via SHM(0) and the
PPS directly.

> I have found another issue.  I have some USB cables that corrupt
> the data.  Happened to me yesterday and confused me for hours.  Swapping
> the cable and my problems went away.

There's probably some bad software conspiring with the bad cable to make
undetected errors that common, though the USB integrity checking is pretty
lame.  It's been pointed out that you shouldn't use USB to copy an entire
disk drive because the chance of an undetected error is too high.

Fred Wright