Warning: This is fairly long and off-topic, but I think it could be extremely useful to most of the people here. Continue at your own peril:

I've been getting all sorts of interesting ideas lately, and they all hinge on the development of a way to emulate a serial port (COMx under Windows) using software.

What I mean is that FakePort could attach itself to COM1 on my laptop where the GPS sits, and virtualize COM2 and COM3, mirroring the incoming data to both of them. Then I could tell Netstumbler that the GPS was on COM2, and Street Atlas could use COM3. Then I could know where I am _and_ who's got an AP, at the same time! Imagine that!

Optionally, FakePort could be set to ignore data that Netstumbler is sending to COM2 (send it to the bit bucket), but take data that Street Atlas is sending to COM3, and echo it out the real COM1. (For bidirectional communication, uploading waypoints to the GPS etc, without interrupting Netstumbler.)

Next idea is more complex. FakePort's sister software will be a GPS translator, which can inhale Rockwell Binary data (used by the DeLorme Tripmate unit and some others) or ETAK data (used by Sony?) and exhale NMEA 0183 sentences on a virtualized port. That way, all NMEA GPS-aware software could make use of funky nonstandard (and cheap) GPS units, without programming. (There's a hardware wedge to do this, Rockwell Binary to NMEA in a small dongle, but who wants to spend $50 for something that should be doable in software?)

Third idea is just plain looney, and it requires some background knowledge of the Ricochet network. I'll now attempt to provide such background: Essentially, when you've got Ricochet coverage (in a metro area populated with their equipment), hundreds of lamppost-mounted repeaters handle your data, playing hot-potato with your packets until they reach a wired interface facility, where they're sent to the internet. Ricochet is totally proprietary, only their modems talk to their poletop repeaters.

Ricochet's parent company Metricom went belly-up over the summer. The network was sold to Aerie Networks who plans to reactivate it, but they're not exactly doing so with much haste. On the downside, Ricochet customers are SOL. On the upside, Ricochet modems are dirt-cheap on eBay, especially the old 28.8kbps ones (~$20). The 128k models still go for upwards of $50.

Here's the kicker: There's an AT command (yeah, the modems are Hayes-compatible) which lists all the poletops your modem can see, and their signal strengths. The poletops are programmed with their lat/long when they're installed, and they identify themselves with those coordinates.

If you see where I'm going with this, you're twisted. Congratulations. Essentially, I think a software wedge could make a Ricochet modem into a "poor man's GPS" for metro areas with coverage. By taking the latitude and longitude of each visible poletop, and weighing them all by relative signal strength, it should be possible to approximate your own location. I can usually see between 3 and 6 poletops at any given moment, and according to Metricom, there are about 5 installed per square mile. Such a GPS-guestimate should be good within a city block or so, and that's all the precision you need for most stumbling tasks. Query the modem for poletops, do the math, and spit the results out as an NMEA sentence on a virtual COM port. Not bad for $20!

The possibilities are endless.

I've searched high and low, and I can't find any existing software that even pretends to have these capabilities. It's probably out there, does anyone know of such? All we need is a device driver that looks like a COM port to Windows software. I know it's possible to _monitor_ traffic across COM ports under Windows, the PortMon program from Winternals does it nicely, but nobody pretends to _be_ a port that doesn't physically exist. Virtual Audio Cable is the closest example I can think of.

Hey there,

Check out

http://www.mks.zp.ua/products.html

where you'll find something which at least proves it can be done. This guy's creating virtual serial ports with software, for testing purposes. If you could run two instances of the program maybe you'd get two serial ports, then it would be trivial to write an application that addresses the two from a single serial input (NMEA fed here).

Regarding the Ricochet modem setup, that's neat. It is however nowhere as precise as a GPS, but if you are on a REALLY tight budget it could save you some cash. Again, writing an app that takes the modem's AT output and writes NMEA to a port is easy.

Consider, if you are looking for a cheap GPS, using some boards from SiRF or Motorola, they can be found at low prices, and already output NMEA aswell as their binary format.

Mother

That is funny I was thinking the same thing just before Xmass

Sorry Mr Typo

Now I just need to get off my ass and learn to program. Hmmph. I've seen several programs that do just the inverse -- If you have two hardware serial ports, this allows you to bridge them together and monitor data flowing across them. I.E. your machine becomes an in-line analyzer.

Figures, the first project I'm really interested in doing myself, involves a lot of driver-fu and stuff that they usually say should only be tackled by experienced programmers. My code is gonna look like shit.

Actually, the real way to do this is to make a GPS driver for windows that handles the actual communication to/from the GPS. Then, all other apps would just talk to the driver. It would solve the problem of multiple apps getting GPS info and it would let an app instantly support all GPS's that there are drivers for.

However, it requires that all of the apps out there be designed to support it. The virtual serial port idea is actually backward compatible, which would be nice.

- Joe

Check out gpsd and gps3d (sorry, Linux only...)

They include a daemon that talks to the GPS device, then
can communicate to any number of interested processes using
sockets.

Regardless of the difficulty of porting to Windoze it would still be easier than starting from scratch, even if you only use the code as a reference...just bear in mind that any project derived from these needs to be GPL...

I have "ported" gpsd from Motif to GTK, so that the command line/batch stuff is now in a separate "layer", making it
much easier to port to other GUI architectures...but the
basics is still *nix so there's a bit of work to make it
truly multiplatform.

dirgotronix

Using the ricochet as a gps is fairly easy, interfacing it with netstumbler would be great.

If you've got a ricochet modem, install it (usb or serial, doesn't matter.) On my system, I used the usb cable, and it operates on virtual com6. Open up hyperterm (in windows) and tell it to use com6 at 460800 8 n 1 no flow control. (keep in mind this is a new high-speed modem)

connect to it, then type the followin:

ATS311?<enter>

You should see output like the following:

That output specifies the latitude and longitude of the closest pole-top trancievers, in this case, I have two close to me (within two blocks of my location.)

Now, it's not exact, and you have to be in a high density area (this is denver, colorado, one of their two current service areas) but it's accurate to within a block or two.

With the stumbler, that's something that would be cake to implement, i think. It'd be a good poor-man's gps system for those of us with cash to blow on used ricochet modems. Have stumbler average the coordinates of all the available poletops that respond, and bam, a pretty good idea of where you are.

I'm still looking for windows software that'll treat it as a gps reciever, considering how simple it is to grab coordinates and how long ricochet has been around, I'm surprised there hasn't been something made already. Hope to see support for it in the stumbler soon, at least.