Kismet Wireless

Kismet Forums

 

Posted by:dragorn
Subject:gpsd.cc quirks
Date:01:30:13 03/10/2007

> I'm writing a program that reports location data using the gpsd protocol. I've tried it with Kismet and noticed some weirdness.
>
> Admittedly, there's some ambiguity in the gpsd protocol documentation (about midway at http://gpsd.berlios.de/gpsd.html), but Kismet also seems to make some strange assumptions in gpsd.cc.
>
> Firstly, is the use of nulls to mark line endings. gpsd docs says the input lines are delimited by a newline and responses are delimited by CR/LF, yet Kismet sends a null-terminated string and expects one back.

Kismet gpsd sends a newline.

const char gpsd_command[] = "PAVMH\n";

> Secondly, Kismet uses 'H' but the closest command which gives the intended values (heading) is 'T' (track made good). Could this be due to an older protocol?

H is used on some GPSDs designed to report magnetic compass heading.

> Finally, gpsd recommends using the "watcher" mode instead of polling like Kismet does. Again, this could be due to some differences in protocol versions.
>

I've yet to see good documentation on gpsd, nor multiple versions of gpsd which agree on what they support. Newcore is moving away from gpsd - support will be there if someone really wants it, but so will direct serial support and a gpsd emulation server.

> I'm basing this off a quick look at the gpsd.cc source from Kismet version 2007-01-R1b.

Some moderately significant changes to it in svn. newcore is totally different.

Honestly, gpsd has been a rocky road for a long time, because there constantly seem to be changes to the protocol or how it expects things, or how it reports things, or how it expects the client application logic to change in ways which aren't backwards compatible or compatible against other gpsd implementations. (if anyone wants to convince me I'm wrong, feel free, this isn't an attack against the gpsd guys at all, just saying it's difficult to work with.)

-m


Reply to this message