Page 6 of 13 FirstFirst 12345678910111213 LastLast
Results 51 to 60 of 122

Thread: bluetooth woes

  1. #51
    Low Bitrate
    Join Date
    Sep 2005
    Posts
    82
    Quote Originally Posted by Zimans View Post
    It seems that 1.5 adds more status type of information. For example, roaming/not roaming, signal strength, battery level, etc. However, I believe you can get alot of this information through the serial port, or may be able to atleast. There are at commands to retrieve this. 1.5 also provides a mechanism to retrieve current cell carrier.

    1.5 has more options in the CIND response, so make sure you parse it properly (No assumptions :P)

    The basic call control seems to be un-changed.

    --Zims
    Well, I'm confused here. My phone reports handsfree version 0x0101 in it's SDP record. So it's not 1.0 and it's not 1.5, I assume they mean 1.1, but I can't find a spec for version 1.1 anywhere, only 1.0 and 1.5. And my phone does give me it's signal strength through +CIEV messages. So I wonder if Motorola used a draft version of 1.5 or something when they made my phone. I'll have to check my wife's phone tonight.

    For now I will use the 1.5 spec and will be very careful in parsing. I have no idea how common 1.0 vs 1.5 profile versions are, so when this is done and working, we'll see if anybody is left out wrt the new indicator goodies, and go from there.

  2. #52
    Newbie Zimans's Avatar
    Join Date
    Jan 2006
    Posts
    38
    Quote Originally Posted by gentoocar View Post
    Well, I'm confused here. My phone reports handsfree version 0x0101 in it's SDP record. So it's not 1.0 and it's not 1.5, I assume they mean 1.1, but I can't find a spec for version 1.1 anywhere, only 1.0 and 1.5. And my phone does give me it's signal strength through +CIEV messages. So I wonder if Motorola used a draft version of 1.5 or something when they made my phone. I'll have to check my wife's phone tonight.

    For now I will use the 1.5 spec and will be very careful in parsing. I have no idea how common 1.0 vs 1.5 profile versions are, so when this is done and working, we'll see if anybody is left out wrt the new indicator goodies, and go from there.
    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
    --------------------------------------------------------------------------------
    Now, Where are my Pants?

  3. #53
    Low Bitrate
    Join Date
    Sep 2005
    Posts
    82
    Quote Originally Posted by Zimans View Post
    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

  4. #54
    Maximum Bitrate nasa's Avatar
    Join Date
    Aug 2006
    Location
    PA
    Posts
    721
    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

  5. #55
    Newbie
    Join Date
    Feb 2007
    Posts
    5
    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

  6. #56
    Low Bitrate
    Join Date
    Sep 2005
    Posts
    82
    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

  7. #57
    Low Bitrate
    Join Date
    Sep 2005
    Posts
    82
    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?

  8. #58
    Low Bitrate
    Join Date
    Sep 2005
    Posts
    82
    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?

  9. #59
    Newbie Zimans's Avatar
    Join Date
    Jan 2006
    Posts
    38
    Quote Originally Posted by gentoocar View Post
    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?
    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)

    Quote Originally Posted by gentoocar View Post
    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?
    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.

    --Zims
    --------------------------------------------------------------------------------
    Now, Where are my Pants?

  10. #60
    Low Bitrate
    Join Date
    Sep 2005
    Posts
    82
    Quote Originally Posted by Zimans View Post
    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

    Quote Originally Posted by Zimans View Post
    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.

Similar Threads

  1. Bluetooth woes!
    By daveg360 in forum Wireless Communications
    Replies: 1
    Last Post: 10-01-2005, 11:11 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •