any news about the project?

Yup! Testing rev3 of the baseboard now and have new FPGA modules in production. I haven't been keeping up with project updates here, but if you want to follow the development in real time feel free to join our discord server: https://discord.gg/pds7k3WrpK

Hey Bro! I know HMCAD1520( 2Gsps ADC ) it's hard to buy in distribution, i am  in china! So I want to know your purchase channel !!! hope  your repy!!

I also DIY a scope  ( 1Gsps x 2, and 2Gsps x1 ),united a  logic analyse, scope, Signal generator，by use Zynq Ultrascale+ MPSOC . Now  I lack HMCAD1520 2pcs！！

Just want to encourage you to keep going. This project is very interesting and will be quite useful, especially since it allows direct logging on a computer. I am looking forward to the CrowdSupply campaign.

If at some point in time you also plan to make a 10 bit version, that would be great!

Appreciate it! We're making good progress to launch by the end of the year. As for a 10 bit version, how about 12 :) I've got a lead on a tray of hmcad1520s which can sample at 8, 12 and even 14 bit and is pin compatible with our current ADC (hmcad1511)

The high res version would be interesting. I see the chip is about 100 instead of 50 $, so it could be an interesting option for those willing to have higher res :)

Are there plans to make this compatible with sigrok?

Sorry for the late reply, I didn't get notified about this comment for some reason! We're focusing our efforts on glscopeclient right now, but it should be able to support sigrok with appropriate tweaks to how the triggered data is sent to the client software.

You probably know https://hackaday.com/2019/05/30/glscopeclient-a-permissively-licensed-remote-oscilloscope-utility/

There is a recent demo if its capabilities.  https://www.youtube.com/watch?v=z0ckmC2RXi4

That's a great demo, I'm seriously considering integrating it into this project. Why reinvent the wheel adding all these features when another open source project has them all? Just got to figure out how to hook the two together. I'm not a software guy myself, so I'd love to chat with a contributer behind that project to figure things out with!

Awesome hardware without proper SW support is pretty useless. I was told that any hardware project these days consists of 80% software development effort. I really suggest to you to find someone who is capable and >>willing<< to put in the effort to make GLSCOPEclient work with your hardware.  But finding this person will be a challenge in itself. You might be able to provide/find funding to/for this person.
If you succeed and make a first version usable, you can tap into the community of developers for the GLSCOPEclient and don't have to build your own community for your firmware (which is even harder).

Your opportunity with your headless scope is that all existing cheap scopes suck with their capability to transfer waveforms >>fast<< to the PC (this is where you shine).

(PS: the 8 bit resolution unfortunately is on the low side)

Hi,

