Forum Replies Created
-
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 WBMy 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.
