DIY high resolution multi-slope converter

[Kleinstein]

Probably not it, but I wonder if there might be problems with setup/hold times on the flip flops. If the uC output toggles too close to the clock edge the flip-flop may do odd stuff

As noted before the setup time for the flipflop should be OK: some 45 ns setup and some 15 ns hold time. 74HC74 calls for a minimum of 15 ns setup and 3 ns hold time. So this looks good, like a near perfect phase setting.

I have not checked with the extra resistor. The resistor is expected to delay the clock to the µC and would thus reduce the setup time and increase the hold time.  Getting too close to the limit may let some jitter through even if inside the set-up specs.  A slightly lower clock may help - something like 8-10 MHz clock should be OK for the rest.
 
How the clock is effected is still not clear. I have 3 main suspects: one is capacitive coupling directly to the clock output pin of the oscillator and this may upset the actual oscillator inside. So the upset may cause some frequency modulation.
A 2nd possible way could be the internal state of the µC effecting the input capacitance of the clock pin and this way effecting the load to the oscillator. This may effect the frequency and the delay to the µC. I was hoping the 68 ohms resistor would reduce this effect, but the 68 Ohms are probably to low and the additional damping could be just as bad.
The ground path may introduce transient shifts for the µC and this way effect the load from the µC - however this would be more short time.

So for a new board an extra buffer is definitely a good idea.

The circuit has not really changes much in the last year or so:  I went one small step back at the slope amplifier, using diodes only and no longer the transistor as a diode substitute. With the transistor there was quite some drift in the DC level, so the ADC needed some 30 minutes of warm up before working. This was probably from to much reverse recovery with only the BE junction. It may get better with the collector connected to the base, but I have not tested yet. The diode is also not perfect - it shows a little more drift in the gain for the µC internal gain.
I think I would skip in the option to use the scaled down main reference for the µC internal ADC: The gain of the slope amplifier is not that stable anyway and the supply as reference is good enough.

For the resistors the ORN or MORN resistor array seem to be the best bet now, as they offer 50 K with low noise (comparable to LT5400) - I have not tested (only ordered), but they should work OK. The TC matching may differ, but chances are good to get good enough matching. 
I have tested the already optional ground buffer OP - it works about as good as with the direct ground. The difference is that with the ground buffer one can better use an external reference module as there would be very little load to the reference ground. Some of the candidate OPs for the integrator are available in duals - some, like OPA1678 even as duals only. A dual OP makes sense, as the current is switched between the 2 OP outputs. 

A point may be reducing the µC voltage to some 3.3 V, as the modern crystal oscillators are often only some 3.6 V max.. This would not change much with the board: The 74LV4053 switch would change to a LVT4053 and get a separate regulation - just like in the 34401.

[Kleinstein]

So I did some test with clock buffers. I have 2 gates of a 74HC14 as buffers for the clock to the µC and 74HC74 flipflop for synchronization. The buffers have 100 Ohms each at the input to reduce interaction between the buffers.  The chip is dead bug in the bottom of the board with 10 Ohms an 2.2 µF for the supply. The circuit is little similar the the clock buffers at the HP34410.

The result looks a little better (see attached curve), but not that much. The more short scale errors sill stay essentially the same, but as positive aspect the overall curve is more straight.  The curve shows the differences for 3 run-up modes. All with the same frequency, but different lengths (500 ns , 750 ns and 1125 ns) for the fixed phases. The curve with the 500 ns mode has a slope of some 30 µV over the range, that is subtracted, as it would not contribute to INL, but only to the gain.
It is not such a surprise to see a sight effect on the gain, as 500 ns are quite short compared to the settling time as the ADC. So short pulse at that level can behave different.  It is more a surprise that the shorter pulse version looks a little better than the case with sufficient time for settling.

So far for the good side. As a negative effect the extra buffers made the board quite sensitive to the shield and exact position of the cables. This looks like some nasty EMI problem, e.g. spooky RF going to the cables and coming back. In part this may be due to the not so ideal dead big construction - it was a lot better without the buffers. The scope shows quite some crap RF background on the ground and 5 V supply at some places. So this part needs some more attention.

[iMo]

Happy New Year to everybody here!
AVR vs ARM - the issue with MIPS and ARM is they are not cycle precise so you cannot do the same "precise clock counting" as with an atmegaXXX or a pic16/18/24/30/33.
I always pleaded to introduce a small fgpa (or cpld) into this design.
I made a reciprocal counter with stm32duino and the smallest fpga at that time - the ICE40LP384 (384 cells around 25 i/o, 32pin qfn, low power). You may fit everything inside and it will be clock edge accurate.
You may load the bitstream from the MCU's flash into the fpga easily (a few lines of code).
You may use schematic capture (instead of verilog) if you are more comfortable with cmos/ttl hw.

PS: fyi - atmegas have got 2FF synchronizers at their I/O pins, so there could be a random delay, when you are messing with input edges..

[Kleinstein]

For the ARM version I would use timer hardware to do the part that needs to be cycle accurate, and at least use the timer capture function to measure actual times. The important part is to know the exact times, not even to have it eactly to the cycle as planed.  I allready have quite good idea which timers to use and as far as I understood the manuals it should work in the way that the comparator signal can be used to start a timer and this creates the control signal via PWM. Another timer's capture function would measure the time when things happend. So far it looks like the signal can be all linked internally.
The delay should be about comparable to the AVR version and one would have the option to add a variable delay to replace the trimmer in the current circuit.

The nice point of using a µC is that it has the low grade ADC for the residual charge and the comparator inside. A FPGA solution would need to have an 10-12 bit ADC and comparator extra. The ADC and comparator don't need special performance, but add to the board.  Quite a few tasks would kind of need a kind of state machine in the FPGA and are more suited for a µC.  It is definitely possible to use an FPGA, but not the way for me.

I have tested a ORN resistor netzwork on one of the board:  the noise is lower than with the NOMCA resistors, though not yet so much. However this is only with the 50 K resistors replaced the divider for the reference part is still PTF56 on that board.

[Kleinstein]

Replacing the PTF56 resistors for the reference amplification with an ORN array gives the expected improvement in noise. So the noise is now good (some 500-550 nV RMS) for relatively slow modulation. The is still a little 1/f noise left, but not very much.  The board were I have changed the resistors seems to have still some switching related noise., like clock jitter of variations in charge injection. So faster modulation gives more noise.

[ogden]

PS: fyi - atmegas have got 2FF synchronizers at their I/O pins, so there could be a random delay, when you are messing with input edges..

Very good point actually. Many MCU's latch input signals with peripheral clock meaning worst case jitter equals 1/Fclk.

[Kleinstein]

PS: fyi - atmegas have got 2FF synchronizers at their I/O pins, so there could be a random delay, when you are messing with input edges..

Very good point actually. Many MCU's latch input signals with peripheral clock meaning worst case jitter equals 1/Fclk.

There is no critical timing signal going into the µC - the final last part is from the µC internal ADC and this can correct small errors from the stages before. So noise  / jitter at the comparator does not contribute (at least not much). The AVR internal comparator acltually seems to perform quite good, with less noise than had hoped for. The residual charge ADC shows a rather sharp boundary.

The 2 FF sync seems to the standard inside chips. It can be needed for signals that are asynchonous. If the signal transition comes just a t the wrong time the first FF may go in a metastable state and take a little time to decide. The 2nd FF gives it near 1 clock cycle and only than does the final sync.
I use the FF only to remove jitter - the control-signal from the AVR is allready in sync. So the 1 FF solution should be sufficient, as the timing is in the well defined range.

The weak point seems to be more like coupling troung the supply or ground, so that something effects the oscillator itself.
There may be some resonances in the RF range, that can effect the coupling and it may take only minimal disturbance to shift resonances or change coupling. I currently have no good idea how to measure - nearly looks like one may need a VNA to do DC precision design.

