bluetooth woes

gentoocar · 02-02-2007, 01:26 PM

Hi everyone,

I want to make my linux PC emulate a handsfree kit, so that my phone will connect to it and I hear audio out of the car speakers. For some reason it's REALLY hard to find any information on doing this. Has anybody managed to do this yet? Here's what I have done so far:

- registered HF profile with sdptool
- set the device class to 0xff0408 with hciconfig
- dbus-send --system --dest=org.bluez /org/bluez/hci0 org.bluez.Adapter.SetMode string:discoverable (makes the PC discoverable)
- rfcomm listen hci0 6 (PC accepts connection on channel 6 (handsfree) and routes it to /dev/rfcomm0)

Now I can use my phone to search for handsfree devices, my PC shows up, I select it and try to connect, and it says "seeking PCNAME...." And after a few seconds rfcomm tells me it's connected. But the phone just sits there waiting. I'm sure I need to send some command over, but I can't find any specs anywhere.

I tried the ProjectBluezHandsfree (it's down now, gotta use the google cache) but that doesn't seem to help me. It makes the connection, but the phone still says seeking and never connects (it times out after a while).

Any thoughts? I can't run any of the kde stuff, this is a very minimal system with a stripped X server (no fonts, etc), so I want to do all this on the command line. I'm not afraid to code something up if I find some specs

Alex

timekiller · 02-02-2007, 04:48 PM

I have been looking for a handsfree linux app since i started on my carpc, and it is still on my wishlist. The bluez handsfree project looks promising, but is obviously still very early in developement. Best I have working is using my phone as a bluetooth DUN device.

I will be watching this project though!

ruzzmon · 02-04-2007, 12:57 AM

I've been trying to set up BlueZ for the HF profile as well and haven't succeeded yet. I don't use the dbus command, as I don't think I need it. Do you have a source that explains the need for that command? When I do 'Search for Bluetooth Devices' from my phone, I can find the computer, and it shows up as HF.

Are you sure you need rfcomm? I thought rfcomm was to setup file transfer and data transfer (DUN and FTP?).

So far, my phone will find the computer and successfully pair with it. But it will not 'connect'. Running 'hcitool cc [address of phone]' doesn't seem to work either. When I run 'hcitool con' its supposed to print out a list of currently connected devices, but my phone doesn't show up. If I run 'hcitool scan' it will print out my phone's Bluetooth address. Do either of you think I've misunderstood something here?

It also seems as Bluetooth development is very fluid on Linux, as I haven't been able to find any thorough documentation. Can you both list your resources? I've only used the manpages and random Google searches so far, but those may be incomplete as well. Maybe I should try to set up DUN and then go from there...

timekiller · 02-04-2007, 04:08 AM

ok, you guys got me curious enough to download the handsfree source and give it a whirl. Having successfully connected to my phone for bluetooth DUN, I figured it was worth a shot.

Here's what I did, and how far I got:

First off, I am running gentoo, and currently have bluez-utils-2.25-r1 installed - I tried compiling with and without dbus support - had no change in my results.

If you don't know your phone's bdaddr use hcitool to find it:
(make sure your phone is "discoverable")
> hcitool scan
Scanning ...
00:14:9A:19:75:22 Mazda3

Now use sdptool to find the channel for the handsfree gateway:
> sdptool browse 00:14:9A:19:75:22
Browsing 00:14:9A:19:75:22 ...
<snip>
Service Name: Handsfree Voice Gateway
Service RecHandle: 0x10002
Service Class ID List:
"Handfree Audio Gateway" (0x111f)
"Generic Audio" (0x1203)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 4
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Handsfree" (0x111e)
Version: 0x0101
</snip>

So for me, channel 4 is the handsfree gateway

Now run handsfree:
(first register the handsfree service)
>sdptool add hf
Handsfree service registered
>./handsfree 00:14:9A:19:75:22 4

You will be prompted on your phone to enter your pin. If you have not changed the default, it is either 0000 or 1234. I entered my pin which was verified and accepted.

At this point I received an error from handsfree:

Voice setting: 0x0060
RFCOMM channel connected
sending.cmd AT+BRSF=31
poll descriptors count 1
poll descriptors count 1
opening control pipe - set to stdin: No such file or directory
>>
ERROR

Error found in phase 0.
Error: 0.96 handsfree detected (or you are using the wrong channel!)
sending.cmd AT+CIND=?
>>
ERROR

Error found in phase 1.
>>
+MBAN: Copyright 2000-2004 Motorola, Inc.

But here is the good news: At this point, my phone believes it is connected to a handsfree set. I verified this by making a call and confirming no sound came out of the phone ear piece. So, my pc connected, the phone accteped the connection - now to find out what went wrong...

I straced the process, and found that handsfree was trying to open /tmp/ctrl - a pipe it uses for stdin:

write(1, "poll descriptors count 1\n", 25) = 25
write(1, "poll descriptors count 1\n", 25) = 25
open("/tmp/ctrl", O_RDWR) = -1 ENOENT (No such file or directory)
write(2, "opening control pipe - set to stdin: No such file or directory\n", 63) = 63
select(7, [0 6], NULL, NULL, {0, 1000000}) = 1 (in [6], left {0, 956000})
read(6, "\r\nERROR\r\n", 2048) = 9
write(2, ">>\r\nERROR\r\n\n", 12) = 12
write(2, "Error found in phase 0.\n", 24) = 24
write(2, "Error: ", 7) = 7

Looking through the code, I do not see anywhere the pipe is created. For giggles, I did a `mkfifo /tmp/ctrl` and ran handsfree again. This time I got the following output:

Voice setting: 0x0060
RFCOMM channel connected
sending.cmd AT+BRSF=31
poll descriptors count 1
poll descriptors count 1
>>
ERROR

Error found in phase 0.
Error: 0.96 handsfree detected (or you are using the wrong channel!)
sending.cmd AT+CIND=?
>>
ERROR

Error found in phase 1.
>>
+MBAN: Copyright 2000-2004 Motorola, Inc.

Still got an error, but the "no such file" is gone. strace showed the following:

write(1, "poll descriptors count 1\n", 25) = 25
write(1, "poll descriptors count 1\n", 25) = 25
open("/tmp/ctrl", O_RDWR) = 8
select(7, [6], NULL, NULL, {0, 1000000}) = 1 (in [6], left {0, 956000})
read(6, "\r\nERROR\r\n", 2048) = 9
write(2, ">>\r\nERROR\r\n\n", 12) = 12
write(2, "Error found in phase 0.\n", 24) = 24
write(2, "Error: ", 7) = 7

I looked at the code some more and determined that it dies when it requests the audio link:

wlen = writecmd(rd, "AT+BRSF=31\r"); // request audio link

This command is not making it to the phone, so the phone just stays in limbo - connected to the pc, but not sending anything.

I am not a programmer, so I do not know where to go from here. If anyone has any suggestions to debug, I'd be happy to try it

Hopefully this will help get someone a little closer!

gentoocar · 02-04-2007, 11:02 AM

OK I have made a bit of progress! First, let me explain the need for RFCOMM.

RFCOMM is like a serial link, where you can communicate using AT commands (like with old school modems). For a partial list of AT commands, google for "T39 Developer's Guide.pdf" - some of the commands are Ericsson T39-specific, but a lot are standard. So you can use the rfcomm program to connect to the DUN channel (for me that's channel 1), which will create /dev/rfcomm0. Open that with minicom and you should be able to enter some commands (ATDT 12345 will dial 12345).

Now, it seems that the headset/handsfree profiles first connect a RFCOMM channel, then talk back & forth with AT commands. This is the main control channel. It is how you answer/reject/hangup a call, and how you get notification of signal strength and whether somebody is calling you (and who). When audio is needed, somebody sends an AT command to open a SCO (audio) link. When the audio has been quiet for a few seconds, the link will close (to save battery life I guess).

Anyways, I could not get handsfree to work on it's own, but after hacking around in the code a bit I was able to get it to write audio to a pipe, and play that pipe, so I can now hear phone audio through my speakers. There is a good bit of lag though. I'm going to have to find my BT headset and compare lag with that.

The error about /tmp/ctrl is normal, you want to mkfifo /tmp/ctrl. Then you *should* be able to send commands like "echo a > /tmp/ctrl" to answer a call, but there are a lot of bugs in handsfree that prevent that (for me it doesn't get that command until after you hang up the call).

But those errors you get from the AT commands are not good. That means you have a good rfcomm link to the phone, but when you send the commands, instead of the phone responding with "OK" it responds with "ERROR" - the commands ARE getting to the phone, but the phone is saying it doesn't like them. The printout said something about maybe being on the wrong channel. I find I can connect on either 3 or 7 (if I remember correctly), but 7 gives me a high pitched squeal for audio. I think one's handsfree and one's headset, but they seem very similar. Anyways, 3 works for me.

The errors I get with the unmodified handsfree are about not being able to write to the sound card.

So I've sent the author an email asking if I could take over the project... hopefully he answers soon. I'd like to make a sourceforge site and get this thing going!

gentoocar · 02-04-2007, 11:10 AM

Quote: Originally Posted by ruzzmon

I've been trying to set up BlueZ for the HF profile as well and haven't succeeded yet. I don't use the dbus command, as I don't think I need it. Do you have a source that explains the need for that command? When I do 'Search for Bluetooth Devices' from my phone, I can find the computer, and it shows up as HF.

Good. if you can find your computer, you don't need that dbus command. It is just to turn on/off discovery of your PC. I guess your config file has discovery enabled by default.

Quote: Originally Posted by ruzzmon

Are you sure you need rfcomm? I thought rfcomm was to setup file transfer and data transfer (DUN and FTP?).

see my prev post

Quote: Originally Posted by ruzzmon

So far, my phone will find the computer and successfully pair with it. But it will not 'connect'. Running 'hcitool cc [address of phone]' doesn't seem to work either. When I run 'hcitool con' its supposed to print out a list of currently connected devices, but my phone doesn't show up. If I run 'hcitool scan' it will print out my phone's Bluetooth address. Do either of you think I've misunderstood something here?

hmm.
root@vaporless-MK1:~# hcitool cc 00:0A:28:89:4E:65
at this point the bluetooth icon on my phone comes on

root@vaporless-MK1:~# hcitool con
Connections:
< ACL 00:0A:28:89:4E:65 handle 12 state 1 lm MASTER
Is your phone already paired? I forget what I did to pair them, but I don't think you need them paired to make a simple connection like that (I don't think that even has an RFCOMM channel open or anything).

Do you get any errors? or just no result from hcitool?

Quote: Originally Posted by ruzzmon

It also seems as Bluetooth development is very fluid on Linux, as I haven't been able to find any thorough documentation. Can you both list your resources? I've only used the manpages and random Google searches so far, but those may be incomplete as well. Maybe I should try to set up DUN and then go from there...

I've basically just used random google searches as well as the handsfree homepage. This site also has howtos on pretty much everything EXCEPT for what we're trying to do: http://www.holtmann.org/linux/bluetooth/

gentoocar · 02-04-2007, 11:20 AM

Quote: Originally Posted by gentoocar

I find I can connect on either 3 or 7 (if I remember correctly), but 7 gives me a high pitched squeal for audio. I think one's handsfree and one's headset, but they seem very similar. Anyways, 3 works for me.

Scratch that, I have this:
Service Name: Voice Gateway
Service Description: Headset Audio Gateway
...
"RFCOMM" (0x0003)
Channel: 3

Service Name: Hands-Free voice gateway
Service Description: Hands-Free voice gateway
...
"RFCOMM" (0x0003)
Channel: 7

And I can use either channel 3 or 7. But no matter which channel I use, I sometimes get squealing distorted audio. If I disconnect and reconnect, it's fine. But man it's awful when your speakers are turned up!!

ruzzmon · 02-04-2007, 03:12 PM

Quote: Originally Posted by gentoocar

root@vaporless-MK1:~# hcitool cc 00:0A:28:89:4E:65
at this point the bluetooth icon on my phone comes on

root@vaporless-MK1:~# hcitool con
Connections:
< ACL 00:0A:28:89:4E:65 handle 12 state 1 lm MASTER
Is your phone already paired? I forget what I did to pair them, but I don't think you need them paired to make a simple connection like that (I don't think that even has an RFCOMM channel open or anything).

Do you get any errors? or just no result from hcitool?

Yes, phone is already paired, but Bluetooth icon on the phone doesn't light up like when connected to my headset. When I run 'hcitool cc [address]', hcitool returns nothing. I was beginning to think it might be my phone, a Samsung a-900, but it seems there's a few more things I need to do. I know for a fact I have not setup rfcomm, since I had assumed I didn't need that, but I see I am wrong. Maybe rfcomm is what maintains the connection, for the HF profile. I also was not aware of the channels and that specific channels were used for different protocols. Thanks, I'll report back when I try a few more things.

OLAS · 02-04-2007, 07:15 PM

Guys, just today I decided to get my linux machine working as a headset/handsfree device for a bluetooth phone and came across this thread as we've all got the same problem.

After a bit of playing about, I managed to get audio sent to my linux machine from a Motorola Razr phone.

I simply issued the command ./headset /path/to/any/file/here [phone address] 3

The message "Houston, we was connected! 8 8" appears then lots of .:!

The audio lasts for a couple of seconds then "lost sco audio connection!" and I'm thrown into a command line thing. Tried sending commands and some make the phone try to call my last number!

If I make any progress, I'll be sure to let you know.

gentoocar · 02-04-2007, 10:05 PM

OK, I think I might try to rewrite this thing. I'll have to dig out some of my old notes on linux programming though. So how would you guys want this to work? I think I'd want to be able to receive/send the audio streams from my frontend app (it's custom, and a work in progress), instead of having the handsfree prog talk directly to alsa. Of course, you could always run an instance of aplay and one of arecord to route the audio for you.

I was thinking of something like so:

Code:

audioOut  <-- |-----------|
audioIn   --> | handsfree | - - - rfcomm
cmdIn     --> |           | - - - sco
statusOut <-- |-----------|

Where the 4 things on the left side are pipes. audioIn and audioOut are self explanatory, cmdIn would be where you send commands to handsfree (answer, hangup, etc) and statusOut is where you get status (ringing, signal level, etc). Also, I was thinking instead of having to connect to your phone, you could connect FROM your phone, by having handsfree listen for the rfcomm instead of making it. Maybe handsfree could send something through statusOut when somebody tries to connect, and you can accept the connection through cmdIn?

Does this make sense to anybody else, or am I making this too complex?

OLAS · 02-05-2007, 12:00 AM

Made a little progress but nothing usable.

With

Code:

./handsfree [phone addr] 3

I always hear something and occasionally the audio is sent - I made a call and heard the no answer message.

After checking strace, I noticed the app. was trying to access /dev/snd/controlC* - 0 to 30, so I

Code:

mknod /dev/snd/controlC0 c 116 12;mknod /dev/snd/controlC1 c 116 12

With that, it worked for a while before the "Write to audio interface failed (Too many files)" error popped up.

This looked interesting; http://ubuntuforums.org/showthread.php?t=75978 but ultimately doesn't work, although the phone is recognised.

gentoocar, your idea looks good, however if we can work out why the app/sco drops after a few seconds and fix that, I don't think much more coding will need to be done. That said, making the app stable and adding extra features would be good!

Will keep bashing away at different configs and report back.

gentoocar · 02-05-2007, 11:58 AM

Quote: Originally Posted by OLAS

gentoocar, your idea looks good, however if we can work out why the app/sco drops after a few seconds and fix that, I don't think much more coding will need to be done. That said, making the app stable and adding extra features would be good!

The SCO link should drop out after a few seconds of silence, and come back up as soon as there is more audio (from the phone) (To save power?) I think also if there is audio from the pc it should come back up too, but I don't think there is anything in the code that will do that right now.

If you keep making noise with the phone (the mic will be shut off, so keep pressing buttons or make a call and talk into the other phone), the sco link should stay active as long as you're making noise.

I wish there were some way to disable that behavior. Maybe there's an AT command to do that?

Anyways, stability is what I'm after here. Handsfree won't do me any good if I have to restart things while driving!

Zimans · 02-05-2007, 12:24 PM

I wish I had seen this thread earlier.

I have written an app that connects to my cell as a hands-free device
and bridges it to my asterisk PBX. It's not finished, as it does have a
few bugs still with states, and when there is more than one phone
connected audio stops working, but it does work. I can pick up a phone
elsewhere in the house and the call goes out through my cell phone (I do
not have a POTS). As well as when a call comes in the phones in the
house ring.

When you scan the services on your phone you want the one that is "voice
gateway" or some such. On my phone that is channel 8. This rfcomm channel
only supports a subset of the at command set. This subset is laid out in
the Handsfree Profile doc. The doc is pretty straight forward. (As opposed to teh USB spec, wich I still haven't made sense of yet)

If you can find a program that simply listens for SCO connections
irregardless and sends/receives audio you could use that in conjunction
with another program that sends the at commands. SCO is channel-less. So
aside from BDADDR there is no way to know one connection from another.

I did not know that the bluez people had a handsfree program.

The documentation you are looking for to work on this is

http://bluetooth.com/NR/rdonlyres/94EAD32B-3E70-4AEC-9CD5-1E3F887A15F4/917/HFPSpecVersion1_0.pdf

I'll put together a tar-ball of my code. The program is designed to
connect to asterisk, and as I said above has a few quirks that I haven't
taken the time to fix. But hopefully it would be a good reference for
anyone trying to work on this. I'll post this soon.

I've actually been writing my own front-end for linux. But I haven't
gotten to the point of adding Handsfree support yet. (I intend to).

Edit: Link
biax-0.0.1.tar.bz2

--Nate

Zimans · 02-05-2007, 12:27 PM

Quote: Originally Posted by gentoocar

The SCO link should drop out after a few seconds of silence, and come back up as soon as there is more audio (from the phone) (To save power?) I think also if there is audio from the pc it should come back up too, but I don't think there is anything in the code that will do that right now.

If you keep making noise with the phone (the mic will be shut off, so keep pressing buttons or make a call and talk into the other phone), the sco link should stay active as long as you're making noise.

I wish there were some way to disable that behavior. Maybe there's an AT command to do that?

Anyways, stability is what I'm after here. Handsfree won't do me any good if I have to restart things while driving!

The Phone should not drop the SCO conection, audio or not. If you only have one device on your bluetooth link the phone will take over as master. When a call comes in, it will establish a SCO link to your client. If you have more than one device, your bt adapter will act as master, and then (i think) you will have to establish the sco connection to the phone.

--Zims

gentoocar · 02-05-2007, 02:05 PM

Hey, thanks for that info Zimans! Looks like I have some reading ahead of me.

Quote: Originally Posted by Zimans

The Phone should not drop the SCO conection, audio or not. If you only have one device on your bluetooth link the phone will take over as master. When a call comes in, it will establish a SCO link to your client. If you have more than one device, your bt adapter will act as master, and then (i think) you will have to establish the sco connection to the phone.

Well, if you have a cell and a BT headset, give this a try. Connect to the headset, then make some noise with the keypad (on my phone i can hit up&down to scroll through the phonebook. It makes a beep every time you press those buttons). Now let it sit for a few seconds in silence. Now press those buttons again. The beginning of the first tone should be chopped off, as it has dropped the SCO connection and had to re-connect it. Having the SCO connection active drains the battery faster. Imagine you have your phone in your pocket connected to your earpiece, and you're not on the phone. If it sits that way for hours, you don't need that SCO channel active. Once you make some noise, it will reactivate itself. I'm not sure, but I'm guessing that during an actual call it wouldn't do that.

Now, all of that is just what I've gathered from playing around and watching the SCO link drop and reconnect in response to silence/noise. I have yet to find any documentation that confirms that. But in any case, I don't think it will really be a problem.

User Name		Remember Me?
Password