Question on analogue input (ADC) performance

patrikdj

Hi,

I am doing some tests on a metawear using one of the analogue inputs (ADC).

When checking the specification (metawearPPSv0.6.pdf) I read about that there seems to be different modes for the ADC, 8-bit mode, 9 bit mode and 10 bit mode, and I am especially interested in the 10 bit mode. The 10-bit mode is the one used, right?

Assuming 10-bit mode is used, I am interested in the accuracy that can be achieved. Could you explain a bit on this?

My understanding is that 10 bits (2^10=1024) in a 3V system correspond to 3V/1024=30mV approximately, and I try to understand the specification points in the document. Please explain.

Another related question is if there are any features in the FW for averaging samples from the ADC in order to improve accuracy?

(If possible I would like to achieve around 20mV accuracy in a 3V system, and I don't know if this is feasible.)

Thanks in advance!

Matt

Hi patrikdj,

The MetaWear firmware is always set to use the 10-bit mode.

You are correct about the number of bits and how that affects the resolution, except that 3V/1024 would be 3mV per step.

In terms of absolute accuracy, it will be subject to the ADC's offset voltage, and the voltage reference accuracy if you are using the absolute reference mode.  They will contribute a worse case of around 60mV offset.

So, you will be able to see changes of down to 3mV on the input, but their measurement against the absolute voltage will only be within 60mV.  This offset will be consistent over the input range, so it meets the needs of many applications where the relative change is most important.  You could consider a simple form of calibration on the app side if higher accuracy rather than resolution is required.

With our recently released "Data Processing" module in the firmware, you can apply an average of N to the output of the ADC to increase the resolution.  If there are enough requests, we could add an "oversampling" feature to the ADC.

Let me know what you are measuring and I may be able to comment about the accuracy for that use case.

patrikdj

Hi,

Thanks. Regarding the ADC offset it would be helpful with some kind of offset calibration as you suggest, based on a known precise input signal level (or possibly several levels). And this could be handled in the app, while it would be also nice (better?) to handle it in the FW as cal offset value(s) stored in flash memory. Perhaps a nice to have feature for future releases?

For us we actually want to measure a DC level coming from an external battery (not the battery included that powers the Metawear board) and measurements only need to be logged every minute or so.  This suggests that we would benefit from doing oversampling. Could you kindly elaborate a bit more on the averaging capabilities in FW that you mention above vs. oversampling?

I will do some experiments here and come back on my findings.

Matt

We will give some thought to how an ADC calibration feature might work in the FW.  A static offset cannot easily be applied to a supply relative measurement, due to the varying supply voltage.  With the data processing module, it is now possible to apply a static offset to any ADC samples before logging them.  We have a feature in development that will enable such rules to be restored on power loss.  This is roughly equivalent to applying a calibrated offset from flash, but user configurable.

Oversampling is really a form of averaging, typically just highly integrated in the measurement source, and returned as a sum rather than an average.  An oversampled measurement might consist of 2-4-8 or more samples taken in rapid succession, and then summed together to form a higher bit result.  It is useful for increasing resolution and detecting relative changes, but would not improve the absolute accuracy in your case.

Our averaging filter would allow you to average samples in rapid succession as in oversampling, or you could use it to average the value over a longer period of time.  In your example, you may do an average of 16 over the course of your minute to balance out any load dependent variation.  Using the data processing feature we recently released, the averaging depth can be adjusted via the mobiles APIs.

patrikdj

Hi Matt, Thank's a lot for excellent support. Let me digest and come back in case of further questions.