Can Bluetooth HID devices be connected to the Prop thru a module?
JRetSapDoog
Posts: 954
Hi, all. I'm investigating whether it's possible to connect Bluetooth human interface devices (HID), such as game pads, keyboards and mice (input devices), to the Propeller (or other microcontrollers) using some kind of "off-the-shelf" module (preferably already FCC tested and Bluetooth SIG qualified). In the desired application, the Propeller would act as a host or master, receiving input from the input devices. Also, at least for the present and for various reasons, I'd like to stay away from connecting to the Propeller/microcontroller through a USB (bit-banged or otherwise) connection. I guess the type of connection I need is something like the UART or I2C ones.
I've spent a few hours seaching the net but haven't really come up with much (I thought I'd find some examples, but haven't yet). And most of the Bluetooth-related threads I found here in the Parallax Forum pertain to using modules that support the serial port protocol (SPP), which doesn't appear applicable to what I'm looking to implement. So, I'd be interested in obtaining any links relating to interfacing a Bluetooth input device to a microcontroller (such as a Propeller or PIC), wherein the microcontoller was the master (it's a big web and I've only dipped my toe in it).
Online, I've seen some references to some Bluetooth modules supporting the HID protocol, but I'm not sure that they fit the bill. For example, SparkFun sells the Roving Networks RN-42-HID module, but it seems geared towards implementing an HID input device (which is cool, but the opposite of my current focus), rather than receiving input from them. Perhaps that module can go both ways. Does anyone know? That is, for a module supporting the HID protocol, is there a possibility that it can function as either master or slave, such that it could be configured to be on the receiving end of data sent from a Bluetooth input device (not the radio core used to implement such a device). I'm sure that would depend on the specific module, but any comments would be welcome.
Adding to the complexity, ultimately, I'd like to be able to pair-bond multiple input devices of the same type to the Propeller, though not more than 7 (which appears to be the upper limit for a master (not that any particular master can necessarily handle that many)). I wonder how such pair-bonding would work. I'm kind of assuming that HID devices have a fixed ID (perhaps the 48-bit ID I've read about, which I presume doesn't change), and I'm guessing that devices of the same kind have different ID's. Also, with regards to authentication, I think some modules have a fixed PIN code for authentication (such as 0000 or 1234). Anyway, I'm wondering if the Bluetooth module would store the bond relationships or if that would be handled by the microcontroller. And if it's done in the module (with some kind of non-volatile memory, perhaps), I wonder if such a module could handle more than one bond (pairing). I think authentication may be optional at times (though I'm not sure which end would determine that). For one input device, I even read that pairing was not required, but perhaps that source was referring to authentication, as I'd kind of think some kind of "channel" would need to be established (but maybe not). I also recall reading that there's legacy paring and a new form.
Oh well, at this point, I'd be happy to find out what it takes to get just one Bluetooth input device paired with the Prop, so don't let the multiple pair bonding complexity stop anyone from commenting. And all comments are welcome. Meanwhile, I'll keep searching. Although it's not my application (or intended input device), maybe someone has gotten something like a Nintendo Wiimote to connect to a microcontroller (in the past, I've read that it's been done for PC's, but they have operating systems that implements the HID protocol). On the other hand, perhaps it's the case that not much information is available since Bluetooth modules implementing the HID protocol are fairly new. Advance thanks for any comments and feel free to set me straight or be the bearer of bad news (Propellerites welcome news of the "impossible" with open arms). Oh, and I won't feel bad if I "hear the sound of crickets chirping in the night" (deafening silence) in response, considering the nature of this thread.
I've spent a few hours seaching the net but haven't really come up with much (I thought I'd find some examples, but haven't yet). And most of the Bluetooth-related threads I found here in the Parallax Forum pertain to using modules that support the serial port protocol (SPP), which doesn't appear applicable to what I'm looking to implement. So, I'd be interested in obtaining any links relating to interfacing a Bluetooth input device to a microcontroller (such as a Propeller or PIC), wherein the microcontoller was the master (it's a big web and I've only dipped my toe in it).
Online, I've seen some references to some Bluetooth modules supporting the HID protocol, but I'm not sure that they fit the bill. For example, SparkFun sells the Roving Networks RN-42-HID module, but it seems geared towards implementing an HID input device (which is cool, but the opposite of my current focus), rather than receiving input from them. Perhaps that module can go both ways. Does anyone know? That is, for a module supporting the HID protocol, is there a possibility that it can function as either master or slave, such that it could be configured to be on the receiving end of data sent from a Bluetooth input device (not the radio core used to implement such a device). I'm sure that would depend on the specific module, but any comments would be welcome.
Adding to the complexity, ultimately, I'd like to be able to pair-bond multiple input devices of the same type to the Propeller, though not more than 7 (which appears to be the upper limit for a master (not that any particular master can necessarily handle that many)). I wonder how such pair-bonding would work. I'm kind of assuming that HID devices have a fixed ID (perhaps the 48-bit ID I've read about, which I presume doesn't change), and I'm guessing that devices of the same kind have different ID's. Also, with regards to authentication, I think some modules have a fixed PIN code for authentication (such as 0000 or 1234). Anyway, I'm wondering if the Bluetooth module would store the bond relationships or if that would be handled by the microcontroller. And if it's done in the module (with some kind of non-volatile memory, perhaps), I wonder if such a module could handle more than one bond (pairing). I think authentication may be optional at times (though I'm not sure which end would determine that). For one input device, I even read that pairing was not required, but perhaps that source was referring to authentication, as I'd kind of think some kind of "channel" would need to be established (but maybe not). I also recall reading that there's legacy paring and a new form.
Oh well, at this point, I'd be happy to find out what it takes to get just one Bluetooth input device paired with the Prop, so don't let the multiple pair bonding complexity stop anyone from commenting. And all comments are welcome. Meanwhile, I'll keep searching. Although it's not my application (or intended input device), maybe someone has gotten something like a Nintendo Wiimote to connect to a microcontroller (in the past, I've read that it's been done for PC's, but they have operating systems that implements the HID protocol). On the other hand, perhaps it's the case that not much information is available since Bluetooth modules implementing the HID protocol are fairly new. Advance thanks for any comments and feel free to set me straight or be the bearer of bad news (Propellerites welcome news of the "impossible" with open arms). Oh, and I won't feel bad if I "hear the sound of crickets chirping in the night" (deafening silence) in response, considering the nature of this thread.
Comments
http://svn.navi.cx/misc/trunk/propeller/usb-host/
Jeff
I took a look at some of the Bluetooth-related Propeller files packaged together at the link you guys provided. I think that sheds some light on the questions I had. I believe that one of the files implements a so-called "KeyRing" to manage bondings, storing them in the propeller (and on eeprom), discarding the oldest bondings if the list is full (IIRC).
I think some of my questions about pairing and authentication above mixed some facts up. But in that I'm still muddy on the specifics, I won't elaborate. I did find a link detailing the pairing situation with regards to the Nintendo Wiimote (to a PC) that also helped. However, I do think that some of the details will depend on whether one is using a Bluetooth module (with the Bluetooth stack and some protocols implemented) or a Bluetooth dongle, as perhaps a dongle implements less, leaving some to USB and associated drivers to resolve (as the Bluetooth HID protocol apparently takes advantage of existing USB HID stuff, wrapper-like).
I haven't really looked into the USB files that handle the HID aspects yet, but at least I know where I could look into that, thanks to the link you've provided and the work of the gifted creator, Beth. I'm guessing such an approach would be even more applicable to the Prop 2, wherein a single cog should be able to handle the USB aspects, rather than three (plus another for Bluetooth) as on the current Prop.
Although those cheap dongles are great, I'd still kind of like to stay away from USB if possible, as USB adds yet another proprietary technology on top of Bluetooth. It's a real shame that proprietary technology (with its licensing/membership requirements) has become a de facto standard, compared to something really open. Anyway, I'll keep monitoring the situation and checking to see if the Bluetooth-to-UART modules implement the HID protocol in a way that can be used the way I mentioned.
At this stage, I'm just exploring, having modified some HID devices to communicate over infrared. I noticed that Chip even mentioned infrared in a Prop 2 thread he initiated, but no one took the "hook" apparently due to USB and BT being so ubiquitous and having range and signal path advantages over humble IR. Still, I like its simplicity of IR. Maybe Chip was talking about something more high-speed than lowly remote control protocols, perhaps something more on the order of IrDA. At any rate, it's a pity that there aren't more license-free options. That's life (and another thread), though.
Thanks again, Mike and Jeff...for pointing me in the direction of that link...giving me something more concrete to mull over. And if anyone hears of any new developments or related information, of course feel free to post. --Jim