nrfx SAADC values missing when combined with BLE

Hello,

I have been developing an embedded system where, data would be captured from analog sensors and then processed and sent by Bluetooth to a android device. In my project, I am capturing ECG data from one of the analog pin of nRF52840 DevKit. Then, I save data in a buffer and send them by BLE. In the Android phone, we have a custom App where, we would receive those data and plot them.

Problem: I face an issue of missing ADC data on the mobile App side when I am trying to send 96 samples in a Bluetooth packet (96 samples are converted to 192 bytes, as each sample is 2 bytes). When I send 48 samples (96 bytes) in a Bluetooth packet, I still have some data missed on the Mobile App side but, the problem is not severe in that case. When ADC data checked without combining the BLE part, they look fine.

Description: I have taken the SAADC example from here and merged it with blue_app_uart example. I am sampling the ADC at a rate of 1kHz and storing 96 samples in the buffer. Few of the important BLE settings are as follows,

Min Conn Interval 95 ms

Max Conn Interval 105 ms

BLE GAP EVENT LENGTH 76 (95 MS)

GAP DATA LENGTH 251

Thank you for reading my post. I would be very grateful if anyone can point out a possible solution for this case. I can also share the code here if it seems required. Please let me know.

Parents
  • Hi,

    The first item to point out is that BLE is lossless so the data you queue up for transfer is either successfully sent over, or the connection is terminated. This in turns means that the missing data you're observing is happening on the application level somewhere. If you are 100% certain that the data you receive is correct, you have to look into if something is wrong in the application when you put together SAADC + BLE.

    One thing to consider is if you queue things faster than you send it (which will fill the SoftDevice buffers) will cause issues on the next attempt to queue data to the SoftDevice.

    Could you check if that is the case?

    Could you check the error code that nus_send returns?

    If you need any assistance with checking error code sent by ble_nus_send, feel free to upload the project here and we'll have a look.

    Kind regards,
    Andreas

  • Hello,

    Thank you for your prompt response. I have tried to go through the issues you mentioned.

    I have done the following modification/checks:

    1. For the BLE transmission (Tx), I send the packet through BLE only after storing 96 samples. I also added a partial code to increase the queue size of BLE Tx. The code is as follows (this code is added inside nrf_sdh_ble.c file): 

    code:

    ble_cfg.conn_cfg.params.gatts_conn_cfg.hvn_tx_queue_size = 10;

        ret_code = sd_ble_cfg_set(BLE_CONN_CFG_GATTS, &ble_cfg, *p_ram_start);
        if (ret_code != NRF_SUCCESS)
        {
            NRF_LOG_ERROR("sd_ble_cfg_set() returned %s when attempting to set BLE_CONN_CFG_GATTS.", nrf_strerror_get(ret_code));

        }

    2. I have added an APP_ERROR_CHECK FOR ble_nus_data_send function. After putting the error check, I get an error 5 code (no error found) in my debug window. If APP_ERROR_CHECK not added, then the code runs successfully and BLE Tx is active (debug window shows BLE event 0x57 in this cases) for around 30 minutes. After 30 minutes, the BLE gets disconnected by itself. I am adding below the debug info when error check is added after bee_nus_data_send:

    Debug:

    <debug> nrf_sdh: State request: 0x00000000

    <debug> nrf_sdh: State change: 0x00000000
    <debug> nrf_sdh: State change: 0x00000001
    <debug> nrf_sdh_ble: RAM starts at 0x200034C8
    <info> SAADC: Function: nrfx_saadc_init, error code: NRF_SUCCESS.
    <info> app: SAADC evt 5
    <error> app: ERROR 5 [NRF_ERROR_NOT_FOUND] at E:\nordic_final\nRF5_SDK_17.0.2_d674dde\examples\saadc_v0.3\main.c:1034
    PC at: 0x00032441

    <error> app: End of error report

    Moreover, I think I need to describe a bit about our custom Android App. In the Android App, we are converting and combining the hex (sent from the device) to form the same values we get from the SAADC. We have considered the concept that SAADC is filling the buffer in 2's complement form while building the App. I have added 2 snapshots of the App where, i) we can see the value we are getting through BLE and ii) we can see the plotting of a real time ECG (from this view, it seems like we are missing some ADC samples)

    i)                                                   ii)

                                 

    Also, I think it will be convenient if I share the project here. At this point, the code may look little bit messy. Please pardon me for that. I will clean them up and add few more things at later stages. I am using SDK V17.0.2 and nRF 52840 DevKit. The project is as follows:

    nus_saadc_v1.3.zip

    Thank you again for your help and sorry for being late. Please let me know if you need any other info.

  • Hi,

    I looked over this together with a colleague and we have the following thoughts that you should have a look at.

    Mahfuz said:
    1. For the BLE transmission (Tx), I send the packet through BLE only after storing 96 samples. I also added a partial code to increase the queue size of BLE Tx. The code is as follows (this code is added inside nrf_sdh_ble.c file): 

    Regarding item 1 we see that you make changes directly to nrf_sdh_ble.c. We don't recommend this practice as changing the source code in the drivers might lead to issues down the line as there might be other dependencies that expects the drivers to behave as they are implemented.

    Instead if you wish to get more space for your samples, you could implement a ring-buffer that collects all the data which then dumps that data in to ble_nus_data_send whenever available. Every sample should go through the ring buffer to ensure that the data is properly organized

    Mahfuz said:
    2. I have added an APP_ERROR_CHECK FOR ble_nus_data_send function. After putting the error check, I get an error 5 code (no error found) in my debug window. If APP_ERROR_CHECK not added, then the code runs successfully and BLE Tx is active (debug window shows BLE event 0x57 in this cases) for around 30 minutes. After 30 minutes, the BLE gets disconnected by itself. I am adding below the debug info when error check is added after bee_nus_data_send:

    This must be where the data is lost. 

    You get nRF_ERROR_NOT_FOUND when you attempt to call ble_nus_data_send without a valid connection handle/without being connected. Implement some more error handling in combination with APP_ERROR_CHECK for ble_nus_data_send should give some more hints about where stuff breaks.

    For now, try out the suggestions mentioned and see if that helps narrow down the issues and implementation. As for cleaning up the project, it will help us more easily narrow where the issue might be, but no worries about that for now. If we need to revisit the code at a later stage in this support case you can consider sharing a cleaner project

    (Edit: Removed one incomplete, duplicate sentence in my reply) 

    Kind regards,
    Andreas

  • Hi,

    Thank you so much for your response. I will make the changes and modifications you mentioned and get back to you soon. I will obviously clean up the project next time I share. Sorry for any inconvenience.

  • Hi,

    Happy to help, and no worries at all about the inconvenience :) Just keep me posted if you find the solution and/or feel free to open new tickets regarding new questions that are not related to this specific topic

    Kind regards,
    Andreas

  • Hi,

    Thank a lot for your support.

    I have gone through few more debugging and my observations are as follows,

    1. The piece of code for queue size extension is removed from nrf_sdh_ble.c. Will follow this practice from now. I have adjusted the RAM size accordingly. Regarding the ring buffer, I think that can be a good way to handle the data processing. I plan to implement the ring buffer. I will update you as soon as I implement that. 

    2. I tried some more error handling with the ble_nus_data_send function. Looks like, the error code was 0x5 when it was not connected. As the device is discovered and data Tx is started from the App side, the error code changes to 0x8 and 0x13 (I had to remove the App_Error_Check to see the error message in this case).

    i) Going further, I tried to check the error messages during BLE Tx. From the observation, it looks like I am getting a number of error code 0x13 (BLE_GATTS_HVN_TX_COMPLETE retry message) in between successful BLE Tx. I am adding part of logs from the Debug window. Here it is:

    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> nrf_NUS returned:0x13
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    

    This repeats during the BLE Tx process. I am not exactly sure if this is something as expected.

    ii) Following the error messages, I then added a BLE_GATTS_HVN_TX_COMPLETE case inside ble_evt_handler() function. After adding this case, the BLE Tx tends to become slower than earlier and also looks like there is a queue for BLE Tx. I am adding part of logs from the Debug window. Here it is:

    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x13
    <warning> app: Queue full, waiting
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x13
    <warning> app: Queue full, waiting
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x13
    <warning> app: Queue full, waiting
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.

    The code added inside the ble_evt_handler is as follows:

    Code:

    case BLE_GATTS_EVT_HVN_TX_COMPLETE:

                NRF_LOG_DEBUG("HVN_TX_COMPLETE: %d", p_ble_evt->evt.gatts_evt.params.hvn_tx_complete.count);
                m_notifications_queue_full = false;

                break;

    The error handlers for ble_nus_data_send is as follows (inside main loop):

    Code:

    if (BF1==1){

    do {
    err_code = ble_nus_data_send(&m_nus,printf_buffer, &length, m_conn_handle);
    NRF_LOG_INFO("NUS returned:0x%x",err_code);
    if(err_code == NRF_ERROR_RESOURCES) {
        NRF_LOG_WARNING("Queue full, waiting");
        NRF_LOG_FLUSH();
        m_notifications_queue_full = true;
        while(m_notifications_queue_full) {
            nrf_pwr_mgmt_run();
        }
    }
    } while (err_code == NRF_ERROR_RESOURCES);
                        BF1=0;

                        }

    I have also changed the interrupt priority to 7 for nrfx_saadc and nrfx_timer following this post. But, the problem exists.

    My question is,

    Am I going to right direction with this problem?

    Can this issue be related to improper handling of "notification enabled" from peripheral side?

    When would be appropriate time to call the ble_nus_data_send function in my case?

    Please let me know if you need any info. Thank you.

Reply
  • Hi,

    Thank a lot for your support.

    I have gone through few more debugging and my observations are as follows,

    1. The piece of code for queue size extension is removed from nrf_sdh_ble.c. Will follow this practice from now. I have adjusted the RAM size accordingly. Regarding the ring buffer, I think that can be a good way to handle the data processing. I plan to implement the ring buffer. I will update you as soon as I implement that. 

    2. I tried some more error handling with the ble_nus_data_send function. Looks like, the error code was 0x5 when it was not connected. As the device is discovered and data Tx is started from the App side, the error code changes to 0x8 and 0x13 (I had to remove the App_Error_Check to see the error message in this case).

    i) Going further, I tried to check the error messages during BLE Tx. From the observation, it looks like I am getting a number of error code 0x13 (BLE_GATTS_HVN_TX_COMPLETE retry message) in between successful BLE Tx. I am adding part of logs from the Debug window. Here it is:

    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <info> app: NUS returned:0x13
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> nrf_NUS returned:0x13
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <info> app: NUS returned:0x0
    

    This repeats during the BLE Tx process. I am not exactly sure if this is something as expected.

    ii) Following the error messages, I then added a BLE_GATTS_HVN_TX_COMPLETE case inside ble_evt_handler() function. After adding this case, the BLE Tx tends to become slower than earlier and also looks like there is a queue for BLE Tx. I am adding part of logs from the Debug window. Here it is:

    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x13
    <warning> app: Queue full, waiting
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x13
    <warning> app: Queue full, waiting
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x13
    <warning> app: Queue full, waiting
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <info> app: NUS returned:0x0
    <info> app: NUS returned:0x0
    <debug> nrf_sdh_ble: BLE event: 0x57.
    <debug> app: HVN_TX_COMPLETE: 1
    <debug> nrf_sdh_ble: BLE event: 0x57.

    The code added inside the ble_evt_handler is as follows:

    Code:

    case BLE_GATTS_EVT_HVN_TX_COMPLETE:

                NRF_LOG_DEBUG("HVN_TX_COMPLETE: %d", p_ble_evt->evt.gatts_evt.params.hvn_tx_complete.count);
                m_notifications_queue_full = false;

                break;

    The error handlers for ble_nus_data_send is as follows (inside main loop):

    Code:

    if (BF1==1){

    do {
    err_code = ble_nus_data_send(&m_nus,printf_buffer, &length, m_conn_handle);
    NRF_LOG_INFO("NUS returned:0x%x",err_code);
    if(err_code == NRF_ERROR_RESOURCES) {
        NRF_LOG_WARNING("Queue full, waiting");
        NRF_LOG_FLUSH();
        m_notifications_queue_full = true;
        while(m_notifications_queue_full) {
            nrf_pwr_mgmt_run();
        }
    }
    } while (err_code == NRF_ERROR_RESOURCES);
                        BF1=0;

                        }

    I have also changed the interrupt priority to 7 for nrfx_saadc and nrfx_timer following this post. But, the problem exists.

    My question is,

    Am I going to right direction with this problem?

    Can this issue be related to improper handling of "notification enabled" from peripheral side?

    When would be appropriate time to call the ble_nus_data_send function in my case?

    Please let me know if you need any info. Thank you.

