NHS 3152 - Conversion out of specification?

Showing results for 
Show  only  | Search instead for 
Did you mean: 

NHS 3152 - Conversion out of specification?

Contributor III

I am in the process of developing an application using the NHS3152 that requires reasonably performant analog-digital conversion and have discovered that the performance is unexpectedly poor. I am hoping there is something I can do to rectify the situation. To quantify this, I have generated the following plots. The first of these shows the relation between DAC code requested and the corresponding ADC code with the output and input MUXed together. In grey, we find data for the sweep from zero to 4095 for our custom board (which has the controller positioned within the NFC coil). In red and in blue, I have plotted the same data for the development board (controller outside of the NFC coil) with red being an internal MUX and blue being an external loop (jumper wire on the 0.1" headers)


Clearly there are large non-linearities between sequential steps that appear to be tied to the 13.56 MHz NFC communication link or other EMI (as made evident by the difference between external loop and internal MUXing).  In any (every) case, the ADC is over-reporting values on the low end and under-reporting the high end. The orange vertical line marks the point of intersection. The second figure shows the sequential difference between ADC codes, which should be equal to unity for all steps, in ideality, but instead spans +/- 50 to +/- 250 or so. Notably, this is minimized near the point of intersection.  

Figure 2023-06-19 135337.png

Some of this could be addressed through regression to correct for gain and offset errors and averaging to mitigate the effects of EMI noise (assuming that is what is at fault for this variance). However, there are also meaningful offsets with respect to voltage:

Figure 2023-06-19 151851.png

Above, blue and red are the DAC and ADC lines for the custom board whereas cyan and orange are for the development board. I should mention that our application involves a feedback loop where measurements from the ADC are used to set the output of the DAC. So it is problematic that both peripherals have different relationships with respect to actual voltage.

Figure 2023-06-20 115958.png

All of the above plots are with 0x19E written to the AD setup register, detailed here: 

Screenshot 2023-06-20 at 12.23.07 PM.png

As you can see in the above figure, I have tried various configurations. 0x3 had a particularly unexpected behavior, while 0xE and 0X19E improved slightly upon 0x2. Admittedly, I am not sure what to make of the provided description for ADOFFSETCAL in relation to these plots and cannot find additional information elsewhere. All measurements were taken with an NHS3152 operating passively with power provided by a Sony RC-S380 reader. 


If relevant, the goal of our application is to measure the impedance of electrodes at 1 kHz. We selected this chip given the NFC support and support for very thin packaging. Here is an example of the waveforms we are able to capture at the moment: 

Screenshot 2023-06-20 at 12.32.36 PM.png

Through averaging and curve fitting, we are able to achieve OK readings for known impedances (especially after various forms of correction and calibration), but would like to improve accuracy and precision through addressing the performance of the converter itself. 


  1. Is this really the performance I should expect from this nominally 12 bit SAR? I have seen a few other posts that have hinted at the ADC's non-linearity but this characterization is not favorable. 
  2. What can I potentially try to improve performance? Thanks for your time and consideration.
Tags (4)
0 Kudos
3 Replies

NXP Apps Support
NXP Apps Support

Hi jesmith,


Your analysis of the ADC and DAC is correct.

The datasheet spec points are calculated versus an ideal curve between the lower and upper limits (not being zero nor full-scale), resulting in the (poor) numbers as seen in table 24 and table 25 of the NHS3152 datasheet, but a graph of the actual transfer functions would have made things much clearer.
The ADC and DAC function share the same building blocks, so both have the non-typical behavior. (The DAC output is a sample and hold buffer on an internal node of the ADC)

The intended application of the chip was detecting the presence (or absence) of resistors in medicinal pill blisters by coarse current measurements. The implementation and spec of the ADC and DAC were deemed sufficient to do this.

An active SWD connection can cause disturbance on the ADC, f.i. during a debugging session.

The Chip_ADCDAC_XXX functions provided in the SDK use the preferred settings for the ADC and DAC registers.

To minimize pick-up of the NFC field, the loop area between analog pins and VSS needs to as small as physically possible.


Kind regards,






Contributor III

Thanks @patrickgeens. I've done some looking already and I don't think there are any alternatives that work for us, but I'm curious if you can point me to another MCU offering from NXP with a similar feature set (integrated ADC, passive NFC operation, WLCSP, flash OTA)?

I've looked at the TI RF430FRL15xH series, which is pretty similar with a 14-bit SD ADC, but its packaging is twice the height I'm looking for at ~1 mm > 500 microns (max).


0 Kudos

Contributor III

@driesmoors Tagging you here, since you have previously provided the most helpful responses with respect to this chip. 

0 Kudos