Kinetis Microcontrollers中的主题 afe resolution of MKM34Z256**

afe resolution of MKM34Z256**

manfredeggersdo — Tue, 18 Oct 2016 19:22:08 GMT

Hello,

I need for a measurement application the 24bit ADC of the MKM34Z256. I use for the first steps the demo code "afe_qtimer" on a TWR-KM34Z EVM - and are a bit confused about the resolution of the ADC.

I disabled the PGA and connected SDADP with the SDADM Pin of the used channel have put the polling of the ADC into a loop and looked to the results.

Decimator Oersampling Ratio is set to 2048 - Startupcount like the demo 80U.

The ADC results looks like the least 8..9 bits are noise? That means, that from 24 bits only 15..16 bits are usable?

What could be the reasons?

Best regards

Manfred

Re: afe resolution of MKM34Z256**

xiangjun_rong — Wed, 19 Oct 2016 03:00:07 GMT

Hi, Manfred,

The AFE resolution is 1.0V/0x7FFFFF=1V/8388607=1.192*10**(-7)V.

Assume the sample is 0x1FF or 512, it is 0.06mV. 512*1.192*10**(-7)V=0.06mV.

You can connect b oth the SDADPx and SDADMx to GND to test the noise or offset.

Hope it can help you

Xiangjun rong

Re: afe resolution of MKM34Z256**

manfredeggersdo — Wed, 19 Oct 2016 06:32:47 GMT

Hello Xiangjun

Thank you for your reply.

The resolution is fine - i will need for the project approx 18 "real stable bits" resolution.

But - if I do connect the SDADPx and the SDADMx to GND and run the demo in a loop i get values like:

0xffffffe0, 0xfffffbb3, 0xfffffe72, 0xfffffa77, 0xfffffd6f...

In my eyes it looks like the least 8..10 bits are noise and not stable.

Am I wrong?

What could it be? How I can improve that?

With best regards

Manfred

Re: afe resolution of MKM34Z256**

MarMi — Thu, 20 Oct 2016 07:23:29 GMT

Hi Manfred,

device datasheet provides typical SNR of 90dB with PGA disabled, 3000 sps output data rate and 500mVp-p input signal range. This translates to around 15 stable bits (ENOB).

1) Do you need full 500 mVp-p input signal range?

If lower input signal range is needed engage PGA to get better ENOB for given lower input signal range.

2) Do you need full 3000 sps output sample rate?

If slower output sample rate is fine then perform additional software averaging. For example, if 50sps would be enough then you gain additional ~3 bits of ENOB.

If measured data are processed by algorithm that is based on accumulation and/or filtering then always averaging comes into play and will be the source for further improving resolution of computed results. We can look on your application more and do some additional math if you want.

Kind regards,

Martin M.

Re: afe resolution of MKM34Z256**

manfredeggersdo — Fri, 21 Oct 2016 12:48:16 GMT

Hello Martin,

I don't want do tell to much about the project in a community like this, but let me decribe this as following:

I need a result with min 18 stable bits - approx every 20ms.

So, I have time for a slower sample rate and software averaging.

I tried a slower sample rate - with a different Value for the register clockDivider = kAFE_ClockDivider256 but it seems to make mor worse results than better.

I tried a simple filter too - like (pseudocode):

// make a unsigned long with space for bit-shifting (Channel 0)

afe_result = (uint32_t)((AFE_GetChannelConversionValue(AFE, 0)& 0xFFFFFF)+0x7FFFFF);

// simple digital filter function
u32filter_reg = u32filter_reg - u32filter_reg >> AFEFILTERFACTOR) + afe_result;
u32filtered_result = (uint32_t)(u32filter_reg>>AFEFILTERFACTOR);

with bit-shift-factor AFE4FILTERFACTOR of 4.

So it looks like I got approx 16..17 stable bits - but I need 1, 2 bits more...

Do you got a hint for a better way?

Best regards

Manfred

Re: afe resolution of MKM34Z256**

MarMi — Fri, 21 Oct 2016 13:18:53 GMT

Hello Manfred,

keep AFE setting to output 3000 sps (AFE clocked by 6.144 MHz generated by PLL, OSR set to 2048). Accumulate 60 subsequent measurements and after final accumulation divide sum by 60 - such results will be obtained 50 times per second. Try to look on the number of stable bits of results averaged this way. My e-mail address is: martin.mienkina@nxp.com.

Kind regards,

Martin M.