4 channel ADC, 10 MHz, 8 bit design

[StillTrying]

"10 MHz analog bandwidth would be nice."

Should be quite possible. I think the trick is to keep the red track as short (mm) and capacitance free as possible, so that you get to choose the value of the feedback cap. - in theory. 

[FrankBuss]

I finished the layout:



Luckily someone on the kicad.info forum mentioned the these plugins: https://github.com/MitjaNemec/Kicad_action_plugins/ Has "replicate layout", which places all components of all sub-sheets in a configurable distance and duplicates all traces, and it has the swap-pins script, which I really missed from Eagle. I think now KiCad is perfect

Minor changes for the schematics are in github, too, with updated PDF files. Will do a flood-fill on the bottom for GND, add labels, make supply traces bigger etc., and then it should be done.

[StillTrying]

You've moved TP1 to the other side of the 150k input resistance.

[FrankBuss]

Right, I thought I wouldn't need it at the other side, because I can always connect a scope to the input pin header, together with the input jumper wire, and would be more interesting to see what happens at the inputs of the OpAmp.

I ordered the boards this week, I should get it in 1-2 weeks. The final layout is in the github repository. Looks like this:



I did a GND flood fill on bottom and 5V flood fill on top, except for the input at the left, because I guess if there is noise on the 5V, it could couple into the input signal. Maybe for the final version a 4 layer board would be better, so that I can use a dedicated +5V / +3V power layer?

[StillTrying]

"would be more interesting to see what happens at the inputs of the OpAmp"

There'll be nothing happening at the inputs of the op amp, until you connect a probe. then it will oscillate.

[FrankBuss]

I got the board and soldered the first channel:



You were right, I can just connect VRB to GND and it converts down to 0 output reading. For VRT I used the 4 V reference.

A first test with 1 MHz square wave had some overshooting. I added a 1 pF capacitor for C3, no capacitor for C1, and it looked like this:



I guess the potentiometer RV2 adds some more capacitance, because I could even lower it to 0.5 pF. Then it starts to wiggle a bit, but even better edges:



The FPGA is sampling it with 25 MHz and I read it over the serial port with 1 Mbaud with this Python script, which also displays the nice oscilloscope diagrams and updates it live, with about 2 seconds per frame.

Next will be soldering the other 3 channels. Then I will finish the FPGA programming, because at the moment I'm using just the internal block RAM, but I plan to use the 1 GB DDR3 RAM. I hope I can save all the data at this bandwidth. Maybe I need to add a FIFO for saving it without gaps, in case the DDR RAM decides to do a refresh etc.

Later I can use the ARM on the Cyclone 5 and Linux to transfer the data over ethernet. But this might be some work to access the DDR RAM from both, the ARM and the FPGA part of the Cyclone 5, and Linux driver development etc. But shouldn't be too much work.

[StillTrying]

The 1MHz shape looks OK, must be close to 10MHz worth, but I can't see how the +/- 7.5 scale relates to the op amps expected ~0V to ~4V ? output.
I would think any overshoot or undershoot on fast edges depends on the actual amplitude of the op amps output, or at least it does when I try for a large fast dynamic range.

[FrankBuss]

I tested it with a 15 Vpp AC square wave, generated with my Siglent SDG1050. In the Python script you can see at line 70 that I scale the linear output of 0..255, to -10..+10 with (d / 256 - 0.5) * 20. Then I turned the two potentiometers until it looked right in the live update They are quite sensitive, I think I should use some fixed resistors and smaller potentiometer values in the next revision.

For testing that it goes to 0 and 255, I turned the offset potentiometer and watched the output on the console, where I added a min/max calculation of the values, see line 72. The waveform didn't get distorted near the limits 0 and 255, so looks like the OpAmp and the ADC both can go down to 0 V (at least good enough for the 8 bit resolution), and of course up to 4 V is no problem.

