Incorrect link settings to phone and windows pc

[T IJ]

Hello Devzone,

In our product we are working with a nRF52840 microcontroller and periodically transmitting large sums of data to a PC or a phone. 

We noticed that over time a delay is occurring the data stream which kept incrementing until we had a 5 second delay in the data.

After inspecting using Wireshark and the nRF52 Ble Sniffer example I noticed that the initial link settings were a bit odd.

We requested a data length of 251 bytes for up and down, with a up and down time of 2120 us, but what we received was something else.

We received on the PC the correct data length of 251 bytes but incorrect timing. A PC to nRF time of 7851 us and a nRF to PC time of 328 us.

The 328 us time is not enough for us to transmit the entire payload, so the payload is fragmented in pieces, building up delay.

This startled me, thinking I was doing something wrong with setting up my Bluetooth connection to the PC.

I reverted back to using an example project from the 17.0.2 SDK, the ble_app_uart example to be precise and I tested this code out of the box with various hardware.

I tested 3 different nRF52840 development boards, a ISP1807 development board and multiple boards of us where the ISP1807 is used on.

All showed similar things where the same negotiation took place, where the data length is set correctly but the time is off.
Connecting to a phone resulted into even different settings. The data length requested by us is still 251 but we receive 251 for phone to nRF but 27 for nRF to phone.

The time is set to 17040 us for phone to nRF and 328 us for nRF to phone.

I would expect an example from Nordic to work without an issue but this wasn't the case. 

There are four ways I have done these tests.

- Direct connect using Windows 10 Bluetooth settings app
- Python using PySide6 Bluetooth class on Windows 10.
- Direct connect using an Android Phone with Android 14.
- Using nRF Connect on the same phone.

All methods resulted in the same behavior where the timing is incorrect.

Is this something you are able to reproduce and verify yourself or are there things I am doing wrong on my side?

Kind regards,

[T IJ]

Well after a very long time of debugging and searching possibilities we've finally figured out that our timing is off.

Our min and max connection interval were both set to 8,75ms. Using this between two Nordic microcontrollers worked seamlessly since we were both in control of the central and the peripheral.

The times were set fixed in order to cope with our data throughput.

Connecting to an "OS" we were expecting the same behavior as it worked on our Nordic hardware, but oh boy were we wrong.

We totally missed the part where the OS uses the Bluetooth link to always scan nearby devices and other things. If we would get our 8,75ms + 2120 us time, the OS would have no time to do all the other things.

This is why we only received the 328 us, limiting our bandwith and providing the OS a moment to use the radio for other things.

When we relaxed the connection interval from 8,75-8,75 to 8,75 - 100, we get a maximum of 17040us. I believe the BLE NUS exampled worked but due to Bluetooth caching on the OS it kept the original settings thus always giving us the poor connection bandwidth.

Knowing all this, we've discovered that our device in development phase is unable to offload all data to an OS, thus we have to use a Nodic device to translate Bluetooth to USB.