WiGLE.net

I've proposed a bounty on an application / driver to be released as free software that would allow a GPS on one real serial port to be accessed by multiple applications attached to virtual serial ports. (i.e. NetStumbler and MapPoint) It looks like it's about $120 right now. If you want to chip in, check out the thread at http://forums.netstumbler.com/showthrea ... eadid=1887.

I would love that. Then we could tie the gps into JiGLE, add polling, and you could watch as points appear as you move around on the JiGLE map as you stumble. yum.

Akin to the virtual serial port for GPS sharing, would be support for accessing GPS position data via TCP/IP from a GPSd server.

This allows GPS sharing not just between local applications, but also across machines on a LAN. For example, several machines on a hub in a war-driving RV or huge-ass SUV.

There are already 'moving map' X-Windows apps that use GPSd.

I've been working on software for the last month that already does this. It can accept data from as many GPS units as you have ram for, and plot their current positions on a map, along with showing where everybody has been, and where they are going. Right now, I'm adding in a live triangulation method, where as soon as atleast 3 points are found, it plots a point using real triangulation, not a weighted average. The program so far is nowhere near done, but after testing it out for the wwwd3 last weekend, it seems that it's gonna work pretty good. The biggest obstacle is getting gps data from all the other cars out war driving with you. A simple 4800 baud serial transmitter would work great for this. However, all the current ones out there are very expensive, as they're generally for industrial use. I'm working on this aspect of it too. I'll post here about it when I get this software done.

Also see the gpsd project, it's what kismet uses, we're modifying JiGLE to use it, it's a nice simple gps abstraction. It doesn't do any aggregation of multiple gps's, it's more a 1 gps to many gizmo.

it works already (with some patching); i've even got DiGLE to poll data from it. now we just need marius to integrate support for GPSD into netstumbler

Comfoolery does this. It's shareware with a nag at startup if you don't contribute. See Agent Green's site for info on setting it up. It works for me, but I find it occaisionally drops data, so I tend not to use it when stumbling.

Jim

I find it amusing to look at the distance between the posts on this thread. This was solved by several different methods shortly after the time I posted this. None of them were as good as the gpsd method. It would really be wise to standardize around gpsd for this kind of functionality now unless you have a really good reason to write it all from scratch again. The best thing that could be done would be to add more input and output protocols to gpsd. For instance support for input in Garmin binary and output in NMEA would be very cool for those of use with eTrex's which only update every two seconds in NMEA, but every one second in Garmin. It would allow kismet and any other gpsd compliant program to get 1 second fix coordinates and allow "raw" NMEA programs like gpsdrive to continue to work though gpsd. I'd think that input modules for NMEA (of course), Garmin binary, Garmin text, and Earthmate binary would cover most inputs. Output modules could be the same, or just NMEA. I've implemented a Garmin text input, it's not pretty but it also wasn't terribly hard. So, this all is just my 2 cents about where I'd like to see gps handling go.

Hear, Hear.

I'll do the sony etak module, if i can ever find a clearer reference about what precusely the weird, character-based DoP/QoS characters mean.

Has anybody ported GPSD to win32 yet? I haven't seen it anywhere. If not, is this planned in the near future?

I've gotten it working by making modifications to the instructions listed
here:

http://nms.lcs.mit.edu/projects/cricket/README

basically, this was for a version back, so the line numbers are a little off, and the makefile doesn't need fixing anymore. we were talking about doing a binary release with an accompanying cygwin.dll, but i don't know if the licenses permit.

-a

PS> note that your serial port arguments will be COMx instead of /dev/ttyx under windows.

Right now, I'm adding in a live triangulation method, where as soon as atleast 3 points are found, it plots a point using real triangulation, not a weighted average.

Hi, can you tell me where I can find some info on how to calculate the triangulation (formula's, ...)

For UNIX gearheads, you could probably make any NMEA-Serial aware program work with gpsd. I don't use it, but I'd imagine I could get gpsd working, then make a few fifo's (maybe in /dev?) and then use netcat to fill the fifos from gpsd, and then tell the program you want to use to use your fifo as it's "GPS Serial port".

This way, GPSd would lock your serial port, but /dev/serialfifo0, /dev/serialfifo1, ... would be up and running. Point JiGLE to serialfifo0, point dstumbler to serialfifo1, and then set up a few backgrounded netcats to yack gpsd's output to the fifos.

As long as GPSd just puts out the exact same NMEA text as it gets from serial, and doesn't add anything non-standard, I don't see why this won't work.

I'm sure someone could get (or already has gotten) GPSd working on windows, and I know netcat is already there. The only missing piece is that I don't know that Windows can handle filesystem FIFO's. If it can, this solution could probably work across many platforms, with slightly different implementation methods.

jigle and dstumbler at least already work with gpsd (or if they don't, let me know ;-)