Page 8 of 13 FirstFirst 12345678910111213 LastLast
Results 71 to 80 of 122

Thread: bluetooth woes

  1. #71
    Newbie
    Join Date
    Feb 2007
    Location
    NJ
    Posts
    7
    http://bluetooth-alsa.sourceforge.net has some good code for working with SCO links, the aim of the project is getting bluetooth headsets working through alsa, which is kind of the opposite of what we are trying to do, but they have some good sco libraries. It actually looks like some of the source in handsfree was taken directly from the btsco project.

  2. #72
    Constant Bitrate
    Join Date
    Jun 2006
    Location
    Chicago, IL
    Posts
    143
    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.
    EPIA TC 1G 256MB 60GB Linux,WindowMaker, Roadnav, Xine, XMMS, iGuidance3
    Lilliput 8", Pharos i360, WUSB11v2.6 WiFi

  3. #73
    Newbie
    Join Date
    Feb 2007
    Location
    NJ
    Posts
    7
    Quote Originally Posted by dupa2 View Post
    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.

  4. #74
    Maximum Bitrate
    Join Date
    Aug 2004
    Location
    at home
    Posts
    591
    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...

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

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

  7. #77
    Newbie
    Join Date
    Feb 2007
    Location
    NJ
    Posts
    7
    Quote Originally Posted by gentoocar View Post
    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.

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

  9. #79
    Newbie
    Join Date
    Mar 2007
    Posts
    18

    Unhappy

    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

  10. #80
    _
    Join Date
    Mar 2004
    Location
    Little Elm, Texas
    Posts
    13,500
    cyber - please see the following thread: What causes a post to be moderated?

    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.
    Jan Bennett
    FS: VW MKIV Bezel for 8" Lilliput - 95% Finished

    Please post on the forums! Chances are, someone else has or will have the same questions as you!

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
  •