ADC steps to maximize resolution/accuracy

Status
Not open for further replies.
L

linuxgeek

Well-known member
I am planning on revisiting the ADC. Essentially, I want to try and get fast sample rates, on multiple channels, writing to uSD card. But initially I will work with a moderate sample rate on a single channel, writing to uSD card.

In the past, I have gotten fast sample rates to write to SDcard (50ksps), but was not able to get sufficiently clean ADC. And I'd like to get a list of things to try and see if I can make some progress. I suspect the biggest problem is the intermittent power draw of the uSD writing, and an impedance mismatch. In the past I used IntervalTimer to sample and place in a memory buffer, and within the loop checked for filled buffers to write to sdcard using sdfat library.

I've read through the various related postings, and have come across various suggestions. Many of them from Constantin's and Jp3141 posts. I've put them down as a list of things to try, and am looking on some further tips, but more importantly, help in prioritizing the list. Any input appreciated. I know it's possible to get a separate ADC, but I see this also as a learning experience. I'll try and document as a go, and post something more useful when I'm done.

Not that it matters too much, but I'll be working with T3.1 instead of T3.0 this time around.

A. No electrical connections to PC or other things with power sources. No USB, etc.

B. battery power for T3
b1. deliver power at 3.3V
b2. capacitors: 0.1uF/100uF
b3. Voltage Regulator or LDO? Best type to manage a battery source with these current levels?

C. direct battery power for uSD adapter (rather than from T3)
c1. deliver power at 3.3V
c2. capacitors: 0.1uF/100uF

D. bypass the 5V->3.3V converter (74cx125) on uSD adapter, and deliver power directly. Not sure best way to do this.

E. Use differential ADC (A10/A11 || A12/A13)

F. Use Internal Reference (1.2V)

G. Use a voltage reference chip. LM4132: http://www.ti.com/lit/ds/symlink/lm4132.pdf

H. Use a buffer for the ADC. AD8137: http://www.analog.com/static/imported-files/data_sheets/AD8137.pdf
I assume a buffer essentially acts as a continuous sample & hold.

As I'm writing this, I think I should try filling up RAM with the samples, and then writing to uSD card. And compare that to writing to uSD card in 512 byte blocks as I go. At least it will give me a good idea if it's really the uSD card power draws that are creating problems.
 
linuxgeek said:
G. Use a voltage reference chip. LM4132: http://www.ti.com/lit/ds/symlink/lm4132.pdf
Click to expand...
Yes, voltage reference chips are readily available which give initial errors in the order of 2mV on a 3V or 2.5V output, temperature drift of a few ppm, very good line regulation and reasonable load regulation.
Remember there is a certain minimum voltage needed to drive the Vref. It tends not as much as even a LDO regulator, but it still needs to be taken into account. For the one you linked to, the minimum is 400mV so with battery supplies, a mostly discharged supply should still provide at least 400mV gigher than your Vref.

linuxgeek said:
H. Use a buffer for the ADC. AD8137: http://www.analog.com/static/imported-files/data_sheets/AD8137.pdf
I assume a buffer essentially acts as a continuous sample & hold.
Click to expand...
Depending on the frequency range of the output, you don't actually want a sample and hold as the capacitor has to charge up and discharge. However, an output buffer presents the DAC with an essentially constant, high impedance load so that you don't get loading effects on the DAC. It also presents whatever you are driving with a stable, low source impedance.

If you are going as far as an off-board Vref and off board output buffer, the next logical step is to add an off-board SPI DAC as well. You can then choose a chip that has the DNL and INL specs you want, and keep its power and ground plane free from interference by digital signals from the Teensy.
 
b3) A really good LDO option for Teensy3.1 is LT1962, teensy3.1 have two chips, the MK20DX256 (with 185mA max. supply current) and MINI54TAN (with 120mA max. supply current), I suspect that it is normal to use less power ¿150mA max? see LT1762 it is the interchange chip of LT1962 (same package, same pins).

But the big issue is to write in the microSD without noise, how to solve this problem?, I thing that the way to solve this problem is in the design.
You can do a benchmark to the latency taken by your microSD (sandisk extreme pro for example) to write the buffer, this is the length of the pulse to filter, maybe I'm wrong, but it's the only light I see...
 
How about using two Teensies ? -- one for the ADC and the other just for the uSD card ? Use I2C (if it is fast enough) to communicate between them; else try SPI or SCI ?
 
Thanks for the feedback.

Is it a good idea to use 2 LDOs? One to the t3, and the other to the uSD adapter.

I was wondering about using two T3's as well. But, since the uSD card uses SPI, wouldn't it be most likely to work because there's now a dedicated power supply to the uSD card. Each T3 has it's own ground plane so I imagine that could help. But having more things electrically connected might create other problems. Just guessing here mostly, as I'm no expert. Although having another T3 could be interesting for other things too. Having an optic coupler would likely help too I imagine, but have never tried something like that.

