Most of the work on Multislope 3I concluded by late July 2022. I was on an informal deadline since I was due to move to Germany on the 15th of August that year to start my higher education. Although readings with a theoretical resolution of 10uV had been achieved, there were still a lot of unanswered questions, the biggest one being the source of severe noise and banding in the residue ADC readings. The residue ADC of choice was the MCP3202, which is a pretty interesting part.

The below chart plots the residue readings (difference in integrator voltage before and after conversion) obtained. The +/-1000 count noise is highly unusual, and upon closer inspection, some banding is also visible. 

Two of the biggest suspects were a bug in the software and PCB layout. To test the former, I desoldered the MCP3202 and put it on a Manhattan prototyping board to ensure neutral layout. 

The MCP3202 IC has a somewhat complicated SPI transaction that had to be split into three transfers of a byte each. Recombining these bytes incorrectly could have possibly led to noise and banding. The input to the ADC was a simple 1K/1K divider connected between VCC and ground. With a neutral layout, I tested four apporaches:

• PIO: I used the RP2040's PIO to set up a custom SPI interface, which let me get the data in a single 18-clock transaction. 

• Original SPI code: I separated and re-compiled the code used in the original project and used it to get a conversion in three bytes. 

• "Direct" SPI: The C/C++ SDK comes with a built-in function to read more than 8 bits "directly", although upon probing it does split the transaction into bytes. 

• PIO with SPI pins: I had to change the wiring a little bit between PIO and SPI readings since the SPI pinout was slightly different. To make sure that the wiring changes didn't affect the readings, I set up PIO to operate from the SPI pins. 

In all four cases, noise was quite acceptable and the readings showed no banding. The MCP3202's input was probed during sampling and the input spike settled within 1/10 of the SPI clock. 

The above tests prove that a software bug could be ruled out, since all four approaches have very similar results, with non-PIO readings being slightly noisier. 

Once again, I put the MCP3202 back on the original PCB and bodged some connections to the external Pi Pico. 

The readings were now much worse, with banding being visible in histograms of a single run. This proves with reasonable certainty that the original layout was not optimal. 

This was a four layer board, and the ground plane was on the bottom-most layer, two layers below the MCP3202. Signal and power traces were also routed freely below the part, which was clearly a mistake. 

There were still a few more things I wanted to try. The first was a simple filter on the input, consisting of a 56 Ohm resistor and a 1nF capacitor (values copied from Jaromir's NVM). I also added an extra 470uF capacitor across the supply pin and ground. 

The readings are now perfect - not a single bit of noise over three runs of 1000 samples! Looks like the previous poor results were caused by lack of proper layout and decoupling, which is on me. 

The above test was performed on a slightly modified setup where I used some copper tape and an SMD adapter on the PCB itself, ready for future testing.