- This topic has 0 replies, 2 voices, and was last updated 1 hour, 12 minutes ago by
.
-
-
I’m noticing an issue where if I have an active HFP connection with audio streaming from the source (s) device, to the headset (h), abruptly power cycle the headset device, sometimes when I restart the HFP connection it will ring and succeed to connect but no audio will be playing.
let me provide more details..
“`
IOT747 Copyright 2022
AudioAgent IDC777 V3.1.70
Build: 0400427b
“`Firstly, i’m following the example procedure in the IOT777 command manual for “Classic: Establishing a Call Between IDC777 and IDC777 (or Headset) – HFP and AGHFP”. i’ll attach a picture of this procedure for reference
After both dev kits are connected “call 13 answer” I can hear audio out of the headset device (GOOD).
At this point, i’m following this procedure:
1. instead of issuing “call 13 end”, i’m pulling power on the headset device and waiting until the source device receives ‘CLOSE_OK …’ to indicate that the connection is lost.2. on the source device, i’m issuing “DISCOVERABLE OFF” followed by “DISCOVERABLE ON”. for some reason this puts the device back into a ‘PAIR_PENDING’ state. i’m not sure if there is an eaiser way to do this?
3. plug power back into the headset device and wait for boot
4. on the source device issue: “open … aghfp” and wait for “OPEN_OK”.
5. on the source device issue “call 12 incoming”
6. on the headset device issue “call 13 answer”
at this point both devices will have rung successfully and connected “SCO_OPEN” (GOOD). However, SOMETIMES (~20%) of the time there will be no audio output on the headset device?? “STATUS” and “VOLUME” indicate that the connection is active and should be working. I can also issue a “TONE” command and that will work.
Note, I’ve done some testing and verified if I issue command “Call 13 end” BEFORE pulling power on the headset, when I reboot and reconnect it works 100% of the time (I think).
I need the device to be able to handle a power down event gracefully (without having to issue “Call 13 end”) such that when I power up again it will actually stream audio. Can you help me fix this issue?
Thank you!
-
1)
if i DON’T cycle the discoverable state, when I try send the following command ‘OPEN … AGHFP’, the source device will show ‘PENDING’ on the UART but hang forever (despite the other paired module on and in range)…The Command manual for IOT777 suggests that when sending the ‘OPEN’ cmd the device should be in (Pairing mode). I’ve noticed on startup the module boots up into (pairing mode) as noticed by the UART message ‘PAIR_PENDING’. However, if the device is paired, then loses connection, it seems it will no longer be in (pairing mode).
In this case, instead of power cycling the module to put it back into pairing mode, i’ve noticed that by cycling the discoverable state, after sending ‘DISCOVERABLE ON’, i receive the message on the UART ‘PAIR_PENDING’ which puts it back into pairing mode and therefore will allow the ‘OPEN … AGHFP’ cmd to work.
2)
I don’t believe it to be a timing issue given that i’m able to reproduce the issue fairly quickly using the procedure i’ve documented. but also unable to reproduce the issue using the exact same procedure aside from ending the call before power cycling. Also, the UART responses for the good and bad case look exactly the same. The only functional difference being the fact there is no actual audio coming out of the headset device.I’ll attach annotated pictures of both UART logs for headset and source devices for both Good and bad test cases. Note, these logs begin after both modules are connected and activly streaming audio in HFP and the power is pulled from the headset. (the beginning of my step 1).
For the GOOD case:
For the Failed case:
You’ll notice there is no difference in the UART to indicate the audio is not working. If i issue ‘STATUS’ in both the good and bad test cases I receive the same response :
For Source:
STATE CONNECTABLE[ON] DISCOVERABLE[ON] ADVERTISING[ON] SCAN_UNI[OFF]
LINK 12 CONNECTED AGHFP 245DFC0201AD ACTIVE WBFor Headset:
STATE CONNECTABLE[ON] DISCOVERABLE[IDLE] ADVERTISING[ON] SCAN_UNI[OFF]
LINK 13 CONNECTED HFP 245DFC03B624 ACTIVE WB -
My apologies. You were correct. I forgot to disable autoconn on the headset which is why i didn’t have to re-open. I’ve now restored both headset and source and made just the configuration change you suggested:
1) Borad1: transmitter. On the AGHFP. I changed PROFILES=ON 0 1 0 1 1 1 1
2) Board2: receiver. On the HFP (headset), I changed AUTOCONN=1 3
Source:
Headset:
I’m using two DISKIT’s for testing running the latest fw “V3.1.70”. the source is plugged into my PC streaming music and the headset is connected to wired earbuds. and i’m still able to reproduce the issue occasionally.. Your testing procedure looks to match mine.
I was able to develop a workaround for our product implementation so this issue is less of a concern now at this time..
my workaround is as follows:
1. source see’s ‘close_ok’ to indicate the headset lost power.
2. source see’s ‘open_ok’ to indicate it was reconnected.
3. source initiates call “call 12 incoming 121”
4. headset answer’s call ‘call 13 answer’
5. source ends call ‘call 12 end’
6. source re-calls ‘call 12 incoming 121’
7. headset answer’s call ‘call 13 answer’
On the second call, the audio seems to always be functional. my theory was that in the module internal state, a call needed to be ended before the state could be reset for the next call (or something along those lines).
In any case, this procedure, when controlled by a host micro happens actually surprisingly fast so it doesn’t add much to the initial connection time and as such is acceptable.
-
You must be logged in to reply to this topic.