Kismet Wireless

Kismet Forums

 

Posted by:Dutch
Subject:gpsd weirdness fixed in kismet yet?
Date:07:50:53 10/04/2006

> Depends on the gps you have. Some people have had good luck with the berlios.de gpsd -- for me, it doesn't work with sirf-II at all, it completely screws up the speed and altitude. I've had passable luck with the old gpsdrive-gpsd, but it still randomly crashes, especially when it can't open the device right away (as is the case with bluetooth).
>
> -m

Have you tried tacking on the -K parameter to the gpsdrive-gpsd ? I know it is meant to keep the gps device open all the time, in order to work around USB problems, but it might also be able to fix the problems you have with Bluetooth.

On another note, I posted this at the NS forums, and it seems fittingly appropriate for this thread as well :

/soapbox on
I must admit, that although I know ESR did a lot of stuff for the GNU/Open Source community, I tend to feel that he somehow lost focus when he took over the steerage of the GPSD development.
*nix has allways prised it self, on being made up of a lot of small utils that could be combined in a lot of ways to accomplish what ever tasks you wanted to accomplish. I.E. one util to parse text, another util to format it, and a third util to output it. If one wanted to do all three things in one go, one just piped the output from one into the input of the next.

If we take that philosophy and apply it to a gps deamon, what should it do ?
It should take the input from the gps, and make it available to whatever program that requests that info. We had that in the old series of GPSD's (See http://gpsd.berlios.de/history.html for an overview of what happened during GPSD's lifespan sofar), albeit with a thick crust of dust on the code.
But it did what it was supposed to do, according to the old *nix philosophy : It parsed NMEA input from a GPS, and made it readily available for whatever program that requested the data.

Whatever happened to the K.I.S.S philosophy ?
It's great that ESR decided to refactor and clean up the code, but since he took over the project steerage, there have been more versions of GPSD released than in the 9 years of its lifespan before. Each version adding more features, and IMHO becoming more bloated and in several cases more unstable. It has also become more demanding in ressources such as memory and cpu cycles.

100 % of all consumer GPS's that output data which can be accessed by the user, can output that data as NMEA. Admittedly NMEA as a protocol is a clusterfuck, but it IS a standard, and a standard that almost any GPS aware application understands.
Now tell me the reason why GPSD should change a GPS into its native language (Sirf, Garmin Binary, etc) and then translate that into NMEA if the application that requests data from GPSD asks for NMEA formatted data ? Yes, I know some older GPS's only output NMEA location data every 2 seconds, while the native binary can do it every second. If you need the 1 hz update, get a GPS that supports it. Don't force everybody else to have to spend cpucycles in converting from native binary to NMEA, when their GPS's allready supply NMEA data every second.

Ahh, its for making GPSD more userfriendly.. It autodetects the chipset and baud speed and such, then uses the right protocol, you say ?
Well, I've had the first 5 people ask me why their Sirf based GPS's suddenly didn't work with their windows programs, after they had used it with a newer GPSD under *nix...
Yeah, they might have forgotten to read the documentation, but if GPSD changes the state of a device to speak another protocol, it should damn well change the state back to the previous protocol, when exiting. That would be userfriendly, instead of letting the average user try to figure out that his GPS should be reset to NMEA and how to do so, in order for it to work with his other programs and OS's.

It's also fine that there are many new features such as ability to function as a timesource for NTP servers, ability to communicate over DBUS, and a lib based approach for new programs, to directly communicate with GPSD..
But it has taken GPSD further and further away from the original *nix philosophy.

That, and the fact that every new release seem to have introduced new bugs in the BASIC functionality of GPSD, keeps me away from the newer series of GPSD.
Thats my prerogative, just as it is ESR's prerogative to keep on making GPSD an allsinging, alldancing, bloated GPSD/NTP timepiece/toastmaking and coffeebrewing machine/kitchensink.

I'll stick with the NMEA only, low ressource demanding, old GPSD that just plain works.

/soapbox off

Dutch


Reply to this message