Kismet Wireless

Kismet Forums

 

Posted by:dragorn
Subject:gpsd and kismet
Date:19:46:19 28/06/2011

> > I was testing on 2.92 (lucid) but 2.94 (maverick) and 2.95 (natty) appear equally broken. I didn't see any change in behavior switching to the (pre-JSON) 2.89.
>
> The behaviour doesn't exist when using a direct serial connection in Kismet, which correlates with your observed behaviour re JSON/Non-JSON behaviour. The problem exists in the gpsdclient.cc code. Whether it lays in the way GPSD submits data when there is a no-fix situation, or in the kismet gpsdclient.cc code, I'm not completely sure off yet.
>
> I need to talk it over with dragorn, before doing more, as I believe a proper fix means rewriting that code severely, and/or going to use GPSD's libs access methods instead.

Dutch caught me on IRC and the fix should be in SVN now. The fix is pretty simple, fortunately - if more than 3 seconds go by without a TPV fix component of the JSON report, it flags the gps as losing the fix. Since it looks like gpsd will either report a tpv with a fix, or not report anything when it loses a fix, this should catch it.

We COULD detect that there is no TPV and immediately flag the fix as lost, but I don't know if gpsd is likely to flap tpv/no tpv frequently. 3 seconds seems like a reasonable time to me.

> Dragorn has had issues with that road before, which is why using the gpsd API via the libs is disabled in the code. Need to hear from him what issues and in which versions it was in.
>

the GPSD api had, at least when I tried to use it, severe concurrency issues (did not coexist nicely with a standard select() loop) and would be really hard to integrate w/ kismet without spawning another thread. I also had some concerns at the time about how it parsed things, and the opaqueness of parts of it (such as calling commands in the wrong order leading to invisibly corrupted data, but no indication of the correct order).

All in all I'd much rather (and did, as you can see) write a whole parser just to deal with it, than address those issues.

> One of the great things about kismet over the years, is that it really hasn't demanded the use of any specific versions of non-dragorn developed code, including stuff like GPSD. I want to make sure that anything my meager contributions to his code can do, to keep it that way, is done.

Well thank you. :) Yeah you can always use the raw nmea mode, assuming your gps talks nmea (the majority do). Some don't; it's possible to add support for binary protocols, but since I don't have any that talk them I'm not too inclined, and I haven't heard too many people asking for it.

The GPS code is pretty modular now so if you need to add another gps type you can just subclass it out and you'll be set.


Reply to this message