NRF52840 DK, SAADC, and HFXO

[Thiago]

Hello, all.

I am working on a project in which I got to sample a signal that has a minimum frequency of 1Hz and a maximum frequency of 10kHz (The full range must be faithfully sampled and transmitted) and stream the sampled data via BLE to an Android device. Overall, I made the thing work, not perfectly, however. I am having problems sampling certain frequency ranges. If I configure the SAADC:

• No Oversample mode
• Gain 1/6
• 8-bits
• Vdd/4 Reference

When configured as above, the performance is relatively good for frequencies above 5kHz. But the signal is significantly distorted for lower frequencies, especially, under 1kHz.

If I enable Oversampling, on the other hand, the data is perfectly sampled for frequencies under 1kHz, but the signal is distorted above that.

From the datasheet of the NRF52840, on the last page of the SAADC chapter, I see that the performance is increased when the HFXO is used. In the Segger Embedded Studio debugger, I see that the HFCLKSTAT, field SRC is configured as RC (HFINT source). I would like to test the sampling with the HFXO as the source.

First of all, is the ADC in the NRF52840 capable of correctly sample this whole range of frequencies? Secondly, how could I configure the high-frequency clock to have the HFXO as a source?

[Jørgen Holmefjord]

Hi,

What is the sample-rate you are using for sampling? Enabling oversampling will reduce the effective maximum sample-rate, as the SAADC needs to capture N number of samples for each channel before performing the averaging, so it makes sense that enabling oversampling may distort the higher frequency signals if the sample rate is not kept high enough. I can't explain why the lower frequency signals are distorted without oversampling though.

Can you give some example output or plots of the distorted samples compared to the original signal, to give a better understanding of the problem?

The source of the HFCLK is not configured per se, but it is used whenever it is started by triggering the HFCLKSTART task:

NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
NRF_CLOCK->TASKS_HFCLKSTART = 1;
while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);

Best regards,
Jørgen

[Jørgen Holmefjord]

The outlier-samples seems to happen quite regularly. Does these correspond to the start/end of the SAADC buffers or something similar?

Are you running offset calibration in your application? If you are, you should make sure to follow this errata.

Can you post your full project/code for us to reproduce this behavior?

[Thiago]

Hello, Jørgen. Happy new year.

I am not running offset calibration. Could it be the cause of the issue?

The code is in the uploaded file. It runs in the nRF_SDK_16.0.0. It should be placed in the \examples\ble_peripheral folder of the SDK.

BLE_SAADC.zip

[Jørgen Holmefjord]

Not running offset calibration should not cause this, but we have an errata for some of the nRF52 chips that could cause samples to be written to RAM after offset calibration if the correct steps are not taken.

I will try to test your application, but it will take some time to get hold of some signal generator for the inputs.

I see that you send the samples over BLE. Is the plots from the buffers on the nRF side, or have they been transmitted over BLE? Have you verified that the samples in the SAADC buffer match what is received on the other side of the BLE link?