(Yet Another) DIY Multislope ADC

[iMo]

I've updated above table, there are RDN and RDP "fixed" clocks (5 as an example), and the zero values returned by RDN and RDP (an example) to see the runup values and diffs, where the RDP always returns at least "1" (we make the decrement before the comparator check).

Also my understanding is the rundown process above returns max 31n+1p (or 0n+30p) "net" counts, where one count == 2 SM clocks (thus rundown_resolution = runup_resolution/60 ).

[iMo]

Here is the excel table you may play with v1.0.
If you may find an issue pls do report..

PS: the formula used:

Code: [Select]


Vin = (Vref * Rin / Rref) * (PWMcharge * (2 * RUPN - MS_N) + 2 * ( 2 * RDN - RDNP + 1)

          + RDNfix - RDPfix) / (PWMperiod * MS_N)


Update: v1.1 with fixed PWM clocks input
Update: v1.2 with fixed rundown calculation
Update: v1.3 with fixed rundown calculation - the RDPfix and RDNfix are single SM clock values, RDP and RDN are 2 SM clocks counter values
Update: v1.4 fix - everything shall be related to 56 SM clocks of charge (PWM_charge)..

[Kleinstein]

The run-up modulation with a 4/60 or 60/4 modulation has a usefull part of 60-4 = 56 cycles that are actually modulated. It is not just the 4 cycles that are effectively lost, but also the 4 the other polarity.
Depending on the integrator hardware 4 cycles (500 ns) for the shortest pulses and settling looks about right.
This gives the residual charge a range of about +-60 cycles range. depending on the delay between reading the comparator and the start of the feedback the range may get a little larger than just 1 feedback step. This way the run-down part could get a little larger than just -31 to + 30 counts. The range is more approximate than accurately calculted through.

A big question is how good the jitter is and if one needs / wants external synchronization to a more stable clock. Chances are the clock from the RP pico is not good enough and would at least need an external oscillator. It is not so much jitter, modulation of the crystal frequency depending on how neighboring pins are set or how much current is drawn. At the very least the pins for the ref. modulation should be away from the clock.

[iMo]

Updated to a perhaps the final version, where I returned to the traditional formula, which works properly only when the rundown charges are related to the "PWM charge" (56 in our case above).

The rundown range is +/- (0..27) counters diff counts (that is 56 SM clocks, also mind there are the RDN and RDNP inputs now as per the PIO source). The rundown now returns "reasonable" values, imho, which fit the both resolutions "smoothly".

For example the above runup resolution is 9800uV and the rundown resolution 175uV in 56 steps.

Still the question is how to handle the +/-1 noise in the rundown results and the incorporation of the noisy auxADC results..
 

[NNNI]

I finally took the time to read through all of the messages posted and process them properly.

I think I finally see some merit in removing as much charge from the integrator as the clock resolution will allow. As per the Landsberg rundown scheme, if I use the same clock to carry out rundown as I use for runup, the rundown counts can basically just be added to the runup counts. This eliminates the need for more constants that would need to be calibrated somehow. The effects of comparator hysteresis can be removed to a large extent by using some kind of zero-crossing slope amplifier, similar to the one described by Jim Williams in National Semiconductor App Note 260. This way, we don't need to add a certain amount of clock cycles' worth of charge into the integrator to compensate for comparator hysteresis. The board I designed has a footprint for such a slope amplifier, but I removed it since it had some issues. I will have to experiment with it some more. The residue ADC will have to digitize a much smaller integration range, I guess calculating that range mathematically and figuring out gain such that the small amount of charge left in the integrator spans the residue ADC's range will be most beneficial.

Of course, the latter part depends on the integrator starting and ending within that specific limited range. Dithering might necessitate a larger voltage range on the residue ADC. I will have to play around with my board to see what kind of numbers I get.

Regarding jitter, the numbers from a crude test performed by a friend indicate around 50ps RMS jitter, measured between successive rising edges of a GPIO toggling at 20MHz (done using PIO) with a 400MHz overclock. I am not sure how much of this comes from the crystal and how much from the PLL, and if a better crystal will make a difference. More (proper!) measurements will have to be made.

[Kleinstein]

The crystal clock jitter is usually on the order of 1 ps RMS. So the measured 50 ps are most likely mostly from the PLL.  This number also makes sense - it is about what the STM32G071 datasheet gives for a different µC with internal PLL. Jitter is usually not 100% white phase noise, but may have some extra lower frequency component. So when the clock is divided down (even with an ideal divider) the period jitter can go up. For the mudulation patter (some 5-20µs period) the effective noise could be a littler higher than the period jittter.

The noise added from jitter is about RMS jitter divided by the integration time times the reference strenght times the square root of the number of ref. switching events. As a number example maybe 50 ps / 20 ms * 28 V * sqrt(4000) = 4.4 µV rms.

50 ps jitter would add a noticeable noise source to the ADC, especially when using relatively fast modulation. It could still be OK for the 6-7 digit range. For lower noise one would likely need external synchronization directly to a stable clock. This could bring the jitter down to the 1-3 ps range.

[NNNI]

Thanks for the example calculation, it was very insightful.

There is always the option of running the RP2040 without a PLL from an external 48MHz clock (which would also work out in terms of timing, 48MHz is exactly half of the 96MHz I chose for the previous code). I am not sure if this would yield much improvement.

Would I be right in assuming that the faster a logic IC is meant to be clocked, the lower the jitter? For example, the SN74LVTH273 [1] can be clocked at up to 150MHz. The latch can be clocked from the same oscillator that is feeding the RP2040, that might help with synchronization issues.

[1]: https://www.ti.com/lit/ds/symlink/sn74lvth273-ep.pdf

[Kleinstein]

The faster locic chip usually add less jitter, though it is not a direct link. I had a hard time finding some jitter specs for the logic chips. An an analog devices application note (AN 501) there are a few numbers:
74HCT... ~ 2.2 ps
74ACT... ~ 1 ps
74LS...      5 ps
The 74LVTH and similar modern CMOS series are likely more like the ACT.

Depending on the code to run, one may not need that much clock. After all the RP2040 has 2 cores. So not need to get close to the 50 MHz max for an external clock.
In my ADC version I use only 8 MHz, though I see it getting tight in some places to do the math. The same clock for the sync and RP2040 is definitely a good idea. If the PIO runs slower one would still want a phase adjust step and than could still use the PLL for the µC clock.
A direct USB link and thus need for the 48 MHz is not really there, as one usually wants an isolation layer to USB.

[iMo]

..In my ADC version I use only 8 MHz, though I see it getting tight in some places to do the math. The same clock for the sync and RP2040 is definitely a good idea. If the PIO runs slower one would still want a phase adjust step and than could still use the PLL for the µC clock.
A direct USB link and thus need for the 48 MHz is not really there, as one usually wants an isolation layer to USB.

Why do you need that perfect sync at the clock level between 2040 and PIO? The 2040 and PIO have nothing common with the clocking, there is no clock domain crossing with missing sync. Those are fully independent, because they communicate via FIFO/interrupts (this handles the domain crossing), a kind of async communication.
The PIO is a bunch of cmos logic stuff, with perhaps 1ps or less jitter, which has no "direct signal lines" to the CPU, except the clock line.
The CPU and PIO share the clock in 2040, but there is no need on phasing or whatever. The design here is different to your AVR/ARM designs where your peripheries and core CPU were somehow phase depended, imho.

[Kleinstein]

There is no need for a perfect sync betwen the CPU and PIO part. Usually this is given as the PIO clock is from a divider. Only the possible fractional divider could cause trouble.

The sync problem would appear, when the CPU runs from the PLL and than external sync FF are used to directly synchronize to an external clock. This case is triky and if possible I would avoid it because of the complications with the phase, even if the PIO clock would be the same as the PLL input clock.

The more realistic case is an external clock (e.g. 20 MHz range) to directly run the CPUs. The PIO clock could even be a bit lower to get the delays without extra code.
Chances are one can skip an external sync step, though there is possibly a tiny bit of delay modulation from the µC internal state that could lead to a little INL.
If needed / wanted an external sync with 2 flip flops (the input path is not that critical and could be direct) is not that complicated if there is no PLL involved.

[iMo]

NNNI may test that easily (including the new rundown) while running off the stock 12MHz crystal against the PLL version. A stable canned XO/TCXO would be even better. The 48MHz is needed, however, as you want to upload the binary to the 2040 easily, and you will do it many times, sure.

On the other hand I would be much more concerned about the noise around the comparator and auxADC.. That introduces errors and I would be happy to see some real data coming off the above code, such we may play with the math. Perhaps NNNI finds some free time for running it on his pcb, its just a copy/paste exercise..

[Kleinstein]

To make use of the extra resolution gained from the rundown part one would need additional gain for the residue ADC. Without extra gain there is not much gained.

The comparator noise  should not be an issue - it only increases the range that the residue ADC has to cover a little.
For the aux ADC it is often more the amplifier than the actual ADC noise. With less resolution needed from the aux ADC it would be less than before.
Including the rundown part makes the aux ADC less critical (get some 5 bits from the rundown instead) and even the internal ADC may than be good enough.

Wanting the 12 MHz for an easy code download is a good point.

[NNNI]

I was just about to bring up the point about being able to upload code via USB. It is very convenient and fast. However, programming via the SWD pins (using a Raspberry Pi debugger, for example) is another alternative. I am not sure how much SWD programming is dependent on system clock.

I am honestly not sure when I will be getting back to the project. I left it in a rather messy state, so getting everything running and familiarizing myself with the code diminddl and I worked on nearly a year ago will take some time, plus I have to finish testing my own ideas first. The project files are available, so it should be possible to get your own set of boards for experimentation, or replicate the core circuit (it's quite simple) on a breadboard. I understand your eagerness for the results, but all I ask for is a little patience till I can get everything sorted on my side.

[PCB.Wiz]

NNNI may test that easily (including the new rundown) while running off the stock 12MHz crystal against the PLL version. A stable canned XO/TCXO would be even better.

An external Osc is certainly easy to try.
TCXO's need care, as some use digital corrections that give small jumps in frequency as the temperature varies.
Some vendors now call their better TCXOs analog compensated - eg
https://ecsxtal.com/news-resources/what-are-the-benefits-of-using-analog-compensated-tcxos/

I'm thinking the ideal is an oscillator that is (very) stable over the integration time.
That means long term drift is less important, & it is best to focus to avoid effects like micro-jumps or other disturbances.
The close-in phase noise is looking like the best indicator of that.

A bit of thermal mass around the oscillator can help reduce temperature slope effects, and a local low noise regulator can isolate supply variations.

The 48MHz is needed, however, as you want to upload the binary to the 2040 easily, and you will do it many times, sure.

You just need to be able to generate 48MHz for the USB, so more clock choices exist.
I've not found a very low phase noise oscillator at 48MHz yet, tho NDK say they can cover 20-50MHz in their NZ2520SDA family. Just needs some MOQ 

Addit : chip1stop do show a NZ2520SDA 48MHz order code, so I've asked the MOQ on that. (they also have codes for 35MHz and 54MHz, not indicated by NDK ?)

[iMo]

..The project files are available, so it should be possible to get your own set of boards for experimentation, or replicate the core circuit (it's quite simple) on a breadboard..

Yep, the analog part of the design is an another story which we have not elaborated yet
My basic motivation has been to have a look at the 2040/PIO and its applicability. Of course it could be done by a stm32xxx (here we lack the PIO) or an fpga+MCU (here the complexity is higher) as well.
Hopefully rPi company will come with the rp2041 soon - with the fixed ADC, and with 4xPIO with 256 instructions each

[Kleinstein]

There is no need for a super stable clock. The point is jitter over a time frame of some 10 µs. The switches and an optional buffer to improve the isolation would add a few ps of jitter anyway. So a standard crystal oscillator should be good enough.  The crystal directly at the RP2040 as for the RP-pico could have an issue with the internal state effecting the clock - I had this issue with the AVR and this caused quite some INL error (e.g. 10 ppm range). Chances are 12 MHz directly with no PLL could be fast enough for the ADC, though this would not allow to use the USB while using the ADC.

[NNNI]

iMo, I got a chance to talk to Eben Upton at Maker Faire Hannover 2023. He mentioned that the instruction memory for PIO was closely coupled to the architecture, so more memory is apparently not the easiest to implement. He did hint at using out exec to overcome this limitation, but that comes with its own challenges.

I was looking at suitable crystals, and apparently a 48MHz version of the crystal [1] Jaromir used in the ADC for his NVM project [2] exists. I was not able to find jitter specs in the datasheet. But as Kleinstein says, a 'regular' oscillator will probably suffice, since a latch like the '273 will add its own jitter. The 48MHz version [3] of the temperature compensated crystal series PCB.Wiz recommended is available at a reasonable price in single quantities from Mouser.

Once I have the issues with the code sorted out, I think it would make for an interesting comparison to see how well the latched version performs.

[1]: https://www.mouser.com/datasheet/2/137/SG5032CAN_en-961596.pdf
[2]: https://github.com/jaromir-sukuba/nvm/blob/main/hardware/Schematics_pdf/HOMER/rnvm_homer.pdf
[3]: https://www.mouser.com/datasheet/2/122/ECS_3225MVQ-1825332.pdf

[Kleinstein]

I would not go for just a crystal, as the frequency can be effected by the µC and this can cause nasty INL problems.
There are relatively cheap boxed oscillators that can do the job (some 1 ps jitter specs seem to common).
The question is if one needs external latches / flip flops for an extra sync. step. The extra external sync step may reduce the jitter a little and reduce possible delay modulations at the µC, but it also adds power consumption and possibly EMI problems. There is a good chance that one could skip it.
With an external sync one would likely use a relatively low clock (like 12 MHz), which should make the USB use easy.
Without an external sync one may opt for a faster clock (maybe 48 MHz if one wants USB while the ADC is active).
For the processing power already 12 MHz should be sufficient. A DMM would anyway have a 2nd µC at the output / interface side.

[iMo]

I would not go for just a crystal, as the frequency can be effected by the µC and this can cause nasty INL problems.
There are relatively cheap boxed oscillators that can do the job (some 1 ps jitter specs seem to common).
The question is if one needs external latches / flip flops for an extra sync. step. The extra external sync step may reduce the jitter a little and reduce possible delay modulations at the µC, but it also adds power consumption and possibly EMI problems. There is a good chance that one could skip it.
With an external sync one would likely use a relatively low clock (like 12 MHz), which should make the USB use easy.
Without an external sync one may opt for a faster clock (maybe 48 MHz if one wants USB while the ADC is active).
For the processing power already 12 MHz should be sufficient. A DMM would anyway have a 2nd µC at the output / interface side.

In your latest MS ADC schematics here (the AVR based one ) you are passing the 2 channel selection signals of the 4053 (VrefP and VrefN switches) via two FFs (1x 74AC74), while the two FFs are clocked directly from the canned xtal oscillator box. That could be added into the design, and bypassed when not needed.

[Kleinstein]

The extra flip flops synchronize the ref. signals directly to the clock. It is not so much for the jitter, but more for small INL effects when the µC state effects the delay. For the AVR this effect is visible though still not that much of an issue ( < 0.1 ppm FS for the INL). I have tried both with and without the extra FF with not much difference.

[NNNI]

Fast allows to use a small integration capactor and thus allow low residual charge noise (only relevant for short integration).

Kleinstein mentioned this, does it have something to do with kTC noise? I am not really familiar with that concept, I would be glad if it could be elaborated upon.

[Kleinstein]

For the residual charge in the integrator it is likely not yet at the kTC limit and the reset noise would only apply for a reset of the integrator and not reading the charge with an auxiliary ADC. The noise is more from the amplifier(s) voltage noise that than translates to charge noise with the capacitance as factor.

Reset noise or kTC noise can be relevant at the reference swiches, if the switches are at the integrator input (like the 4053 at the 34401). Here the switch part with it's capacitance in the 10 pF range is connected / disconnected to the integrator multiple times. With these switching events the kTC charge noise applies and adds to the noise - often not a major noise source, but it could with fast modulation and high capacitance switches.

[NNNI]

I have been reading up on different types of jitter [1], and I was wondering which kind of jitter would have the most effect on the noise/linearity of an integrating ADC, perhaps it is a mix of everything, with each kind of jitter having a certain effect (more noise, worse INL, etc.).

[1]: https://www.sitime.com/support/resource-library/application-notes/an10007-clock-jitter-definitions-and-measurement-methods#Phase-Jitter

[Kleinstein]

The relevant jitter should be mainly for time intervals of some 1-10 µs. So a little more than just period jitter and still not really long time jitter. It is probably kind of a mix of the short and long pulse lengths in the run-up modulation. The point is how the PWM ratio changes from the nominal.
In the frequency offset plot this would be a frequency offset of some 100 kHz - so not very close in, but also not period jitter.

In most cases the actual oscillator should be less of an issue. A limiting factor could be the actual switch part. Here jitter specs are rare. The more precision type switches are usually slower than typical logic chips and thus more jitter is expected there. I selcted the 74LV4053 not just for low cost, but also for a good speed.

[NNNI]

I wonder how a more modern switch with lower on resistance and charge injection will fare in that regard, such as the TMUX1133/4 [1]. I don't know if there is an easy way to test for jitter in an analog switch.

[1]: https://www.ti.com/lit/ds/symlink/tmux1134.pdf?ts=1715116885492