This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sending SAADC data via ble_nus_data_send

Hello,

I am trying to send data obtained from a SAADC port via BLE using the ble_nus_data_send function. This must happen periodically at frequencies within the Gigahertz range, ideally.

I started with the ble_app_uart example, from SDK16. Then, I initialized a timer using PPI to trigger an SAADC sampling event, such as in the saadc example.

Inside the saadc_callback function, I process the data and call the ble_nus_data_send function, as seen bellow:

void saadc_callback(nrf_drv_saadc_evt_t const * p_event)
{
    if (p_event->type == NRF_DRV_SAADC_EVT_DONE)
    {
        ret_code_t err_code;

        err_code = nrf_drv_saadc_buffer_convert(p_event->data.done.p_buffer, SAMPLES_IN_BUFFER);
        APP_ERROR_CHECK(err_code);

        saadc2ble_convert();   
        uint16_t length = (uint16_t)UART_TX_BUF_SIZE;
        err_code = ble_nus_data_send(&m_nus, adc_output, &length, m_conn_handle);                  
        APP_ERROR_CHECK(err_code);         
    }
}

the saadc2ble_convert function simply converts the data from uint16_t to uint8_t and the length of the data transmitted via ble_nus_data_send function has not been modified from the initial example:

#define UART_TX_BUF_SIZE                256                                         /**< UART TX buffer size. */
#define SAMPLES_IN_BUFFER  UART_TX_BUF_SIZE/2
static nrf_saadc_value_t adc_buf[SAMPLES_IN_BUFFER];                   //!< Buffer used for storing ADC value.
static uint8_t          adc_output[UART_TX_BUF_SIZE]; //!< Current battery level.


void saadc2ble_convert(){

   int i;

   for(i=0; i<SAMPLES_IN_BUFFER; i++){
       adc_output[i*2] = adc_buf[i] & 0xff;
       adc_output[i*2 + 1] = (adc_buf[i] >> 8) & 0xff;
   }

}

I initialize all in the main function as seen in the next code block:

int main(void)
{
    bool erase_bonds;
    ret_code_t err_code;

    // Initialize.
    uart_init();
    log_init();
    timers_init();    
    buttons_leds_init(&erase_bonds);
    power_management_init();
    ble_stack_init();
    gap_params_init();
    gatt_init();
    services_init();

    saadc_init();
    saadc_sampling_event_init();
    

    advertising_init();
    conn_params_init();

    // Start execution.
    printf("\r\nUART started.\r\n");
    NRF_LOG_INFO("Debug logging for UART over RTT started.");



    advertising_start();

    saadc_sampling_event_enable();



    // Enter main loop.
    for (;;)
    {
        idle_state_handle();
    }
}

Debugging, I see that the SAADC is reading data well, however, I couldn't get any data at the smartphone.

I am getting the error shown on the image:

Could anyone help me to find a way to solve this problem?

