Open Source Oscilloscope, can it be done?

[haastyle]

I agree it's borderline, but the FPGA clock output is good enough in this case. The RMS jitter is 660ps / 14 = ~47ps.
The 660 ps is the peak-to-peak jitter, or bit error rate of 10^-12, as noted in footnote 31 of the datasheet: https://www.altera.com/en_US/pdfs/literature/hb/max-10/m10_datasheet.pdf

To convert to RMS jitter, you have to divide by the error function probability, which is about 14 for a 10^-12 BER. See:
http://pdfserv.maximintegrated.com/en/an/AN462.pdf

And this 660ps is when driven from a clock with jitter of up to 30ps. I'm using a low-jitter oscillator which has RMS jitter of ~3ps. This must reduce the output PLL jitter somewhat (not a factor of 10 though). With this, I'm within the 25 ps spec, or close enough that the additional noise/distortion is negligible.

Anyways, it works well, and a 25 MHz sine wave looks good. The FFT shows no signs of distortion.

[ogden]

I agree it's borderline, but the FPGA clock output is good enough in this case. The RMS jitter is 660ps / 14 = ~47ps.
The 660 ps is the peak-to-peak jitter, or bit error rate of 10^-12, as noted in footnote 31 of the datasheet: https://www.altera.com/en_US/pdfs/literature/hb/max-10/m10_datasheet.pdf

You are reading wrong book BER does relate to digital I/O, not analog signal sampling using ADC. You shall care not about BER but SNR and resulting ENOB degraded by ADC aperture jitter. For example this appnote says "At 100ps, the ADC SNR begins to degrade with input frequencies of only 200kHz!": http://cds.linear.com/docs/en/design-note/dn1013f.pdf

Anyways, it works well, and a 25 MHz sine wave looks good. The FFT shows no signs of distortion.

All the energy of 25MHz sine falls into single FFT bin, no "smearing" or PLL "spectrum skirts"? - No way for 660s p-p ADC clock jitter and 25MHz sine signal. What's order of FFT used?

[Marco]

Approximately the derivative times the jitter is the error range near 0 ... so 2*pi*25e6*47-12 ~= 8 mV RMS for a 1V amplitude 25 MHz sine. So you lose a bit or so.

[erikg]

Have you guys seen this?

https://www.digikey.com/product-detail/en/analog-devices-inc/HMCAD1520TR/1127-1198-2-ND/3660273

It's ~$100 a chip, but I can imagine a multi-mode measurement device built around it.  Internal interleaving modes for 1,2 or 4 channels allow a range of speeds, multiple ADC precision levels are also switchable.  Four channel scope at 12 bits/160MSPS, two channels at 12/320MSPS, or one channel at 12/640MSPS.  You can also drop down to 8 bits for single channel rates up to 1GSPS, or engage "precision mode" for four channels at 14 bits/105MSPS.

Looks like it's designed to be used in portable devices too, with low power use and sleep modes.

The flexibility of the built-in interleaving plus the variable bit depth would seem to me to be a nice fit for a wide variety of uses... a portable cheap scope for field use, a first scope for hobby use, an "extra" scope for when you need just one more channel.  If it's cheap, you could even build the software to run multiple units as one... so you could run up to e.g. four of them as 1 GSPS scopes together.  You could also do tricks to save battery like sleep for an interval, wake up to sample, then trigger a reconfig to higher speed or precision, record data, then back to sleep.  Doing most of the processing in software on commodity PC hardware gives you lots of sample depth and open source allows for hardware/software upgrades and even a complete re-tasking of the hardware with a different program loaded.

Since I'm a noob at this though, I'm wondering what other components would be needed for such a critter?  The A/D has internal references, so it's a single chip solution for its function, but there would also have to be an op amp on the front end with wide bandwidth, a microcontroller running the show, and an interface chip for streaming the samples over USB 3.1.  Maybe local memory for buffering when not attached to a host PC, a watchdog, digital I/O for logic analysis and triggering, a dedicated SPI interface for target control that allows for a variety of control interfaces (SPI, I2C, RS-485, Ethernet, TTL, etc). 

Would it be possible to use a Beaglebone as the local controller, maybe using the PRUs to keep up with the data stream?

I'd guess overall it would be best to make the hardware acquire data and get it quickly to a computer, then make most of the functionality happen in software (basically a software defined 'scope).  A rough guess would be about $200-$300 or so in parts plus board fabrication and assembly cost... which is not nothing, but is still a lot cheaper than a Rigol DS1102, and it would have a much bigger screen

Anyone want to speculate on a cheap way to use this chip in a design for a software 'scope front end?

[haastyle]

Yeah, it's a nice chip! It's not so easy to make a board that uses such a chip however - there's huge data rates, lots to configure, noisy digital outputs, and you want super low noise! (Even just 12 bits means you want less than 0.2 mV of noise at your ADC inputs!)

You definitely need an FPGA to handle those data rates.

Take a look at their evaluation board:
https://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyEVAL01-HMCAD1520
and the linked datasheet there.
This is a reasonable start at what you'd have to do to have a working system. It's ~$500. You could probably design something more integrated and specialized and trim away the fat, so to speak, and get it down to ~$300. But not easy!

[erikg]

Yep, definitely not a board that would work if designed by a noob.

I'm sure I could do the software with more than a little effort, but hardware wise I basically can manage to understand why everything is where it is

So what criteria do you use to decide what's needed to handle the data rates?  Software wise, I'd expect something like a dedicated chip reading the data from the ADC and writing it to dual ported memory, and a dedicated USB processor reading it out the other end and transmitting it to a computer, with the computer doing all the hard work.

What does the FPGA do in this scenario?

[ogden]

I'm sure I could do the software with more than a little effort, but hardware wise I basically can manage to understand why everything is where it is

Yo mentioned 1GSPS at 8bits right? Most of modern CPU's will struggle to read data at 1GByte/s, not to mention doing something useful with it. For such a "beast chip" you don't even do a software but high speed logic using FPGA. https://en.wikipedia.org/wiki/Field-programmable_gate_array. Most likely digging into FPGA topic will answer your question:

What does the FPGA do in this scenario?

Hint: all the job.

[erikg]

I'm continuing with this thought experiment for learning purposes, thanks for reading and any replies you continue to provide.

So... getting that much data handled in real time would be nearly impossible to do over a USB link, ok.  Putting gigabytes of memory on the 'scope end for buffering is possible, but doing something with the data is the problem.  Even with data compression, something still has to scan through the data to e.g. trigger, and then whatever determines that the trigger conditions were met has to, well, trigger.

So that means a portable scope is difficult in general because of the hardware requirements for handling that much data.  An FPGA or an ASIC would be needed, and following that thought the FPGA has to be programmed with most of the functions of a 'scope, which would get expensive quickly, limit features, and in general not be significantly cheaper than a purchased scope.

It might be possible to use an FPGA with a simpler config to couple the ADC chip to a PCIe x8 slot on a PC motherboard, functioning as an LVDS receiver, buffer, and DMA engine?  That's more than enough speed to stream data to PC memory.  Lots of capture depth, and I could imagine streaming data to a ring buffer a few gig in size while the PC CPU scans through it looking for trigger conditions.  When triggered, data starts getting put somewhere else in memory for processing, possibly in compressed form. 

I'll start reading up on FPGAs.  I've wanted to learn about 'em anyway

[hermit]

PCI is getting even faster.
http://www.tomshardware.com/news/pci-sig-releases-pcie-4-specs,35767.html

[rhb]

There is no way that an open source scope could be made cheaper than a low end Chinese unit.  If it could be done, the Chinese would.

What *could* be done is to reverse engineer something that uses a Linux distro and write custom firmware for it.  Unfortunately that is a good bit of work.  There is precedent though in the form of DD-WRT which leveraged the GPL to get enough information about the internals to write new firmware.

However, the easiest route to an open source oscilloscope is to write a portable PC UI for the SCPI LAN interface. The 2nd step would be to write a UI for specific hardware that transformed the button presses into SCPI commands sent via 127.0.0.1.

That might well tempt an OEM to build hardware for the UI.

[BradC]

There is precedent though in the form of DD-WRT which leveraged the GPL to get enough information about the internals to write new firmware.

I think you need to re-check the history on that. DD-WRT started when they obtained a practically complete copy of a linksys firmware and effectively re-badged it. It has evolved significantly from there, however they started from a pretty-much complete working source.
That's more like Rigol giving you the V0.9 source in a buildable format and then you go and start enhancing it, and it's *considerably* different from reverse engineering from scratch.

[ogden]

There is no way that an open source scope could be made cheaper than a low end Chinese unit.

Agreed. Sure you can build low cost "toy scope" but again chinese are offering such all over the place 

DD-WRT started when they obtained a practically complete copy of a linksys firmware and effectively re-badged it.

Not the whole firmware, just source code of the kernel which have most of the router functionality in it. Kernel of the scope will contain just scope-specific I/O drivers which is close to nothing. All the scope magic is happening in the FPGA or ASIC. CPU is also doing some useful stuff, but in application code which again is unobtainable.

[hermit]

There is no way that an open source scope could be made cheaper than a low end Chinese unit.  If it could be done, the Chinese would.

What *could* be done is to reverse engineer something that uses a Linux distro and write custom firmware for it.  Unfortunately that is a good bit of work.  There is precedent though in the form of DD-WRT which leveraged the GPL to get enough information about the internals to write new firmware.

However, the easiest route to an open source oscilloscope is to write a portable PC UI for the SCPI LAN interface. The 2nd step would be to write a UI for specific hardware that transformed the button presses into SCPI commands sent via 127.0.0.1.

That might well tempt an OEM to build hardware for the UI.

How far could you get with something like a Beagle Bone Black that has two real time units embedded?  They run at 200Mhz.  Someone did a cape with 16 logic analyzer channels running at 100Mhz.

[ogden]

It might be possible to use an FPGA with a simpler config to couple the ADC chip to a PCIe x8 slot on a PC motherboard, functioning as an LVDS receiver, buffer, and DMA engine?

Much more cheaper and simpler will be just to add external memory to the FPGA. Or maybe do not add too much memory to keep costs down For example (now obsolete) 54855A Infiniium scope had PC inside, but it did not use RAM of embedded PC for sampling. Sorry, but it is stupid engineering to sample into PC RAM - of course if we talk about high speed (>= 1GSPS) scope. PC-based "open source" 1GSPS scope shall process waveform in the FPGA, draw video framebuffer there, transmit resulting video stream (containing just waveform picture, not even grid) over USB.

[ogden]

I still believe that building DIY scope is like a building better mousetrap. Indeed it could be done as an challenge project "because I can", but economics is not worth it. There's lot of scopes which cannot be beat by DIY approach:

48MSPS/20MHz  Hantek 6022BE USB scope: ~60$, including two probes
100MSPS/25MHz OWON VDS1022 USB scope: ~80$, including two probes
100MSPS/25MHz isolated OWON VDS1022I USB scope: ~100$, including two probes
250MSPS/70MHz Hantek iDSO USB scope: ~170$, including two probes
1GSPS/100MHz Hantek DSO5102P (standalone!): ~225$, including two probes

[rhb]

However, the easiest route to an open source oscilloscope is to write a portable PC UI for the SCPI LAN interface. The 2nd step would be to write a UI for specific hardware that transformed the button presses into SCPI commands sent via 127.0.0.1.

It appears that a portable PC GUI already exists for some or all the GW Instek scopes in the form of:

https://github.com/OpenWave-GW/OpenWave-2KE

It's written in python, so I assume it's written on top of the SCPI interface, but I'll have to check that.

I don't see a lot of value in rewriting the FPGA software except for bug fixes.  The hardware choices pretty much control what can be done in terms of sampling, etc.   It might be possible to make minor improvements, but that depends upon whether there are any unallocated resources.

One can do all manner of interesting things with a Beaglebone or any other high power MCU dev board.  Lots of people are doing that and selling some version on eBay.  I had a project to do that, but dropped it when I realized that world + dog was doing the same thing.  Still a good project, I'd rather implement a VNA using a DSO and an add on board w/ DDS and directional couplers.

[ogden]

I'd rather implement a VNA using a DSO and an add on board w/ DDS and directional couplers.

Great idea! -Especially if you could consider to add SCPI-capable waveform generator support. Then "VNA" electronics reduces to quite simple board (no DDS needed), all the magic is software. I think, Rigol 1000Z-S series scope owners/hobbyists would be especially happy with such.

[erikg]

>Sorry, but it is stupid engineering to sample into PC RAM

Why exactly is that?


>I still believe that building DIY scope is like a building better mousetrap. Indeed it could be done as an challenge project "because I can", but economics is not worth it. There's lot of scopes which cannot be beat by DIY approach

That's not the point, though.  The point of an open source scope is to have a working non toy Oscilloscope that's able to be modified and improved by anyone who wants to take the time, with those modifications able to be contributed back to the original design - everyone who's using it can benefit.  Since open source allows commercial use provided users can get schematics and are free to modify them (and any commercial mods are contributed back to the design) it's even possible for people to manufacture and sell open source hardware designs for profit.  Provided the design is somewhat modular, as new chips (like a new front end) come out, it can evolve and integrate new technology.

So... a DSO or MSO with complete schematics and source code that has reliable software, full documentation in a variety of languages, and isn't vulnerable to a single hardware manufacturer dropping support, getting sold, going out of business or otherwise sticking it to the buyer?  I'd buy two.  Even if they cost twice as much as the Chinese scopes.

[ogden]

>Sorry, but it is stupid engineering to sample into PC RAM

Why exactly is that?

Do I really need to explain that? Come on..

0) To reach 1Gbyte/s, scope shall be in form of some PCI express adapter for desktop PC. Scope "head" shall be connected to PCIe using hi-speed bus. It means quality hi-speed cable and connectors. Could add quite a lot of cost.
1) Because of point 0) laptop and miniPC users are out of luck of using such PCIe adapter scope. This is HUGE disadvantage.
2) PC is laggy and not "realtime" by definition. Do you really want to lose samples or trigger events when OS decides to flush some bigger data chunk on HDD?
3) Such "software" scopes cannot have trigger output hardware signal by definition - because PCs are laggy
4) Yes, PCIe can transfer data at 1GByte/s so what? - It shall be processed too. Even so simple operation as trigger event search requires quite lot of CPU cycles. No offense, but either you get it here or you are way too out of "1GSPS scope league".

As I said - all the job of such scope shall be done in the FPGA and PC shall act just as "I/O terminal" for it. Period. Then even USB2 is good enough BTW.

[edit] Owon VDS3104 have proper hi-speed USB scope architecture.

[erikg]

>Do I really need to explain that? Come on..

Yes, because I'm trying to understand your point of view.  Replies below...

>0) To reach 1Gbyte/s, scope shall be in form of some PCI express adapter for desktop PC. Scope "head" shall be connected to PCIe using hi-speed bus. It means quality hi-speed cable and connectors. Could add quite a lot of cost.

PCIe slots just require the edge of the circuit board to be shaped for insertion... no cables required.  Not sure what you mean here?


>1) Because of point 0) laptop and miniPC users are out of luck of using such PCIe adapter scope. This is HUGE disadvantage.

It depends.  You can make it a half-height card suitable for mini PCs and full size.  Laptops are a miss, sure, but there's a limited amount you can do with them if you need more speed than USB can provide.

>2) PC is laggy and not "realtime" by definition. Do you really want to lose samples or trigger events when OS decides to flush some bigger data chunk on HDD?

Hard real time is difficult, but possible.  Look at the example of RTAI - https://www.rtai.org/.  Besides, we're talking about DMA over the PCIe bus, which doesn't require CPU intervention.  Unless there's a hardware fault holding the bus hostage, the 'scope card could write data whenever it needed to do so, right?

>3) Such "software" scopes cannot have trigger output hardware signal by definition - because PCs are laggy

Not true always, as mentioned above.  Even Windows 10 has a real time solution: http://www.intervalzero.com/

Besides, if you're using the PC's memory as a giant buffer, you don't need to trigger in real time, exactly.. you just record everything in a ring buffer a few GB in size and keep overwriting it with new data.  As long as the CPU gets around to examining the data before it gets overwritten so it can record the target data, it would work I think.

>4) Yes, PCIe can transfer data at 1GByte/s so what? - It shall be processed too. Even so simple operation as trigger event search requires quite lot of CPU cycles. No offense, but either you get it here or you are way too out of "1GSPS scope league".

See above, if you record all samples continually into memory it isn't necessary to trigger in real time... you just examine the recorded data often enough to ensure you don't miss something before it's overwritten.  Once the CPU finds the "trigger" condition, it just ceases overwriting data and records a sample for review instead.

I'm not sure how long a PC could sustain DMA at that speed, though.... from what I can tell, most of the high speed acquisition cards out there use local RAM and an FPGA like a Virtex-5 for sample capture, then transfer to the PC's memory for further processing.

Example: http://www.signatec.com/products/daq/high-speed-digitizers.html

>As I said - all the job of such scope shall be done in the FPGA and PC shall act just as "I/O terminal" for it. Period. Then even USB2 is good enough BTW.

