Searching \ for '[EE] Bluetooth headsets on computers...' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=bluetooth+headsets
Search entire site for: 'Bluetooth headsets on computers...'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Bluetooth headsets on computers...'
2010\01\13@024451 by William \Chops\ Westfield

face picon face
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...)

Thanks
BillW

2010\01\13@070052 by Peter

picon face
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
Bluetooth weaselspeak.

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
daemon.

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.

 Peter


2010\01\14@143026 by Vitaliy

face
flavicon
face
William "Chops" Westfield wrote:
{Quote hidden}

I don't have an answer to your main question, but wanted to comment on your
last paragraph. Blutooth dongles cost so little for two reasons: (1)
economies of scale and (2) PC is doing much of the work.

If you are interested I can give you a discount code for the Roving-based
adapter that we sell:

http://www.scantool.net/accessories/stm4100-low-profile-bluetooth-to-uart-module.html

It's cheaper than Sparkfun's.

Best regards,

Vitaliy

2010\01\14@213726 by Dr Skip

picon face
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.

-Skip



On 1/13/2010 2:44 AM, William "Chops" Westfield wrote:
{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 2010 , 2011 only
- Today
- New search...