[ogden]

The weak point seems to be more like coupling troung the supply or ground, so that something effects the oscillator itself.

It could be, could be not. I would test - disconnect existing oscillator, build external osc powered from AA batteries + cap, no LDO. Connect it through coax + decoupling cap, look for difference if any.

[SilverSolder]

[...] nearly looks like one may need a VNA to do DC precision design.

It isn't really a DC design, in fairness?  More an AC/DC design that measures an average DC?

[Castorp]

One has to be mentally (and technically) prepared for such exercises 

Pure DC is a concept comparable to pure analog audio. AC will find its way in, either as auto-zeroing, or phase noise in adc, or something else. One should be grateful if it's actually measurable. I'm saying it from the perspective of someone who has debugged a Sigma-Delta ADC built of discrete parts... and DC SQUIDs, where the DC response is the result of black magic quantum interference and oscillations happening at many GHz.

[SilverSolder]

I had a rude awakening when I swept the output of a well respected linear lab power supply with a spectrum analyzer from 5Hz to 1MHz.  Let's just say that "DC" was present, but it was not alone! 

[Kleinstein]

The ADC circuit is using AC and timing needs to be quite accurate in some cases, so it's not pure DC.
The need to look for AC effects already starts with AZ OPs, where the AC part is not that obvious. Many modern ones include EMI filtering - but I doubt this would avoid all the possible trouble.

Luckily a VNA is no longer very expensive as it used to be. So it is a real option - no longer a funny side note. My hope is to reduce the blind try and error with decoupling.
I am afraid it needs a littel more than the simple layout rules made to avoid excessive EMI emissions.
The funny part was that the initial version of the ADC was working surprisingly good, with the analog part on a bread-board.

[SilverSolder]

[...]
The funny part was that the initial version of the ADC was working surprisingly good, with the analog part on a bread-board.

That is due to the engineering discipline known as "Black Magic"!   

[antintedo]

I have discovered an interesting noise source, not sure if you are compensating for it already as I'm not following the thread very much.

When measuring small signals, where integrator effective swing (caused only by ADC input) per measurement cycle is less than one runup step worth of voltage, large differences in average integrator voltage can occur between adjacent measurement cycles. A simple runup algorithm will randomly start the conversion in positive or negative direction based on the noisy comparator output. Under the right conditions, there is a good chance the average voltage will stay always positive or always negative for the whole cycle. As a result, assuming the reference sources cause 2V integrator swing per step, the average voltage can randomly flip between -1V and 1V. If a flip occurs, some of the charge stored in the capacitor as DA in the previous cycle will appear in the current cycle, visible as increased noise.

Take a look at this chart of 100 samples. Left and right part of the chart run at constant integrator average voltage, arrows represent 3 events where it flips back and forth. If the input voltage happens to fall in the right spot, the described effect can swamp other noise sources. At the moment this is the most significant noise source in my ADC project when measuring around 0V. Stable chart regions are around 450nV RMS (without AZ), frequent flipping can increase noise to ~800nV RMS. Estimated DA recharge of my capacitor is 150ppm for 20ms charge time.

So there is definitely some room for improvement in the runup algorithm, not only to improve noise at low voltages and during AZ cycles but to keep the DA related INL errors low. The region around -0.5V to 0.5V input is the most chaotic and simple threshold compensation like in old HP meters (34401A R406) does not handle it very well. I will try a software approach next.

[Kleinstein]

There are a few special cases (the most obvious in the center) where the pattern of the run-up changes quite a lot. I see this as a change in the average integrator voltage. I would not consider this so much a noise problem, but more a problem for the linearity (here more DNL, as a more local problem).
If everything else is working correct the result should not be influenced by the integrator pattern / average voltage so one can use this more local possible linearity problem to also judge about the more general quality and INL effects that are more difficult to measure.  For the test phase it thus makes sense to not use some averaging over different run-up starts to suppress the error, but make sure the result is good despite of the changing patterns.

