(Yet Another) DIY Multislope ADC

[MegaVolt]

Two groups of readings can cause popcorn noise of the reference source.

[NNNI]

Kleinstein, thanks for your suggestions. I'm not sure if I want to continue experimenting with this board, I already have a long list of improvements planned for a next revision including a slope amplifier and maybe the addition of some kind of slow slope. Another idea on my mind was to convert the reference voltages to currents like in the K2002.

MegaVolt, do you mean the input voltage or the ADC reference? In any case, that thought never occured to me, thanks for the information.

Meanwhile, I measured a 9V battery over around 6000 measurements. The histogram maybe meaningless for a drifty measurement, but the scatter plot looks interesting...now the readings have diverged into sets  .

[Kleinstein]

Using current sources like in the K2002 is quite some extra effort with relatively little return. On the downside on no longer gets compensation for the drift in the on resistance of the switch for the input channel.

The splitting of the signal looks to be too large to be caused by popsorn noise (either the ADC reference or the external reference for the test voltage).
The line split in 4 really looks like a SW problem, like missing a count or PWM value update (and thus having one step twice). The difference between the curves may give a clue.

For an initial test of the noise the usual test point is 0 input and thus no reference noise for the source and ideally no effect of reference noise for the ADC side.

The slowly drifting votlage source is also a good test, as this can show DNL errors and possible weak points where the ADC does not work well.

[NNNI]

I tried the method Kleinstein suggested of measuring input and then zero and considering the difference between them. I also averaged 10 readings. Each input and zero reading was 1PLC. The results look slightly better.

[NNNI]

It's been a long while since I posted updates here, and a lot has happened!
I designed a completely new set of PCBs with better layout, and got it working, complete with software. I was able to run a few INL tests (compared to Keithely 2000), and I got a reasonable inverted parabola, which is a good sign which means linearity could be better with tweaking. However, the readings are very noisy, and I narrowed it down to problems with residue readings.
I'm using an MCP3202 ADC IC to do the job. Reference voltage and supply is 3.3V from a 3.3V LDO, 1uF bypass capacitor on the power pin. Since the readings were noisy, I decided to investigate the ADC alone, and on feeding a constant voltage into it I got readings that were insanely noisy (hundreds of counts), and there was also "banding". On zooming in closer, some codes are also missing. I have no idea what is causing this.

[branadic]

Are you sure your ADC scaling is correct? If not, that could explain the "banding".
Have you checked the MCP3202 ADC independently on a breadboard with shorted input? Maybe you have some weird coupling effects that affect your noise readings.

-branadic-

[julian1]

Also review the code used to read the adc. I used mcp3208 for a project, and found it a bit fiddly to set up the control bits for input - either differential or single-ended. As well as flipping the spi read bytes by the adc to match the endiness of the mcu. The grouping/clustering of values could be explained by a problem handling the conversion.

[NNNI]

branadic: These are raw counts from the ADC, so I don't think it's a matter of scaling constants this time. But maybe it might have something to do with the layout, that is something I'll have to confirm later.
julian1: I've attached the code used to this post.

[MegaVolt]

Apply a slowly varying signal to the input. I think a lot will become clearer. Perhaps there is a problem with the order of the bits.

[Kleinstein]

There are still too many codes coming up to be a problem with just the order of the bits. That much noise looks more like a problem with the supply, reference or the clock (e.g. way to fast or too slow).

[NNNI]

I've finally figured out why the residue ADC readings were so bad - turns out that there's something in the software that is returning the wrong pair of readings for a given charge balancing cycle.
The first image shows what is going on graphically.
The second image is the raw readings from the ADC. Column B and C are "before" and "after" residue ADC readings respectively, and the blue highlighted numbers are the difference between the two. If I move the values in column B one row up and then take  the difference with C, the results are the ones highlighted in green, consistent expected values.
I was able to figure this out by reading the voltage on the integrator during the residue readings manually while making single-shot measurements, the values in column C were consistent with what I was seeing on the scope, while column B was not.

[iMo]

Hi, I've been playing with your SW (rp2040 with PIO state machine) and have couple of questions perhaps, if I may..
My current understanding is following:
1. you set rp2040's clock to 96MHz
2. SM's clock is set to 52.1ns (96/5)
3. the PWMcycle is set inside PIO for 32 SM clocks with 2:30 duty, thus I see the "2" (for example) aprox 105ns long on my scope, in total the PWMcycle=1.66us (=32*52.1ns) I can see here, is that correct?
4. the "MScyclesPerPLC" is the number of "PWMcycles in 1PLC measurement period", thus with 50Hz it should be 12000 (you have there 6000), imho (because 20ms/1.66us is 12000), is that correct?
5. in "final" this line should be

Code: [Select]

//uint32_t counts = get_counts(pio, multislopeSM, pwmCycles); //Multisloping for 20ms
uint32_t counts = get_counts(pio, multislopeSM, MScyclesPerPLC); //Multisloping for 20msas the pwmCycles (12 in your source) there is for testing purposes only, is that so?.
I've been running it on a waveshare's rp2040-Zero..
Tnx!

[iMo]

Hi, as the rp2040 PICO with its PIO state machine engines is a pretty interesting gadget for multislope experiments, I have commented in a little bit better detail what is happening inside the PIO assembler program for the state machine providing the MS events in NNNI's design.

I've done it such the algo is somehow readable for people who mess with the PIO asm first time (inclusive myself), it may contain errors, for information only.
I will update or remove it when NNNI will update his MS on the github.

PS: corrected my many typos.. 

Code: [Select]

;
; The PIO asm program for the MUltislope 3
; by NNNI in https://github.com/NNNILabs/Multislope-3I/tree/main/SW
; commented in detail by iMo 04/2024
;
; PWMB and PWMA is a GROUP of TWO OUTPUT PINS ("pins"), manipulating switches for positive nad negative REFERENCE charges
; BOTH PWMA and PWMB pins are manipulated in a single cycle, shall be adjacent pins, PWMA being the lower bit
; MEAS is a so called "sidepin" (you may set/clr the sidepin within any asm instr) - here the OUTPUT PIN indicating a running MS cycle (an MS cycle consist of "N" PWM cycles)
; COMP is the INPUT PIN ("pin") wired to the comparator
;
; this program does 32 clocks long PWM cycles (PWMA and PWMB) with a duty of 2:30
; the number of switchings within one MS cycle should be kept constant by this algo
; the "clock" frequency and pins/pin assignments are set outside this PIO program
; the residual voltage measurements are done via CPU0 (an external ADC), based on
;   the irq0 (at the MS start) and the irq1 (at the MS end) signals issued by this PIO SM machine
; outside the MS cycle this program provides constant "dithering" of the integrator input (toggling PWMA and PWMB)
;
; the C part of the system
; 1. writes the required number "N" of PWM cycles to PIO's Y register (like 6000 for example)
; 2. reads the residual voltage at the beginning of the MS cycle (via SPI through the CPU0)
; 3. reads the number of PWMA charge buckets counted during the MS process
; 4. reads the residual voltage at the end of the MS cycle (via SPI through the CPU0)
; the number of PWMB buckets is equal (N - PWMA)


.program ms
.side_set                                   ; one "side set" bit is the MEAS pin, when 0 we do not count PWMs cycles/buckets, when 1 we do count

; don't forget to enable auto push
start:                                      ; here we start a single MS cycle
set pins, 0             side 0              ; this sets GROUP of two pins [PWMB, PWMA] = [0, 0], MEAS = 0
    mov X, !NULL        side 0              ; set X (number of PWMA charges) to initial 0xFFFFFFFF, we will count down at each bucket, MEAS = 0
    out Y, 32           side 0              ; read from input FIFO the desired number of MS PWM cycles (like 6000 for example) and put it into Y, MEAS = 0
    irq 0               side 0              ; first residue ADC reading, done via SPI via DMA by the CPU0, MEAS = 0
    out NULL, 32        side 0              ; stall until DMA finished reading the ADC into the CPU0, MEAS = 0

