BLE UART - ble_nus_string_send() connection interval & data transfer

[leonhart88]

Hey guys,

From what I understand, the minimum connection interval on say, an iPhone, is 20ms. Also, you can send up to 6 packets of 20 bytes within a connection interval. So that's 120 bytes every 20ms.

I've been playing around with the UART peripheral example in SDK 14. I notice that the function ble_nus_string_send() sends a max length of 20 bytes.

What I want to know is how exactly are the data packets and connection interval handled? For example, if I call ble_nus_string_send() once with 20 bytes, will it just go ahead and send the 20 bytes and take up the entire 20ms connection interval?

Consequently, if I call ble_nus_string_send() 6 times with 20 bytes, will all that data transfer within the one connection interval?

Just trying to wrap my head around how this all works. I'll search for some explanations on the SDK and tutorials, but thought it might be more time effective to ask on here.

Thanks!

[leonhart88]

Yup, that's exactly what I was trying. I'll upload some images in a bit. It seems like in the SDK config, there is a parameter "NRF_SDH_BLE_GAP_EVENT_LENGTH" that is used to set the connection time for every connection interval. By default the UART example set this to 3 (3*1.25ms). If I change it to 16 (20ms), then the data in the sniffer seems to make more sense. See related thread below:

devzone.nordicsemi.com/.../

Again I wish there was some better documentation on this stuff...

[endnode]

I do agree that bandwidth settings in the latest Nordic SoftDevice API is little bit cryptic, but have you looked to API and SD specifications? Also timing in your both JPG screenshots looks pretty similar to me (always ~40ms between two Notifications) - could you show unfiltered trace to see where are empty PDUs and also some view of PDU headers to check MD bit value? Note that Nordic sniffer isn't accurate in timing on this scale and it can go off because of different delays and caching along the way through USB to Wireshark (I've seen inaccuracy larger then 10ms).

[leonhart88]

I admit i should read the specs closely again.

Where are you looking at for the 40ms? I was looking at the time on the left.

OK ill upload an unfiltered trace later.

[endnode]

You are right, I've missed the zero. Packets really seems to fit into much smaller intervals then 20ms (in case of "length 16") so there is good chance that 5 or even 6 of them went through. The other strace have ~44ms intervals between Notifications so hard to say what's going on there and what is actual Connection interval. However looking to detailed flow on LL including empty PDUs, Connection Request and other info should give you definitive answer.

[leonhart88]

Yup. Don't really know why I was getting the 44ms either...but all tests since that one have shown 20ms packets which is what the connection interval is set at.

I've included an image of the LL message as well as the Wireshark dump logs if you want to take a closer look. It definitely does seem like the connection interval is 20ms as desired and that the config parameter is solving the issue. I'll have to look deeper into this to really understand whats happening.