For the final solution it absolutely makes sense to have different start parts for the runup and this way a kind of dithering to reduce the DNL. I have not implemented this, but only planed as a possibly last step improvement for slower conversions.

In some of the plans I already have a modified feedback (using an extra DG419 switch) in the run-up phase, to also use the signal for the average voltage. This should give a more constant average voltage and less stable run-up patterns. I have not tested this in real world hardware.

[Kleinstein]

Take a look at this chart of 100 samples. Left and right part of the chart run at constant integrator average voltage, arrows represent 3 events where it flips back and forth. If the input voltage happens to fall in the right spot, the described effect can swamp other noise sources. At the moment this is the most significant noise source in my ADC project when measuring around 0V. Stable chart regions are around 450nV RMS (without AZ), frequent flipping can increase noise to ~800nV RMS. Estimated DA recharge of my capacitor is 150ppm for 20ms charge time.

The noise level looks really good.  The excursions in the critical region also still look quite good - not as a noise level but as contribution to nonlinearity. This may be the point of worst DNL error.

It is a little odd to measure the noise in the non AZ mode - because of 1/f noise one would normally use the AZ mode anyway in a precision application. So this would be the more relevant number - it may not be so much higher: the difference gives 1.4 times the noise for white noise, but low frequency noise is suppressed.
Even if one has no switching at the input yet, one can use the difference of adjacent samples (the first point of the Allan deviation curve) as an approximation of what the AZ mode would look like.

150 ppm DA  for the capacitor already looks reasonable good. The number depends on both the charging and discharging part, so one usually has at least 2 times involved - so the comparison of just the number is difficult without knowing the exact conditions. I think I got lower DA with a C0G cap from TDK  - they are not even expensive.

I would not be so sure the error at the critical point is only from DA. There are other parasitic effects that change at the same point and can contribute to the error.

[antintedo]

This may be the point of worst DNL error.

I agree. I did some preliminary tests with a slowly slewing input voltages as well as theoretical runup simulations and this seems to be the worst region.

Even if one has no switching at the input yet, one can use the difference of adjacent samples (the first point of the Allan deviation curve) as an approximation of what the AZ mode would look like.

The noise in simulated AZ mode is around 600-650nV rms, perfectly fine. I refrained from implementing AZ until I resolve the runup issue - the discontinuity happens to be right in the spot where AZ measurement is being done at 1PLC. The result is a noise increase up to ~0.9-1.5uV no matter what the input is. The chart above is a measurement of a small voltage at the input. I can keep applying bandaids and shift the problematic region a bit but I don't think it's the correct approach.

150 ppm DA  for the capacitor already looks reasonable good. The number depends on both the charging and discharging part, so one usually has at least 2 times involved - so the comparison of just the number is difficult without knowing the exact conditions. I think I got lower DA with a C0G cap from TDK  - they are not even expensive.

Thanks for the recommendation - I am using that TDK cap I believe, at least the same series. I can recall the DA testing chart you published - what was the discharge time in your test, same as the charge time? My estimation came from observing runup patterns and their effects, I'm yet to perform standalone DA testing. Selecting a better cap alone might not be enough to mitigate DNL/INL errors related to the average integrator voltage as this DA performance is already close to what the best C0G/teflon caps achieve. It would be a good idea to reduce known and controllable error sources as much as practical.

I would not be so sure the error at the critical point is only from DA. There are other parasitic effects that change at the same point and can contribute to the error.

Which effects do you have in mind? Offsetting the comparator threshold voltage by 2V or more doesn't seem to reduce the error, so it might not be related to the sign of the integrator average. On the spot I can't think of any other sources that would be equally significant.

[Kleinstein]