Of course, I first need to test w/ and w/o uSD adapter, and verify that is a problem. I'll try and adapt the sketch for testing the RMS of the noise, and have it read the samples from uSDcard too.
 
There are 3+ ways the uSD card could cause noise in the T3's ADC. Here's a simplified desription.

1) SD card current consumption could cause ripple on the shared VDD 3.3 V supply. Separating the LDO would help mitigate that (although LDOs are not great at rejecting high frequency noise).
2) Common ground paths -- if some of the SD card's ground current flows through a path (i.e. part of the PCB) that is common with the T3, the resistance (and inductance) of this path effectively makes the T3 see varying 'ground' voltages and this will affect the ADC. Mitigating this ususally implies a single ground point for all the sensitive paths ('star' connection, or 'Kelvin' connection).
3) Transient currents from the SPI drive -- the input capacitance of the SD card, and the drive strength of the T3 mean that the T3 also has transients in its current consumption. Likely this is not a dominant issue. The K20 MCU has options to change the output drivers strength and slew rates; don't know if the library overrides that. Note that if you have other peripherals (or an oscilloscope / logic analyzer) connected to the same SPI, this will exascerbate the effect.
4) Capacitive or inductive coupling to the ADC's inputs (or the signals you are trying to measure) from any of the SPI or other HF digital I/O lines. Keep the inputs to the ADC short, twisted, decoupled at the T3. Be just as careful with ground as the 'real' signal. Try an experiment using the ADC to measure a T3.1's DAC output (i.e. v. short lines) and see what noise you get.
5) What reference are you using for the ADC ? Using the 3.3 VDD supply will also generate noise.
 
Last edited:
Last edited:
One option is to have multiple MCUs working the issue. If having a dedicated data logger is a true requirement, then I'd shy away from a solution that requires one MCU to do multiple things.

Instead, I'd consider dedicating one MCU (perhaps a 328P) to logging the data and queuing it for the master MCU. The Master periodically calls on the 328P to send data over (once a second?). Then manage / analyze the data and then write it to disk with the Master. I've had such serial buses communicate on board at 1Mbit/s between 328P's.

That way, the DAQ MCU can work away practically dedicated and the Master deals with all the other junk. Put the two on dedicated power supplies with a shared GND and you should be good to go.
 
If that's the solution, then I guess I'd probably use x2 teensy3.
Maybe a shield for an extra MK20 chip, wiring the SPI I/O, and using the teensy 3 to flash the 2nd MK20?
Sounds too tricky, but might make a cool product.
 
All depends on how critical it is for your CPU not to be hung up by the occasional SD-write 'burp'. Per Bill Greiman, the delays can reach 100ms, so if continuous logging is essential, you pretty much have to use a dedicated CPU that can pipe the data in batches to another CPU that can process them in lumps. FWIW, I am happy enough with the performance of the MK20 to just use as much of the RAM as I can to minimize the number of SD writes.
 
Is it possible to write ADC directly to flash memory? That should be large enough to hold the samples until the sdcard is ready.
RAM might work too, but that might be a little tight.
 
This is kind of a basic question. Does the sketch run in flash memory? And does that mean that all RAM is available to the sketch?
If so, then RAM is probably enough to hold all the samples while sdcard writes.
 
You're assuming some sort of RTOS implementation?

I'd consult with Mr. Greiman re: how the SD card would react to the CPU 'switching off' to do other things, such as responding to an interrupt request from the ADC. All depends on the length that the SD card has to wait for the CPU to pay it full attention again.

One thing that likely helps your implementation over mine is that the internal Teensy ADC operates 100% independently of the SPI bus. My logger uses the same SPI bus for the external ADC as well as the SD card, so switching between devices while the SD card is doing its 'I'm busy wait for me' thing is unlikely to solved by any solution other than using the soft SPI implementation that Mr. Greiman came up with.

Even then, I worry how interrupts might screw up bus transactions. I'd love to see a known-working implementation of a software SPI-driven ADC that uses interrupts to flag a conversion completion and a SD-card on the hardware SPI bus coexisting peacefully. In the meantime, I plan on using as much of the 64kB of RAM as possible to store data and then squirt it all in one go onto the SD card to minimize the impact on the data logging.

A back of the envelope calculation suggests I may be able to store up to an hour of data on the MK20DX256 before I'd run out of RAM for my data logger - assuming I collect second-by-second data. Since the collected data is usually compressed, the logging requirements could be theoretically stretched into multiple hours. I'd likely go for an hour limit though to minimize the impact of potential glitches. If there was easy access to the flash memory, then things could get really outrageous.
 
linuxgeek said:
This is kind of a basic question. Does the sketch run in flash memory?
Click to expand...

Yes, your compiled code runs from flash.

And does that mean that all RAM is available to the sketch?
Click to expand...

The USB stack, interrupt vectors (in 1.20) and some other stuff requires some RAM. When you compile just a simple LED blink and a few kbytes of RAM are used, that's mostly the USB stack.

All the rest of the RAM is available for your sketch to use.
 
Status
Not open for further replies.
Back
Top