SparkFun Forums

[tetsujin]

Hi there. I am trying to work out how to incorporate various Bluetooth features into some projects of mine, and I was hoping someone here might be able to help me out with some basic information. I have been trying various searches, and I've found some useful information but not quite everything I need. I understand it's possible that there may just be no one here who has these particular answers...

First, the basic capabilities I'm after:I'd like to be able to implement an HID device, device and service discovery, and maybe some handset features and object exchange. I don't expect to be able to do all these different things at once, of course. Basically I want to build a small device that can do a few handy things with Bluetooth, either controlling computers with BT capabilities, or receiving information pushed out by previously-paired devices.

Now, my understanding of modules like the RN-41 (or RN-42) is that they're capable of some of these things but not necessarily set up for it. I'm not real clear on the limitations of the Real Networks modules, honestly. They're apparently set up, by default, for "cable replacement" - providing a serial link with minimal effort. And they have the SPP (serial port profile) built-in. My understanding is that these modules could also be used for other profiles, such as HID but that this would require either alternate firmware for the module itself, or else a more extensive BT stack on the host controller... (And likewise for HCI profile which - I'm not fully versed in Bluetooth but I guess it's important for playing certain "host" roles in the communications??) I'm not really sure what the limitations of the module are.

I don't really know what other hardware one would use to add Bluetooth to a project apart from either a module like the RN-41, or a USB Bluetooth dongle on something with USB host capabilities. So from my perspective a USB dongle is "the other option" - I know there must be other options for adding Bluetooth to a project - less specialized than the modules, built for interfacing with a CPU that has a Bluetooth stack in software... Maybe someone can help me identify what those options would be...

Anyway, so "the other option" is to have a microcontroller that can act as a USB host and connect it to a USB Bluetooth dongle. This seems a bit needlessly complicated (i.e. having to write a USB host stack in addition to whatever Bluetooth stack and so on) but it is nevertheless an option... And apparently a very cheap way to get the BT hardware itself. I did see this project already - in which PS3 and Wii controllers are to be interfaced to Arduino via a USB host shield and (eventually) a USB Bluetooth dongle...

I'll have to hope that someone will correct me if I'm wrong here, but my understanding of Bluetooth USB modules is that they tend to be rather minimalist in design and (here's the important bit) the hardware is independent of any device profile, so the behavior of the host computer on the wireless network is almost entirely dictated by bluetooth software on the host computer... And that, therefore, creating an HID device with this hardware would be a possibility... So if I'm ready to rock the software needed to do this thing, this would seem like the way to go. But having to make the device a USB host just to make that happen is kind of unappealing... I'd like to avoid that if I can...

[ribbotson]

The most capable modules I have found are the Bluegiga with iWrap4. Take a look at their website and read the specifications carefully to see if they might meet your needs. Ask questions here, there are some experts on these, or at the bluegiga forum.

Some module can be configured to HCI mode for more flexibility with a different serial protocol, but you are probably better going to USB instead.

If you want to make your own with a USB dongle, three possible routes are:
1) USB Host and Arduino. You re right, I have not updated the blog on circuits@home for a while, but can share the bluetooth code with you. It is only HID at present.
2) LUFA has bluetooth support, and works well on AT90USBKey or similar hardware. Serial is provided, and I have HID working on it.
3) There is a new propeller object which I have tried ,which has serial and HID support on bluetooth, also SDP.

USB stacks are coming to be pretty common and easy to use for micros with USB Host or otg capability (AT90USB, PIC32, AVR32, ARM,...)

Maybe a combination of these ? Also code from lwbt and linux give good examples.

[tetsujin]

The most capable modules I have found are the Bluegiga with iWrap4. Take a look at their website and read the specifications carefully to see if they might meet your needs.

OK, let's say I'm starting with a single-function device - a Bluetooth Keyboard.
First question: My understanding is that this requires use of the HID profile, and that therefore modules set up for easy use of SPI profile won't be suitable. Is this correct?
Second question: An HCI-only module would be able to do the job, right? I would just need to program a microcontroller with a BT stack to control everything?
Third question: As before, but with a USB dongle - can a host connected to a USB dongle act as a Bluetooth keyboard?

Some module can be configured to HCI mode for more flexibility with a different serial protocol, but you are probably better going to USB instead.

Why is that? Wouldn't HCI mode get me everything that USB would? Have I misunderstood what HCI mode is and what it can do? I thought a USB BT module just provided HCI mode to the host computer...

If HCI works, then I may have found a module that's good for my needs: Bluegiga WT21. If I understand it correctly, it gives me basically what I'm after - all the hardware bits I need for Bluetooth comms, plus enough firmware to make it reasonably easy - and without having to use a USB connection...

[jmb]

(It's a while since I worked on BT for Symbian, so I'm hoping the grey cells have regurgitated this correctly...)

HCI isn't a Bluetooth Profile, or a stack component, it's the protocol used between the top of the lower (controller) layers of the stack and the upper (host) layers. SPI is also not a Profile - like USB or a UART, it's a physical interface (with its own protocol - more strictly a transport layer) which lets you talk HCI to the device.

If you use an HCI-only device, you'll have to implement all the parts of the host stack that you need - L2CAP, SDP for sure, plus your application-specific components. HID basically just uses L2CAP channels but you'd also have to implement everything in GAP (which defines all the basic inter-device interactions). If you really want to go that way, you could do worse than porting/customizing an OSS host stack - maybe BlueZ(the linux stack) or lwBT (the latter designed for low memory usage for embedded systems).

The BlueGiga / iWrap that ribbotson described gives you a sort of commandline interface (switchable to a packet-ized multiplexing interface) to a host stack they've implemented on-chip in the module. Have a look at the iWrap stack description and the more detailed datasheets linked from SparkFun's product page which should give you a good idea of what you'd be working with.

[edited to better describe GAP and HCI transports, and link to transports spec]