Issue with working with the McuMgr together with the Android BLE library #156
Labels
question
Further information is requested
Comments
|
I don't think this is related to any of the mobile libraries. I'd say it may be something with timings, e.g. when the device is quickly saving incoming data it may slow down responses every now and then, causing the phone to drop connection. Did you experiment with using different connection parameters? You may request them from the Android or peripheral side. Mind, that longer connection interval does not necessarily mean slower upload, as sometimes more write without response packets can fit into longer connection interval. You may also experiment with using lower window capacity (less packets sent in parallel). Do your logs show anything intersting apart from the error code? |
|
I see interesting things in the Logs, upon disconnecting our Bluetooth peripheral device the Then the peripheral device turns back on and immediately continues to sending and receiving packets: Then somehow something changes and it suddenly stops receiving notifications from the Bluetooth peripheral: After 2 seconds our logical code that wasn't aware of this disconnection (this is what I mentioned in the issue of having 2 BLE Managers) is creating a new McuMgrBleTransport and sending packets without receiving a notification: |
|
Hello,
Here the library is sending request to get McuParams and is getting this as response:
The SMP packet that's being sent is 2474 bytes long, so it will take number of Write Commands (each MTU-3-bytes long) to send it. The notification should be sent when the whole packet was sent. The target device should buffer these and reassembly upon receivng all packets. |
|
The first long packet after reconnection that you send, the one of size 2474 bytes, has
Seems like the app is trying to continue sending the packet, but the device might have lost the context on reboot, so may be expecting |
|
When you create a new instance of Mind, that you may have multiple 'virtual' clients connected to the same physical Bluetooth LE device, in one or many apps. With each client ( |
|
I understand, thanks for your response. Our use case involves making several file uploads/downloads to our Bluetooth device one by one while passing other messages on different services. So what do you think is the best way to handle the Create a new Also, what is the best way to gracefully clear and close the resources of the |
|
I think I know what is the issue of the connecting after disconnection. Every send call is calling connect over and over again with a retry. Therefore if the send is called just before disconnection we are entering this loop causing the above issue. |
|
The BLE transport implementation indeed initiates connection when not already connected. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
We are working with the Nordic SDK for 2 purposes that are running together.
For some reason, we get timeouts while uploading/downloading large files and sudden disconnections while connected to the Android BLE library and the McuMgrBleTransport together.
What can we do in this situation?
The text was updated successfully, but these errors were encountered: