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

Incorrect sample order in high frequency ADC sampling + BLE transfer

Hello Guys,

I am running an application which is sampling 3 ADC channels at 50 MHz. I am using sample buffers of size 150 and PPI to generate a sample event every 20 microseconds. At lower sampler rates, the data position in the buffers is consistent. But as I go below a sample period of 100 microseconds, the buffer order is corrupted.

This seems to be a very common and important issue but there is really no clear cut instructions on how to fix the issue.

I have tried the tips provided here, but none of them seem to work.

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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);
/* Get average battery value */
uint16_t bat_total = 0;
/* Create Bucket from ADC Data */
sample_bucket_t* pbucket = malloc(sizeof(sample_bucket_t));
if(pbucket == NULL) return;
for(uint16_t i=0; i<SAMPLE_BUCKET_SIZE; i++){
int16_t mic_val = p_event->data.done.p_buffer[i*3];
int16_t acc_val = p_event->data.done.p_buffer[i*3+1];
bat_total += p_event->data.done.p_buffer[i*3+2];
printf("%d\n", mic_val);
pbucket->samples[i].data[0] = (uint8_t)(mic_val);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The SAADC runs with priority level = 2, and there is not much else that interrupts it other than the softdevice. In the near future I will incoorporate a feature to send a BLE packet every 10 ms.

Please can you shed more light on how the solution 1 (Use PPI to trigger START task on an END event. This will avoid the delayed triggering og the START task due to a queued interrupt generated by the END event,) from the link above should be implemented. I have tried the implied implementation but this doesnt solve this problem.

I am using the latest nRF17.0.0 SDK so I am suprised this issue still persists after soo many years. 

Please what is the best workaround for this?

Is a sample rate of 50 kHz achievable using CPU interrupts?