Hi!
I'm wondering about how BT headsets and mobile phones usually work
together, in hope of implementing automatic connection in btsco.
Normally, it seems that a mobile phone and a headset manage to keep
their link, even across "reboots" and other disconnections. Does a phone
periodically scan for headsets that it knows, or does the headset
somehow try to automatically reconnect to the phone under certain
circumstances, or is it something completely different?
Can anyone tell me where to find info on this?
Fredrik Tolf
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, 2005-08-16 at 12:20 -0600, Brad Midgley wrote:
> Fredrik,
>
> You can get pdfs from bluetooth.org. The relevant ones are 6_headset.pdf
> and "HFP Spec Version 1_0.pdf"
>
> Most headsets attempt to make the rfcomm connection to the last-used
> handset (or only handset if they only keep one pairing) on power-up. The
> stereo headsets tend to wait until the first click of the answer button.
Indeed -- I tried clicking the button on my headset, and judging from
hcidump, it attempts to connect to my computer (although I have a mono
headset, not a stereo). After that, however, weirdness occurs.
Looking at the data from hcidump, the headset requests a connection, and
the computer replies with a success message. The next package, the
headset disconnects again immediately (and the computer acknowledges
that). Then the headset connects again, and disconnects again, over and
over.
> I don't think we are doing the device class or sdp stuff to even make
> the headset aware that it can make this connection. On top of that, we
> need to be listening for connections.
Indeed, I'm not even attempting to public SDP data to the headset at
this point, but if that were the problem, I would think that the headset
wouldn't even attempt to connect to begin with, rather than going into a
loop of connecting and disconnecting all the time, right?
Does anyone have any idea what the cause of this could be?
Fredrik Tolf
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Technical details:
hciconfig -a
hci0: Type: USB
BD Address: 00:10:60:AA:AA:AA ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING=20
RX bytes:1577 acl:40 sco:0 events:126 errors:0
TX bytes:1201 acl:32 sco:0 commands:55 errors:0
Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3=20
Link policy: RSWITCH HOLD SNIFF PARK=20
Link mode: SLAVE ACCEPT=20
Name: 'Debian-Note'
Class: 0x3e0100
Service Classes: Networking, Rendering, Capturing
Device Class: Computer, Uncategorized
HCI Ver: 1.1 (0x1) HCI Rev: 0x460 LMP Ver: 1.1 (0x1) LMP Subver: =
0x460
Manufacturer: Cambridge Silicon Radio (10)
# aplay -l=20
**** List of PLAYBACK Hardware Devices ****
card 0: I82801CAICH3 [Intel 82801CA-ICH3], device 0: Intel ICH [Intel 828=
01CA-ICH3]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Modem [Intel 82801CA-ICH3 Modem], device 0: Intel ICH - Modem [In=
tel 82801CA-ICH3 Modem - Modem]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: Headset [BT Headset], device 0: Bluetooth SCO PCM [BT SCO PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
# btsco -v 00:03:89:AA:AA:AA
btsco v0.4c
Device is 2:0
Voice setting: 0x0060
RFCOMM channel 1 connected
[After run aplay]
speaker volume: 15 mic volume: 1
i/o needed: connecting sco...
connected SCO channel
Done setting sco fd
recieved AT+VGS=3D07
Sending up speaker change 7
[after I change volume manually]
recieved AT+VGS=3D08
Sending up speaker change 8
recieved AT+VGS=3D09
Sending up speaker change 9
recieved AT+VGS=3D11
Sending up speaker change 11
recieved AT+VGS=3D15
Sending up speaker change 15
All seems ok, but I don=B4t have any sound in speaker of HS.
Notebook=B4s sound works great with xmms (alsa config), aplay, ausamixer=20
works fine too.=20
Any hints?=20
Thanks for your time and attention,
./nelson -murilo
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fredrik,
You can get pdfs from bluetooth.org. The relevant ones are 6_headset.pdf
and "HFP Spec Version 1_0.pdf"
Most headsets attempt to make the rfcomm connection to the last-used
handset (or only handset if they only keep one pairing) on power-up. The
stereo headsets tend to wait until the first click of the answer button.
I don't think we are doing the device class or sdp stuff to even make
the headset aware that it can make this connection. On top of that, we
need to be listening for connections.
a2recv listens for connections, but it may not be the clearest example.
the way a2recv gets run is like this:
# add a2dp to the class bitmap (I don't know which bit(s) it is)
hciconfig hci0 class 0x200404
# advertise through sdp
sdptool add A2SNK
./a2recv
The way sdptool gets invoked there, A2SNK is advertised on the standard
channel. You could also add --channel to change that.
Brad
Fredrik Tolf wrote:
> Hi!
>
> I'm wondering about how BT headsets and mobile phones usually work
> together, in hope of implementing automatic connection in btsco.
>
> Normally, it seems that a mobile phone and a headset manage to keep
> their link, even across "reboots" and other disconnections. Does a phone
> periodically scan for headsets that it knows, or does the headset
> somehow try to automatically reconnect to the phone under certain
> circumstances, or is it something completely different?
>
> Can anyone tell me where to find info on this?
>
> Fredrik Tolf
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel