can't send data via ble nus service at high speed and leads to disconnection

RE: can't send data via ble nus service at high speed and leads to disconnection

LeeJW — Sun, 06 Aug 2023 12:13:48 GMT

thanks for your reply!

i will try that to my project.

have a nice day!

best regards

LeeJW

RE: can't send data via ble nus service at high speed and leads to disconnection

haakonsh — Sat, 05 Aug 2023 08:38:59 GMT

[quote user="LeeJW"]

BTW 20kHZ sample rate was able in my project.

i was just unable to send adc value via ble more rapidly

so the problem was about throughput am i right?

[/quote]

Yes, definitely. Also, if you want to use the Nordic Uart Service as a transport layer I suggest you don't encode your data into a string representational form, but leave it as int16_t and treat the received string as a binary blob with string termination. NUS is great for prototyping, but I suggest that you create a custom service instead of using NUS. That way you can have a dedicated characteristic for sending raw data, in addition to characteristics for control and meta-data (configurations, start/stop sampling, etc).

Also, one neat feature of the TIMER peripheral is that you can capture timestamps of your ADC samples. The timestamps are useful if the datastream is interrupted/corrupted as you'll have reliable points of reference for parsing the received data. You'll be able to buffer a few seconds of data in local RAM if the link is interrupted for any reason, or if the link throughput momentarily falls below your datastream throughput requirements.

You can start a TIMER at the same point in time as you start a sampling session and periodically capture its value using the same signal that triggers SAADC sampling. A TIMER's CAPTURE task will record its own counter value and place it into one of its 5 CAPTURE/COMPARE registers that can be read by the CPU at a later point. You won't be able to reliably read timestamps with the CPU at 20kHz or even 500Hz, but you can capture timestamps for every 'x' number of samples. F.ex. once per block of samples that will fit inside a BLE payload.

RE: can't send data via ble nus service at high speed and leads to disconnection

LeeJW — Fri, 04 Aug 2023 04:02:56 GMT

Hi haakonsh

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(30, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(30, UNIT_1_25_MS)

NRF_SDH_BLE_GAP_DATA_LENGTH 251

NRF_SDH_BLE_GAP_EVENT_LENGTH 6 to 320

NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247

SAADC_SAMPLES_IN_BUFFER 4 to 8

also used

void conn_evt_len_ext_set(void)
{
ret_code_t err_code;
ble_opt_t opt;

memset(&opt, 0x00, sizeof(opt));
opt.common_opt.conn_evt_ext.enable = 1;

err_code = sd_ble_opt_set(BLE_COMMON_OPT_CONN_EVT_EXT, &opt);
APP_ERROR_CHECK(err_code);
}

yeah increasing NRF_SDH_BLE_GAP_EVENT_LENGTH and SAADC_SAMPLES_IN_BUFFER

solved above problem

BTW 20kHZ sample rate was able in my project.

i was just unable to send adc value via ble more rapidly

so the problem was about throughput am i right?

there are so much more things i must learn about this stuff !!

thanks for your help haakonsh

best regards

LeeJW

RE: can't send data via ble nus service at high speed and leads to disconnection

haakonsh — Thu, 03 Aug 2023 21:38:45 GMT

What is you connection interval, Event, length, MTU size, and LL packet size?

I think you're running a connection interval of 20ms, event length of 7.5ms, MTU of 27, and LL of 31, as that is the default params.

If that is in fact the case I suggest you increase the MTU and LL packet sizes, as well as the SAADC buffer sizes.

Do you have any real-time latency requirements?

I suggest you don't convert the samples from int16_t to float before transmission. A float requires at least 32bit so you need 2x the throuput to transmit the same amount of data. Also a 32bit float might loose a bit of precision, and it's best to use int16_t until you can convert to float on a larger machine. Also the float conversions will require a significant amount of power on the Cortext-M4F CPU.

I also suggets you enable at least 8x oversampling and increase the sample rate significantly. The SAADC will not use much more power while sampling extra samples for oversampling.

There's no reason why you should not be able to get up to 20kHz sample rate (including 8x oversampling) with an nRF52840 in both ends of the BLE link in an average RF environment. Though the average current consumption will increase to ~10-12mA at that sample rate and throughput.