Raw NMEA/serial data port request.

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by tz2026 on 22 Jan 2011 at 12:53

• Merged into: #112

[GoogleCodeExporter]

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)

Original comment by matthias.ringwald@gmail.com on 22 Jan 2011 at 2:53

• Changed state: Duplicate

[GoogleCodeExporter]

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.

Original comment by tz2026 on 22 Jan 2011 at 3:29

[GoogleCodeExporter]

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.

Original comment by tz2026 on 23 Jan 2011 at 4:47

[GoogleCodeExporter]

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.

Original comment by matthias.ringwald@gmail.com on 24 Jan 2011 at 8:04

[GoogleCodeExporter]

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.

Original comment by tz2026 on 24 Jan 2011 at 3:02

[GoogleCodeExporter]

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.

Original comment by matthias.ringwald@gmail.com on 25 Jan 2011 at 10:39

[GoogleCodeExporter]

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.

Original comment by tz2026 on 25 Jan 2011 at 10:59

[GoogleCodeExporter]

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.

Original comment by matthias.ringwald@gmail.com on 26 Jan 2011 at 10:01

[GoogleCodeExporter]

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?

Original comment by tz2026 on 26 Jan 2011 at 3:25

[GoogleCodeExporter]

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)

Original comment by matthias.ringwald@gmail.com on 29 Jan 2011 at 10:39

[GoogleCodeExporter]

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.

Original comment by tz2026 on 29 Jan 2011 at 12:34