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

nrf52 multiple signal sampling with softdevice

I migrated to nrf52 and countering some problems. I am trying to sample 4 pins every 2ms with SAADC.

I started with Example here.

I simply changed

uint32_t ticks = SAADC_SAMPLE_RATE_DIVIDER;
nrf_drv_timer_extended_compare(&m_timer, NRF_TIMER_CC_CHANNEL0, ticks, NRF_TIMER_SHORT_COMPARE0_CLEAR_MASK, false);
nrf_drv_timer_enable(&m_timer);

This part to

uint32_t ticks = nrf_drv_timer_ms_to_ticks(&m_timer, 2);

in order to sample every 2 ms.

Initial sampling rate works but when I change the sampling rate to 2ms, I do not get constant data transfer and connection with BLE. Also, the phone sometimes loses connection with the chip with GATT CONN TIMEOUT (err 133).

From my understanding, since ADC is triggered by PPI soft device should have a minimal effect even with fast intervals. Can somebody help me debug this problem?

Also with a soft device enabled, is using PPI the best method for triggering ADC sampling? I know that there are multiple ways to trigger SAADC sampling. Like in ble_app_proximity example, they just use nrf_drv_saadc_sample(); function and adc_event_handler

Can somebody explain the difference between using a PPI and the method used in ble_app_proximity example?

Parents
  • Hi John

    I think the SAADC is well capable of sampling with 500Hz. It should not take more than 42us to sample, so even if you take multiple samples, there should not be a problem on the SAADC side.

    There might however be a problem on the BLE side. What connection interval have you chosen? If you are sending each sample over BLE, you will overflood the softdevice with packets. The softdevice should however normally not disconnect, it should just report error and not accept packets when the softdevice buffers are full, and then accept more packets when space becomes available again in the softdevice buffers.

    Since each packet can contain 20 bytes, you could insert 10 samples into each packet, i.e. call hvx function once with 10 samples. You could also set connection interval to minimum 7.5 ms and configure the softdevice to send 6 packets (setting BLE_CONN_BW_HIGH) per connection interval to obtain maximum throughput, see the S132 v2.0.1 migration document, which is bundled within the S132 softdevice download. Look in the "Configurable bandwidth" section.

    Yes, the SAADC in the example that you point to uses TIMER and PPI to trigger SAADC sampling. When sampling is complete, the SAADC will automatically transfer the samples to RAM. When the RAM buffer is full the SAADC interrupt handler will need to process the data and CPU is needed for that.

    There is an updated example now on github that uses BLE and also scan mode to sample on multiple pins.

Reply
  • Hi John

    I think the SAADC is well capable of sampling with 500Hz. It should not take more than 42us to sample, so even if you take multiple samples, there should not be a problem on the SAADC side.

    There might however be a problem on the BLE side. What connection interval have you chosen? If you are sending each sample over BLE, you will overflood the softdevice with packets. The softdevice should however normally not disconnect, it should just report error and not accept packets when the softdevice buffers are full, and then accept more packets when space becomes available again in the softdevice buffers.

    Since each packet can contain 20 bytes, you could insert 10 samples into each packet, i.e. call hvx function once with 10 samples. You could also set connection interval to minimum 7.5 ms and configure the softdevice to send 6 packets (setting BLE_CONN_BW_HIGH) per connection interval to obtain maximum throughput, see the S132 v2.0.1 migration document, which is bundled within the S132 softdevice download. Look in the "Configurable bandwidth" section.

    Yes, the SAADC in the example that you point to uses TIMER and PPI to trigger SAADC sampling. When sampling is complete, the SAADC will automatically transfer the samples to RAM. When the RAM buffer is full the SAADC interrupt handler will need to process the data and CPU is needed for that.

    There is an updated example now on github that uses BLE and also scan mode to sample on multiple pins.

Children
No Data
Related