Trying to implement S132 SD with SDK 15.2.0 for nRF52810. Please help me understand few things.

[Manish Kaul]

I’m using nRF52810 in my design and for BLE communication I want to use Data Length Extension (DLE). Currently I’m using SDK v 15.2.0 , S112 and since DLE cannot take place in S112 but in S132, I came across that S132 has been production tested for nRF52810 SDK v14.2.0. Now since my design is currently implemented on 15.2.0, I don’t want to change my SDK version but at the same time use S132 for DLE.

Q1. Even though S132 with SDK 15.2.0 for nRF52810 is not production tested yet, can it still be implemented? If yes, what are the important considerations to keep in mind for the project to run as smoothly as it currently does with S112.

Q2. I followed shorturl.at/qrJQ7 article to see how to switch from S112 to S132 in my project and it compiled and linked successfully. I also debugged to figure out the start address of RAM and changed that in the linker file. But I’m getting a weird error (err_code=0x3002) i.e. BLE_ERROR_INVALID_CON_HANDLE as the return to the function 'sd_ble_gatts_service_add()' which is not even any of the return type for the function and if I take this function and call it somewhere else I get other errors like watchdog event. Could all this be in anyway related to compatibility between SDK 15.2.0 and S132 and is there something I need to correct in order to not get such errors ?

[Sigurd]

Hi,

For the S132 variant, only version 5.1.0 has been production tested on nRF52810, other S132 versions would not be recommended to use on the nRF52810.

If your requirement is S112 + DLE, I would instead recommend that you use S113 v7.0.1 / v7.2.0. 

Support for S113 was first added in SDK 16.

You can download S113 here:

https://www.nordicsemi.com/Software-and-tools/Software/S113

[Manish Kaul]

Okay I implemented S113 in place of S112 and am also able to extend data length to (ATT_MTU+4) bytes (but not beyond that like 247 bytes, why? )
Also , I'm transmitting PCM data from the PDM peripheral of nRF52810. Output data rate is 16000 sps which I want to stream over BLE. I use 50ms connection interval and 207bytes data length(ATT_MTU=200+3) but after first ~60 application frames (consisting of 200 bytes data) I keep loosing around 15-20 frames every 7 consecutive frames. This pattern remains same with any throughput I set the BLE for. What could be the reason ? The master (receiver) here is the nRF connect desktop app.
Given, SD is S113, SDk is 16.0.0, SoC is nRF52810, what is the max. throughput I can have ? My sample output rate is 16000Hz, bit depth is 16 bits, channel is mono; bit-rate according to this = 16000*16*1 bps = 256000bps = 256Kbps. Given the above parameters settings I've kept, I should easily be getting around 600-700Kbps, then why am I loosing data ?

[Manish Kaul]

NRF_SDH_BLE_GAP_EVENT_LENGTH  is set as 6. What exactly does it denote ?

Sigurd said:

Check if it's retuning any error-codes.

I ran a counter.

if ((err_code != NRF_SUCCESS) &&
(err_code != NRF_ERROR_INVALID_STATE) &&
(err_code != NRF_ERROR_RESOURCES) &&
(err_code != (uint32_t)BLE_ERROR_GATTS_SYS_ATTR_MISSING) )
{
APP_ERROR_HANDLER(err_code);
}

if(err_code != NRF_SUCCESS)
{
SRV_BLE_state.txErrorCnt++;

}

And it indeed increments 'txErrorCnt' many times over the course of transmission. And when I broke the flow at 'txErrorCnt' the error code was 19(0x13) which is NRF_ERROR_RESOURCES. What does it mean and please suggest how to get over it ?

[Sigurd]

Manish Kaul said:

NRF_SDH_BLE_GAP_EVENT_LENGTH  is set as 6. What exactly does it denote ?

NRF_SDH_BLE_GAP_EVENT_LENGTH is the time set aside for the connection on every connection interval in 1.25 ms units. It also indirectly sets the SoftDevice buffer size.

Manish Kaul said:

NRF_ERROR_RESOURCES. What does it mean and please suggest how to get over it ?

It means that too many notifications are queued, and that the internal SoftDevice buffer is full. If you get this error, then it means that you were not able to queue your packet.

If you are using 50ms connection interval, I suggest setting NRF_SDH_BLE_GAP_EVENT_LENGTH to 40. (40x1.25=50). After changing this, you will likely need to allocate more RAM to the SoftDevice.

[Manish Kaul]

Sigurd said:

I suggest setting NRF_SDH_BLE_GAP_EVENT_LENGTH to 40

I did this but it seemed to make no difference.

Sigurd said:

After changing this, you will likely need to allocate more RAM to the SoftDevice

Also I did not require to do this. This was my RAM start address before as well as after changing the above value to 40: '0x20003F38'

[Manish Kaul]

Sigurd said:

ble_conn_state.c
ble_advertising.c

ble-> components, I use the following files:

[Sigurd]

Manish Kaul said:

I did this but it seemed to make no difference.

Did you get the same amount of NRF_ERROR_RESOURCES errors? 

What device are you connected to ? 

Could you try to decrease the connection interval, and see if that makes any difference ?

[Manish Kaul]

Sigurd said:

Did you get the same amount of NRF_ERROR_RESOURCES errors? 

