bluetooth woes - Page 6

gentoocar · 03-01-2007, 02:08 PM

Quote: 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.

Quote: 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?

L2SHO · 03-01-2007, 04:56 PM

Quote: 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.

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

Quote: 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...

Quote: 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.

Quote: 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.

cyberwizzard · 03-18-2007, 08:02 PM

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

RedGTiVR6 · 03-18-2007, 09:45 PM

cyber - please see the following thread: http://www.mp3car.com/vbulletin/mp3car-forum-suggestions-comments/97914-what-causes-post-moderated.html

This is why your past 5 posts didn't show up.

Please be patient and one of the admins or mods will approve your post shortly.

gentoocar · 03-19-2007, 09:15 AM

Quote: Originally Posted by cyberwizzard

Is the SF project in a usuable state?

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

No, nothing usable yet. But I promise I am still working on it

I have been creating the JNI library as I go, that's part of what's taking so long... I hadn't used JNI (or C++ for that matter) in years, so I was a little out of practice. But it's all coming back now

Pretty soon I expect to have something up there you guys can download and play with. It won't have necessary features like audio or call management yet, but I'd like to make sure everybody can compile it and connect to their cell phones before starting on that stuff. I'll post here when that's ready.

cyberwizzard · 03-19-2007, 11:46 AM

Quote: Originally Posted by RedGTiVR6

cyber - please see the following thread: http://www.mp3car.com/vbulletin/showthread.php?t=97914

This is why your past 5 posts didn't show up.

Please be patient and one of the admins or mods will approve your post shortly.

Thanks

That explains a lot...

