mike_ts

[mike_ts]

Hi,

The IDC777 ins installed on a cutom board with PIO_3 left floating by default as it was not being used for anything.
So if I ensure this pin is tied high, then power-up and boot the module, it will do the same as the RESETORE command ? Is this correct ?
So it won’t actually return to some factory version of the Firmware, but rather it will simply reset the module’s configuration to the factory default values, according to the current Firmware installed.

I may have to try this first… But I also suspect a possible hardware issue on the module itselft as the Rx displays the correct UART commands being sent from TeraTerm (checked with a DSO), but nothing comming out except for the Welcome message. Unfortunately I cannot interact further with the module…
If for some reason some flow control setting is out of wack maybe I can RESTORE it with PIO_3, so this might be worth trying first – thanks.

Regards, Michael

[mike_ts]

Ok, thanks it turns out there was a H/W issue on the board I was using. Replacing it solved the issue.

[mike_ts]

I have another quick question Ash, regarding some notifications I’m receiving, namely :
CALL_RINGING HFP 13
CALL_INCOMING HED HFP 7CB37BFB74E3 IDLE

What is the purpose of having both as it appears they both notify an incoming call that one has to act on ?
They appear to be in sequence.
Also I am not identifying the “HED” tag attached to the second notification ?!?! Is this some internal specific to the IDC777 firmware ? Is this something new as I was not seeing this in the previous tests on calls ?
Are these notifications allways sent with a call and should one expect them in a consistent sequence ?
We currently parse only the CALL_RINGING HFP 13 notification as this is ample info to store for active calls … perhaps it may be different if multi-calls need to be managed (not an immediate issue but may be later).
So if these are not too many questions perhaps you can shed some light on this please ?

So to summarise :

1. What is the purpose of having both notifications, as one seems enough ?
2. What is this “HED” tag ?
3. Are these notifications allways in the same expected sequence ?

Cheers, Michael

[mike_ts]

It would be 3.1.70 or something similar.

[mike_ts]

Should this Tag “HED” not be part of, or have anything to do with the IDC777 firmware, it could be a possible glitch on my side that occurs (rarely) and that I would need to confirm. But if it is something that is part of the IDC777 firmware then it may be necessary to know … sorry for the trouble.
The other questions remain relevant though. So far I am seeing that CALL_RINGING always appears before CALL_INCOMING etc. So this is encouranging nevertheless….

[mike_ts]

Ok, that was a bug in the code. “HED” showed up as a phantom string.

Other thing I notice with the current code is that CALL_END is no longer sent. It appears that CALL_IDLE is now what is being notified after a SCO_CLOSE.

Is this corrent ?

Thanks, Mike

[mike_ts]

Hi there Ash,

How are you ?
I have a question for you regarding the capability of the IDC777 Bluetooth stack implementation with regards to the simultaneous use of the HFP and AGHFP profiles with phones and headsets.
Is this handled reliably on the IDC777 or should one assume it is better to not confuse the two profiles and to keep the separate during use with a phone or a headset ? I am ware of some BT stacks that will correctly handle such scenarios but am not sure if the IDC777 can as after trying, I do get some odd behaviour.

Namely with these settings : 
BT_CONFIG=1 1 0
PROFILES=ON 1 1 0 0 1 0 1
When I reboot the IDC777 the paired Shokz C102 headset connects automatically after a few seconds, like :
AudioAgent IDC777 V3.1.70
Build: 0400427b
Bluetooth address 245DFC020046
Ready
aptX Lossless: ON
PAIR_PENDING

OPEN_OK 12 AGHFP 2074CFB4E54B     <——– Shokz C102
ABS_VOL 12 13
STATUS
STATE CONNECTABLE[ON] DISCOVERABLE[IDLE] ADVERTISING[OFF] SCAN_UNI[OFF]
LINK 12 CONNECTED AGHFP 2074CFB4E54B IDLE
OK

When I manually connect the Android phone this is what happends straight after :

IOT747 Copyright 2022
AudioAgent IDC777 V3.1.70
Build: 0400427b
Bluetooth address 245DFC020046
Ready
aptX Lossless: ON
PAIR_PENDING
OPEN_OK 12 AGHFP 2074CFB4E54B
ABS_VOL 12 13
status
STATE CONNECTABLE[ON] DISCOVERABLE[IDLE] ADVERTISING[OFF] SCAN_UNI[OFF]
LINK 12 CONNECTED AGHFP 2074CFB4E54B IDLE
OK

And another attempted manual connection from the phone.
IOT747 Copyright 2022
AudioAgent IDC777 V3.1.70
Build: 0400427b
Bluetooth address 245DFC020046
Ready
aptX Lossless: ON
PAIR_PENDING
OPEN_OK 12 AGHFP 2074CFB4E54B    <—– Shokz C102 connects silently after a little delay …
ABS_VOL 12 13

It appears the IDC777 reboots, disconnects everything, then the C102 reconnects silently since BT_CONFIG=1 1 0.
The reboot was not initiated by my app, it happend when the manual connection to the phone was done on the phone.
This suggests to me some possible exception error on the IDC777 with this attempted manual connection from a phone, whilst a current connection was already in place with the Shokz C102 headset : OPEN_OK 12 AGHFP 2074CFB4E54B.

I would like to know if this is not something you recommend, or is/was not/never implemented yet etc. ?!?
perhaps this feature will be implemented at a later date ?

Regards, Michael

[mike_ts]

Ok, so that is good to know. We’ll need to ensure one or the other is selected by a button toggle or similar … thanx for the confirmation.

[mike_ts]

Hi, can you confirm, is it still necessary to do a RESET after a WRITE in the most recent firmware updates ?
Is the effect the same if after the WRITE, there is a H/W Reset instead of a software RESET ?
Thanks, Michael

[mike_ts]

Hi, ok, that’s good, since we have a special case where I need to change the CONNECTABLE state to OFF before we do a reboot or a switch off of the PCB. So we can avoid doing a software reset and then another hardware reset in a row… Just checking, but from what I can tell it works as intended wuth the hardware reset … thanx

[Author]

Posts