Great project! As the developer of the first CrowdSupply scope ( https://www.crowdsupply.com/andy-haas/haasoscope ) I share your goals!

I've read a bit through your work here, but I have two main questions. 

What chip do you use to get 1 GB/s to the PC? 

Can a PC CPU really keep up with processing that much data in real time? To calculate the triggers, for instance, might take 10-100 floating point operations per sample. That's 10-100 GFlops. Do you use multiple threads/cores? GPU?

Thanks, Andy.

Hi Andy,

Seeing your scope succeed on Crowd Supply made me realize that people really do want open source test equipment - great work!

We've used the hard PCIe IP in a Artix7 FPGA to reach >1 GB/s with four lanes of PCIe gen 2. These PCIe lanes go to a Thunderbolt device controller and out to the user's PC.

Currently we only have edge triggering set up, but it does work in real time. This is since it only takes one operation per sample (subtract one from the other) and another operation to check for trigger events, that is only done once per block of samples. This will be further optimized by using a proper SIMD implementation. Triggering is only one part of the pipeline, so we do use multiple threads. We're aiming to run smoothly on any modern quad core, so can't use too many threads. Rendering the waves is GPU accelerated, but should run smoothly on integrated graphics.

Please feel free to ask me any more questions you might have, and consider joining our discord! https://discord.gg/pds7k3WrpK

Cheers,

Aleksa

Great project.
I have a question: What's the highest data rate you can actually sustain continuously with that tiny little 24kB buffer on the usb3 fifo? 

I ask, because I know that with USB 2.0 Hi-Speed, one really needs at least about 8MiB of sdram attached to the FPGA as a 'deep buffer' in order to maintain 30 MB/s without dropping packets. This isn't the fifo chips' fault - it's the USBIF's fault for not requiring USB root hub controllers to handle packet timing with state machines and DMA when they added hi-speed.

What happens all too often, is that the PC OS just doesn't poll the bus sometimes, and the hardware attached to the fifo needs someplace to store fresh data whilst the usb-fifo chip is full and waiting on the OS.  This all didn't matter with USB 1 speeds, but with USB 2.0, just missing a packet time for a few too many microseconds really breaks using bulk transfers to capture data steadily from an FPGA with ADC's attached.

But with USB 3, I hope, this should not be an issue - I fervently hope that the super speed bus can in fact DMA straight through to host ram without needing the OS to service an interrupt. I haven't tried it, which is why I ask.

I found that it was a very good idea to test transfer integrity by just running a free-counting 24 bit binary counter on the FPGA - having it increment for each sample, and have a copy of it streamed through the USB fifo all the way to a file on a (big) disk. 

This helped me verify that it could reliably sustain the data rate I was shooting for by leaving it running until it filled the disk array (about 11TB at the time). With an incrementing counter, you can quickly scan the beginning and end of the file, and very easily determine whether the counter is where it should be at.

I also found that leaving an oscillocope to 'watch' the 'fifo full' fifo interface pin was good practise - you're looking for pulses longer than expected, which means the data isn't flowing as expected. 

In any case - I'd suggest that streaming the raw (from ADC) data straight to disk, and then looking at it 'retroactively' is a very good way to do science. In my line of work, I do 1MS/s capture of 6-8 channels at 12 bits, then just save it down to a file. This is run like the old paper 'strip chart recorders' - start and run all day - never bother with trying to 'trigger' and save just data you think might be interesting - you miss all the stuff that happens unexpectedly. And since I'm working things that may break very quickly without warning, it has been very helpful to have such a 'black box recorder' record to go back through later to figure out exactly what went wrong. I regard the 'trigger and save' approach to basically be too close to cherry picking. It's too easy to miss too much.

Anyway since the work is in an 'industrial' environment, I have a linux SBC in a box with the ADCs/FPGA's etc (with a gigabit ethernet adaptor) with which I stream the data out to where the big disks are, just using a couple invocations of netcat. I have mostly just been using the ztex.de usb-fpga boards this way, although only the usb 2.0 ones.

The program called 'snd' (https://ccrma.stanford.edu/software/snd/ or just 'apt install snd' in any debian) is very useful for quickly looking at arbitrary raw PCM files. It's intended for raw sound file editing, but uses memory mapped io and can accept data with arbitrary number of channels, format and sample rate. It can seem to 'lock up' if you open a very large file and zoom 'all the way' out - but this is because it internally scans the whole file and makes a low-res map of it. It may take a while, but when it's done you can then zoom right in anywhere - feels a bit like using google earth. 

For actual processing/data extraction, you can just use numpy from python. Just open the raw pcm file with memory mapped io, and let the OS kernel worry about chunking/loading/unloading it through memory. It just looks like an array to you ( there's a package called tqdm that easily adds nice progress bars with ETA's, great when you're chewing through multi-TiB data files). This usually results in performance quite close to disk read speed, depending on how much processing you do. Profile and use cython etc where it matters, if it does.

I have also got a setup which does the whole 'looking for a trigger, and saving so many seconds capture' setup, but that was at a much lower data rate with NI hardware and software. Using a multithreaded software architecture with separate threads and queues to pass data between them was key there, as was assembling the data into fairly large 'blocks' to handle at once. First thread handled 'catching' the data and chunking it up, second handled looking for trigger conditions and handling a ring buffer so that data before the trigger could also be saved, third thread to catch the 'collected' data to be saved out to a file.

If I was going to suggest anything to do with processing the datastream live, rather than just saving to a file and worrying about it later,  it would be to look into using either gstreamer (which is for pipeing video processing - also tends to be fairly heavy data streaming rates) and/or gnuradio (or both). 

Gstreamer would be especially useful, as it is already architected to try to handle high data rate streams like uncompressed video.  You could use your data to feed 'live' instrument readouts / plots (generated within custom gstreamer plugins), which you could then 'mix' into another live video stream. You could even then connect this directly to youtube, and livestream video with a event-detecting oscilloscope overlay mixed in running from live data. (I have kind of done this, but cheated by putting the whole oscilloscope I was using where the high res security camera I was livestreaming from could see it). 

Would be great for any experiments where things can go wrong quickly, and I suspect using gstreamer like that is possibly how spacex does it when they launch rockets. From what I recall, you could even use html5 in gstreamer to draw the overlay, and you can certainly do 'live' video mixing like cutting between cameras and greenscreen etc. 

Gnuradio is also an obvious one - the SDR guys are going to love your hardware, I am sure!

Hope this helps, good luck!

Great comment! I found that the FT601 could sustain a data rate of 370 MB/s. To verify that, I lowered the clock rate from an external clock generator until the FIFO full led wasn't lit. I also used a counter much like you described and sifted through the data in csv format to make sure it was all consecutive. I really like the idea of triggering off of the FIFO full pin (since it should never be full while streaming) and the method of analyzing the data coming out (certainly beats waiting ~10min for excel to do anything in such a large csv). Piggybacking off of video processing is also an interesting prospect for handling such large streams of data. I appreciate the suggestions!

Thank you for the logs. I enjoy reading them

Thanks, glad to hear you're enjoying them so far!