5600 + Kismet + GPS?

[h4rdc0d3]

Hello. I was just wondering if anyone has kismet working with gps on a 5600 (or any zaurus) and could share their insight or experience here? I have searched high and low finding plenty of related howto's but no definitive anything on this subject.

I'm pretty sure that I have everything that I need to make it work but is still not working. One other bit to point out: I do have kismet and kismet_qt installed and both working fine without gps.

Here is the body of an email that I sent to the qpeGPS folks that illustrates my current hangup:

<emailbody>

First off, I have to say that you've done an excellent job on the qpeGPS
software and I'm amazed at its capabilities and the foresight required to
create such a program. And that it's been working great for me.

However, I was wondering if you could give me any details concerning the
version of gpsd that is packaged with qpeGPS 0.9.1, specifically the one
located at:

http://prdownloads.sourceforge.net/qpegps/...rm.ipk?download

Background Information:

I have an Sharp Zaurus SL-5600 running the tkrom (2.0alpha3) with qpeGPS
0.9.1 installed. I use the Garmin eTrex with the Garmin data cable to the
M-DB9 Zthincable to the Sharp port at the bottom of the Zaurus to receive
gps data.

I'm in the process of trying to get Kismet to run with gps enabled and am
conducting testing of the gpsd that came packaged with qpeGPS. Via the
console, I start up gpsd with the same options that qpeGPS uses and telnet
to localhost at port 2947. Using the gpsd commands 's' and 'm', which
respectively stand for status and mode, I'm getting some strange output
values. For example, when I use the s command, I get a response of '1',
which according to the protocol details at
http://www.pygps.org/gpsd/protocol.html indicates 'no signal'. When I use
the m command, I get a response of '3', which is not valid. It seems to me
that this version of gpsd may be reporting the s command's output when I
give it the m command and reports the m command's output when I enter the
s command. Under this assumption, the values would indicate a mode of
'GPS' and a status of '3D Fix', which makes a lot more sense.

What I'm really looking for is if the qpeGPS team would care to comment on
whether or not this version of gpsd is the 'standard' gpsd or if it has
been modified in some way to be 'non-standard' so that it works with
qpeGPS. Another way of putting it could be: does qpeGPS work with any gpsd
or must it be the gpsd packaged with qpeGPS?

Any help or insight would be greatly appreciated.

</emailbody>

[h4rdc0d3]

I'm about sick of trying to make it work... I think that I'll reinstall one last version of kismet and if it doesn't work with gps then I'll just write up some perl or bash script that does the gpsd interfacing and logging for me.

Take that script and add 3 more on the backend to do data merging, map retrieval (like mapfetch) and plotting and it'll work the way I want it to anyway and the separate scripts could be quasi-useful for other applications.

Btw, mapfetch.pl is kind of like getmaps and you can view/download it at http://www.hardcodelabs.org/projects/mapfetch.txt.