Hello,
I am trying to create a feature using the WT32i with simultaneous SPP and HSP connections. The base use case of simultaneous connections works. Problems exist when I need to disconnect and reconnect the HSP while leaving the SPP connection intact. The disconnect/reconnect of the audio channel is a key element of this feature and is controlled by an external sensor input.
I am trying to understand how this would work. Per my understanding, the HSP connection is made up of two connections, 1 control channel (set up first) and 1 audio channel. When I want to disable audio I can:-
1) Either send the "CLOSE " command to disconnect the SCO or audio channel. Does this command also disconnect the control channel ? If it does not, will it be enough that I send the "BUTTON" command when I want to reconnect ? If the close command disconnects the control channel, we have to reissue "CALL" to connect it first and then "BUTTON" for the audio, right ?
2) Or disable HSP altogether. I have tried this and in my experience, to apply this, I need to send a "RESET" command after the "SET PROFILE HSP" command and that ends up dropping the SPP too which is undesirable. Does this sound right ?
I guess I don't yet understand the system level design for this behavior yet. How would you do this ?
Appreciate the help, thanks
K
Simultaneous SPP and HSP connection going using the WT32i.
Hello,
I am trying to create a feature using the WT32i with simultaneous SPP and HSP connections. The base use case of simultaneous connections works. Problems exist when I need to disconnect and reconnect the HSP while leaving the SPP connection intact. The disconnect/reconnect of the audio channel is a key element of this feature and is controlled by an external sensor input.
I am trying to understand how this would work. Per my understanding, the HSP connection is made up of two connections, 1 control channel (set up first) and 1 audio channel. When I want to disable audio I can:-
1) Either send the "CLOSE " command to disconnect the SCO or audio channel. Does this command also disconnect the control channel ? If it does not, will it be enough that I send the "BUTTON" command when I want to reconnect ? If the close command disconnects the control channel, we have to reissue "CALL" to connect it first and then "BUTTON" for the audio, right ?
2) Or disable HSP altogether. I have tried this and in my experience, to apply this, I need to send a "RESET" command after the "SET PROFILE HSP" command and that ends up dropping the SPP too which is undesirable. Does this sound right ?
I guess I don't yet understand the system level design for this behavior yet. How would you do this ?
Appreciate the help, thanks
K
Hello @kaustubh,
The "BUTTON" command is the correct way to do this. When HSP is enabled, this command will toggle the SCO audio channel on and off, leaving other connections (HSP control, SPP/RFCOMM, etc.) intact. It is not necessary or recommended to completely disable the profile; you are correct that a stack reset is necessary to do this.
Using the "CLOSE" command on the SCO link ID should basically do the same thing that "BUTTON" would when the connection is opened, and should not close the control channel. However, using "BUTTON" is preferred, since it is specifically designed to be used within the context of HSP for this exact purpose.
Hi @jrowberg,
Thank you for the speedy response ! I just realized something after reading your response.
The intent in disconnecting the audio link using that external sensor signal is to return the remote AG-gateway to a state where it can use its own mic and speaker. In other words, the remote gateway device; that my system becomes the headset for, has its own mic and speaker which it obviously does not use when we connect to it as a headset. If I let the control channel to stay connected, I am guessing that the remote device will still see this as a valid connection and will not be able to use its own resources.
Does this fit the bluetooth paradigm in your mind's eye ?
Would this mean that I have to disconnect both the audio and the control channels ? Is there any way to disconnect the control channel without issuing a RESET ?
K
Hi @kaustubh,
You can close the control channel easily with the CLOSE command if desired. However, audio resource usage on either side only matters if a SCO audio link is open. What exactly do you mean by "the remote device...will not be able to use its own resources"? How exactly are the mic and speaker on the gateway device intended to be used when not in a Bluetooth context?
When the SCO audio connection is not open, the audio interfaces provided by the module will be inactive.
@jrowberg
The Audio gateway is a motorola APX series, bluetooth capable, long range comms radio. It is a requirement to disconnect from those radios when we detect that we are not being an audio source so that they can be used for comms directly using its own push to talk feature for eg. You can imagine our product to be an intelligent headset that wants to disconnect if it sees no audio.
Thanks,
K
I was reading the Hands free and headset profiles iwrap app note dated 28 march 2014 version 1.8 and on page 34 it mentions that the only way to terminate the audio SCO connection is to use CLOSE. Does "terminate" mean something different vs your "on and off" ?
Hi @kaustubh,
I checked into this, and it appears that the use of BUTTON to actually toggle the SCO audio stream connectivity state was selectively enabled only in a few custom builds. In normal iWRAP builds, it is apparently only meant to be used to open the stream, while the CLOSE {link_id} command should be used to terminate the SCO audio connection, as you noted.
@jrowberg
Thank you for that confirmation ! One last question, is there any way to set the WT32i to not accept incoming rings from paired AG devices using the HSP profile ?
For example,
Thanks for all your help,
K
Hello @kaustubh,
You can use the SET BT PAGEMODE setting (page mode 0) to disable incoming calls altogether, but you cannot selectively block only HSP calls.
Separately, the AG should not believe that the call was dropped if the connection is closed cleanly with the CLOSE {link_id} command. The Bluetooth stack provides reason codes for link termination, and a lost link is different from a closed link. If the connection is being reattempted automatically even for a cleanly closed link, then the AG may not be configured correctly.