Thread: bluetooth woes

Originally Posted by dupa2

this is C/P from bluetooth specs (HFP1.5_SPEC):
---------------cut---------------------------
Synchronous Connection Interoperability Requirements
Synchronous connections may be realized by a SCO or by an eSCO logical transport. Only the support for SCO logical transports is mandated.
The remainder of this section relates to devices supporting eSCO logical transports. Here, “initiating” and “responding” refers to the initiating and responding (i.e. accept or reject) role in setting up the synchronous connection.
Table 5.6 defines eSCO configuration parameter sets S1, S2 and S3. HCI level parameters are given as a reference. On systems not incorporating HCI, values for LMP level eSCO parameters TeSCO, WeSCO and packet length shall be associated that correspond to these HCI parameters and fall into the mandatory parameter ranges for these packet types as given in the LMP specification, and the Voice Setting parameter translates into the air mode parameter of LMP.

Code:

eSCO parameter       S1    S2      S3
Packet type              EV3  2-EV3 2-EV3
Bandwidth               8000 8000  8000
Voice_Setting          CVSD CVSD CVSD
Max_Latency           7 ms   7 ms  10ms
Retrans_Effort         0x01  0x01  0x01

---------------------------------cut--------------------------

all 3 modes show CVSD format, that apparently is mandatory in SCO
at least I would concentrate on it.

If you need this document, I can post it (PDF), it explains all the communications required to set up HF.

That table is for eSCO links, not SCO links, and only SCO links are mandated by the handsfree spec. You can find all the audio specs for SCO in the "Core v2.0 + EDR.pdf" spec.

I've been successfull with a Motorola RAZR V3 on main functions, only the microphone was weak and on the other side people were hearing me like a bit far away from the phone, anyway it was working fine, including signal and battery levels with bluetooth libs corresponding to the mandriva 10.0 (i think but i don't remember exactely maybe 10.1 or 9.2 ?), since alsa merged inside the kernel everything simply collapsed and is not working anymore.
It was also able to display the called name when existing in the phonebook otherwise it was simply displaying caller number...
Now that the Bmw is offering a simple snap-in system for the RAZR V3, no more need to search in this way.

So ok, no code, only blah blah will you say but maybe it could give some directions to where or what search for...

Actually, after re-reading the HFP1.5 spec, is seems that CVSD is required. So I guess thats's that. We just have to make sure that when we set up our SCO link that it's set to transmit and recieve using CVSD.

Originally Posted by Zimans

This is a a phenomenon i've encountered before, and it just seemed to go away. What I suspected is happening is that a byte is getting lost somewhere. If you open the resultant raw file, but offset by 1 byte, it should play fine. I dunno if this was caused by not reading fast enough, not sending bytes regularly enough or what, but as my code became more stable and less of a hack it seemed to go away.

Hey I wonder if that's what the handsfree app was doing with the binning and the sco offset. From a quick glance through the code, it looks like he was checking whether the average audio data value was centered around some value, and then shifting all of the data by 1 byte if it wasn't. We might have to do something similar to ours. I don't know if his code worked or not since I could never get it to output any audio.

Originally Posted by Zimans

Now my problem is that audio will drop out after awhile. I can here the person on the other end, but they can no longer here me. I haven't taken the time to look into this yet, so dunno what is going on.

Haven't come across that one yet...


It's been a while since I had anything substantial to post, I've just been too busy to do any coding on this. But I've been thinking about it a lot, and I am really considering scrapping the idea of a background service, and instead thinking of a C or C++ library, since it doesn't make sense to have more than one app interact with the service, and you wouldn't want the service running without some way to control it, and also parsing the status text will be a pain for everyone.

Also, I like your idea of just reading responses as OK or ERROR (or the fancy mobile equipment error) and treating all of the other data the same as unsolicited responses. I think I'll steal that approach from you

Finally, it appears that there's a firmware update for my sony ericsson that affects bluetooth functionality. Maybe that will fix the lack of signal strength indicators. If that's the case then I will not worry about polling for that stuff. I'll have to grab a usb cable for my phone and try it.

this may be a dumb question, but what's the difference between SCO and eSCO? Is eSCO widely used? Did the handsfree app open a regular SCO connection? I don't have the code in front of me but I think the protocol constant it used didn't have that "e" in it. Also, the data that the handsfree app was outputting seemed to just be raw waveform data, since aplay could play it, right?

Originally Posted by gentoocar

this may be a dumb question, but what's the difference between SCO and eSCO? Is eSCO widely used? Did the handsfree app open a regular SCO connection? I don't have the code in front of me but I think the protocol constant it used didn't have that "e" in it. Also, the data that the handsfree app was outputting seemed to just be raw waveform data, since aplay could play it, right?

the e stands for extended or enhanced or something. It's optional in the HFP1.5 spec. The handsfree app used regular SCO links, which are a mandatory part of the HFP spec. I'm not even sure if BlueZ supports eSCO yet.

I'm still trying to figure out when you read() from the SCO file descriptor, it only reads 48 bytes. The Bluetooth spec specifies a packet length of 240 bytes for a SCO packet (including header information). I'm also not sure if BlueZ automatically strips off the header or not, I think it probably does. Also when you read from the SCO link, does it put the bits in the right order? I'm not very familiar with the in's and out's of Berkeley Sockets. I know the bluetooth spec says that it transmits the lowest order bits first. Also, I know when a SCO link is established, BlueZ has to negotiate things like audio encoding and such, I'm not sure where or how this is done or what the defaults are. I've been trying to dig through the bluez source, but it's slow going.

Originally Posted by L2SHO

the e stands for extended or enhanced or something. It's optional in the HFP1.5 spec. The handsfree app used regular SCO links, which are a mandatory part of the HFP spec. I'm not even sure if BlueZ supports eSCO yet.

Then I'll focus on plain ol' SCO for now...

Originally Posted by L2SHO

I'm still trying to figure out when you read() from the SCO file descriptor, it only reads 48 bytes. The Bluetooth spec specifies a packet length of 240 bytes for a SCO packet (including header information). I'm also not sure if BlueZ automatically strips off the header or not, I think it probably does.

Check this out:
http://netbsd.gw.com/cgi-bin/man-cgi...NetBSD-current
Read the "Caveats" section, it explains where the 48 bytes comes from. It's for netBSD but I assume it applies to us too.

Originally Posted by L2SHO

Also when you read from the SCO link, does it put the bits in the right order? I'm not very familiar with the in's and out's of Berkeley Sockets. I know the bluetooth spec says that it transmits the lowest order bits first. Also, I know when a SCO link is established, BlueZ has to negotiate things like audio encoding and such, I'm not sure where or how this is done or what the defaults are. I've been trying to dig through the bluez source, but it's slow going.

While you're digging through the source, let me know if you see any place where Bluez is buffering the audio. I'd still like to know why I've been getting such a high latency compared to my real bluetooth headset.


By the way, I will be setting up a sourceforge project today or tomorrow.

Project will be called "Bluehands". I think it'll probably have a libbluehands, a jlibbluehands (JNI bindings), maybe a javabluehands app or an xbluehands app... maybe some day somebody could write a gluehands or a kluehands I submitted a sourceforge application, so I should be able to start uploading code in a day or two.

Thank god! I was affraid i was the only looney on the planet trying to hook up my phone to my computer

I'm running into trouble with the handsfree app:

Code:

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

boo.
sending.cmd AT+CIND=?
>>
OK

sending.cmd AT+CIND?
>>
+CIND: ("battchg",(0-5)),("signal",(0-5)),("batterywarning",(0-1)),("chargerconnected",(0-1)),("service",(0-1)),("sounder",(0-1)),("message",(0-1)),("call",(0-1)),("roam",(0-1)),("callsetup",(0-3))

>>
OK

sending.cmd AT+CMER=3,0,0,1
>>
OK

sending.cmd AT+CMER=3,0,0,1

And then it hangs Right now I'm trying to figure out why the CMER command is repeated... Any clues what to do? Is the SF project in a usuable state?

Btw I'd like to vote to get a JNI interface