beginning:                                  ; the beginning of one MS Measurement cycle, ie 20ms long, with fixed count of ie. 6000 PWM cycles
    set pins, 1         side 1              ; set [PWMB, PWMA] = [0, 1] and set MEAS = 1
    jmp pin pwmhigh     side 1              ; pin is the COMP input pin, if 1 jump to pwmhigh, MEAS = 1
    set pins, 2         side 1 [15]         ; set [PWMB, PWMA] = [1, 0], and stay so for additional 15 clocks, MEAS = 1
    jmp Y-- beginning   side 1 [13]         ; decrement Y at each PWM bucket polarity regardless, jmp if not 0 to a new PWM cycle, stay so for 13 additional clocks, MEAS = 1
    jmp finish          side 0              ; jmp to finish of the MS cycle and set MEAS = 0 (end of MS cycle)
   
pwmhigh:                                    ; when pwmhigh we decrement X (PWMA)
    jmp X-- dummy       side 1 [15]         ; decrement X and stay for additional 15 clocks, jmp if not 0 (it never be 0), MEAS = 1
dummy:
    nop                 side 1 [11]         ; do NOP and stay for additional 11 clocks, MEAS = 1
    set pins, 2         side 1              ; set [PWMB, PWMA] = [1, 0], MEAS = 1
    jmp Y-- beginning   side 1              ; decrement Y at each PWM bucket polarity regardless, jump to new PWMcycle if not 0, MEAS = 1
    jmp finish          side 0              ; jmp to finish of the MS cycle and set MEAS = 0 (end of MS cycle)

finish:
    set pins, 0         side 0              ; set [PWMB, PWMA] = [0, 0], MEAS = 0
    in  X, 32           side 0              ; push the X value (number of PWMA charge buckets) to FIFO (will be read by CPU0 via FIFO), MEAS = 0
    irq 1               side 0              ; perform the second final stage ADC residue reading via SPI (done by CPU0), MEAS = 0
    out NULL, 32        side 0              ; stall until DMA finished reading the ADC, MEAS = 0

.wrap_target                                ; this is an endless "desaturation loop" (between wrap_target and wrap) keeping integrator input around ZERO when not doing the MS cycle
dither:                                     ; we toggle PWMA and PWMB in a loop around ZERO integrator voltage
    jmp !OSRE start     side 0              ; jump out of this desaturation loop when the OSR has data (it means the CPO0 has sent the "N" at the beginning of the MS cycle), MEAS = 0
    set pins, 1         side 0              ; set [PWMB, PWMA] = [0, 1], MEAS = 0
    jmp pin dither      side 0              ; check if the comparator output pin is still 1 and jump to dither if 1, MEAS = 0
    set pins, 2         side 0 [1]          ; set [PWMB, PWMA] = [1, 0], stay so for additional 1 clock, MEAS = 0
.wrap

[Kleinstein]

There should be no need to have the reference modulation that fast. 96 MHz and 16 cycles would be modulation frequency of 6 MHz. For comparison the HP3458 uses some 330 kHz. With a good capacitor there is no need for more than some 50 kHz to reduce the DA effect on the INL sufficient.

A very fast modulation also comes with downsides: Charge injection gets more important. The integrator settling gets more important and really fast settling integrator is wanted. More time is lost to the fixed short pluses needed for settling. This limits the usefull range (looks like  4/16 of the range are lost in this example). Jitter and becomes more relevant as a noise source. Even worse may be other delays (ps range is enough) caused in the µC that can cause INL errors.

Even without such a fast modulation one may want to consider separate syncronization to a stable clock (e.g. with 74AC74 flip flops) to avoid juster and delay modulation from the µC. This would likely be with a slower clock not 96 MHz anyway.

The RP2040 could still be interesting as it may be able to run the ADC part in parallel to normal operation. AFAIK the µC internal ADC has some flaws so that the usable resolution is more like 8 or 10 bits.

[iMo]

In his example as of today on his github a single pwm modulation cycle is made of 32 clocks, where the clock is set to 96MHz/5=19.2MHz.
The single pwm cycle is therefore 1.67us (say 600kHz). It is perhaps his testing setting. You may set the PIO's SM clock as you wish (CPU_clock/div). I've been running the code on my rp2040-zero and I can see that timing on the scope. You may overclock CPUs (there are 2) to 300-400MHz max, btw.

