We developed interface in Windows 10 c++ based on GATT Windows libraries.
We succesfully completed unlock procedure up to getting back txnonce and rxnonce.
We succeeded in sending encrypted Local AT frames and getting proper answer back through indication callback.
If we then issue a new Local AT command (encrypted with same txnonce), indication is not fired anymore.
It looks indication should be confirmed at app level but that was not necessar during unlock procedure; is this proper behaviour?
We went through few other GATT indication callback examples and it seems that confirmation is automatically issued even for indications and not required at APP level.
Device looks to be still connected but unresponsive: we can succesfully write characteristic (without any error) with a new Local AT command encrypted frame but without indication fired.
In case confirmation is required: we did not find any info concerning how to acknowledge indication receipt.
Tried following without any success:
- Tried to repeat unlock procedure but it looks to stay unlocked up to device disconnection
- Renewed indication flag on descriptor after indication received
- Renewed callback event registration after indication received
You can’t issue local AT commands via the BLE interface. You need to use remote AT commands for the BLE interface. What I would suggest is looking at the XCTU Mobile application code to see how that it done.
Thanks for your reply, appreciated but we are connecting from PC. Please, check documentation (page 316 of 90001539) it is stated that after unlocking "you may send Local At Command Request 0x08 frames and receive AT Command Response frames.
In fact we receive proper answer but just once at first request.
Did we misunderstand your point?
I think you did. I would suggest looking over the sample application we have as it shows you exactly how to do it.
Thanks for your help but, apologies, we did not find any example code based on Windows BluetoothGATT APIs apart winrt that we cannot use.
Can you, please, address us there?
No problem in Android following examples provided but not in Windows.
Your help is highly apreciated.
The code that is used for the Android can also be used on Windows.
Reading your posts make me think perhaps you have some misunderstanding on how the system works.
You’ll need to develop either MicroPython code to run in the XBee itself or have your own processor connected to the XBee over the UART connection.
Your Windows application then would rely on API frame command 0x2D and 0xAD to send and receive messages to or from either MicroPython or your processor behind XBee.
MicorPython or your embedded firmware would be the one that deals with local AT commands wrapped in API frames. In other words, you can’t control radio directly from the BLE interface. You need a middle man, who can be either MicroPython or your own processor.
Hope this makes sense.