Well there were so many that I couldn;t really see that. But what what I've done right now is that I've placed the sd_ble_gatts_hvx() inside a do-while loop which will keep pushing data till it gets NRF_ERROR_RESOURCES until SUCCESS. 
But when I use another Development Kit as master, a disconnection between peripheral and master occurs after transferring data for a short while probably because the rate at which application pushes the data (every 6ms) is more than SD can transmit at Data Length=27bytes. Can you please:
1. Suggest if the do-while method is the right thing to do here for audio PCM data(DMA) ?
2. How do I enable data length extension request (DLE) from the master to the peripheral. I'm using the uart central example as master. Which function should I use to send a DLE request to my peripheral device ? nrf_ble_gatt_data_length_set() doesn't seem to do the job.

Also, why does the peripheral reset (and hence gets disconnected from the master) in a while (10-15 seconds) after continuously streaming data ? What could be the reason for that ?

Regards

[Sigurd]

Hi,

The GATT module will request a higher DLE value for you, based on the value of NRF_SDH_BLE_GAP_DATA_LENGTH. It can also be overridden by calling nrf_ble_gatt_data_length_set().

Did you increase the value of NRF_SDH_BLE_GAP_DATA_LENGTH in sdk_config.h ?

You should set it to 251:

// <o> NRF_SDH_BLE_GAP_DATA_LENGTH   <27-251> 


// <i> Requested BLE GAP data length to be negotiated.

#ifndef NRF_SDH_BLE_GAP_DATA_LENGTH
#define NRF_SDH_BLE_GAP_DATA_LENGTH 251
#endif

You can set NRF_LOG_DEFAULT_LEVEL to 4, and when the DLE is updated, you should see this in the log:

<debug> nrf_ble_gatt: Data length updated to 251 on connection 0x0.

Manish Kaul said:

1. Suggest if the do-while method is the right thing to do here for audio PCM data(DMA) ?

There is nothing wrong with it, but there are more robust ways to do it. It depends on the data rate.

Manish Kaul said:

Also, why does the peripheral reset (and hence gets disconnected from the master) in a while (10-15 seconds) after continuously streaming data ? What could be the reason for that ?

Maybe an error code was passed into APP_ERROR_CHECK(). You should add DEBUG as a preprocessor symbol, it will prevent the chip from resetting, and you can check what function returned an error-code.

What connection interval are you using now? 

What is the value of NRF_SDH_BLE_GAP_EVENT_LENGTH ?

[Manish Kaul]

Sigurd said:

Did you increase the value of NRF_SDH_BLE_GAP_DATA_LENGTH in sdk_config.h ?

You should set it to 251:

Yes I did increase the value to 207 (exact size=3+4+200bytes of data) on the master and that enabled DLE exchange which wasn't happening earlier. Now this happens even without calling nrf_ble_gatt_data_length_set(). The GATT module apparently automatically updated the Data Length. However, in the peripheral NRF_SDH_BLE_GAP_DATA_LENGTH is still set to 251.

Sigurd said:

you should see this in the log

Yes, I've already done that and get this

Sigurd said:

but there are more robust ways to do it. It depends on the data rate.

Like what ways ? Can you please elaborate on this.
Currently my MTU is 207 bytes, Data Length is also 207 bytes and if I sniff BLE packets notifications are sent using single packet of 207 bytes only (in some cases its fragmented into two, just few packets in the beginning sometimes). 

Sigurd said:

Maybe an error code was passed into APP_ERROR_CHECK(). You should add DEBUG as a preprocessor symbol, it will prevent the chip from resetting, and you can check what function returned an error-code.

Okay, I'll do that. But the disconnection part i've taken care of. It was basically mismatch in the connection parameters (conn interval) of the peripheral and master, which i guess was the reason for resetting of peripheral. Peripheral was 50ms while master was 7ms.

Sigurd said:

What connection interval are you using now?

50ms on both master and peripheral

Sigurd said:

NRF_SDH_BLE_GAP_EVENT_LENGTH

Master

Peripheral

[Sigurd]

Hi,

Manish Kaul said:

Yes, I've already done that and get this

Good.

Manish Kaul said:

Like what ways ? Can you please elaborate on this.

 The easiest thing to do is to just increase the SoftDevice buffer, so that you don't get this error(NRF_ERROR_RESOURCES ). But on the application layer, you could create your own buffer by using e.g. the SDK queue library/block allocator library, to store the data when the SD buffer is full. Then when you get the BLE_NUS_EVT_TX_RDY event, then retry the transmission.

Are you still getting NRF_ERROR_RESOURCES ? Did you try to increase NRF_SDH_BLE_GAP_EVENT_LENGTH to value higher than 40? 

[Manish Kaul]

Sigurd said:

 The easiest thing to do is to just increase the SoftDevice buffe

How ? By increasing SRV_BLE_HVN_QUEUE_SIZE ? It's currently set to 33 and I've increased it to 36, cant increase it too much as I'm using nRF52810 and its constrained on RAM.

Sigurd said:

ncrease NRF_SDH_BLE_GAP_EVENT_LENGTH to value higher than 40? 

No, I didn't but I'll try doing it. It should be within minimum and maximum connection interval right ?

Sigurd said:

Are you still getting NRF_ERROR_RESOURCES ?

No I'm not getting this error as I've implemented this

The only issue right now is while I'm transmitting PCM audio data from device using the above logic and receiving on the master and playing it back as an audio file, I'm loosing few data packets and that can be seen in the audio, how can I prevent that from happening ? Would implementing the queue/block allocator help me with it ?