I am the author of minigpsd on github which has a web based GPS monitor (the satellite circle, status, moving google maps using HTML canvas) which also creates a log as a KMZ file. I could port it to the iOS devices, but I would need a source for the raw NMEA (hopefully with any other data in the serial stream, private GPS or even interstitial metadata since I have other projects that geotag).

All I would need is a TCP or UDP port that when connected I would see the bytes coming from the bluetooth GPS. Even if only the registered version.

Interesting. Would you need TCP/UDP to access it over the network or is local access via Unix Sockets (I'm using them a lot and they are portable and efficient)

I can use UNIX sockets as well, the only consideration is I could leave the unit elsewhere and grab the GPS data remotely, but if I really want to do that I can use socat, and minigpsd will by itself echo the data and I could use the webpages remotely anyway.

A named pipe somewhere obvious would work, probably as well or better.

While I'm begging, if you can do the sockets, it would really help to have a BTSerial program that would only do the BT to sockets, but do multiples, e.g. create /tmp/btserial as a directory, and add a named pipe (maybe from the BT address) for each device that gets connected. That would allow my Arduino, OBD-2, and other devices to be accessible. Just a connect and disconnect.

That's certainly not the problem of BTstack /GPS/ :) Also, in my opinion, RFCOMM itself and the idea of virtual Bluetooth serial ports is just wrong. See my rant on the RFCOMM Wiki page.

I saw the rant and agree with it in substance. But low power inexpensive wireless comm modules for devices are all bluetooth rfcomm UART unless you know of something else (and please tell me!). That is all most GPS units are, a chipset with UART out connected to a uart serial to bluetooth module - I'm just connecting the module part to other things. The iPod doesn't do zigbee or nordic, and things like the WiFly are expensive and don't do mDNS/upnp/bonjour.

two parts: 1. part there are options to not use RFCOMM on the device: a) run BTstack on the embedded device. I've got a MSP430 dev kit here and hope to show a full version of BTstack on it in a few months. b) there are Bluetooth chips that provide other profiles via basic interfaces. e.g. http://www.bluegiga.com/iWRAP_module_firmware and I've also seen one from STM 2. Virtual serial ports are wrong. If an app on the iPhone/iPod wants to use RFCOMM it should not open a fake serial port, but rather talk to the other RFCOMM device via a Bluetooth lib/driver.

Thanks for the suggestions - I might try the lib/driver rfcomm access (I'll have to work through the example). I'm not sure about the other profiles - I just need to do bytes across and most are focused for particular applicatons. Maybe I'm thinking SPP but saying rfcomm. AVR microcontrollers are a bit underpowered for a full BT stack - the one I want to use for grabbing a pulse train has only 2-4k. Going larger, I have some small ARM boards that I can run Linux with Bluez. But the MSP version sounds interesting since it seems to be halfway between the two solutions (I have a few other dev boards but haven't done a lot with them). Thanks again.

SPP Profile = RFCOMM + Serial Port descriptor in SDP

For custom stuff, L2CAP channels are perfect to send/receive messages. If those messages look like input data, HID provides a generic way to describe whatever input device you can come up.

Also, AVRs are good/big enough. I've worked on the http://btnode.ethz.ch with an ATmega128 although this node had 256 KB RAM. I'm confident that BTstack would run on an ATmega128 without external memory (128 KB ROM/4 KB RAM) and there's the 1280 with 8 KB RAM, too.

I pulled the build tree and I am very impressed - lightweight but complete, and the examples are short but work well. I would still need the raw NMEA out when using BTGPS but I can easily integrate what I need for the other stuff. I guess I was just afraid it would be complex or messy and it turned out to be (at least with the examples) clear and straightforward. I will definitely have to look at it under linux.

I usually use 328 (32k rom) and below but have an arduino mega. Are there some BT chipsets or modules you can recommend that are easy to interface to microcontrollers?

While it's trivial to buy a USB Bluetooth dongle, buying a Bluetooth module with a serial HCI interface isn't so easy. What I've seen, they all follow the HCI H4 Transport standard and just have a regular UART interface with hardware handshake + power. The ones from bluegiga.com seem nice, and as I pointed out can be ordered also with a complete set of built-in Bluetooth profiles. Didn't see others doing that. (CSR have that too, but I never figured out how I could buy one)

If the module does the bluetooth profiles internally, then why do I need your stack? The original thing was to replace the SPP/RFCOMM with something on the Arduino and maybe to do other profiles. Also, the bluegiga (the one I can find at least) is twice the price of the simple serial modules, and I can find roving networks RN 41 and 42, but I can't find the -h that can do H4 anywhere.

And I posted a comment but haven't checked for a reply about the svn and linux. When I do the bootstrap/configure it wants to build dylibs, not sos.