Jump to content

OpenLogger ADC resolution + exporting


Recommended Posts

I'm looking at the .csv file captured using OpenLogger and Waveformslive and the output looks something like this:

image.png.70c6d8ce0ca2dc88ed1ac19dc6298d94.png 

The analogue input range is +/-10V or 20,000mV so with a 16bit ADC we should have a resolution of about 0.3mV or 0.0003V.

Why is the export limited to 1mV resolution? Can the export be updated to provide more decimal places so that the 0.3mV resolution is available?

Thanks

Link to comment
Share on other sites

Hi @sgrobler,

I have asked another engineer more familiar with WaveFormsLive to see if there is some limitation on that end regarding this. You are correct though that the resolution achievable with the embedded ADC (taking into account the front end gain of 0.1392) is 329 uV per LSB.

Thanks,
JColvin

Link to comment
Share on other sites

Hey,

As you mentioned the analog input range of OpenLogger is +/-10V and the ADC is 16-bits and your math is correct that theoretically that would result in ~0.3mV as the smallest voltage difference we can measure.  In reality every non-ideal system component starts to chip away at that precision.

For OpenLogger our tests show that we can consistently measure to about 3mV (effectively 12 bits of resolution for our ±10V range) and assuming the OpenLogger is appropriately calibrated our accuracy is typically within about 10mV due to noise and distortion.  We can improve these values by oversampling and averaging to get within about 1.5mV which results in an effective number of bits (ENOB) of about 14.

The Digilent Instrumentation protocol was originally designed to support OpenScope MZ and returned values in units of 1mV.  We decided to use the same units in our communication with OpenLogger to leverage some of the existing commands.  What you are seeing is not an error with the export, but a side effect of our decision to return values from the hardware in 1mV increments since anything beyond that resolution is noise.

Let us know if you have any questions about this.

Thanks!

-Kristoff

Link to comment
Share on other sites

Thanks for your reply. Whilst I appreciate that noise will mean you can't really realize 16bit resolution, the ADC is still going to pump out readings to a resolution of 0.3mV and that resolution could have been preserved for the file export. I would have preferred it if I could see the real numbers, not have them artificially limited by the file-export resolution of 1mV. I hoped it might be possible to simply change the export format specifiers to produce an output write resolution of 0.1mV...

Link to comment
Share on other sites

  • 1 month later...

Hi @sgrobler,

Our design engineer who designed the OpenLogger did an end-to-end analysis to determine the end number of bits of the OpenLogger. This is what they ended up doing in a summarized fashion:

<start>

They sampled 3 AAA battery inputs to the SD card at 250 kS/s and set the OpenLogger sample rate to 125 kS/s and then took 4096 samples; they then took the raw data stored on the SD card and converted it to a CSV file and exported the data for processing.

Their Agilent scope read the battery pack at 4.61538 V and as they later found from FFT results the OpenLogger read 4.616605445 V, leading to a 0.001226445 V or ~1.2mV difference, which is presuming the Agilent is perfect (which it is not), but it was nice to see that the values worked out so closely.

They calculated the RMS value of the full 4096 samples in both the time domain and using Parseval's theorem in the frequency domain as well, both of which came up with the same RMS value of 4616.606689 mV, which is very close to the DC battery voltage of 4616 mV.

Because RMS is the same as DC voltage, this gives the previously mentioned DC value of 4.616605445 V. They can then remove the DC component from the total RMS value to find the remaining energy (the total noise, including analog, sampling, and quantization noise) of the OpenLogger from end-to-end.

With the input range of +/- 10V input, this produces an RMS noise of 1.5mV.

At the ADC input, there is a 3V reference and the analog input front end attenuates the input by a factor of 0.1392, so the 1.5mV noise on the OpenLogger is 0.2088mV at the ADC. With the 16 bits (65536 LSBs) over 3V, 0.0002088V translates to ~4.56 LSBs of noise. The ENOB is a power of 2, so log(4.56)/log(2) results in 2.189 bits, giving us a final ENOB of 16 - 2.189 = ~13.8 bits.

Note though that this ENOB of 13.8 bits is based on system noise and not dynamic range, so for non-DC inputs (which will likely be measured at some point) the end number of bits is not easily determined. The datasheet for the ADC used in the OpenLogger (link) shows that the ADC itself gives an ENOB of about 14.5 bits at DC voltage (so the 13.8 bits is within that range), but at high frequencies, this of course rolls off to lower ENOB at higher frequency inputs. Thus, they cannot fully predict what the compound ENOB would be over the dynamic range, but they suspect it all mixes together and is 1 or 1.5 bits lower than the ADC ENOB response.

</end>

Let me know if you have questions or would like to see the non-abbreviated version of his analysis.

Thanks,
JColvin

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...