Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection interval changes on its own #558

Open
arthurianno opened this issue Apr 20, 2024 · 3 comments
Open

Connection interval changes on its own #558

arthurianno opened this issue Apr 20, 2024 · 3 comments
Labels

Comments

@arthurianno
Copy link

arthurianno commented Apr 20, 2024

Hello,

I'm writing an android application, using no.nordicsemi.android:ble:2.3.1. I connect to the sensor and write 49KB data to it. Before recording, I set the desired interval (CONNECTION_PRIORITY_HIGH 11.25 - 15ms) and MTU (247). Next, I initiate the sending of files of 128, 232,240 bytes. But the problem is that after sending, GATT sets me to interval 36 and not 12ms as I need. The sensor supports from 12 to 30ms. I tried different versions of Android and the BLE version doesn't really make a difference either. If you need the code, I can show you some excerpts.

Nothing helps, maybe there are some articles or something similar.

UPD uploaded HCI log

https://dropmefiles.com/SEgPo two files

Before sending all data, I put this:

requestConnectionPriority(ConnectionPriorityRequest.CONNECTION_PRIORITY_HIGH) 
    .done(device -> Log.e("BleControlManager", "Interval request sent")) 
    .fail((device, status) -> Log.e("BleControlManager", "Failed to send Interval request: " + status)) 
    .enqueue(); 
requestMtu(247) 
    .done(device -> Log.e("BleControlManager", "MTU request sent ")) 
    .fail((device, status) -> Log.e("BleControlManager", "Failed to send MTU request: " + status)) 
    .enqueue();

Then I receive a log from Gatt:

2024-04-17 15:03:59.776 18358-18412 BluetoothGatt com.example.bluetoothcontrol D onConfigureMTU() - Device=38:3B:26:7E:76:9B mtu=247 status=0
2024-04-17 15:03:59.910 18358-18412 BluetoothGatt com.example.bluetoothcontrol D onConnectionUpdated() - Device=38:3B:26:7E:76:9B interval=12 latency=0 timeout=500 status=0

Then several packets pass through to the device, and then this happens:

2024-04-17 15:04:00.405 18358-18412 BluetoothGatt com.example.bluetoothcontrol D onConnectionUpdated() - Device=38:3B:26:7E:76:9B interval=36 latency=0 timeout=100 status=0

The log shows, that after sending the packet, the interval changes without my participation:

1704 330.000533 SamsungElect_3a:0a:01 (Galaxy A7 (2018)) JiangsuQinhe_7e:76:9b (SatelliteOnline0000) ATT 12 Sent Exchange MTU Request, Client Rx MTU: 247 
1703 329.798134 controller host HCI_EVT 7 Rcvd Command Status (LE Connection Update) 
1705 330.014861 controller host HCI_EVT 8 Rcvd Number of Completed Packets 
1706 330.059797 JiangsuQinhe_7e:76:9b (SatelliteOnline0000) SamsungElect_3a:0a:01 (Galaxy A7 (2018)) ATT 12 Rcvd Exchange MTU Response, Server Rx MTU: 255 
1707 330.060311 host controller HCI_CMD 10 Sent LE Set Data Length 
1708 330.064660 controller host HCI_EVT 9 Rcvd Command Complete (LE Set Data Length) 
1762 330.616503 controller host HCI_EVT 8 Rcvd Number of Completed Packets 
1763 330.616628 SamsungElect_3a:0a:01 (Galaxy A7 (2018)) JiangsuQinhe_7e:76:9b (SatelliteOnline0000) L2CAP 15 Sent Connection Parameter Update Response (Accepted) 
1764 330.617120 host controller HCI_CMD 18 Sent LE Connection Update 
1765 330.617907 controller host HCI_EVT 7 Rcvd Command Status (LE Connection Update) 
1766 330.630105 JiangsuQinhe_7e:76:9b (SatelliteOnline0000) SamsungElect_3a:0a:01 (Galaxy A7 (2018)) ATT 10 Rcvd Write Response, Handle: 0x0013 (Nordic UART Service: Nordic UART Rx: Client Characteristic Configuration)
@philips77
Copy link
Member

Hello,

Note

I fixed your post, making it more readable. Please, make sure it's readable next time.