All the instructions above are single clock (say 5ns at 200MHz), with additional prolongation of any instruction, and the sidepin(s) set/clr in parallel as well - that is a pretty impressive combination.

For example a single 1 clock instruction

jmp Y-- beginning   side 1 [13]

decrements the 32bit register Y, jumps to "beginning" label if Y is not 0, sets a "sidebit" output pin to 1, and makes this instruction 14 clocks long.. Imagine what could you do with your MS ADC design if you had this gadget handy..


You may have 2 PIO instances with 4 SMs in each, DMAing the SM'es data via a 4/8 words deep in/out FIFOs into/from the CPU0 or CPU1 (or any peripherals, afaik). No need to use an external FPGA for many apps. The 9 instr assembler is not easy to read, and there is a lot of various tricks you may do with it as well, so one need some time to get grip on it..

[Kleinstein]

The PIO part should be capable to control a MS ADC. The limiting factor is however not so much the digital control part, but the analog part (e.g. settling of the integrator with 2 x OPA140 or similar) takes some 200 ns or so. So the shortest pulses should be no less than some 500 ns to get reasonable good settling. This sets a practical limit for the modulation speed of some 200-300 kHz - faster gets sensitive to settling effects or looses quite some of the input range.

The speed for the modulation is a compromise. Fast allows to use a small integration capactor and thus allow low residual charge noise (only relevant for short integration). Fast modulation also allow a fast rundown and gets less INL from DA. One the other side faster modulaton gets you more INL error from settling effects, more INL error from delay modulation, more noise from jitter, switch capacitance and noise in the charge injection.

My ADC version uses the µC internal ADC and here the ADC inside the RP2040 is not that great, though still OK. The RP2040 would need an external comparator - other µC can incluce the comparator.

The main point where fast control and also fast modulation could really make a difference is when it comes to a fast rundown to get really fast conversions (e.g. > 10000 SPS).  However for really fast conversion the MS-ADC (especially the version with a rundown) may not be the best choice anyway.  Modern SAR chips and also some SD ADC chips get pretty good at 100 kSPS or 1 MSPS.

[NNNI]

