SAADC results unclear.

[SeanHowsonTB]

Using the NRF5 SDK V17.0.2

Once again finding myself struggling to understand the structure of the SDK as a result of lacking documentation, there seem to be so many layers of abstraction used accross the example code. functions using nrf/nrfx/nrf_drv prefixes & endless redirect header files. I'm trying to review one of the SAADC example projects. There are less than 10 annotations accross the main.c file & it's not made clear why functions are called at given times.

In my own code, I am inputting to a single ended channel of the SAADC peripheral, a sinusoid that is centred about -30mv (or sometimes 0V). The signal has been AC coupled, but in future this coupling will be removed. For now i must try to conduct some testing regardless, the negative voltage doesn't go anywhere near the -0.3V absolute maximum & features plenty of positive components.

I am using a single ended ADC channel, with a gain of 1 & resolution of 14 bits. Reference voltage 0.6V internal. The SAADC samples are coming out around 8000 (~0.3V).

When i try adjusting the resolution to 12 bits, i get samples around 2000 (again, ~0.3V).

Why is it my samples are centered around the 0.3V region. When i know they are in fact centred around 0V...

It's worth noting that the waveforms i'm seeing, while centred around the wrong value, are roughly correct & in keeping with what i would expect).

I have also noticed that if i invert my signal (signal is an ECG type signal, that i can invert by swapping chest electrodes), the ADC results, do NOT invert to match.

Am i converting the sample values to voltages correctly? (I'm following the standard equations shown on the infocentre).

[SeanHowsonTB]

Hiya,

Thanks for the answer & appreciate the insight. The ECG signal i mentioned had already been engineered to be suitable for use with the single ended input, amplified to a magnitude where resolution isn't lost, run through an INA to improve CMRR etc etc. I've now somehow managed to remove from the ac coupling from the circuit (after a great deal of agro & inappropriate tools for the job). Even if it is possible to use an AC coupled signal as you suggest above, it helped to just eliminate some variables & see a little clearer...i also didn't see your post in time before i began pulling components!.

Subsequently, without this (0.3Hz high pass) filter the signal is not centered around the midrail anyway, so, currently no need for the internal biasing, however, i do have 5 more boards which i would prefer not to modify, so i'll certainly give your approach a shot. Thanks for this!

The primary problem with the system was actually the PIN id defined for the ADC, irritatingingly simple, still not quite sure what the difference was with the two definitions i used in FW. Hence i've marked that as the answer for the thread, but i still really appreciate the input!

-Sean

[mrono]

SeanHowsonTB said:

still not quite sure what the difference was with the two definitions i used

If you follow the trail of macros for definition of NRF_SAADC_INPUT_AIN2, you'll eventually reach the bit description:

/* Bits 4..0 : Analog positive input channel */
#define SAADC_CH_PSELP_PSELP_Pos (0UL) /*!< Position of PSELP field. */
#define SAADC_CH_PSELP_PSELP_Msk (0x1FUL << SAADC_CH_PSELP_PSELP_Pos) /*!< Bit mask of PSELP field. */
#define SAADC_CH_PSELP_PSELP_NC (0UL) /*!< Not connected */
#define SAADC_CH_PSELP_PSELP_AnalogInput0 (1UL) /*!< AIN0 */
#define SAADC_CH_PSELP_PSELP_AnalogInput1 (2UL) /*!< AIN1 */
#define SAADC_CH_PSELP_PSELP_AnalogInput2 (3UL) /*!< AIN2 */
#define SAADC_CH_PSELP_PSELP_AnalogInput3 (4UL) /*!< AIN3 */
#define SAADC_CH_PSELP_PSELP_AnalogInput4 (5UL) /*!< AIN4 */
#define SAADC_CH_PSELP_PSELP_AnalogInput5 (6UL) /*!< AIN5 */
#define SAADC_CH_PSELP_PSELP_AnalogInput6 (7UL) /*!< AIN6 */
#define SAADC_CH_PSELP_PSELP_AnalogInput7 (8UL) /*!< AIN7 */
#define SAADC_CH_PSELP_PSELP_VDD (9UL) /*!< VDD */
#define SAADC_CH_PSELP_PSELP_VDDHDIV5 (0x0DUL) /*!< VDDH/5 */

So they are not equal to the gpio pin number.

[hmolesworth]

Trouble with ECG is the potentially very wide dynamic range caused by outside influences (skin, patch, silver-silver chloride, motion, sweat, etc) which have to be handled by Right Leg Drive or other compensation; offset feedback and/or AC coupling can help with that which allows a trade off between very wide dynamic range and per-bit resolution. Perhaps there is already some form of coupling around the LNA. ECG ADCs typically have 18-, 19- or 24-bit resolution to help handle this; the 12- or 14-bits on the SAADC requires some external processing. The Maxim chipset would be better than the TI chipset for this reason (and cost), as you probably know already.