The minimum Interval Connection supported by Android is 11.25 ms, depending on Android version.
Here you can find the current values for each "priority":
https://cs.android.com/android/platform/superproject/main/+/main:packages/modules/Bluetooth/android/app/res/values/config.xml;l=27;drc=3d19fbcc09b1b44928639b06cd0b88f735cd988d;bpv=1;bpt=0

However, Android requests interval 7.5 ms for service discovery, and switches back to higher one afterwards.
It may also change to any value it wants without user interaction. I guess this is what you observe.
Often phones reserve some percentage of radio for "companion devices", to improve user experience. Or they just want to lower battery consumption.

If you want to send large amount of data, you don't really want short connection interval. Remember, that when using Write Without Response, or Notifications, the phone may send multiple packets in a single connection interval. By using Date Length Extension (DLE), supported on Android 6+, as far as I remember, the Link Layer packets can send fill 247 bytes in a single packet, but can send multiple such packets one by one, which is faster than sending one per connection interval. So, with too short interval it may be that 2 won't fit. Depending on the length of the "unused" gap between end of the last packet and start of the new interval the upload may be faster or slower. Sometimes increasing the interval increases speed.

If you have a good BLE sniffer, like Ellisys, which can show the packets on a time graph, you may tune the connection interval so that as litle time is "wasted" as possible.

If your phone sets the interval to 30 ms, I wound't fight with it, rather would tune the MTU so that the packets fit as much as possible. Also, if your device supports even higher MTU, I recommend using value 498. With that a single GATT packet fits into 2 maximum-length Link Layer packets when using DLE.

@philips77 philips77 changed the title Android BLE Connection interval changes on its own Apr 22, 2024
@arthurianno
Copy link
Author

arthurianno commented Apr 22, 2024

Hello!

Thank you for correcting the post, I would like to clarify that at the moment the interval of 30ms has been corrected to 12 and now the HCI logs look like this, can you be more specific about what the reason could be??

First of all, I connect, set the MTU and then start working with files

39598	426639.081070	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	localhost (Galaxy A7 (2018))	ATT	19	Rcvd Handle Value Notification, Handle: 0x0012 (Nordic UART Service: Nordic UART Rx)
39599	426639.081521	controller	host	HCI_EVT	8	Rcvd Number of Completed Packets
39600	426639.088081	localhost (Galaxy A7 (2018))	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	ATT	12	Sent Exchange MTU Request, Client Rx MTU: 247
39601	426639.125563	controller	host	HCI_EVT	8	Rcvd Number of Completed Packets
39602	426639.188328	controller	host	HCI_EVT	19	Rcvd LE Meta (LE Advertising Report)
39603	426639.188790	controller	host	HCI_EVT	46	Rcvd LE Meta (LE Advertising Report)
39604	426639.215277	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	localhost (Galaxy A7 (2018))	ATT	12	Rcvd Exchange MTU Response, Server Rx MTU: 252
39605	426639.215661	host	controller	HCI_CMD	10	Sent LE Set Data Length
39606	426639.216416	controller	host	HCI_EVT	9	Rcvd Command Complete (LE Set Data Length)
39607	426639.220878	localhost (Galaxy A7 (2018))	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	ATT	255	Sent Write Request, Handle: 0x0010 (Nordic UART Service: Nordic UART Tx)
39608	426639.350541	controller	host	HCI_EVT	8	Rcvd Number of Completed Packets
39609	426639.395584	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	localhost (Galaxy A7 (2018))	ATT	10	Rcvd Write Response, Handle: 0x0013 (Nordic UART Service: Nordic UART Rx: Client Characteristic Configuration)
39610	426639.399510	localhost (Galaxy A7 (2018))	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	ATT	255	Sent Write Request, Handle: 0x0010 (Nordic UART Service: Nordic UART Tx)
39611	426639.438742	controller	host	HCI_EVT	13	Rcvd LE Meta (LE Connection Update Complete)
39612	426639.439502	controller	host	HCI_EVT	7	Rcvd Command Status (No Operation)
39511	426636.712040	controller	host	HCI_EVT	7	Rcvd Command Status (LE Read Remote Features)
39512	426636.741018	controller	host	HCI_EVT	15	Rcvd LE Meta (LE Read Remote Features Complete)
39513	426636.741593	host	controller	HCI_CMD	6	Sent Read Remote Version Information
39514	426636.743243	controller	host	HCI_EVT	7	Rcvd Command Status (Read Remote Version Information)
39515	426636.875833	controller	host	HCI_EVT	11	Rcvd Read Remote Version Information Complete
39516	426636.881483	host	controller	HCI_CMD	18	Sent LE Connection Update
39517	426636.882437	localhost (Galaxy A7 (2018))	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	ATT	16	Sent Read By Group Type Request, Primary Service, Handles: 0x0001..0xffff
39518	426636.883072	controller	host	HCI_EVT	7	Rcvd Command Status (LE Connection Update)
39519	426636.884345	controller	host	HCI_EVT	19	Rcvd LE Meta (LE Advertising Report)
39520	426636.885467	controller	host	HCI_EVT	46	Rcvd LE Meta (LE Advertising Report)
39521	426636.920974	controller	host	HCI_EVT	8	Rcvd Number of Completed Packets
39522	426636.965860	controller	host	HCI_EVT	13	Rcvd LE Meta (LE Connection Update Complete)
39523	426637.010471	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	localhost (Galaxy A7 (2018))	ATT	23	Rcvd Read By Group Type Response, Attribute List Length: 2, Generic Access, Generic Attribute

