The GPS world is full of shoddy, poorly-documented designs. All
too many devices have behaviors that drive the harried maintainers of
gpsd
to shake their heads and mutter What were they
thinking?
This page goes beyond the merely ordinary and commemorates the really special blunders — bugs and design errors so consummately brain-dead that the only possible responses are either rage or helpless laughter.
By naming and shaming the vendors who perpetrated these egregious blunders, we hope to exert some pressure for higher quality standards in the future.
Your contributions are welcome. If you're describing a firmware bug, it's best if you can identify the firmware version or range of versions it applies to.
These are the screwups that lead us to wonder if the GPS chipset vendors ever read the NMEA documentation.
When Qualcomm bought SiRF, they stopped releasing any documentation, and started get creative with their interpretations of NMEA. Thenm starting adding new protocols.
The QUalcomm SiRF-TriG, Furuno GT-88, Navlor CH-4701, and Quectel EG25-G, all emit broken $xxGSA sentences. Each broken in different ways.
The Quectel-chipsets implement "Querky" interpretations of the NMEA protocol. *gpsd* tries to implement workarounds when possiblem but it would be far better is Quectel developers read the NMEA protocol documentation.
These are the screwups that lead us to wonder if the GPS chipset vendors ever actually test their hardware.
The iTalk protocol from Fastrax Inc. sometimes emits well-formed, checksummed binary packets in which the length is incorrect. If you trust it and read the number of bytes it tells you to, you'll land in the middle of the next packet.
Wintec has modified the firmware on the WBT200 (and probably the WBT100 as well) to disable iTalk support, thus making more room in the flash memory for logging. This wouldn't be a problem if they had also disabled the protocol switch command. Users attempting to switch their Wintec receivers to iTalk will find their receiver is left in limbo; not emitting iTalk, and unable to switch back to NMEA either. A hard reset by removing all power sources (including onboard battery backup) is the only way to get the receiver to communicate again.
Some Garmin chips issue a bogus length field, too. This from the outfit that likes to tout itself as the industry leader!
The SiRF-IV chipset has a tendency to freeze when switched from binary to NMEA mode (powering it off unjams it). This is some kind of race condition in the firmware that cannot be fixed by waiting on command ACKs; we have tried that.
The best evidence that the GPS industry is run by morons is the quality (or, rather, utter lack of quality) of their chipset documentation. You would think they'd have figured out by now that good and readily available documentation, making it easy for others to interface to their hardware, will sell more hardware. But no; most vendors make documentation difficult to get, and it tends to be both incomplete and vague when you get it. A few vendors go above and beyond the normal stupidity...
Some versions of the SiRF protocol manual, including 1.4, describe the data widths in the time portion of the Geodetic Navigation Information packet incorrectly. If you trust them, you will extract garbage from good packets.
Qualcomm makes no documentation available on the Sirfstar V GNSS.
The Garmin GPS chipset issues a number of important messages that Garmin has explicitly refused to document.
GPS chipset vendors love their proprietary binary protocols. There
is some excuse for this, given that the industry standard
NMEA
0183 grew by a series of kluges and accretions and would probably have
turned out better if it had been designed by chimpanzees on crack
— but you'd think the vendors would at least make sure that
their binary protocols are a functional superset of NMEA. But no; in
the laugh-one-minute, puke-the-next world of GPS chipsets, it ain't
so...
SiRF binary mode delivers HDOP but not PDOP or VDOP. SiRFs in NMEA mode deliver all three.
EverMore NMEA delivers UTC time. EverMore binary protocol delivers only GPS time, which has a time-varying offset from UTC — and no way to query the offset.