600-650 nV RMS noise is really good and shows that there is not much 1/f noise. It took my quite some time to reach that noise level. The NOMCA resistors contributed about that much to the noise.

For may DA test I used some 40 ms charge time, a discharge time of some 50-100 µs (more or less the normal rundown, slightly accelerated) and than multiple readings of the reappearing voltage. A first reading sets the effective discharge time and the final reading sets the end time. So from a single curve I can get DA values for different time scales, up to the time spend for charging.
Ideally one has a charge time much longer than the rest and than effective discharge time (til initial reading) and the final reading as 2 times to set the time window. For the ADC the relevant time window should be some 100 µs (rundown time) to 20 ms (conversion time). This is still an approximation as the very fast part depends on the voltage at the end, not the average over the full conversion. So one may separate the DA part to the more fast part up to maybe 2 ms and the slow part from some 2 ms to 20 ms.

The brute force way to reduce the DA error is to increase the frequency of the modulation.
The HP way with the extra part to the comparator only gives a linear correction: not real effect of INL, but a smaller integrator swing and less effect of the DA on the ADC gain and thus still some advantage. The worst case in the center is really hard to correct - my crude idea of adding a fraction of the average voltage to the feedback in the run-up should work for most of the range, but it would not help just in the center - so I am not sure it is worth it.

Another option would be a drastically different form of the run-up, with a more continuous PWM - this would avoid trouble in the center, but may show INL errors when approaching the extremes  (e.g. > 90% or the range) when the pulses get short and the settling is no longer perfect. The simple fixed pattern type feedback is surprisingly resilient against non perfect settling and can thus use a higher modulation frequency.  The continuous PWM feedback can and must be slower. Because of the faster part of the DA it would help to have some waiting time in the run-down, like 1 run-up period.

I have a crude Idea to use the timing of the comparator for control - it needs more math (especially 1 division) and would be tricky though may work with the AVR. Chances are the continuous PWM type FB could give better performance for slow conversions (lower INL and less noise because of less switching related noise) - but it may not be as good for very fast conversions, because of a larger capacitor.

Changing the run-up (e.g. the start) to make sure the critical region is not in the AZ mode (the zero reading is not just at the bad spot) is definitely a good idea. An linearity error of some 1 µV for the worst case part would already be very good, especially if limited to a very small known range. The worst part are those errors that come unexpected.

As additional contributions to the INL I have seen some circuit parts to effect the oscillator circuit. This was especially bad with just a crystal at the µC for the clock (e.g. some 100 µV turn over error). With the canned oscillator it gets much better, though still not perfect.  I still don't know the exact source of the disturbance - it looks like some is via the supply voltage. So supply decoupling / filtering may be very important.
Another possible nasty coupling would be from the comparator to the reference or from the comparator to the integrator. Another nonlinear effect that was visible on the scope was an effect of the load current to the integrator on the OPs response and settling speed - well visible on the scope, but essentially no net effect on the INL with the simple 1 comparator test per period version. Chances are it contributes with the 2 steps per period version.

It does not need much to get an overall effect of 1 µV for the result.

[RandallMcRee]

What value of integration capacitor does the ADC require?

You should try a polystyrene cap--they have lower DA than polypropylene or C0G. Of course, they are only available in size under 22nF. (Teflon is ridiculously expensive).

If it's a size that I have I will send some along. I acquired a bunch for filter matching. I would be curious.

Randall

[Kleinstein]

I currently have 2.2 nF for one board and still 2x2.2 nF in parallel for the other (still from times with 10 K and 20 K resistors at the integrator).  Depending on the frequency for the modulation a smaller cap, like 1-1.5 nF can be sufficient. The frequency is a compromise between the DA caused error that gets larger at low frequency and the switching related errors that get larger at higher frequency. A large cap would also increase the noise for very fast conversions (e.g. < 1 ms integration).

From my tests PP, PS and the usual C0G caps had a similar level of DA, with indeed a slight lead for PS. The TDK brand C0G caps I currently have are something like 5 times lower DA than the other caps I have tested. The DA measurements are in this thread at around post 90.

My test is at the time scale relevant to the ADC - for the usual DA testing at a much longer time scale (e.g. 10 min instead of 20 ms), PS may have a slight advantage over PP, as there are less leakage currents from the surface / potting. The potting part can be a problem especially with the smaller PP ones.

[Kleinstein]

With the changes (better decoupling) to the ADC I repeated the difference test for the region around the center of the span, where the sudden change in feedback pattern happens.
The curve showns the diffence between 2 conversions with slightly different feedback mechanism ( different fixed times and slightly different  point in time when the comparator is checked - this effects the exact feedback pattern. The average (low pass filterd and measured after the conversion) integrator voltage is also shown for the 2 modes. Because of the filter there is still some combination from the other mode included.  Because of the assymetry the critical region is not at zero in my case, but alittle off. The points are the average over 50 conversions at 1 PLC. Much of the higher freuqncy noise is the normal ADC noise (~80 nV rms , ~ 500 nV_pp).

There is a little residual linearity error ( the curce shown the difference for the 2 cases), but it does not look like what one expects for the slower part of the DA (should follow the difference in average voltage).

[iMo]

A crazy idea which is rather an attempt to entertain you a little bit in these times  :
2+ years back I made a Mecrisp Forth port for the Lattice UP5k fpga part supporting its full BRAM space for the forth dictionary.  Added some features.
The forth's 16bit cpu fits in the half or less of the 5k LUTs.
There is also 128kB of SPRAM still free for use (and more resources as well).
The forth's basic dictionary occupies around the third of the 15kB BRAM.
There is 4MBytes large external flash used for the fpga's bitstream, where you may also store/load many of your forth's dictionaries with a single command off the running forth.
The "stock" cpu includes serial and 8 interrupts and a timer. The multiplication is supported in hw. Thus you have got ~2500 LUTs free for your additional hw. That is a _huge_ amount of potential space for everything related to this converter design.
Programming in forth is much easier compared to asm. 16/32bit math forth words available. Entire forth development runs on-the-chip. Only a terminal is required.
The hw part is done in verilog. There is the open source "icestorm" dev tool and free Lattice's Radiant and IceCube tools available.
The forth machine runs ok at 24MHz clock with that part, and you have ~35 I/Os available. The device is low power. An external 12bit cheapo ADC (ie. an 8pin serial one) could be wired to the fpga easily, the verilog code is easy to do (or available for some ADCs). 
The chip is 7x7mm qfn. There are small pcb modules available as well (called UPduino v1, v2, v3..)..
The author of the Mecrisp Forth has done a port to that Lattice device (supporting full BRAM) as well recently.

[ogden]

If we look at such kind of options, then I would rather suggest Cypress Psoc 5LP. Maybe even Psoc4 could do the job.

[Kleinstein]

One is free to use a different device. The demands on the µC/FPGA are not that high:  The code is some 2 kBytes with about half of this actually needed for the ADC - the rest is more for test like difference run-up versions, the DA test and so on. For the ADC even 8 bits would be suffifient and there is no high performance needed for the comparator (a LM339 quality is sufficient - though the AVR internal one seems to perform quite good). The only tricky part is to set or measure the timing during the run-down accurate. So higher porformance µCs that are hard to program cycle accurate would likely need hardware measurement of the timing, which would be enough. The simple  2 cases run-up version (like used in many other meters like 34401, 3458,..) also does not need much computational performance.

A µC instead of a FPGA is interesting as it includes the ADC and comparator - at least initially the projet was more about a simple solution.
My first version used a arduino like board (µC, clock and UART interface) and had the analog part an a bread board. From the hardware side it is still similar and on the simple / cheap side.

[SilverSolder]

I like the simple approach with an Arduino (Atmel chip) -  if it does the job, it keeps the concept easily within reach of most engineers and hobbyists.