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

SAADC scan mode sample order is not always consistent

I am seeing a problem using the nRF52 SAADC with two analog channels enabled in scan mode. Essentially, channel 0 is measuring an analog signal with gain ~= 15 while channel 1 is measuring the same signal with gain = 1.

The ADC is sampled in scan mode at 4kHz into a buffer that holds 2048 samples for each channel. When I receive the interleaved buffer, I usually see that the channel 0 ADC data is at address offset 0, 4, 8, etc and the channel 1 data is at address offset 2, 6, 0xa, etc.

Unfortunately, sometimes these channels are swapped. (ie. the channel 0 data is at address offset 2, 6, 0xa,... and the channel 1 data is at address offsets 0, 4, 8, ....).

Is there anything I can do to ensure that channel 0 data starts at offset 0 and channel 1 data starts at offset 2?

Here is a printf from the code that shows the peak value of each channel as well as the buffer address:

Capture 1:

base_ptr=0x20003028, peak=1363.000000

base_ptr=0x2000302a, peak=86.000000

Capture 2:

base_ptr=0x20005028, peak=1342.000000

base_ptr=0x2000502a, peak=96.000000

Capture 3:

base_ptr=0x20003028, peak=92.000000

base_ptr=0x2000302a, peak=1352.000000

As you can see, the first two captures have the higher gain signal in the 0 offset position as expected. However, the third capture has the lower gain signal in the 0 offset position.

Is there something I need to do to the EasyDMA module to reset between captures? Currently, I am just calling nrf_drv_saadc_buffer_convert() to start a new capture.

I am using SDK version 11.0.0 and S132 version 2.0.1

  • Hi

    I have not seen this problem before that you are describing. There is saadc scan mode example here that should be similar as yours. Try to run that example and check if you get the same behavior. You probably need to set a higher sampling frequency and increase the EasyDMA sampling buffer.

    Update 6.10.2016 Make sure the buffer size is a multiple of number of configured channels. If you have two channels configured, the buffer size should be 2,4,6,8,... . If the number of configured channels is 5, then the buffer size must be 5,10,15,20,...

    Scan mode does not work on nRF52832 Engineering A IC. It should work on Engineering B, C, and revision 1.

    Update 12.10.2016 I am unable to reproduce this issue. I have made a test example that calls nrf_drv_saadc_abort when pressing button 3 on the nRF52-DK board. Sampling is resumed by pressing button 2. After If I press button 3 to stop sampling and then press button 2 to resume sampling, I get consistent SAADC output values from the two configured saadc channels before aborting and after resuming. The test example is attached and is based on this github example.

    ble_app_uart__saadc_timer_driven__scan_mode__abort_test.zip

  • The example I presented above was simplified in order to make it brief. A full examination of both channel's data shows that it is not simply a sampling rate limitation (peak error). I am sampling at 4kHz and the signal is bandwidth limited at 1kHz. The two channels' data can be compared directly and it is clear that one channel's data is always ~15 times larger than the other (at every data point). The problem is that sometimes that channel has address offset 0 and sometimes it has address offset 2.

    I am wondering if this problem could be due to the fact that my code occasionally calls nrf_drv_saadc_abort(). I am thinking there may be a bug somewhere in the driver if abort is called at the wrong time or possibly the state doesn't get cleared properly for my next call tonrf_drv_saadc_buffer_convert().

    buffer size: 2048 * 2 * sizeof(int16) = 8096 (2 byte aligned) sample rate is 4kHz

  • I have seen all kind of behavior w.r.t. scan mode. I would love Nordic engineers to take a look at scan mode, put one pin consistently at say 3.3V and another at 0V and observe all kind of interesting effects... I assume it has to do with timing issues on the peripheral bus (related to other activities on it, e.g. addressing the encryption peripheral).

    Things we have seen:

    • Swapping of channels halfway
    • Individual samples suddenly coming from another channel
    • The first sample from another channel (especially if acquisition time is set low)

    We still have to create a short example to show these cases, but didn't have time yet to do so. Anyone heavily using scan mode and relying on correct samples should encounter these things though.

    See also:

    Suggestions:

    1. Regarding not swapping channels, enabling -DNRF52_PAN_28 solved that for us although rev1 shouldn't need this PAN. Doing the scan mode in software should not be your first course of action nevertheless. It's just because we got fed up by it.

    2. Play around with the priority of ADC. Or even better, turn off BLE when doing ADC. I've never had the problem when doing just ADC. These problems arise only when more is done (e.g. a connection is set up and some information is acquired). A channel rotation also regularly occurred in our case in (the more involved) startup phase.

  • I had the channels swap every now and then, what solved the problem was to set the priority of the SAADC to 2 (or even 6) keeping the BLE enabled.

  • @Alessandro. I wish it was that simple. We're running it at 3, should be low enough.

Related