First off: Extremely sorry for not replying to the previous messages sooner. I am unfortunately not very active here, and somehow I completely missed the fact that this thread had replies (I don't get E-Mail notifications).

iMo did send me a private message regarding the topic of this thread, but somehow it never occurred to me to check. I will read the messages and questions in detail and get back as soon as possible.

I was wondering why the GitHub repo for the project was suddenly getting so many stars, never occurred to me that it might be from here...

diminddl, who is collaborating with me on this project and is responsible for the software side, wrote a post on Hackaday explaining the code: https://hackaday.io/project/190528-multislope-adc/log/217945-code-overview, I hope this answers some questions.

[NNNI]

Regarding the modulation frequency: Yes, the PIO clock divider is set to 5 for testing.

The original intention of the 96MHz underclock (I have stably overclocked the RP2040 to 400MHz) was to have a PIO clock divider of 10 to get a 9.6MHz PIO clock. That results in each PIO instruction taking 1.04167us. Each PWM cycle is 32 clock cycles long, and therefore a period of 3.333us (300kHz modulation frequency). This was chosen so there would be an integer number of PWM cycles in both a 50Hz and 60Hz PLC (20ms/3.333us = 6000 PWM cycles, 16.667ms/3.333us = 5000 PWM cycles).

[iMo]

I've been playing with the digital part, getting familiar with the PIO+MCU combo..
I've wired my junkbox MAX1247 ADC and running the modded test chunk of code, watching what is going on. Of course I've played with various settings. My ADC works fine with 2MHz SPI clock, with LM385-2.5V ref and 1N4148 (5mA If) as the source I get rock stable reading with occasional 1LSB excursion for both pre- and -post MS readings (btw. all on a solderless breadboard with jumpers and my pico-zero dingsbums). Also my pico has got linear voltage regulator.

The first residual measurement occurs 20-40us (it depends on ADC SPI clock) before the start of the MS cycle, that might be too long before the MEAS=1, I guess. It is because you wait on DMA reading the ADC SPI.
Why not use an another channel for ADC, such it reads the ADC in parallel with the beginning of the MS cycle?
Simply issue the irq0, wait for ADC_acquisition time (perhaps 1-2us) and do not stall the PIO during the ADC SPI DMA..

PS: in the MCU section I've asked whether we know the typical jitter of the clocks generated by the rp2040 pll. Soon or later somebody here will ask that too (as the clock jitter has been identified as a potential troublemaker with 6+ digits)..
Worst case you may run the MCU off an external 50MHz canned oscillator.

[Kleinstein]

300 kHz modulation period for the run-up sounds much more sensible (similar to 34401 and 3458), though still relatively fast. It may be needed for the MS3 (34401) like version with no rundown. Otherwise fast modulation makes jitter more relevant and with just the RP2040 there is a chance for quite some jitter from the PLL. For the jitter I can see the difference between an 74HC74 and 74AC74 for synchronization, even with slower modulation (~100 kHz).

[iMo]

The 2040 strategy with jitter is to set the internal pll as close as possible to 1500MHz, and then divide down to say those 125MHz (or other  cpu clock). Then the jitter should be lowest, DS says. For example the Si570 gadgets worked with 4.7GHz pll and achieved pretty low jitter, perhaps the 2040 follows that too (better it needs to be measured, considering their ADC design flaw).

[NNNI]

Why not use an another channel for ADC, such it reads the ADC in parallel with the beginning of the MS cycle?

This is exactly what I was planning and working on last year.

[iMo]

Ok, I see..
What I do not understand fully (a 2040 beginner here..) is following:

    // IRQ setup:
    // PIO sends interrupt in IRQ0 for first residue reading
    // IRQ0 handler starts DMA to read SPI of the ADC
    // when DMA finishes, it sends a value over to the TX FIFO of the PIO instance
    // all this time an OUT command was stalling the state machine to wait for the reading to finish

Why do you send the ADC value to the TX FIFO of the PIO instance?
That delays the MAES rising edge by XXus when the integrator's input voltage has been already disconnected (so it may change during the "XXus long" preADC conversion)..
What I thought above is to have the ADC channel "independent" of the PIO instance (so both will do in parallel, no need to stall the SM..). Something like that..

PS: below what I see now.. preADC samples some 12uS before MAES=1 and postADC about 4-5us after MAES=0 (with 2MHz spi).

[PCB.Wiz]

The 2040 strategy with jitter is to set the internal pll as close as possible to 1500MHz, and then divide down to say those 125MHz (or other  cpu clock).

Yes, the VCO's are usually current controlled oscillators, giving the best jitter at higher power/highest MHz.

For example the Si570 gadgets worked with 4.7GHz pll and achieved pretty low jitter, perhaps the 2040 follows that too (better it needs to be measured, considering their ADC design flaw).

re Si570 area : If you want to look at cased i2c oscillators here is table I drew up a while back, that shows jitter-GHz are certainly related, and they tend to use higher MHz, xtals for lower jitter. (and probably smaller size too)

Code: [Select]

~~~~~~~~~~~~~~~~ SiLabs i2c Oscillators ~~~~~~~~~~~~~~~~~~~~
Device SpeedGrade Xtal    Out(MHz.CMOS) MinFvco(GHz)    MaxFvco(GHz)   Icc         Jitter
 Si564.A         152.6    0.2~3000     10.8            13.122222222    87mA CMOS   95fs RMS 
 Si549.A         152.6    0.2~1500     10.8            12.511886114    87mA CMOS   95fs RMS
 Si549.B         152.6    0.2~800      10.8            12.206718160    87mA CMOS   95fs RMS
 Si549.C         152.6    0.2~325      10.8            12.206718160    87mA CMOS   95fs RMS 
 Si544.A          55.05   0.2~1500     10.8            12.550082103    74mA CMOS   150fs RMS
 Si544.B          55.05   0.2~800      10.8            12.109728345    74mA CMOS   150fs RMS
 Si544.C          55.05   0.2~325      10.8            12.109728345    74mA CMOS   150fs RMS
 Si564.A          3GHz out $42
 Si570           114.28   10~160M      4.850           5.670           90mA CMOS   0.62pstyp
 Si599            39.17   10~810       4.85            5.67            90mA CMOS   0.7ps     
 Si514           31.98MHz 0.1~250M     2.080           2.500           21mA CMOS   0.8ps     
 Si5351A.QFN20   25~27    0.002~200    0.6             0.9             22mA CMOS   ~40ps pp 
 Si5351A.MSOP10  25~27    0.002~200    0.6             0.9             22mA CMOS   ~70ps pp 

Those are highly flexible but not especially cheap.

Over in the Audio sandpit, there are many complex oscillators offered up, but this one looks to be simple, using a 74LVCU04 gate
https://www.diyaudio.com/community/attachments/twtmc-p-pdf.615086/
Note they use a large can, custom crystal when chasing extreme numbers.

Addit3: I found another variant, a Pico gate Pierce, shows the crystal matters most for low Hz phase noise.
https://www.thewellaudio.com/wp-content/uploads/TWTMC-PPG-V2_User_Manual.pdf
Note they test here with batteries and shielded.

At the simpler end, Nisshinbo offer a NJU6385, in a DFN6 package,

https://www.nisshinbo-microdevices.co.jp/en/products/quartz-crystal-oscillator-ic/spec/?product=nju6385
that part claims impressive low jitter and noise. (I think tested at 49.152MHz )

●Phase noise
 -103dBc/Hz(Typ.) @10Hz Offset
 -163dBc/Hz(Typ.) @1kHz Offset
●RMS Jitter 0.05psec(Typ.) @12kHz to 20MHz

Not much mention of power supply, but these inverter oscillators would likely benefit from a modern, low noise local regulator.

It's hard to tell how much secret sauce is in that NJU6385, or if it is just a DFN packaged standard unit ?
ie how much better is it really, than a 74LVCU04 or 1GU04 oscillators above ?
The Pico gate info above, suggests less secret sauce, but NJU6385 is small and includes C and biasing.
Mouser do stock the similar NJU6311, in MSOP10, with divider choices.


The lowest ESR crystal generally available looks to be ABLS-LR-12.000MHZ-T in HC-49/US (SMD) ESR <15 Ohms

Addit: Another option point, for high end instruments like ADC's, could be crystals like ECS's aged models :  a slight premium on jellybean crystals.
Their ESR is higher, than the larger ABLS-LR, but they have been pre annealed/aged  - maybe that matters more ?

ECS-120-10-33B-CKM-TR3  12.000 MHz 10 pF ECS-33B 10/10 ppm -20 ~ +70C 1 ppm Aging 3225  ESR <100 Ohms
https://ecsxtal.com/news-resources/how-ecs-inc-b-series-crystal-oscillators-support-your-future-forward-technology/

That looks easy to retro fit onto a RP2040 board, as I think they use 3225 commonly.

Addit2: Another reference point on the KISS/Cost/performance curve, is to simply bolt on the 'best TCXO' like the ATX-H12-F-12.000MHz-F25-T
Numbers are a tad worse than the NJU6385 claims, but it's all in one package, and spec'd out of the box.
An alias/branding clone of that ATX-H12 looks to be the FT2MHUPM12.0, showing stock at Newark, strangely a bit cheaper than the ATX-H12, at under $2 ?
These Abracon parts spec (ATX-H12 / FT2MHUPM12.0)
Phase Noise (@ 10 MHz Carrier, @ 25°C ±2°C)
@10Hz offset      -98 dBc/Hz Typical  -94 dBc/Hz Max
@100Hz offset    -122 dBc/Hz Typical -118 dBc/Hz Max
@1kHz offset     -145 dBc/Hz Typical -141 dBc/Hz Max

That would be easy to add to a RP2040 board, to check.

[iMo]

Yep, I collected many various Si570s (20y back while messing with the first SDR radios), afaik they output till 1.5Ghz based on the part number suffix and type of output, cmos till 160MHz-250MHz, lvds till 1.5Ghz. Expensive, indeed.
Now, how the rp2040 does perform?