Interesting observation on the ADC of Teensy 3.0

Status
Not open for further replies.
I ordered some TL1431's from Digikey today. It'll be at least a few days until they arrive. I'm currently working on the flight sim USB stuff, and I play to port and test IRremote and OneWire later this week (easy, since I'm familiar with their code and I have the hardware ready), so I wouldn't be able to actually do anything for a few days anyway.

If this is still unresolved next week, please let me know and I'll hook at a TL1431 and try to reproduce the problem.
 
I'll let 'darkness' answer for his final results, but I think it should be OK. He will need at least 10 µF from AREF to AGND though (you have 0.1 µF which will oscillate with the TL1431).

Ultimately, people might find the LM-285 types easier to use -- available in a TO-92 with just 2 pins needed.
 
Paul, I consider this issue closed. Basically, as Jp3141 pointed out, I did not include a capacitor of at least 10uF to stabilise the TL1431. The inclusion of either a 33uF or 100uF capacitor (of which I happen to have on hand) solved the oscillation problem. Jp3141, just to give closure to this issue, I did write in to TI and they confirmed that there is indeed a printing error on the X-axis of that chart.

As I have posted on post #22 for the 12 bit result and post #24 for the 10 bit result on the Teensy 3, there are some inherent noise problem that I can't overcome. Using the Arduino Leonardo (post #23) gave a squeaky clean output which had almost zero noise (no tails at all on the frequency histogram plot of the ADC results).

However, in all fairness, the output of the ADC is still usable. The maximum difference in the channel means across A0 to A9 in 12 bit mode is 1.96 units (out of the max 4095 units). The standard deviation is about the same across every channel and is around 2.36. The kurtosis of the distribution is > 0 which implies excessively long tails in the distribution (i.e., increased frequency of ADC readings far beyond the average reading). This may imply that there seem to be some random uniform noise in the ADC reading as oppose to the expected Gaussian distribution.

How I intend to overcome this problem is to simply read multiple values (say, maybe 50 readings??) and then average them up (to minimise the random noise). Given a std dev of 2.36, it should still produce very usable results for my application (which I only need 1 reading per second to measure the battery voltage). As for the differences in means across the channels, since they are around ~2 ADC units which is (2/4095 x 2.5 V) = 1.22 mV, I guess I shouldn't be too worried since the component tolerances that I'm using is around 1% anyway which is higher than these channel differences.

I'm very glad that I went with the Teensy instead of the Arduino. I do not think I will get this kind of responsive, personalised and experienced tech support if I had posted this in the Arduino forums. :eek:
 
@Darkness,

First off, thanks for posting detailed data + the code that generated it!

I've wrestled with several A2D systems (remember when those were entire boards?) in which the Mux, particularly the Mux's settling time was not sufficient for it to settle to within 1 LSB, before the conversion begins. (And this "feature" was buried deep in the specs.) Insufficient Mux settling can present as sequence-dependent errors or (IMHO, even worse) voltage-dependent errors, especially if there's a big deltaV between channels that are read in sequence. I haven't looked into the details of the K20 chip's A2D, but if you can increase the Mux settling time, that might help reduce inter-channel artifacts. If you cannot change the Mux settling time, you might try reading a channel and discarding the first reading (or two) to get the Mux/Sample-and-hold settled better, and then immediately re-read that exact same channel. But I agree that making Vref stable (and accurate for making absolute measurements) is vital.
 
LarryP, thank you for your insightful post, I will give the idea of throwing away the initial readings a try.
 
Three things come to mind - a better reference, a better power supply, and potentially a better load /sample time.

For reference purposes, I like the LM4132A - 0.05% initial accuracy but a $3.37 price.

I also prefer a more stable external power supply for the Teensy. This requires you to cut the Vin/VUSB pad connection and deliver 3.3V directly to the pins in question. FWIW, I am using a TC1262 LDO voltage regulator with several hundred uF of capacitor on both sides (input and output) along with some small ceramic 0.1uF caps to keep the power supply going into the Teensy as stable as possible. I also like to have the voltage regulator off-chip because this is one less source of heat inside the chip and likely much more stable / capable also (500mA, if you believe the data sheet).

If you dig through the ADC section of the K20 manual (i.e. around page 600), you can see that the ADC sampling time can be programmed to help deal with higher-impedance loads. FWIW, the test 'load' that Freescale used was a mere 8 Ohms. Many sensor manufacturers recommend the use of a buffer / unitary gain op amp / adc driver for that reason. A TI paper that I referenced elsewhere on this site suggests that having a sampling time of about 31 time constants (i.e. RC) should allow measurements to within 1/16th of a LSB at 16 bits.

Given that the max capacitance of the ADC in the Teensy 3 is about 10pF, calculating said sample time is pretty easy if you know your load impedance. IIRC, the maximum recommended source impedance is 5k Ohm and the MUX adds another 5.6k to the overal impedance.
 
Constantin, thanks for your insights. I don't really need a 0.05% accuracy for my application, simply becoz I did not use higher precision components in my circuits (particularly, the resistors were 1% rated). But I found your comment regarding the sampling time rather interesting. Are you able to provide further guidance on how I can change the sampling time of the Teensy? So far, what I have been doing is only to average out multiple readings.

One issue regarding the impedence of my circuitry is that it should technically be very low. I connected a NiMH battery directly to the sampling points (A0 to A9) with a smoothing capacitor across the channel to ground. I'm not sure if that would be of any meaning to increasing the sampling time.
 
See page 612 of the programming guide - it shows the expected sample time as a function of resolution (lower bits = higher speed) as well as impedance (i.e. higher impedance = longer required sampling time). The sampling time is set using the ADLSMP in ADCx_CFG1, ADHSC and the ADLSTS bits in ADCx_CFG2. This allows significant fine tuning. FWIW, all my differential inputs are 4k7 Ohm type with 1.5nF capacitors.

Averaging readings is certainly a valid approach also.
 
Status
Not open for further replies.
Back
Top