Further, during the file transfer process, the interval changes again to 12ms.

39654	426639.787868	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	localhost (Galaxy A7 (2018))	ATT	19	Rcvd Handle Value Notification, Handle: 0x0012 (Nordic UART Service: Nordic UART Rx)
39655	426639.788557	controller	host	HCI_EVT	8	Rcvd Number of Completed Packets
39656	426639.800704	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	localhost (Galaxy A7 (2018))	ATT	10	Rcvd Write Response, Handle: 0x0013 (Nordic UART Service: Nordic UART Rx: Client Characteristic Configuration)
39657	426639.807843	localhost (Galaxy A7 (2018))	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	ATT	255	Sent Write Request, Handle: 0x0010 (Nordic UART Service: Nordic UART Tx)
39658	426639.817814	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	localhost (Galaxy A7 (2018))	ATT	19	Rcvd Handle Value Notification, Handle: 0x0012 (Nordic UART Service: Nordic UART Rx)
39659	426639.819035	controller	host	HCI_EVT	8	Rcvd Number of Completed Packets
39660	426639.830895	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	localhost (Galaxy A7 (2018))	ATT	10	Rcvd Write Response, Handle: 0x0013 (Nordic UART Service: Nordic UART Rx: Client Characteristic Configuration)
39661	426639.841405	localhost (Galaxy A7 (2018))	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	ATT	255	Sent Write Request, Handle: 0x0010 (Nordic UART Service: Nordic UART Tx)
39662	426639.847761	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	localhost (Galaxy A7 (2018))	ATT	19	Rcvd Handle Value Notification, Handle: 0x0012 (Nordic UART Service: Nordic UART Rx)
39663	426639.848611	controller	host	HCI_EVT	8	Rcvd Number of Completed Packets
39664	426639.860603	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	localhost (Galaxy A7 (2018))	L2CAP	21	Rcvd Connection Parameter Update Request
39665	426639.861550	localhost (Galaxy A7 (2018))	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	L2CAP	15	Sent Connection Parameter Update Response (Accepted)
39666	426639.862666	host	controller	HCI_CMD	18	Sent LE Connection Update
39667	426639.864004	controller	host	HCI_EVT	7	Rcvd Command Status (LE Connection Update)
39668	426639.864655	controller	host	HCI_EVT	13	Rcvd LE Meta (LE Connection Update Complete)
39669	426639.876053	JiangsuQinhe_7e:76:9b (SatelliteOnline0008)	localhost (Galaxy A7 (2018))	ATT	10	Rcvd Write Response, Handle: 0x0013 (Nordic UART Service: Nordic UART Rx: Client Characteristic Configuration)
39670	426639.876970	controller	host	HCI_EVT	8	Rcvd Number of Completed Packets

The logs show that I’m transferring files to the device and for some reason it’s set to 12ms again, although previously it was 30, but now it’s fixed. This is an excerpt of the logs, I will attach the full logs

@arthurianno
Copy link
Author

btsnoop_hci.log

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants