Notification packets missing periodically

[Catytu]

Hello, I am working on the modified versions of hrs and hrs_c examples, on two NRF52832 with s132. I modified the apps so that when they connect the peripheral reads from a sensor (enabled data read using GPIO) and streams data in packets of 35 bytes to the central. The 35 bytes are to be sent every 20ms. With the setting I have the data is being packed and notified in the peripheral, and decoded and printed in the central quite well. Except I have two problems:

1. The last two bytes of my packet are being processed correctly in the peripheral, but the central always prints zero.

2. The second problem, and more troubling, is that periodically the data stops transmitting entirely and I am missing packets. When it happens, about 300ms of data are not sent at all.

I have attached a zip of my main and hrs files for both the peripheral and the central because I thought it better to show the entire process my boards are doing.

files.rar

It may be useful to know that the data I'm acquiring is 7 bytes per sample at 250Hz.

Any help in making the code more efficient and solving the problems I mentioned is greatly appreciated. Thank you in advance for your time.

[Marjeris Romero]

Hi Catalina,

The easiest way to check if the last two bytes of your packet are actually being sent is using the nRF Sniffer. You can also try to print the values of the buffers hvx_params.p_len and hvx_param.p_data using NRF_LOG_INFO for debugging purposes.

Secondly, you should check for error codes after calling ble_hrs_heart_rate_measurement_send(). The local attribute value may be updated even if an outgoing packet is not being sent to the peer due to an error during execution, see sd_ble_gatts_hvx.

I suspect you may have too many notifications queued, you should check if the function call will return NRF_ERROR_RESOURCES, and then call the function again before moving forward.

do {
  err_code = ble_hrs_heart_rate_measurement_send(&m_hrs, heart_rate);
  NRF_LOG_INFO("ble_hrs_heart_rate_measurement_send retuned: %d",err_code); 
} while ((err_code == NRF_ERROR_RESOURCES));

Best regards,

Marjeris

[Catytu]

I tried printing the values using NRF_LOG_INFO and I do get zero in the central but actual values in the peripheral 99% of the time. When I sent two packets of 20 bytes I did not see this problem. I'm currently implementing the sniffer.

I have implemented the print to check for errors during ble_hrs_heart_rate_measurement_send() and they always return 0. It may be that packets are being lost (doesn't seem like it) or that the peripheral is not executing the data readout continuously., although I don't see why it wouldn't.

Please note that I don't mind a lower latency as long as all the data gets sampled at 250Hz and sent through safely.

[Marjeris Romero]

Hi Catalina,

Could you check what the maximum ATT_MTU size for your project is? And which version of the SDK you are using? The default ATT_MTU max size is 247 in SDK v15.5.0 but it may be lower in older SDK versions.

In sdk_config.h:

// <o> NRF_SDH_BLE_GATT_MAX_MTU_SIZE - Static maximum MTU size. 
#ifndef NRF_SDH_BLE_GATT_MAX_MTU_SIZE
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247
#endif

[Catytu]

Hi Msromero,

I did adjust the ATT_MTU to 38 in both the peripheral and central, since I am sending 35 bytes every time. I am using SDK 14.2.0.

[Marjeris Romero]

Hi Catalina,

You are writing data outside the array, index 35 is not a valid index for array with size 35. You declared ble_data_pckt in:

uint8_t ble_data_pckt[35] = {0};

and you are writing data to ble_data_packet[35] in main:

 ble_data_pckt[35] = (*(adsData+2));

See https://www.tutorialspoint.com/cprogramming/c_arrays

In ble_hrs_heart_rate_measurement_send you also have hardcoded the length to be 35 which you will need to change as well. In general is not good approach to hardcode values.

My advice is to test your peripheral implementation together with the nRF Connect app (either for desktop or mobile app) as a central and enable notifications to debug your peripheral implementation without having to worry about bugs in the central side and check if the notification values you are getting are as expected.

When you are sure the peripheral is sending the correct data it will be easier to debug the central side.

[Catytu]

Oh of course, I'm sorry for the simple mistake. That did fix the last byte issue, but there is still something in the peripheral side that is jamming the data readout periodically. I haven't been able to figure out what process the peripheral is doing, or if its reaching the maximum number of packets, which is causing it to stop transmitting data for about 300 ms every 3.5 seconds. It will always return hvx 0 when ble_hrs_heart_rate_measurement_send is called.

Sending a 36 byte packet every 20ms doesn't seem like too much data to me...

[Catytu]

I figured it out. There was a physical problem with the sensor I was using, the BLE implementation was working perfectly fine.

Thank you for your time.

[Marjeris Romero]

Hi Catalina,

Good to hear that! I am sorry for my late answer to your last question. Have a nice day and good luck with your project.

Best regards,

Marjeris