Parents
  • Hello,

    Could you make sure that DEBUG is defined in your preprocessor definition, like shown in the included image?

    Enabling DEBUG will let you see which and where the error is generated.
    Please do this, and run the program again, to see the output and returning function written to the log.
    With this information, we can begin debugging and resolving the issue.

    the saadc2ble_convert function simply converts the data from uint16_t to uint8_t

    I would also alert you to the BSD utility library, and the uint16_t to uint8_t encoding / decoding functions, for future reference.

    Looking forward to resolving this issue together!

    Best regards,
    Karl

  • Thank you for your response.

    I followed your instruction and got the following messages:

  • Hello Thiago,

    Thiago said:
    Thank you for your suggestions. 

    It is no problem at all, I am happy to help!

    Thiago said:
    I fixed the NRF_ERROR_NO_MEM and modified a few parameters as described in this link. I was able to get an increase in the bandwidth and now I get transfer rates of ~51kBps.

    I am glad to hear that you were able to resolve your NO_MEM issue, and increase your throughput.

    Thiago said:
    Signals are only well reproduced if the input voltage is higher than 0.25V and lower than 1V. I expected that any voltage from 0 to 3.3V would be ok, but the signal is distorted if not in the 0.25V to 1V range. I can live with it, but I would like to know why this is happening.

    This definitely sounds strange, since the SAADC's input range is determined as specified in the documentation, which in your case should yield and input range of 0.6 V / (1/6) = 3.6V -> range: 0 - 3.6 V. When you say that the signal is distorted outside this range, what do you then mean? That the signal is not properly captured, or that the SAADC only captures values in the 0.25 - 1.0 V range? The more specific you are, the easier it will be to determine the cause of this behavior.
    Could you also tell me how you are generating this signal? Are you also monitoring it with an oscilloscope, to rule out the possibility that the signal source could be sending unexpected values? 

    Thiago said:
    Now I can successfully transmit signals with frequencies up to approximately 20kHz, but signals with frequencies in the hundreds of Hertz are appearing distorted. This is not good since this frequency range contains important information for my application. Would you happen to know what could be causing this?

    Could you confirm for me that you read my previous comment regarding Aliasing, and that you are fulfilling the Shannon-Nyquist sampling requirement? This is an elementary requirement we will have to know is fulfilled, before we can proceed with the debugging.
    Could you also confirm for me that you did in fact mean Hundreds of Hertz, and not Hundreds of Kilo Hertz?
    From your wording and previous comment, I suspect you might have been meant Hundreds of Kilo Hertz.

    Thiago said:
    This is not good since this frequency range contains important information for my application.

    It would be beneficial if you could tell me exactly which frequency range you intend to sample.

    Thiago said:
    Would you happen to know what could be causing this?

    There are many possible reasons for the sampled signal appearing distorted, but we will have to rule out the common pitfalls before we may delve deeper into this.
    Please answer my questions above, so we may proceed with the debugging.

    Looking forward to resolve this issue together!

    Thiago said:
    From the link of the ATT_MTU Throughput Example, there are two values that I couldn't find. They are the Data Length, which is defined as 27 bytes in the example, and the Connect Event Extension. Could you let me know in what file I can find them to modify their value according to the ATT MTU Throughput Example?

    Please take a look at the m_test_params structure used in the ATT_MTU throughput example.

    You might also want to take a look at this page, regarding possible throughput - this is specifically for the S132 SoftDevice, but a similar document is available for other the other SoftDevices also, please make sure you check the for the SoftDevice you are using.

    Best regards,
    Karl

  • Hello, Karl


    I tested the ADC behavior using a voltage divider with a few resistors such as the image below:

    3.3V and ground are connected to the Vcc and GND from the dev. board. I measured all the voltage values with a multimeter.

    I read the ADC data using the debugging mode and after BLE transmission, using the nrf_connect app. The ADC values are shown in the following table:

    You can see the result graphically here:

    Not shown in the graph, but as can be seen in the table, when Vin is 0V, the ADC outputs 0xFFF.

    Could you also confirm for me that you did in fact mean Hundreds of Hertz, and not Hundreds of Kilo Hertz?

    I really meant Hundreds of Hertz. We made a few tests with the ADC and found that oversampling helped to improve the graphs but it drastically reduced the transfer speed. Finally, we found that the causes of this problem were actually two:

    1. Reading the ADC data with the j-link connected to the board
    2. Using the USB from the computer to power the system. When we switched to a more stable power source this problem was fixed.

    Now that I think about that, I didn't try changing the input voltage after I used a stable power source. I will try it again and come back here to tell if it worked.

  • Hello Thiago,

    I hope you had a great weekend!

    Thiago said:
    I tested the ADC behavior using a voltage divider with a few resistors such as the image below:

    Since we are now diverging from the original ticket's issue, I would ask you to open a new ticket for the SAADC investigation - to keep the forum tidy and easy to navigate for other users.
    I will reply to your previous comment here, but I ask that you create a new ticket for any followups you might have on this new issue.

    Thiago said:
    I read the ADC data using the debugging mode and after BLE transmission

    By this, do you mean that you specifically sample when the radio is and is not active? When the radio is active, it will draw a lot of current, possibly skewing your samples ( especially if you are using VDD/4 as your SAADC reference).

    Thiago said:
    I really meant Hundreds of Hertz.

    Thank you for confirming! I just needed to make sure, since it seemed your description was leading up to hundreds of kHz-
    It sounds very strange to me that your lower-frequency signal is not recreated properly, when sampled with a frequency which succeeds at sampling a 20 kHz signal. 

    Thiago said:
    We made a few tests with the ADC and found that oversampling helped to improve the graphs but it drastically reduced the transfer speed.

    Yes, oversampling will increase accuracy - since it averages out white-noise, but it will take longer, since you need to trigger x amounts of sampling per sample outputted.
    You could alleviate this by enabling BURST with oversampling, so that the SAADC will take these samples as fast as possible.

    Thiago said:
    Finally, we found that the causes of this problem were actually two:

    I am not sure I understand you here - are you saying that the source of the behavior seen in the graph and table you posted was verified to be the stability of your power source?
    If so, I would say this is a reasonable finding.

    Thiago said:
    Reading the ADC data with the j-link connected to the board

    I do not understand what you mean by this part, please elaborate.

    Thiago said:
    Now that I think about that, I didn't try changing the input voltage after I used a stable power source. I will try it again and come back here to tell if it worked.

    It will be interesting to see if you still see this behavior with a stable power source, but as I said initially, let us continue this in a separate ticket - since it diverges from the original issue of sending SAADC data over BLE.

    Best regards,
    Karl

  • Ok, Karl.

    Thank you very much for your support. I wouldn't have advanced this much if it was not for your help.

    If I was your boss at Nordic Semi, I would give you an extra month of paid vacations!

    Thank you very much!

    Thiago.

  • Hi again,

    Thiago said:

    Thank you very much for your support. I wouldn't have advanced this much if it was not for your help.

    If I was your boss at Nordic Semi, I would give you an extra month of paid vacations!

    Thank you very much!

    I am happy to hear you say that Thiago, thank you very much! :) 

    Please do not hesitate to open a new ticket for your possible issue of power-stability's effect on the SAADC samples, or any other issue or question you might encounter.

    Good luck with your development!

    Best regards,
    Karl

Reply
  • Hi again,

    Thiago said:

    Thank you very much for your support. I wouldn't have advanced this much if it was not for your help.

    If I was your boss at Nordic Semi, I would give you an extra month of paid vacations!

    Thank you very much!

    I am happy to hear you say that Thiago, thank you very much! :) 

    Please do not hesitate to open a new ticket for your possible issue of power-stability's effect on the SAADC samples, or any other issue or question you might encounter.

    Good luck with your development!

    Best regards,
    Karl

Children
No Data
Related