I've been hacking the handsfree application to skip the +CMER commands as they seem to screw the connection up: the second CMER command doesn't return a value so everything hangs after that. Skipping the CMER commands gives me ERROR results for every command after that which I find weird as CMER only sets event messages on or off right? (Also it should be 3,0,0,1,0 = 5 parameters but that didn't help either).

I can reach phase 7 by skipping CMER but then the application hangs with a SCO connect failure. I have the SCO module loaded so why is it failing? I'm running as root - maybe that screws something up?

If I could just play with it, I can work around the restrictions...

Big thumbs up for the project though! I'm lousy with c but this might be the time to dive into it and help out

Edit:
running strace on the program shows all kinda of stuff for the TCP stack getting opened (including /etc/hosts) and my guess is that it dies here:

Code:

write(4294967295, "POST /push HTTP/1.1\r\n", 21) = -1 EBADF (Bad file descriptor)
write(4294967295, "Content-Length: 210\r\n", 21) = -1 EBADF (Bad file descriptor)
write(4294967295, "\r\n", 2)            = -1 EBADF (Bad file descriptor)
write(4294967295, "<?xml version=\"1.0\" encoding=\"UT"..., 210) = -1 EBADF (Bad file descriptor)
write(4294967295, "\r\n", 2)            = -1 EBADF (Bad file descriptor)
read(4294967295, 0x7ffff28fc8e0, 800)   = -1 EBADF (Bad file descriptor)
close(4294967295)                       = -1 EBADF (Bad file descriptor)
socket(PF_BLUETOOTH, SOCK_SEQPACKET, 2) = 13
bind(13, {sa_family=AF_BLUETOOTH, sa_data="yP\20\335\t\0\0\0\0\0\r\0\0\0"}, 8) = 0
connect(13, {sa_family=AF_BLUETOOTH, sa_data="\364>\271\7\16\0\0\0\0\0\r\0\0\0"}, 8) = -1 ECONNREFUSED (Connection refused)
write(2, "connect: Connection refused\n", 28connect: Connection refused
) = 28
close(13)                               = 0
write(2, "Error: ", 7Error: )                  = 7
write(2, "Can\'t connect SCO audio channel "..., 51Can't connect SCO audio channel @ 00:0E:07:B9:3E:F4) = 51
write(2, "\n", 1
)                       = 1

So why doesn't it connect to.. errr... the AF_BLUETOOTH socket? (I guess?)

I tried running it all by hand the commands still give an error but +CMER does NOT kill the serial link so I don't understand why it does in the handsfree program - prolly bad coding?

Still leaves me with what cannot connect at the SCO layer? Does the program try to open a device node? Or a path to the phone? I don't really understand the call that fails so I can't figure out what goes wrong here...

On a different note: the SCO (voice) link, can I set that up by hand?

gentoocar · 03-19-2007, 07:40 PM

Quote: Originally Posted by cyberwizzard

I have the SCO module loaded so why is it failing? I'm running as root - maybe that screws something up?

I've been doing all my testing as root - I don't have any user accounts on my car computer

Quote: Originally Posted by cyberwizzard

running strace on the program shows all kinda of stuff for the TCP stack getting opened (including /etc/hosts) and my guess is that it dies here:

Code:

write(4294967295, "POST /push HTTP/1.1\r\n", 21) = -1 EBADF (Bad file descriptor)
write(4294967295, "Content-Length: 210\r\n", 21) = -1 EBADF (Bad file descriptor)
write(4294967295, "\r\n", 2)            = -1 EBADF (Bad file descriptor)
write(4294967295, "<?xml version=\"1.0\" encoding=\"UT"..., 210) = -1 EBADF (Bad file descriptor)
write(4294967295, "\r\n", 2)            = -1 EBADF (Bad file descriptor)
read(4294967295, 0x7ffff28fc8e0, 800)   = -1 EBADF (Bad file descriptor)
close(4294967295)                       = -1 EBADF (Bad file descriptor)
socket(PF_BLUETOOTH, SOCK_SEQPACKET, 2) = 13
bind(13, {sa_family=AF_BLUETOOTH, sa_data="yP\20\335\t\0\0\0\0\0\r\0\0\0"}, 8) = 0
connect(13, {sa_family=AF_BLUETOOTH, sa_data="\364>\271\7\16\0\0\0\0\0\r\0\0\0"}, 8) = -1 ECONNREFUSED (Connection refused)
write(2, "connect: Connection refused\n", 28connect: Connection refused
) = 28
close(13)                               = 0
write(2, "Error: ", 7Error: )                  = 7
write(2, "Can\'t connect SCO audio channel "..., 51Can't connect SCO audio channel @ 00:0E:07:B9:3E:F4) = 51
write(2, "\n", 1
)                       = 1

So why doesn't it connect to.. errr... the AF_BLUETOOTH socket? (I guess?)

Hmm, that seems odd. I can't imagine why it would be writing HTTP requests to anything. Does that definitely come from the same program?

The connection refused error... that sounds like a pairing issue maybe. Make sure you've already got the phone paired up.

Quote: Originally Posted by cyberwizzard

I tried running it all by hand the commands still give an error but +CMER does NOT kill the serial link so I don't understand why it does in the handsfree program - prolly bad coding?

Still leaves me with what cannot connect at the SCO layer? Does the program try to open a device node? Or a path to the phone? I don't really understand the call that fails so I can't figure out what goes wrong here...

On a different note: the SCO (voice) link, can I set that up by hand?

AFAIK you cannot set up a SCO link manually. But you should be able to get everything but audio running using rfcomm and minicom (typing everything by hand). One phone I tested with would drop the connection if you didn't enter all the required commands within a few seconds, so I could only connect them by copy & pasting really quickly

cyberwizzard · 03-19-2007, 08:00 PM

Already ran everything by hand it using minicom and channel 3 and it worked fine so I don't understand why the connection seems to stall.

For the http stuff: yeah - its the same program...

I can connect to the phone using an rfcomm channel so I figured I paired it already - am I wrong here? If so, how do I properly pair it?

And to be clear - what fails to open, a SCO socket? can it be that I am missing something in my system? I even tried installing btsco + kernel driver but that doesn't work either

cyberwizzard · 03-20-2007, 12:16 PM

Update:
Still no luck - it keeps failing with the connection refused...

On a side note: I'm running amd64 gentoo, perhaps the 64-bit stuff works different?

Edit: Update:
I finally managed to pair my phone with audio using the btsco tool - so at least SCO links work on my system... Now I'm pondering why the handsfree application won't run...

gentoocar · 03-24-2007, 09:48 AM

Quote: Originally Posted by cyberwizzard

I finally managed to pair my phone with audio using the btsco tool - so at least SCO links work on my system... Now I'm pondering why the handsfree application won't run...

I haven't tried btsco yet. That's to connect from the PC to a headset, correct? Great news that you got SCO working... that means it looks like AMD 64 is supported

I am still working on the new handsfree stuff in sourceforge... my latest headache is figuring out when a BT socket's close() is complete (it is asynchronous and can take like 10 seconds to close an RFCOMM link).

Edit: Damn, it takes almost 20 seconds to cancel a connect(). Anybody know how to change the timeout on a socket? 20 seems a little high to me.

Another edit: in case anybody is interested... it looks like cancelling a connect makes it actually finish connecting before closing it. That's a pain. Necessary to wait it out though, since Bluez (well, probably all Bluetooth adapters) only supports one connection per channel at a time. So if you try to connect to some address on channel 3, then close the connection, then try a different address on the same channel very soon after, the connect will fail. You need to set SO_LINGER on the socket, then close it (it will take a while to flush out anything pending) before you can use that channel again.

Zimans · 03-26-2007, 09:52 PM

Do you mean one connection per channel per device, or one connection period. Cause I can connect to two devices on the same channel at the same time.

--Zims

gentoocar · 03-28-2007, 09:32 AM

Quote: Originally Posted by Zimans

Do you mean one connection per channel per device, or one connection period. Cause I can connect to two devices on the same channel at the same time.

Looked to me like one connection per channel period. Here's what I read in a SF mailing list archive:

Quote:

You can not do this
while (0 > connect(s, (struct sockaddr *)&addr, sizeof(addr)))
if (errno != EBUSY) {
perror("connect");
return -1;
}

If connect returns EBUSY error you have to close() the socket. And it does
indeed return EBUSY in your case (I ran the progs) because close() is asynchronous
and that channel still exist (two connections on the same channel are not allowed
in RFCOMM). What you can do to avoid that error is to enable SO_LINGER option on that
socket, in which case close() will be synchronous.

I can't get to that thread anymore but the google cache is here:
SourceForge.net: bluez-devel

Of course, that was from 2003. So they may very well have added the capability for different devices connected on the same channel. But all I know is that when I close() the socket without SO_LINGER, and then try to make a new connection to the same phone, I get an error. I have not tried to a different phone though...... if indeed you can connect to a different phone while disconnecting from the first phone, that will have to be a version 2 feature

I just got a data cable for me phone so soon I can test whether newer firmware fixes the missing indicators I'm seeing.

Zimans · 03-28-2007, 09:55 AM

Sounds to me that you can only have one connection per channel per device. But connect to as many devices as you wish. (Well, up to the limits of bluetooth).

Why are you closing a connection and then trying to immediately re-open it?

--Zims

gentoocar · 03-28-2007, 07:39 PM

Quote: Originally Posted by Zimans

Sounds to me that you can only have one connection per channel per device. But connect to as many devices as you wish. (Well, up to the limits of bluetooth).

That sounds reasonable.

Quote: Originally Posted by Zimans

Why are you closing a connection and then trying to immediately re-open it?

I want to make sure this library always behaves predictably. I don't want somebody to try to connect to their phone, then hit cancel, then change their mind and hit connect again a few seconds later and have everything go up in smoke. I'd rather the API let them know when they can and can't connect.

So I now have the following states in my API: disconnected, trying, negotiating, connected, and disconnecting. Disconnected means we're completely free, and ready to make an inbound or outbound connection. Trying means we're trying to make an outbound connection. Negotiating means we're connected and trying to establish a service-level connection. Connected means we're completely connected and should be ready to make/receive calls. Disconnecting means we're closing the socket and waiting for that to finish.

All of the code to make and handle these rfcomm connections is in place, just needs some more debugging and tweaking. I'm very frustrated with this phone though. There is no new firmware for it. But mine is really buggy. I will try some of the other phones I have lying around.

Edit: it all runs flawlessly with the motorola

User Name		Remember Me?
Password