Products > Test Equipment

A High-Performance Open Source Oscilloscope: development log & future ideas

<< < (33/71) > >>

free_electron:

--- Quote from: nctnico on November 19, 2020, 11:49:20 pm ---The thought of using PCIexpress to aggregate more channels over seperate boards has crossed my mind too but you'll need seperate FPGAs on each board and ways to make triggers across channels happen. You quickly end up with needing to time-stamp triggers and correlate during post processing because the acquisition isn't fully synchronous.

--- End quote ---
PCI for data dump only. there would be a dedicated ribbon cable carrying the 'qualifier signals' for trigger. kinda like what they do with graphics cards.  the realtime stuff does not go over pci. it is fpga to fpga comms. you would not need too many signals. could use wired-or  wired-and principle. i'm ok with one fpga per baords. would be smaller. you could do a 2 channel acquisition board. then you can do 2 4 6 8 input machines.

tom66:
In the present implementation the data is stored in a 68-bit wide FIFO.  The 64 bits are ADC samples, 1 bit is a trigger indicator and 3 bits are the trigger index.

I only store the 64 bits of data in actual RAM presently, though.  There is only one trigger pointer for any given sample so that goes into a state register which is latched into the acquisition linked list on an interrupt.  I want to replace the acquisition control on the CPU with an FPGA control engine, as the interrupts and slow AXI-slave interface limit the total waveform rate.  I could get a very minimal blind time if the FPGA is doing everything (if I'm very clever - and I like to delude myself into thinking I am - it might be zero lost samples between individual waveforms with frequent triggers.)

tom66:
Hi all,

I made the decision to release all the FPGA designs, software (including Python application) and hardware designs under the MIT licence now. 

scopy-fpga contains the application code, FPGA design, IP repositories and STM32F0 firmware for the system. 
https://github.com/tom66/scopy-fpga

scopeapp is the Python application that runs on the Raspberry Pi that provides the UI.  It contains the rendering engine and rawcam capture libraries.
https://github.com/tom66/scopeapp

scopy-hardware contains hardware designs (schematics, gerbers, STEP file) for the design in CircuitMaker (interested parties can get an invite to the project on CM too, just PM me.)
https://github.com/tom66/scopy_hardware

What I want to do now is build a community of interested individuals and see where we can take this project as I think from the interest here it clearly 'has legs'.   The existing hardware platform is quite capable but I would like to do more and want to flesh out the modular capability and investigate higher performance tiers.  There is obviously debate over where this project can go and I think there are many interested parties who would use it and would be interested in contributing.  There is also a commercial aspect to be considered.

I will release a survey/Google Forms tomorrow, to gather some thoughts and then see where to go from there.

And if it goes nowhere, that's fine.  It's been a fun project to work on,  and maybe what I've developed so far can help others.

nctnico:
As I wrote before: I want to spend some time on creating a 1M Ohm analog frontend that is compatible with the HMCAD1520 / HMCAD1511 ADCs. This will need some number crunching first.

tom66:
It would of course be very interesting to see what you come up with nctnico.  In the meantime I am focused on the digital systems engineering parts of this project.  I am presently designing the render-acquisition engine which would replace the existing render engine in software on the Pi. 

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod