1kHz sampling rate with custom characteristic vs NUS via Android vs via PC

[xproto]

I created a BLE device with custom characteristic showing the sensor value (int16). But I can't achieve 1khz sampling rate.

1. Is sending data via NUS faster since the central reads its receive buffer instead of reading the custom characteristic everytime of the peripheral device? Is 1kHz sampling rate doable for both option? 

2.  With android since the minimum possible interval is 7.5ms , it means I can't achive 1khz sampling rate? How about in pc (windows10)  is this doable?

TIA

[Jørgen Holmefjord]

Hi,

What are you sampling from?

Bluetooth LE have a minimum connection interval of 7.5ms, so you will not be able to send data faster than this. If you do not need to receive the sampled data at 1kHz rate on the phone/PC side, you can buffer multiple samples on the nRF side and send it in a larger chunk every 7.5ms.

Best regards,
Jørgen

[Jørgen Holmefjord]

xproto said:

I needed the data to render a graph for visualization and do computation so the more the samples the better but I'm only targeting 1kHz. 

My point was that if you do not need to receive every sample at each interval (e.g. 1 sample every 1ms), but can buffer up multiple sample (e.g. 20 samples from the last 20 ms), then you can send the samples over BLE in one transfer. This allows you to send much more data than sending a single sample at every connection interval.

xproto said:

Attach is my current setup with 16bit value.
If I decided to send it every 20ms then 20*2 = 40bytes. I prefer custom characteristic but is this still doable with this setup since its too big or is array permissible with characteristic?  Or do I need to switch to NUS?

Using a custom service is totally fine, but you may need to modify it a bit if you want to follow my above suggestion to send larger number of samples in each transfer. The characteristics can support variable length. NUS is also a custom service, defined by Nordic to send variable length strings over BLE.

xproto said:

And based on what I have read I have to change the MTU size since the default is 23bytes?

If you want to send notification with larger size than the current MTU size, you need to increase it yes. There are also other parameters that can help you increase the throughput (DLE, connection event length extension, 2M PHY, etc), see Bluetooth Low Energy data throughput.

[xproto]

Jørgen Holmefjord said:

My point was that if you do not need to receive every sample at each interval (e.g. 1 sample every 1ms), but can buffer up multiple sample (e.g. 20 samples from the last 20 ms), then you can send the samples over BLE in one transfer. This allows you to send much more data than sending a single sample at every connection interval.

Ok I misunderstood this on the first reply, that will do as long I have still 1ms interval data displayed on UI.
I tried doing this but my UI suffered too much delay for many seconds.

Jørgen Holmefjord said:

Using a custom service is totally fine, but you may need to modify it a bit if you want to follow my above suggestion to send larger number of samples in each transfer. The characteristics can support variable length. NUS is also a custom service, defined by Nordic to send variable length strings over BLE.

I'll have to try packing bigger data and rendering it at once at the UI and see if it will make a difference. 

Jørgen Holmefjord said:

If you want to send notification with larger size than the current MTU size, you need to increase it yes. There are also other parameters that can help you increase the throughput (DLE, connection event length extension, 2M PHY, etc), see Bluetooth Low Energy data throughput.

Ok I will look into this and reply here again if ever I have problems regarding this matter

Thanks again