Central to peripheral data transfer time

RE: Central to peripheral data transfer time

ovrebekk — Tue, 02 Apr 2019 06:55:02 GMT

What I mean is that you remove the BLE stack altogether, and use the nRF52 radio in a non standard way. If you access the radio on a register level you have a lot more flexibility than what the BLE stack gives you, but you will no longer be BLE compliant and will need to have Nordic devices on both sides of the link.

We typically refer to this as proprietary 2.4GHz protocols, and provide some examples in the SDK through the ESB and Gazell implementations.

These protocols are primarily included to provide backwards compatibility with older Nordic devices (introduced before BLE was even a thing), but can also be used when having very particular protocol requirements.

Best regards
Torbjørn

RE: Central to peripheral data transfer time

prodey — Mon, 01 Apr 2019 14:16:21 GMT

Hello,

Thanks for the reply and the insight. I will experiment further with the settings of the connection interval.

Can you please elaborate on the last statement "If you are using Nordic devices in both ends of the link you could implement a proprietary protocol, and send packets at a fixed rate of 1ms, but then you wouldn't be compliant with other BLE devices."

As I understand, the fastest data transfer rate between the BLE central and peripheral devices is limited by the connection interval and that can not be less than 7.5 ms in any case. When you say 'proprietary protocol', do you mean an application protocol with a 'wired' connection (like UART/SPI)? Or is there a way to be 'wireless' and still achieve the fixed rate of 1ms between the devices?

RE: Central to peripheral data transfer time

ovrebekk — Fri, 29 Mar 2019 14:57:26 GMT

The connection interval determines how often you can send packets from the central to the peripheral, or vice versa.

You can send multiple packets per connection event, but as soon as the buffers are empty and the connection event ends you have to wait for the next connection event before you can send any more data.

This is the way that a Bluetooth LE connection can reach really low average currents, by keeping the radio disabled as much as possible.

If you see a delay of ~30ms then this is probably the connection interval the central has selected. If you set min and max connection interval to 7.5ms you should get a shorter connection interval, but you can't go any lower than this unfortunately.

If you are using Nordic devices in both ends of the link you could implement a proprietary protocol, and send packets at a fixed rate of 1ms, but then you wouldn't be compliant with other BLE devices.

Best regards
Torbjørn