This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52832 SAADC issues (wrong values)

Hello, I'm developing SAADC on nRF52832.

While developing, I have problems now.

I applied sine wave on ADC input.

And the result is displayed on the figure that I attached.

It has kind of 'spikes'. (I checked using oscilloscope and saw that input signal doesn't have problem)

Does anyone had same issue like me?

It's bigger than noise, and also they appear regularly.

Thanks a lot.

Parents
  • I saw that at 8-bit resolution and 12-bit resolution, there were no spikes like this.

    Can anyone recommend where should I look at? 

  • Have you tried to output the data on UART? E.g. NRF_LOG_INFO("%d",measurement_value);

    This could help debug if the problem is the measurement or later.

  • Sorry for late reply.

    Yes, I checked ADC through UART, and they were perfect.

    So I guess BLE has a problem, but I don't know why.

    I found that it has error when ADC values are around multiple of 256.

    For example, 256, 512, 768...

    So while 10-bit resolution and 12-bit resolution have errors, 8-bit resolution is ok.

  • So how are you transmitting those 10/12-bit values? E.g. are you bit shifting them to fit several sample values into an array, or do each 10/12-bit value use 16bit (2byte) on-air?

    Kenneth

  • #define SAMPLES_IN_BUFFER 123
    #define NO_OF_SAADC_BUFFER 2
    static uint8_t adc_ble_notify_size = SAMPLES_IN_BUFFER * sizeof(uint16_t);
    
    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;
    		buffer_number ^= 0x02; //XOR
    		saadc_event_callback = true;
    		err_code = nrf_drv_saadc_buffer_convert(p_event->data.done.p_buffer, SAMPLES_IN_BUFFER);
    		APP_ERROR_CHECK(err_code);
    		}
    }
    
    uint32_t ble_fs_send_adc_data(uint16_t conn_handle, ble_fs_t * p_fs, uint8_t *  p_data, uint16_t length)
    {
        ble_gatts_hvx_params_t params;
        uint16_t len = length;
        //p_fs->bytes_sent += len;
        memset(&params, 0, sizeof(params));
        params.type   = BLE_GATT_HVX_NOTIFICATION;
        params.handle = p_fs->adc_char_handles.value_handle;
        params.p_data = p_data;
        params.p_len  = &len;
        return sd_ble_gatts_hvx(conn_handle, &params);
    }
    
    Below is part of main function.
    for (;;)
    	{
    		if (saadc_event_callback) {
    			ble_fs_send_adc_data(m_conn_handle, &m_ble_fs, &(adc_buffer.m_buffer_ble[buffer_number * adc_ble_notify_size]), adc_ble_notify_size);
    			ble_fs_send_adc_data(m_conn_handle, &m_ble_fs, &(adc_buffer.m_buffer_ble[(buffer_number * adc_ble_notify_size) + (adc_ble_notify_size)]), adc_ble_notify_size);
    			saadc_event_callback = false;
    		}
    		idle_state_handle();
    	}

    These codes are part of my BLE.

    I put 10/12-bit values in 16bit arrays and send them.

    Thank you so much.

  • I think the problem here is on the central side. For instance it's weird that the data is always peak up when curve is falling, and peak down when curve is rising. There is nothing in BLE transfer that can cause this. It's some computation and/or display library that cause or display the data wrong I think. Maybe you can multiple all sample data on the central side with *0.5, and see how that affect the graph. Maybe you can also try to split the notifications into 3 packets and see how that affect the problem.

    Best regards,
    Kenneth

  • Wow, I found answer...

    As you said, algorithm of central side had problem.

    Thank you for advice!!! Your advice helped me to find out the problem and solution

Reply Children
No Data
Related