Children
  • Hi,

    Glad to hear that you're making progress. I had a chat with a colleague of mine regarding the next steps and your questions and this is what we landed on

    Mahfuz said:
    1. The piece of code for queue size extension is removed from nrf_sdh_ble.c. Will follow this practice from now. I have adjusted the RAM size accordingly. Regarding the ring buffer, I think that can be a good way to handle the data processing. I plan to implement the ring buffer. I will update you as soon as I implement that. 

    This sounds great!

    Mahfuz said:
    2. I tried some more error handling with the ble_nus_data_send function. Looks like, the error code was 0x5 when it was not connected. As the device is discovered and data Tx is started from the App side, the error code changes to 0x8 and 0x13 (I had to remove the App_Error_Check to see the error message in this case).

    The function will always return the invalid connection handle error when you attempt to call it without being in a connection. To avoid this, you should only start to send data after you have gotten the CONNECTED event. If you need to collect data also outside of a connection then you will need to implement a storage for this data for the time until a connection is made - the ring buffer could be used for this as well, just keep in mind that old data will be overwritten if the buffer is filled before a connection is made.


    What do you mean you had to remove the APP_ERROR_CHECK to see these errors?
    Please make sure that you have added the DEBUG define to your preprocessor definitions like shown in the picture, to have the logger module output a detailed error message whenever a non-NRF_SUCCESS error code is passed to an APP_ERROR_CHECK: This makes it much easier to check the meaning of the error codes against the returning functions API reference.

    BLE_GATTS_EVT_HVN_TX_COMPLETE:

    This event is useful to know how many of the queued notifications that were sent in the previous connection event. If you are using a ring-buffer then this becomes less important since you will always keep the SoftDevice buffer full, but if you did not have a ring buffer you could use this event to know that 'the SoftDevice BLE NUS notification buffer now has 3 freed up slots', for instance.

    Mahfuz said:
    I have also changed the interrupt priority to 7 for nrfx_saadc and nrfx_timer following this post. But, the problem exists.

    If the SAADC is triggered by the TIMER through PPI then there will be no issue with their triggering taking CPU priority over the main loop. Also, the SoftDevice always has the highest priority, and so there is no way that the SAADC activity can interrupt it when it needs to send data or perform any other timing-critical tasks.

    Kind regards,
    Andreas

  • Hi,

    Sorry for late reply. I am changing the code according to your suggestions. Meanwhile, I though it would be better if I share what is my approach for modification.

    What do you mean you had to remove the APP_ERROR_CHECK to see these errors?

    With the APP_ERROR_CHECK I was stuck at ble_nus_data_send. That's why I removed this line to check further. But, I understand we need this to avoid any potential problem through out the development. I will put it back in the code Slight smile.

    Also, the SoftDevice always has the highest priority, and so there is no way that the SAADC activity can interrupt it when it needs to send data or perform any other timing-critical tasks.

    Okay. Got it. Thanks!

    To avoid this, you should only start to send data after you have gotten the CONNECTED event. If you need to collect data also outside of a connection then you will need to implement a storage for this data for the time until a connection is made - the ring buffer could be used for this as well, just keep in mind that old data will be overwritten if the buffer is filled before a connection is made.

    Ok. I am changing my code based on this suggestion. As I understand, I have to send data through BLE after a connection is established and store data in ring buffer as well so that no data is lost. To deal with the "Connected event", would it be a proper way, if I set a flag inside "BLE_GAP_EVT_CONNECTED" of ble_evt_handler() and send data based on the flag status?

    just keep in mind that old data will be overwritten if the buffer is filled before a connection is made.

    In this case, what would be the strategy to determine the ring buffer size? Also, SAADC_BUF_SIZE is 96 right now. Should I change it to 1 sample in buffer and save sample by sample in ring buffer? Moreover, what should be GAP_EVENT_LENGTH in that case? Right now it is 6. I am planning to dump 96 samples(or, 192 bytes) from the ring buffer during each BLE Tx. Pardon me as, I am asking a lot of questions. So far, the discussion has helped me a lot Smiley!

    Thank you for your continuous support throughout this issue. I really appreciate your time and support. Please let me know if any info is required.

  • Hi,

    Glad to hear that you're making progress! 

    Mahfuz said:
    As I understand, I have to send data through BLE after a connection is established and store data in ring buffer as well so that no data is lost.

    Just to clarify: A ring buffer will also loose data if there aren't room to store additional data. 

    Mahfuz said:
    To deal with the "Connected event", would it be a proper way, if I set a flag inside "BLE_GAP_EVT_CONNECTED" of ble_evt_handler() and send data based on the flag status?

    Yes, this is one way to do this. Another option is to queue the data as a part of the SAADC DONE-event handling

    Mahfuz said:
    In this case, what would be the strategy to determine the ring buffer size? Also, SAADC_BUF_SIZE is 96 right now. Should I change it to 1 sample in buffer and save sample by sample in ring buffer?

    I would recommend that you decide the ring buffer size based on how fast you generate the data and how long history/how many samples back in time you wish to store

    Mahfuz said:
    Moreover, what should be GAP_EVENT_LENGTH in that case? Right now it is 6. I am planning to dump 96 samples(or, 192 bytes) from the ring buffer during each BLE Tx.

    The GAP_EVENT_LENGTH could be equal to the connection interval. This would mean that you would be able to send several packs in one connection event, up to event_length. Do note that this will increase the power consumption, but you will get a higher throughput.

    I recommend you to have a look at the Online POwer Profiler to get a look at how tweaking the various parameters will influence your transmission

    Online Power Profiler for Bluetooth LE - opp - Online Power Profiler - Nordic DevZone (nordicsemi.com)

    Kind regards,
    Andreas

Related