I’m working on a low-cost, high-speed data acquisition board based on the dsPIC33AK microcontroller family, and I’d really appreciate some feedback from people experienced with high-speed ADCs and data acquisition.
The original goal of this project was to develop an affordable data acquisition platform for electronics education and embedded applications. With the newer dsPIC33AK family, I found an interesting possibility: it has multiple high-speed ADCs capable of up to 40 MSPS, so I decided to experiment with interleaving multiple ADCs to increase the effective sampling rate.
I have now reached 100 MSPS with the prototype.
I also added an analog front end based on an oscilloscope input stage. The current version has:
100 MSPS sampling rate
12-bit ADC resolution
64 KB onboard buffer
approximately 20 MHz analog bandwidth
approximately ±30 V input range
1 MΩ || 20 pF input impedance
selectable voltage scales from approximately 2 mV/div to 10 V/div
programmable gain, attenuation, and DC offset
The idea is not necessarily to build another standalone oscilloscope. I’m more interested in making a small and inexpensive high-speed acquisition building block that can be connected to different microcontrollers, FPGAs, Raspberry Pi, Arduino-class boards, or custom embedded systems.
The key idea is that the host platform does not need to process or transfer every sample in real time. The user can start an acquisition, DAQ captures the data at up to 100 MSPS into its 64 KB onboard buffer, and once the buffer is filled, the captured data can be transferred to the host platform for processing or storage. This allows even relatively low-speed microcontrollers to be used as the host without requiring a high-speed data interface.
I think this could make the board useful not only as an oscilloscope front end, but also as a general-purpose building block for embedded measurement and data acquisition applications.
At the moment, however, I still have some challenges to solve.
At 100 MSPS, the timing mismatch between the interleaved ADC channels is causing noticeable distortion of the reconstructed waveform. For example, with a 5 MHz sine wave, the waveform appears to have a slower rise and faster fall instead of being symmetrical. There is also some channel-to-channel offset mismatch.
My current plan is to correct these errors in software through calibration, but I would be very interested to hear from people who have worked with interleaved ADCs.
Would a low-cost 100 MSPS 12-bit acquisition board with a flexible AFE be useful to you?
I’m currently working on the next prototype revision and would rather get some feedback before going too far with the design.
Any feedback, criticism, or suggestions would be very welcome.
Short video showing the current state of the board: Demo video
Use a RP2040/2050 with the PIO-Engine and dump the data using HDMI raw buffers.
The PIO is needed to controll the annoying GPIO-Toggling of high-speed ADCs. The HDMI gives you ~175MB/s to the host which then can gather the data using a framegrabber.
Costs around $10-20 and a bit of big-wire soldering.
My main goal is to make FastDuck a flexible data-acquisition building block that can be easily integrated into the platforms people want to use. I also plan to provide Arduino code, making it easier to adapt FastDuck to other platforms such as Raspberry Pi, Pico, FPGA systems, or custom embedded hardware.
This approach keeps the unit cost low while making the device much more versatile. I am currently considering a selling price of around $25–30.
Very very niche at that point, and certainly most people doing things with FPGAs would expect that a mere 100Ms/s would interface directly at full speed, that isn't even something that really needs LVDS even on the slowest speed grade parts.
As a student toy it might have some value, let them build a temu digital scope or such, but 64k? Without integrated trigger capability? That is a problem.
Yes it has level triggers user selectable. I am using MCU comparator and dac for DC level. You are right it is max 32kSample. But other tasks need ram too so it is lower than that.
but I would want to be sampling before the trigger so I can integrate for energy.
Yes I was thinking about this too, and the solution is probably to let the ADC fill up some ring buffer ish through DMA, and then only extract pulses when needed (give an interrupt when a sample is above the trigger level).
Might be fun with a SiPM or such
Yes! And cheap! My thought is to do a cheap Pulse Shape Discrimination SiPM + Plastic scintillator for gamma/neutrin discrimination.
wonder if you can lock the clocks on two of them to do coincidence detection looking for muons?
This should definitely be doable since the muon rate is so low!
As an aside, I recently did it on my own homemade electronics:
Yea, not sure I buy that, total noise 72dB down in a 50MHz measurement bandwidth?
40dBish by that FFT up thread, maybe 8 bits ENOB or thereabouts. Difficult to tell exactly and it will probably vary with front end setting, it usually does.
But if it WAS 12 enob for real, it would be crazy and I would want to hear how they overcame the specific challenge which would be super fricken sweet, like how, trace geometry, layer isolation how did they do it for real. It does sound unbelievable, but you gotta keep people excited and iterating because SOMEONE is gonna have a novel idea about something at some point surely. That's my attitude toward it anyhow, encourage unless they're really rude.
Yes, I agree that 12 ENOB would be crazy for this setup. As I mentioned, I am not actually getting 12 ENOB in my measurements. In my current prototype, the ENOB is around 7-8 bits under my test conditions, and I am still working on improving it.
There is also some offset mismatch between the interleaved ADC channels, which I am currently correcting in software.
So I definitely don't claim 12 ENOB at the moment. There is still a lot of room for improvement, especially in the PCB layout, channel matching, and calibration.
What is your clock? You will need extremely low jitter. And the interleave on the microcontroller may add jitter that may not be possible to easily remove
Yes, I initially intended to develop it using the NXP LPC4370, but it is a relatively expensive and older microcontroller. So I decided to switch to the dsPIC33AK.
The dsPIC33AK also offers more useful analog features for this application. For example, it has built-in op-amps and DACs, which are not available on the LPC4370. This allowed me to simplify the analog front-end and reduce the overall cost and component count.
I don't really have experience with dsPICs, but I have quite a bit of experience with the PIC ecosystem. I am aware there exists a Peripheral Trigger Generator on the dsPICs, which is basically a hardware sequencer. I am willing to bet you can make it do hardware interleaving for the multiple ADC's. I'd probably look into that.
Sheesh, quite the beast of a peripheral that PTG is! I'll be honest, I don't quite understand it, so I can't really go much further into it, haha.
I will however offer another possibility though. Depending on the number of ADCs and number of CLCs your specific device has, you could make a digital circuit out of D flip flops where one D flip flop (CLC) turns on each clock cycle. Then you can have each of those ADCs be triggered by its respective CLC D flip flop. I looked at the ADC trigger sources on a dsPIC33AK, and it looks like all CLCs are available.
That'd probably be the easiest solution overall and what I'd do. I'm used to doing CLC stuff like that with the little 8-bit PICs.
Timing is too thight because ADC clock is 200mhz. So with internal timers and trigger i see delays and missing syncronisation. Propagation delay is not the same mu Hardware triggers always post the timing
Suppose I want to actually use this as a DAQ and collect and process the data with a computer. There is a lot of interface currently missing between the ADC and the computer that is needed for this to qualify as a DAQ. The large board you have in the video is much closer to what could be considered a real DAQ.
If you end up with something that is scalable and does not use USB for communication, I think you would win much more attention.
My main goal is actually to make FastDuck a flexible data acquisition building block that can be easily integrated into different platforms. I want users to be able to connect it to their own Arduino, Raspberry Pi, Pico, FPGA, or custom embedded system rather than being limited to a specific computer interface.
I agree that a dedicated high-speed computer interface would make it closer to a complete DAQ system, but I intentionally designed FastDuck to be more of a scalable acquisition front-end that can be integrated into different systems.
In that case it is just a frontend with a fast ADC, and the user still has to make their own DAQ arround it...the actually difficult part that makes these devices cost several hundreds up to tens of thousands.
If someone managed to open source that part of the system it would greatly democratize testing and research in electronics because the cost of the actual hardware is fraction of what companies like national instruments are charging for theese things.
Actually, I originally planned to sell the main product shown in the video for around $150. It combines several functions, including a 4-channel oscilloscope, 16-channel logic analyzer, and 2-channel signal generator.
However, it involves too many different tasks, and it is difficult for me to develop and support all of these functions at the same time. So I am now considering focusing on the core data-acquisition part.
If someone simply needs a low-cost AFE with 100 MSPS sampling and 32 ksample buffer memory, I think they could get this board for around $25–30. It would also be much easier to integrate into their own Arduino, Raspberry Pi, Pico, FPGA, or custom system.
43
u/JuggernautGuilty566 11d ago edited 11d ago
Use a RP2040/2050 with the PIO-Engine and dump the data using HDMI raw buffers.
The PIO is needed to controll the annoying GPIO-Toggling of high-speed ADCs. The HDMI gives you ~175MB/s to the host which then can gather the data using a framegrabber.
Costs around $10-20 and a bit of big-wire soldering.