Exact match. Not showing close matches.
'[EE] Bluetooth headsets on computers...'
William \Chops\ Westfield
I am wondering if a bluetooth headset (of the sort sold for cell phone
use) can be used as a sort of low-cost low-data-rate wireless
connection between a microcontroller and a desktop computer. My Mac
at least will happily detect such a headset and re-route audio to it,
which is a good sign, but I'm wondering if I can get more data to/from
the headset programatically:
1) Can a program use the bluetooth headset as an audio device without
making it the default audio input/output path? (how DO the various
popular operating systems deal with multiple audio devices anyway?)
My first thought was to implement some simple MODEM to send/receive
data sent on the audio stream.
2) What about the assorted buttons on most headsets? Can their status
be detected programatically on the desktop side? I guess this would
imply a need for access to bluetooth devices at a level a bit lower
than a simple "audio device."
(PC-side bluetooth dongle: <$10, cheap bluetooth headset: <$10.
Bluetooth "serial adapter": $55...)
William "Chops" Westfield <westfw <at> mac.com> writes:
> 1) Can a program use the bluetooth headset as an audio device without
> making it the default audio input/output path? (how DO the various
> popular operating systems deal with multiple audio devices anyway?)
> My first thought was to implement some simple MODEM to send/receive
> data sent on the audio stream.
> 2) What about the assorted buttons on most headsets? Can their status
> be detected programatically on the desktop side? I guess this would
> imply a need for access to bluetooth devices at a level a bit lower
> than a simple "audio device."
Bluetooth devices have 'classes' and usually each device belongs to one class,
but there are some which belong to several. The audio device class is different
from the 'media interface' class. Bluetooth classes are called profiles in
On unixish operating systems a bluetooth daemon handles the pairing with a
bluetooth device in range and then either handles by itself or spawns off the
various daemons which each handle one class (or profile) of attached bluetooth
device. When set up right (the bluetooth daemon and the associated bluetooth
sound handler daemon), then the new sound device appears as an ordinary sound
device and it can be selected and opened for output and for input (the input and
the output separately). Running some kind of tone sequence or fsk based control
software over this potential link is not impossible. The buttons are typically
handled by a 'media control handler' which is disjoint from the sound control
On windows, the bundled application that comes with the bluetooth device will do
all-in-one handling of the audio and buttons. I have little experience with
windows bluetooth programming but i know that they have no unixish device layer
equivalent and that extensive list walking and enumeration is needed to find the
relevant end points and that the registry is heavily involved in finding the
right bluetooth class/handler for an application. I won't go there.
The problem is that bluetooth devices are very often buggy partial
implementations of the protocols, and that standard drivers often cannot work
with the resulting 'bugs'. The net is full of descriptions of people whose
bluetooth headset / cell phone combination does not work and there are even more
descriptions of bluetooth devices which do not work with their windows pc. I
could add my own little chapter here, related to OBEX FTP and other nightmares
involving a certain popular Canadian cell phone maker and open source unix (not
that the windows version of things worked better). The general rule seems to be
that the things advertised on the box will mostly work with their driver on one
OS. Beyond that, all bets are off.
I have been looking into interfacing with the now well-hidden PC interfaces in
many ways, and bluetooth is likely not one of them. Lately I have been looking
hard at FT232RL chips which are available for under $3 and have interesting
bit-banged modes which allow a lot of interesting applications to be created,
with or without a microprocessor. They are, of course, not wireless.
|I don't have first-hand experience in the programming of one, but in setting up
a Blackberry it did indeed have bluetooth drivers for a modem, as well as audio
playback device and a number of other things. My impression was that there are
certain defined types of devices under bluetooth, which probably dictate the
various hooks a driver would use. The devices seem to be either a DCE or DTE
similar situation when actually connected in a particular connection, so there
should be pre-defined states each will be in depending on role.
For instance, a headset may not be defined to have a dialer, or the audio
stream only goes from 'base' to 'attachment' in a playback mode like
'headphones'. I did see that I could use the blackberry as a headphone with one
driver, and the PC as a speakerphone with another IIRC. Maybe not drivers per
se, but defined devices within the entire app-driver-whatever it installed. It
just had defined roles.
As such, since an earpiece will change the volume displayed on the phone, and
the PC seems capable of taking on almost any role from what I saw installed as
options, I would assume it would know everything normally known for the
respective role it is playing. One could test with an earpiece and dongle.
BTW, Broadcom makes the most popular (I'm told) drivers for PC bluetooth
outside of Microsoft, but at least in the Blackberry case, they were very
incompatible with whatever RIM wrote, and some tricks had to be played to force
it to use the Microsoft bluetooth stack. It probably isn't the only conflict
out there in the bluetooth world, so if something doesn't work, that might be
it as well.
On 1/13/2010 2:44 AM, William "Chops" Westfield wrote:
More... (looser matching)
- Last day of these posts
- In 2010
, 2011 only
- New search...