Electronics > Metrology

DIY high resolution multi-slope converter

<< < (94/97) > >>

A small update:

The INL testing got slowed down by some likely EMI related problems. Especially if the debugger (ST-Link) is still connected there seems to be some EMI effect. This makes the INL test with my external reference (mains powered) somewhat unreliable. I tried some INL tests with just a chain of 1.5 V batteries. This looks a little better, but there is still a possible catch: the input switching in one case causes a current spike, that may effect the batteries. So the drift on the batteries is not necessary linear in time.
The turn over error curve with the batteries looks more like the expected square law curve and not as linear as the older measurements. However there is still the point at some 9.7 V (6 new alkaline cells). I have checked that point, the measurement is repeatable. At least the more normal turn over error is not really my concern, as the 20 V range suppresses this INL part quite well. There is very little turn over error in the 20 V range.

The sum test looks similar to the old results with some 4-5 µV of error.

For the difference test with 2 run-up modes shown earlier, the 2 cases to compare may have been a bit too similar and the result thus a bit too optimistic. With more different run-up modes the difference looks a little worse, but still not too bad. The plot in the attachment shows 2 cases with different modulation frequency ( 23.5 and 61.5 kHz). The run-up parts are a bit more different and especially with some offset relative to each other. The slower modulation curve looks a little better, but not much.
The idea of the comparison at different modulation frequencies is that errors due to DA get smaller with a faster modulation. Errors from switching related interference should get larger with faster modulation. The curves look different, but no clear pointing to one culprit. It looks more like a combination of both types of error: The more shorter range periodic like part (e.g. at abound -300 mV and -1.5 V) seem to be stronger with the slow modulation (this would point towards DA).

The white noise from the ADC is at some 350 nV for the 1 PLC conversions and thus some 80 nV_RMS for the data points that are the average over 20 conversions. The averaging is a balance between noise and loosing very local details of the curve. So some 500 nV_pp is the expected scattering from noise.
Different from the AVR version the noise does not change much with the modulation frequency. So clock jitter does not seem to be a problem. Less jitter also explains the lower noise.

The more step and piece-wise linear part is worse with the green curve and may be more due to switching effects (like coupling to the clock). Still not the hoped for clear result. There is no direct comparison at the some applied voltage, as with at different frequency the features also move to different voltages. The only fixed point is the center of the range with a symmetric modulation at some -310 mV.

I did a comparison with the same 2 run_up modes (61.5 kHz), but some added capacitance at 2 places: extra capacitance at the AC74 flip flop did not change much, still essentially the same curve.  An extra cap at the oscillator supply does improve things a little, though it does not effect the more periodeic part. So it looks similar to the  AVR version that the clock is somewhat part of the problem. Supply filtering at the oscillator really seems to matter.

Running the oscillator with a separate voltage regulator might improve isolation from other digital states. At low frequencies this is difficult to get with a filter.

Regards, Dieter

An extra regulator is an option for a new PCB. With the current PCB additional filtering is simpler. I am not much worried about the really low frequencies, I am more worried about the harmonics of the clock.

I am also not so much convinced that the problem is directly with coupling via the supply. It could as well be coupling via the oscillator output and vaiations in the loading. Changes in the supply are than more a secondary effect.

I have currently running a new variation, with the extra cap still in place and a larger resistor (51 ohms instead of 14.7 ohms)  in the line between the osciallator and µC. So far the result is confusing: nearly back to the case without the capacitor.

Would it make sense to buffer the oscillator? I noticed the jitter specs on some canned cmos oscillators appear sensitive to the max capacitive loading (50pF). 

I think I calculated that the stray capacitance from traces and the 2 input cmos gates (mcu/fpga gpio and synchronization flip-flop) would be around that level.
For my simple prototype, I added an optional buffer/inverter after the oscillator, but then avoided it on the theory that introducing extra switch propagation would be more likely to upset timing.

Perhaps it would be possible to check the harmonic content (and possible interference) using an independent instrument - a spectrum analyzer/vna?

Bufferig the osciallator is already there for the flip-flops. I have it planed for the µC too, but need to order a non inverting buffer. With 2 inverting buffers the phase relation is just wrong (violates setup and hold times and even seem to get random jumps, so really at the edge) with the ARM. The extra jitter to the flip-flops seems to be not an issue and jitter towards the µC would be no problem. There is currently not much trace : a 0603 size 14.7 Ohms resistor to both sides. U13 is currently replaced by a wire. Attached is the layout around the clock. U14 is the inverting buffer (NC7SZ14 , SOT 23-5 ). 

I don't have a spectrum analyser and my scope is very much on the slow side - just OK to see the approximate phase and realize that it needs 1 inverter and 1 non inverting buffer. Anyway even just the probe can make some difference and the parts are quite small. I don't see how a VNA would help, at least not a simple 1 channel version. A VNA may help with checking the supply filtering, but still a bit tricky.


[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Go to full version