I guess I could do some more measurements, but this is good enough for me. But maybe I should scale it to -10.24..+10.24. Then I would just need to multiply it by 8 (and then subtract 1024), and the result would be exact 10 mV steps. This would be nice for a digital multimeter display. And maybe a relay at the input with some reference voltages, and then using digital potentiometers would be nice too. And then a full conventional input stage with switchable ranges, like -100..+100, -10..+10, -1..+1. So many ideas, maybe later

[StillTrying]

I tested it with a 15 Vpp AC square wave.

I see, for a +/-10V input I'd agree +/-7.5V is a good testing amplitude, 0.5V-3.5V at the ADC.

In the Python script you can see

I'm only looking at a pdf schem. and I'm not even sure that's the lastest, couldn't get the github one.

The bottom of the 1MHz square wave is staying exactly on the -7.5V line, what's causing the tops to drift up and down 5 or 6 ADC counts, especially noticeable in the first graph.

[FrankBuss]

In github is the latest KiCad schematic. I update the PDF file, too:

https://github.com/FrankBuss/adc4/blob/master/kicad/adc/adc1-ADC1.pdf

Maybe the drift is because of the suboptimal test setup with a breadboard, and using jumper wires to connect ground, which I guess I really shouldn't do. But I think it is probably only like 4 counts drifting. This would be 6 digits resolution, which was my goal, so fine for me, at the moment. But you are right, it is strange that the top drifts more than the bottom. BTW, I forgot to invert the voltage in the Python script, so +10 V in the diagram really means -10 V at the input, and +10 V in the diagram means 255 at the ADC digital output.

[FrankBuss]

All 4 ADCs of one board are soldered now:



I enhanced the Python script, it is tempting to add all the oscilloscope controls I'm used to now



The 1 volt offset x channel number was just added to see all traces at once. I think it is a bit less noise now, after changing the ground connection jumper wire of the external USB serial adapter to some other pin directly on the DE10 Nano board instead on the breadboard. Maybe I need a different capacitor for the green trace, and I couldn't find the bag with the 4 V regulator, so it is all powered from one regulator, which might introduce some cross-talk and other problems, but it is a good start. Will now add the 1 GB sampling memory capability, then it gets interesting.

[StillTrying]

They look good, proves a good 8-bits is enough to see wave shapes.
I'd prefer a scope view before the 150k input and after the 20R out put to see what the op amp's doing that the 25MHz sample rate doesn't show.

[FrankBuss]

The DDR3 RAM recording for my ADC4 hardware is working now. I can record up to 62.5 million samples, and each sample can have 128 bits, e.g. 8 ADC channels with 8 bits each and then 64 digital channels or other information. Max samplerate is 25 MHz, and probably can be increased to 50 MHz. The current hardware implements 4 ADC channels. My Python reader script saves it in Sigrok format to view with PulseView, and I enhanced the oscilloscope script a bit to trigger on zero crossing. Some PulseView examples:





The transfer over serial port with 1 Mbaud/s is awfully slow. Next will be to integrate it with the Linux on the DE10 Nano board. Then I can transfer it with the 1 GB/s Ethernet connection. I think it might be very useful to add a driver for it for Sigrok, looks like a nice collection of programs. But for analog signal there are some bugs, like you can't import/export files in CSV format from and to the internal SR format, but it is all open source, so someone could fix it someday

[FrankBuss]

BTW, I refactored all the communication with the FPGA in an extra Python file. Now it is really easy to use the ADC and do something interesting with the data. The reader script, which just dumps the data to a Sigrok and CSV file, looks like this. Most of it is for a nice hexdump of the first few bytes on the screen.

The same functions are used for my Python oscilloscope, for which I added a simple trigger on zero crossing for the first channel, which helps a lot for calibrating. Later I can just change the record_and_read function to use Ethernet, and it works in all programs, only much faster. Might evolve over time to some more useful set of functions.

Maybe Python is better than trying to use Sigrok for it? Adding a driver for PulseView is more work in C++ than in Python, and I can implement project specific functions for data analysis in Python with numpy and all the other frameworks much faster anyway. It could even work from within a Jupyter Notebook.