SAADC noise issue with Bluetooth softdevice (nRF52840)

Hi folks,

SAADC peripheral gives me good results in acquiring & converting a DC signal related to current consumption.

I am using the 12-bits configuration over the internal reference with 1/5 gain (input signal ranging from 0 to 3v). We perform sampling at 1Khz thanks to the blocking procedure named nrf_drv_saadc_sample_convert at a 10us sampling time

At this stage, if softdevice is off, we got a normal measurement and plotting histogram of the several measures shows a normal distribution according to the noise error gaussian form.

Sounds good!

However, just by starting softdevice (+8dbm level selected), things are starting to go wrong since extra noise is added to the initial signal resulting in the following histogram (do not look at absolute values which change from the previous picture):

As we see, a second noise pattern is visible on the right part giving me wrong results when averaging acquired samples.

I am using softdevice 7.0.1 and I was asking myself what kind of trick could I use to overcome this chip noise issue?

Is it chip noise issue due to radio event?

Thank you for your answer.

The best

Parents
  • Hi Jørgen,

    Sorry for the late reply;

    When you say "just by starting softdevice (+8dbm level selected)", do you mean that the softdevice is enabled, but not transmitting/receiving anything, i.e. no BLE roles enabled? 

    Yes, just advertising (Peripheral role) in long range mode with the extra +8dbm power emission. I run two measurement sessions with/without softdevice enabled.

    Do you have the DCDC regulator enabled in your application?

    No, I don't see any softdevice action to activate the DCDC regulator in our code. We use external LDO

    Here is also for information the Nordic schematic for the supply part:

    You can consider enabling oversampling in the SAADC to reduce noise, but this will take more time, and should have given similar results to what you get if averaging manually.

    Yes, for sure. In fact the second pattern noise pattern added by activating BLE acts as a second noise source apart from the histogram given with no BLE.

    Can you post the raw samples from the case with and without softdevice, to better see the difference?

    Yes of course, hereafter are freshly new raw samples for a given current consumption on our board:

    ADCCurrent.xlsx

    Thank you again for your support.

    The best.

    Sebastien

  • Sebastien DRI said:

    When you say "just by starting softdevice (+8dbm level selected)", do you mean that the softdevice is enabled, but not transmitting/receiving anything, i.e. no BLE roles enabled? 

    Yes, just advertising (Peripheral role) in long range mode with the extra +8dbm power emission. I run two measurement sessions with/without softdevice enabled.

    Ok, that makes more sense than just enabling the Softdevice without any radio activity.

    Sebastien DRI said:
    No, I don't see any softdevice action to activate the DCDC regulator in our code. We use external LDO

    You can enable the DCDC regulator using the Softdevice API sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE), but the DCDC regulator will likely cause even more noise, so I was mainly asking if it was enabled.

    Sebastien DRI said:

    Can you post the raw samples from the case with and without softdevice, to better see the difference?

    Yes of course, hereafter are freshly new raw samples for a given current consumption on our board:

    ADCCurrent.xlsx

    The document seems to contain numbers with decimals, which I believe are somehow processed from the raw samples. Do you have the int16_t results form the SAADC buffer, without any processing/calculations?

    Best regards,
    Jørgen

  • Hi Jorgen,

    You'll find hereunder the updated spreadsheet with ADC raw data displayed (simple linear voltage=>current transformation).

    ADCCurrent_bis.xlsx

  • Hi,

    Thanks for posting the raw samples. It looks like you have a difference of 14 symbols between min and max sampled value, which corresponds to ~0.34% with 12 bit resolution. I think this is well within the specifications of the SAADC peripheral (there is a gain error of +/-3%, calibrated offset error of +/- 8 LSB12b, etc).

    Are you running any (periodic) offset calibration in your application?

    Have you checked if the "offset" samples corresponds with radio activity, etc? You can use the radio notification feature or the PA & LNA GPIO toggle feature to see when the radio is active. If you use this to toggle GPIOs on radio activity and do the same when the SAADC SAMPLE task is triggered, you can see the GPIO toggling using a logic analyzer, to see if the sampling overlaps with the radio activity.

    Radio activity, flash activity, and high current consumption may cause more noise on the SAADC sampling.

    Best regards,
    Jørgen

Reply
  • Hi,

    Thanks for posting the raw samples. It looks like you have a difference of 14 symbols between min and max sampled value, which corresponds to ~0.34% with 12 bit resolution. I think this is well within the specifications of the SAADC peripheral (there is a gain error of +/-3%, calibrated offset error of +/- 8 LSB12b, etc).

    Are you running any (periodic) offset calibration in your application?

    Have you checked if the "offset" samples corresponds with radio activity, etc? You can use the radio notification feature or the PA & LNA GPIO toggle feature to see when the radio is active. If you use this to toggle GPIOs on radio activity and do the same when the SAADC SAMPLE task is triggered, you can see the GPIO toggling using a logic analyzer, to see if the sampling overlaps with the radio activity.

    Radio activity, flash activity, and high current consumption may cause more noise on the SAADC sampling.

    Best regards,
    Jørgen

Children
  • Hi Jorgen,

    Thank you again for your answer.

    More generally, thank for high level support you show at Nordic.

    I don't do any periodic offset calibration at all but we plan to further characterize  acquisition chain offset to correct in a software way.

     We don't check if offset samples corresponds with radio activity but we're pretty sure it does since it is the only difference between the twwo generated firmwares.

    I will contact you in a short time after being coming back on that subject in order to confirm/or not that hypothesis based on the method you mentionned.

    Thank you again.

Related