Thread: bluetooth woes

Originally Posted by Zimans

1.0 and 1.1 seem to essentially be synonymous. If you look in the spec sheet that i posted, it says 1.0, but in the section for the spd records it shows 0x0101 or 1.1.

--Zims

Ok, I see it now. So I guess I have 1.0, but motorola included the signal strength indicator as a goody... I won't complain. But I see that I don't have the battery status indicator. Not that the battery status is accurate in these damn motos anyway

Finally got around to trying to get this to work,

So I was following TimeKillers steps in post #4, when I can across this command "./handsfree". What program/package is being compiled to get this? I don't see it in the bluez-utils package (using debian).

Thanks

Nasa

It's has been replaced by the bluetooth[-dev] package - on Ubuntu anyway.

You may also need to create/copy an older linux/config.h file to your current kernel headers as I think the source requires it, and it has now been depreciated for linux/autoconf.h

ok well I've completed the +BRSF, +CIEV, and +CIND parsers (in great depth, lots of error checking). I'm adding methods to retrieve the signal strength, battery, etc. Next will be call management (ringing, pickup, hangup, dial, etc), and then finally SCO audio.

It's slow progress, but it's coming along.

BTW I checked my wife's phone and she has 1.0/1.1 but it gives battery charge status as an indicator. I will be getting a new phone on tuesday (a sony ericsson, my motorola won hold a charge) so that will be one more phone I get to test with.

Alex

Got a little problem...

Some of the phone responses are two lines. For example, after sending AT+CIND=? the phone sends back a +CIND line, and then an OK line.

My motorola would send back everything at once (i.e. "+CIND....\r\nOK\r\n"). My new ericsson, however, sends the +CIND line, then later on sends the OK line (need two separate reads). So I suppose instead of splitting the response into lines and reading all of them I have to loop and keep reading until I get an OK or an ERROR.

The thing I wonder is can I be sure that I will get the whole line in one read? Is it possible that I could get half a line in one read, and then a moment later get the other half of the line? Or is it all buffered for me at a lower protocol level so that I don't need to worry about that?

some sony ericsson goodies:

I have the following extra indicators that I did not see in the spec anywhere:
"batterywarning", "chargerconnected", "sounder", and "message". Each of these is a boolean (0-1). I assume "message" means there is a new SMS message (since there is already a "voice mail" indicator). I have no idea what "sounder" means. Anyways, I will add support for "batterywarning" and "chargerconnected" since they are easy. I'll try to figure out what the other ones do.

Unfortunately, although my phone reports all these indicators as supported and even gives me their values when I do "AT+CIND?", it does NOT send me +CIEV messages. I did "AT+CMER=3,0,0,1" and it sends me back "OK", but still doesn't give me +CIEV's. Both the moto and the LG I tested with do.

Anyone have any idea why that is?

Originally Posted by Zimans

You should buffer. Most likely you will get at least one line all at once, but buffering is the safe way to handle it.

The way I handle response codes is I basically look for OK or ERROR before continuing onto the next command. + codes are handled seperate (As they are un-solicited). At some point I'm going to change the code to move to a command stack vs States. (Thus reducing the number of states that I have)

Yup. Although + codes have an OK or ERROR if they are responses, just to be confusing

Originally Posted by Zimans

Do you mean that when you start a call or the phone rings it doesn't send +CIEV ?, or do you mean that it doesn't send any +CIEV messages after you send other commands? It should only send +CIEV's when states change, such as the phone starts to ring, or service is lost, etc.

OK, after a little more testing I see that I DO get +CIEV's for call, callsetup, sounder, and message, but NOT for battchg or signal (I left my phone connected overnight so that the battery state did change from 5 to 4, but no CIEV for it).

I would think that if the phone says it supports certain indicators (and gives you the correct values when you send an AT+CIND?) that it would send you CIEV's for them. I suppose a crude hack for this would be to poll for signal strength and battery every second or so, and as soon as I receive a CIEV for them then stop polling. Or I could look into getting that info from a different profile (but are all phones that support handsfree guaranteed to provide a dial-up networking or generic serial port profile?) And what bugs me is that I have no way of knowing programatically which phones have busted signal indicators and which don't, so I guess I'd want to do that for everyone.