Staticfree Blog

Back to the main blog

Wed, 28 Jan 2004

Socket Bluetooth GPS and some thoughts on Bluetooth

A new [borrowed] toy

We just got a few Socket Bluetooth GPS adapters in at the office the other day. This device meets my approval with its minimalist interface, while still remaining hackable enough to not suck. It has a place to feed it, a place to make it stronger (antenna), a switch to make it go, and three blinky lights to let you know what's going on inside its little black case. This is good. Except for the ability to replace the battery or perhaps change the Bluetooth pairing key, I can't think of anything else it'd need to meet my approval. I like this trend of devices: where they function on a basic level, do it well, and are flexible enough to meet a geek's approval.

I managed to make it go with both my Palm and my Linux-running laptop - a true trial of a device's compatibility. They both work Really Well with it, so much that they make me want to go get one right away.

In more technical terms, it's simple as well: you pair it with a device, establish a serial connection and it starts spitting out GPS coords in the standard NMEA format. I was able to successfully get it going in Linux with GPSDrive (and gpsd) and on my Palm with Mapopolis. I've been pondering a cheaper USB one for µ, but the novelty (and potential benefit) of being able to use it without a full-fledged computer is starting to win out cost. Walking down the street on my Palm, GPS in backpack, listening to OGGs playing off it is just too wonderful a thing.

Bluetooth doesn't suck!

Despite initial skepticism, I'm starting to like Bluetooth. Devices today seem to mostly play nice: I can go online using either my laptop or cellphone as PPP proxies from either my laptop or Palm without any trouble. (Well, not quite, but that's a known firmware bug on the cellphone.) I can send vCards and other contact information the like between any of the devices, I can place calls on the phone from the Palm - all in all, it actually works.

In my extensive playing around with the technology, I've come across a few usability bugs.

  1. Pairing - an obvious problem for devices, like the GPS, with no user input. The device really should have a user-configurable "pairing password", but most just have some arbitrary hard-coded value. Otherwise, anyone who's near you can pair with the device without your knowledge and potentially get at sensitive information. (Although GPS data is arguably not "sensitive" data)
  2. Detection - Bluetooth device detection seems to be flaky. Frequently, when I scan for nearby Bluetooth devices, one or more that should be shown are not. A second scan tends to correct that problem, but you shouldn't have to do that. Once device detection occurs, a way of seeing what the device can do (can it connect to the 'net and act as a modem? can it accept contacts? can it act as a fax sender?) called service discovery takes place. That frequently fails to give useful information (at least in Linux with Bluez).
  3. Too slow - I've already hit the limit of Bluetooth, hard. I've tried to go online with my cellphone, connect the phone to my laptop so the laptop can be online, then connect my palm to my laptop so I can use that connection. That totally hosed the Bluetooth. I'm not quite sure entirely what went wrong, but I have a feeling it has to do with sending/receiving so much data at once. I ended up getting less than 1KB/s on the Palm which is simply unacceptable.

Besides these complaints, I'm fond of the technology. I still can't get over how keen it is to have a bunch of boxes in various locations on my person (cell in cargo pants, GPS in backpack) and have them all work successfully. This is the wave of the future.

trackback enabled

Comments

Re: Socket Bluetooth GPS and some thoughts on Bluetooth

Peter @ Wed, 28 Jan 2004 09:42

My company makes Bluetooth barcode readers -- the very definition of "dumb" embedded devices and even *we* allow the users to select their own PIN.

Oh, and with the WIDCOMM or WinXP drivers on WindowsXP, I've never had any problems with service detection. Sad to hear that BlueZ is still not "there" yet.

And what you did in point #3 shouldn't have hosed your BT connection, although I have to ask why you didn't connect both the Palm and the Laptop to the phone directly

Re:

Steve @ Wed, 28 Jan 2004 10:00

Well, there's a slight difference between a device that passively reads environmental conditions (which GPS really is) vs. one that actively reads potentially valuable data. Still, it'd be nice to know that your personal network of devices is secure at all nodes. BTW: what's the company? That sounds like a nifty product.

I feel bad blaming BlueZ as it's probably the hardware itself. BlueZ just doesn't handle the errors as gracefully as it could (at least with the version I've got in Debian/testing 2.4.22). Don't tell me you've never had a problem where you have 5 bluetooth devices and one decides it didn't want to show up on the headcount...

I think I've figured out #3, though I need to check the BT specs. Both the cell and the palm were talking to the 'top on the same channel. Now, I don't quite know what a channel is in BT specs, but if the radio metaphor means anything, that'd probably be the source of the problem. I'll try connecting both to the phone directly, but I think the cell only allows one BT LAN connection.

Baracoda.us

Peter @ Wed, 28 Jan 2004 11:00

But Bluetooth uses frequency-hopping, the two devices should Never be on the same channel for more than a few microseconds.

Re:

Steve @ Wed, 28 Jan 2004 11:53

Right. By channel I mean logical channel. I just looked it up:

From Part D §2.1 of the Bluetooth Core specs:

CID assignment is relative to a particular device and a device can assign CIDs independently from other devices (unless it needs to use any of the reserved CIDs shown in the table below). Thus, even if the same CID value has been assigned to (remote) channel endpoints by several remote devices connected to a single local device, the local device can still uniquely associate each remote CID with a different device.

That's at the lowest level. A level above that establishes a Data Link Connection Identifier (DLCI) through the RFCOMM layer which provides the channels that I was reffering to. So yeah, it shouldn't be conflicting unless I was trying to establish a connection multiple times to the same RFCOMM channel from the same devices. I don't quite know what was up with that, I'll have to do more field tests.

I also found this gem. I can just imagine a geek wetting themselves thinking of the obvious power:

Bluetooth Core specs part E §2.7.1:

A UUID is a universally unique identifier that is guaranteed to be unique across all space and all time. UUIDs can be independently created in a distributed fashion. No central registry of assigned UUIDs is required. A UUID is a 128-bit value.

Any time you get to talk about uniqueness across all space and time in a protocol specification, you know you're on to something.

Huh

Opeth @ Wed, 28 Jan 2004 13:29

I recall seeing the pitch for this when I was working there, glad they got a prototype going already.

Re: Socket Bluetooth GPS and some thoughts on Bluetooth

MD @ Sun, 08 Feb 2004 18:11

I wish I understood any of this. Oh well.

Re:

Steve @ Tue, 10 Feb 2004 02:58

And it'd be keen to understand some of your medical ponderings. Oh, there's so much to learn!