Yes, but you're wasting all the PC's hardware (which is cheaper than oscilloscope hardware because it's commodity).  In particular, it would be good to use the memory space for sample depth and the ability to use multiple CPU cores and GPU cores for analysis. 

Thanks for replying, it's interesting.

[ogden]

>Not sure what you mean here?

Who wants scope BNC connectors on the back of desktop PC? Anywone?

>Laptops are a miss, sure, but there's a limited amount you can do with them

From which planet or century you just did arrive?

>>Do you really want to lose samples or trigger events when OS decides to flush some bigger data chunk on HDD?
>Unless there's a hardware fault holding the bus hostage, the 'scope card could write data whenever it needed to do so, right?

Wrong. It does not require hardware fault for bus or RAM peripheral to become busy. Just as I said - it will happen "when OS decides to flush some bigger data chunk on HDD".

>3) Such "software" scopes cannot have trigger output hardware signal by definition - because PCs are laggy
>Not true always, as mentioned above.  Even Windows 10 has a real time solution:
>Besides, if you're using the PC's memory as a giant buffer, you don't need to trigger in real time, exactly..

It depends what you mean by real time. 1ms which for PC is quite "real time" on 100MHZ scope is "too late", not even yesterday. Don't tell now that hardware trigger output (connector) is not needed as someone told here about AC coupling.

>See above, if you record all samples continually into memory it isn't necessary to trigger in real time... you just examine the recorded data often enough to ensure you don't miss something before it's overwritten.

You say that CPU of average hobbyist PC can keep up analyzing & processing data which arrives at rate 1GBps?

>>As I said - all the job of such scope shall be done in the FPGA and PC shall act just as "I/O terminal" for it. Period. Then even USB2 is good enough BTW.
>Yes, but you're wasting all the PC's hardware (which is cheaper than oscilloscope hardware because it's commodity).

Exactly my point. RAM is commodity. 4GByte SODIMM DDR3 memory module costs 20$. 1Gbyte less than 10 bucks.

When you build PCIe-card scope, you are seemingly saving on PC computing and storage hardware (I disagree even here, but whatever). But you are losing huge on FPGA which shall be equipped with lot of GTX transceivers (for PCIe bus). So basically saving 7..20$ you will spend some 1000$ (wild guess) or so on FPGA alone. Monkey business I would say.

[erikg]

>Wrong. It does not require hardware fault for bus or RAM peripheral to become busy. Just as I said - it will happen "when OS decides to flush some bigger data chunk on HDD".

Actually, this isn't possible with PCIe.  Due to the bus architecture, it supports multiple full duplex DMA transfers simultaneously, and in fact the CPU cores being busy would not delay or interrupt DMA transfers. 



I think you're probably misunderstanding what I'm saying for most of this post, but no worries.  Thanks for responding.

[ogden]

>>Wrong. It does not require hardware fault for bus or RAM peripheral to become busy. Just as I said - it will happen "when OS decides to flush some bigger data chunk on HDD".

>Due to the bus architecture, it supports multiple full duplex DMA transfers simultaneously,

Well.. what a revelation

>in fact the CPU cores being busy would not delay or interrupt DMA transfers. 

I said "bus or RAM peripheral to become busy", did not even mention CPU. Well, ok - let's conclude that RAM will be no bottleneck at ANY of the moments. CPU searching for trigger events and processing waveforms - could be indeed. I am not ready to literally waste all the PC resources and performance just because you cannot comprehend that - if you have FPGA then best way is to use it, place RAM and processing where it supposed to be - at/in the FPGA

[edit] What we are talking here about? - That direct to PC RAM sampling at 1GBps is possible? Indeed it is. You did prove it by showing 10000$ sampler which is used by labs which can afford to buy as many rackmount PCs as samplers they have. And some more. Fact that it can be done does not help in discussion where we talk about  "hobby market" low cost, but hi-performance scope.

>I think you're probably misunderstanding what I'm saying for most of this post, but no worries.

No problem, no worries at all. Better show me where I did misunderstood you. BTW you did "skip" most of my arguments except one, which is not that important actually.

[NiHaoMike]

>1) Because of point 0) laptop and miniPC users are out of luck of using such PCIe adapter scope. This is HUGE disadvantage.

It depends.  You can make it a half-height card suitable for mini PCs and full size.  Laptops are a miss, sure, but there's a limited amount you can do with them if you need more speed than USB can provide.

More and more laptops are supporting eGPU nowadays. It's even possible to cobble together your own eGPU from under $20 in parts plus the GPU itself.

[ogden]

More and more laptops are supporting eGPU nowadays. It's even possible to cobble together your own eGPU from under $20 in parts plus the GPU itself.

Those who can afford such laptop and external PCIe cabinet most likely can afford and will be willing to get just proper standalone scope.