Hi Mike,
It seems that you have faulty hardware. You would need to check all your hardware and compare to the DISKIT. The DISKIT and DISKIT schematics have to be used as a reference. the IDC777 cannot go into bricked mode. If the voltage applied is not stable and dips below 3V, it can end in a weird state. but power OFF and POwer ON again should get it back up and running.
You can RESTORE if you hold PIO3 at boot. See below from the manual. But it seems more likely this is from your hardware.
IOT747 Support
Hi Mike,
What firmware are you using?
IOT747 Support
Hi Mike,
CALL INCOMING and CALL_RINGING are 2 separate notifications from Bluetooth. We show them both if you need them. For HED, always compare with the IDC777-DISKIT if you think there is an issue. the IDC777-DISKIT always serves as a reference.
Also, on the newer firmware versions, we display also the number and caller name if he get it. We also have PBAP and MAP. But if you have AA3170D, then it’s fine, you won;t have all these notifications.
IOT747 Support
Hi Mike,
IDC777 can be HFP or AGHFP but not both at the same time. This is on the Roadmap but we don’t have a date for the release.
IOT747 Support
Hello Mike,
1) For some configuration, you need to do a RESET for it to take place (For example AUDIO). For otehr, you don;t need to RESET. The manual tries to let you know whicch ones need RESET. But usually, it is better to RESET for safety.
2) Once you do a WRITE, it writes the new configuration on the Flash. So you can Reset in software or Hardware and it’ll work.
IOT747 Support
Hi Bruce,
The Windows DFU tool does not allow parallel processing.
However, if you sign an NDA (Our NDA is under Support/Documents at https://www.iot747.com/download/iot747-standard-nda-form/), we can share the source code of the python script that does the DFY over UART. Usually we share with customers so they can integrate on their host processor. But in your case, you can run it on your laptop and modify it to use mmultiple UART and do parallel upgrades.
IOT747 Support
Hi Draven,
BLE_SET_DB does not work with IDC777. However, it depends what you want to do:
1) If you would like to act as BLE_Central (Client) and Connect and Read from a Server (BLE Heart Rate, BLE button, BLE sensor), you don;t need BLE_SET_DB and you can search for services, characteristics and read/write using the BLE_xxx commands.
2) If you would like the IDC777 to act as a server (BLE Peripheral usually) and a phone (or something) else connects to it and it exhibits particular characteristics and services, you would need to use DB generator and we would then need to integrate your database in the code.
Let us know what you are trying to do? Thanks.
IOT747 Support
Hi Draven,
Yes, it will be the same firmware but with your Database. You will need a Support pack4 to do this. Otherwise, why don’t you use the SEND/RECV command over BLE or SPP? Since you are building your App, this shoudl be easier.
IOT747 Support
Please see the video at: https://www.iot747.com/aiovg_videos/idc747-connect-an-android-app/
Yes, that is correct. Thanks. IOT747 Support
Hello Dav,
Thanks for the call. Unfortunately, this is not a board we produce, you would have to discuss directly with MIKROE. As they produce and sell this board.
The DEV KIT we produce is the IDC777-DISKIT (https://www.digikey.com/en/products/detail/iot747/IDC777-1-DK/21764288?s=N4IgTCBcDaIJIBEDCB2NIC6BfIA) and this is the one that has a 3.5mm Jack. Sorry about the confusion.
IOT747 Support
Hello Guido,
This is strange as enabling this should just mean the AT commands are displayed via UART, but shouldn’t be changing behaviour otherwise. We tried with an iPhone SE and we could not replicat ethe issue. See below the UART log.
1) With enable_at_notifications=ON, does the module still respond to +BCS
internally on the HFP link, or is the host expected to take over the
full codec negotiation?
>> If it displays ATH for the AT command it shows this is has been handled by the AT parser and the appropriate response has been sent, eg:
ATH 13 12
+BCS: 2
If it just showed: AT ,
Then it has not been handled, and might require a response depending on the AT command.
With enable_at_notifications=ON, it should just be for display purposes, it is not meant to affect behaviour.
2) Is there a recommended way to receive +CIND / +CSQ / +CIEV indicator
updates from the AG without breaking automatic HFP codec negotiation?
>> You can set enable_at_notifications=ON, or send AT commands directly using the command: AT .
3) Is there a non-Apple-specific way to query phone signal strength and
battery level via the IDC777 (AudioAgent commands or AT pass-through)
while keeping HFP audio fully functional?
>> You can use the command: AT
to send AT commands to the connected AG.
Eg.
AT 13 AT+CIND?
OK
ATH 13 25
+CIND: 0,0,1,1,0,5,0
ATH 13 7
OK
AT 13 AT+CIND=?
OK
ATH 13 133
+CIND: (“call”,(0,1)),(“callsetup”,(0-3)),(“service”,(0-1)),(“signal”,(0-5)),(“roam”,(0,1)),(“battchg”,(0-5)),(“callheld”,(0-2))
ATH 13 7
OK
AT 13 10
ERROR
4) We would also be interested if there is a way to toggle
enable_at_notifications at runtime without going through WRITE + RESET
>> You can actually change between these at run time, and the AT information should be enabled/disabled accordingly :
set HFP_CONFIG=ON ON OFF ON 5 ON OFF ON OFF
set HFP_CONFIG=ON OFF OFF ON 5 ON OFF ON OFF
Details of iPhone test with AT notifications enabled.
call 13 outgoing 121
OK
ATH 13 7
OK
ATH 13 15
+CIEV: 3,2
ATH 13 11
+BCS:2
ATH 13 7
OK
SCO_OPEN
ATH 13 15
+CIEV: 3,3
CALL_ACTIVE HFP 13
ATH 13 15
+CIEV: 2,1
ATH 13 15
+CIEV: 3,0
call 13 end
OK
SCO_CLOSE
ATH 13 7
OK
CALL_IDLE HFP 13
ATH 13 15
+CIEV: 2,0
Hi Denis,
It seems like there is a typo in your email. You are upgrading from what firmware version to AA3170D.
But there is no issues, we suggest you upgrade to AA3170D or even the latest firmware for more functionalities. If the firmware was working on one board, an upgrade will still work on that board. So you can go ahead and upgrade.
IOT747
Hi Draven,
Can you please:
1) Explain why you do this:
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?
2) If you don’t do Point2, can you check and let us know if you see the issue?
If this happens 20% of the time, is it related to the time it takes you to issue the OPEN command? Or anything else? So we can try and identify the problem?
IOT747 Support
Hello,
Thanks for the details.
The device shoudl be Paired to be be able to OPEN a connection.
But it should not be in Pairing Mode. You can try this by sending DISCOVERABLE OFF. And then OPEN and it should work. As long as you do the CLOSE 13 END. Could you confirm?
Also, could you try with the latest firmware and an IDC777-DISKIT? https://www.iot747.com/download/aa3170d/
IOT747 Support
Yes, it Autoconnects because you have:
SET AUTOCONN=1 xx.
If you have AUTOCONN set, you shoudl not send the OPEN command. Because the IDC777 is already trying to open the connection. And if you also send an OPEN command, you are conflicting with it. Maybe that is causing the issue.
Can you try the same thing with the IDC777 and the latest firmware and default configurations (except AUTOCONN): https://www.iot747.com/download/aa3170d/?
IOT747 Support
Hi Draven,
I tried with the latest firmware. It had the 2 x IDC777-DISKIT with default configuration except:
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
I kept plugging/unplugging power and then doing Call 12 incoming on Board1 and Call 13 answer on Board2 and I could hear all the time Audio when the SCO was opened.
Could you please try again on your side with IDC777 DISKIT, latest firmware and Default configurations?
IOT747 Support