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

[asmi]

asmi, could you link to that Cypress solution?  I will give it a look, but it does (as nctnico says) seem like added complexity for little or no benefit.

https://www.cypress.com/products/ez-pd-barrel-connector-replacement-bcr
I would recommend to buy this eval kit: https://www.cypress.com/documentation/development-kitsboards/cy4533-ez-pd-bcr-evaluation-kit It's very cheap ($25), and allows you to evaluate all features of the chip.
But I find it's hilarious that you already declared it to be complex and provide no benefit without even seeing it

In my fairly modern home with a mix of Android and iOS devices I have one USB-C cable and zero USB-C power supplies.  My laptop (a few years old, not ultrabook format) still uses a barrel jack connector.  Girlfriend's laptop is the same and only 1 year old.  I've no doubt that people have power supplies with Type C,  but barrel-jack connectors are more common and assuming this device will ship with a power adapter, it won't be too expensive to source a 36W/48W 12V AC-adapter whereas a USB Type-C adapter will almost certainly cost more.

Take a look at Amazon - you can buy 45 W USB-C power supply for like $15-20.
Barrel jacks are good exactly until you connect the wrong one and cause some fireworks.

And there will be that not-insignificant group of people who wonder "why does it not work with -cheap 5W smartphone charger-?"  When you have to qualify it with things like, only use >45W or more rated adapter, then the search-space of usable adapters drops considerably.

I kind of suspect that idiots are not exactly the target audience for DIY oscilloscope project
But again, nothing stops you from having both options if you really want that stone-age barrel jack. It's trivial to implement.

[tom66]

I didn't regard Cypress solution as too complex.    I'd not seen it until you literally just linked it!  I just have an aversion to USB for power supplies because it's not ideal in many cases and for *this product* it is a complex solution with little obvious benefit.  As nctnico says, what does it add?  It needs to add a good thing to be worth the complexity.

There's a big TVS on the input that clamps at ~17V on the present board.  If you put reverse polarity or too many volts in it either blows the fuse or crowbars the external supply.  A barrel jack is about the most rugged DC connector you can get for the size whereas USB-C port could get contaminated with dust/dirt or have connection pads damaged - after all it is a 20 pin connector.  I've had plenty of headaches with USB connectors before failing in odd, usually somewhat intermittent ways: both the Lightning connector on my old iPhone and the USB Micro connector on my old Samsung S5 failed in intermittent fashion and required replacement.  So personally I see the barrel jack as better from an engineering environment perspective where you have more dust and contaminants than typical. 

And you have a point about the target-market being technical but then you will also have non-technical people that might want to use such an instrument e.g. education or hobbyists.  That USB-C supply is twice the retail price of a comparable Stontronics PSU with a barrel jack output, and it's not clear what it offers over the barrel jack for most users.

Don't get me wrong, nothing is set in stone yet,  it might be the best solution for Mk2 of the product.  I will of course listen to feedback in that regard.

[dougg]

Still isn't adding USB-C adding on more complexity to an already complex project? I recall Dave2 having quite a bit of difficulties implementing USB-C power for Dave's new power supply.

There are lots of 1 chip solutions. Have a look at tindie.com for examples with schematics in most cases. If a USB-C power adapter (or battery, the RP-PB201 is a cheaper + more powerful than the Mophie 3XL that I mentioned previously) doesn't have enough power for the 'scope (you always get at least 5 Volts (Vsafe) at 1.5 Amps) then flash a red LED.

Dave seemed to be intimidated by the 659 page USB PD spec (plus the 373 page USB Type C spec). Dave "spat the dummy" for theatrical effect; either that, or he should get out in the real world more often! For example: write a device driver for product A to talk to product B via transport C (e.g. USB, Ethernet, BT) using OS/environment "D". That may involve thousands of pages across multiple specs. You don't read them like a novel, you use them like a dictionary. And when product A fails to talk in some situation to product B, you contact support for product A (say) and point out that it doesn't comply with the spec they claim to implement with a reference to chapter and verse (of the relevant spec).

I proposed two USB-C ports to replace the barrel connector _and_ the USB Type A receptacle. So either one could be power in, while the other functionally replaced the USB Type A host. In that latter role USB-C is more flexible as it can play either the role of (data) host or device. So your PC connection could be via USB-C where the PC is "host" and the 'scope is the device. OTOH you could connect a USB memory key and the 'scope would play the host role (and source a bit of power).

Whoever suggested connecting a USB-C power adapter to a USB dongle might find that hard to do if the USB-C power adapter has a captive cable. [They would need a USB-C F-F dongle.] If the power adapter didn't have a captive cable (just a USB-C female receptacle) then the connection can be made but nothing bad would happen (i.e. no magic smoke), the dongle would be powered at 5 Volts but the dongle would find no USB host at the other end of the cable to talk to. Maybe the dongle would flash a LED suggesting something was wrong. When you use symmetrical cables then many more stupid combinations are possible (so devices and their users need to be a bit smarter) but you need less (a lot less) cable variants. That is a big win for not much pain .

[dougg]

There's a big TVS on the input that clamps at ~17V on the present board.  If you put reverse polarity or too many volts in it either blows the fuse or crowbars the external supply.  A barrel jack is about the most rugged DC connector you can get for the size whereas USB-C port could get contaminated with dust/dirt or have connection pads damaged - after all it is a 20 pin connector.  I've had plenty of headaches with USB connectors before failing in odd, usually somewhat intermittent ways: both the Lightning connector on my old iPhone and the USB Micro connector on my old Samsung S5 failed in intermittent fashion and required replacement.  So personally I see the barrel jack as better from an engineering environment perspective where you have more dust and contaminants than typical. 

And you have a point about the target-market being technical but then you will also have non-technical people that might want to use such an instrument e.g. education or hobbyists.  That USB-C supply is twice the retail price of a comparable Stontronics PSU with a barrel jack output, and it's not clear what it offers over the barrel jack for most users.

I'm proposing an infinitely cheaper PSU supplied with your 'scope :-) That is, no PSU at all. Sounds like you need 15 Volts in and while that is a common USB-C PSU voltage, the El cheapo ones only supply 5 Volts, and sometimes 9 Volts as well. If you need 15 Watts or less than you could boost a RPi 4 PSU (and they are around $US10). All USB-C PSU schematics that I have seen (that can supply > 5 Volts) have a pass MOSFET that gets switched off in a fault condition. For power only USB-C the 24/22 pin connector can come down to as few as 6 active pins (see https://www.cuidevices.com/blog/an-introduction-to-power-only-usb-type-c-connectors ).

[nctnico]

Just wondering... has any work been done on an analog front-end? I have done some work on this in the past; I can dig it up if there is interest. Looking at the Analog devices DSO fronted parts it seems that these make life a lot easier.

I've got a concept and LTSpice simulation of the attenuator and pre-amp side, but nothing has been tested for real or laid out.  It would be useful to have an experienced analog engineer look at this - I know enough to be dangerous but that's about it.

I have attached a design I created based on earlier circuits. IIRC it is intended to offer a 100MHz bandwidth and should survive being connected to mains (note the date!).
Left to right, top to bottom:
- Input section with attenuators. Note sure whether the capacitance towards the probe is constant.
- Frequency compensation using varicaps. This works but requires an (digitally) adjustable voltage of up to 50V and I'm not sure how well a calibration holds over time. Using trim capacitors might be a better idea for a first version.
- over voltage protection
- high impedance buffer
- anti-aliasing filter. Looking at it I'm not sure whether a 7th order filter is a good idea due to phase shifts.
- single ended to differential amplifier and analog offset
- gain control block and ADC.

Nowadays I'd skip the external gain control and use the internal gain control of the HMCAD1511/20 devices. It could be a nice Christmas project to see how it behaves.

[rhb]

- anti-aliasing filter. Looking at it I'm not sure whether a 7th order filter is a good idea due to phase shifts.
- single ended to differential amplifier and analog offset
- gain control block and ADC.

What's required  to preserve waveform fidelity is the flattest phase delay, a Bessel-Thompson filter.  I've spent a lot of time studying the subject.  It's not well treated in the literature, but well documented in scopes.  Of course, all high order analog filters are problematic to produce.  Though with an FPGA one need only get close and the FPGA can trim the last bit.

As the order goes up the Bessel-Thompson passband approaches the Gaussian passband.  So the impulse response of a 10th order Bessel-Thompson is approximately a time delayed Gaussian spike.

Tom is the reason I dropped work on hacking the Instek GDS-2000E after I blew the scope. It no longer made sense to replace it.

Have Fun!
Reg

[Someone]

Shifting the dots is computationally simple even with sinx/x (which is not yet implemented).  It's just offsetting a read pointer and a ROT-64 with an 8-bit multiple, practically perfect FPGA territory.  In the present implementation I simply read 0..3 dummy words from the FIFO, then rotate two words to get the last byte offset.

Noting that triggers in modern scopes are aligned more finely than the sample rate (interpolation), with the reconstruction and interpolation methods also dependent on the front end characteristics. Expect the rendering speeds to collapse in a software/GPU approach once you put in that phase alignment and sinc interpolation.

As I understand it, and please DSP gurus do correct me if I am wrong, if the front-end has a fixed response to an impulse (which it should do if designed correctly), and you get a trigger at value X but intend the trigger to be at value Y, then you can calculate the real time offset based on the difference between these samples which can be looked up in a trivial 8-bit LUT (for an 8-bit ADC).   It's reasonably likely the LUT would be device-dependent for the best accuracy (as filters would vary slightly in bandwidth) but this could be part of the calibration process and the data burned into the 1-Wire EEPROM or MCU.

In any case there is a nice trade-off that happens as the timebase drops: you are processing less and less samples.  So, while you might have to do sinx/x interpolation on that data and more complex reconstructions on trigger points to reduce jitter, a sinx/x interpolator will have most of its input data zeroed when doing 8x extrapolation, so the read memory bandwidth falls.   I've still yet to decide whether the sinx/x is best done on the FPGA side or on the RasPi - if it's done on the FPGA then you're piping extra samples over the CSI bus which is bandwidth constrained, although not particularly much at the faster timebases, so, it may not be an issue.  The FPGA has a really nice DSP fabric we might use for this purpose.

I don't think it will be computationally practical to do filtering or phase correction in the digital side on the actual samples.  While there are DSP blocks in the Zynq they are limited to an Fmax of around 300MHz which would require a considerably complex multiplexing system to run a filter at the full 1GSa/s. And that would only give you ~60 taps which isn't hugely useful except for a very gentle rolloff.

Not sure the trigger interpolation calculation is a single 8bit lookup when the sample point before and after the trigger could each be any value (restricted by the bandwidth of the front end, so perhaps 1/5 of the full range). Sounds like an area you need to look at much more deeply, as the entire capture needs to be phase shifted somewhere or the trigger will be jittering 1 sample forward/backward when the trigger point lands close to the trigger threshold. Exactly where and how to apply the phase shift is dependent on the scopes architecture. This may not be a significant problem if the acquisition sample rate is always >>> the bandwidth.

Similarly if you think a 60 tap filter isn't very useful recall that Lecroy ERES uses 25 taps to obtain its 2 bits of enhancement. P.S. don't restrict the thinking to DSP blocks as 18x18 multipliers, or that they are the only way to implement FIR filters. Similarly while running decimation/filtering at the full ADC rate before storing to acquisition memory makes for a nice architecture concept suited to realtime/fast update rates, its not the only way and keeping all "raw" ADC samples in acquisition memory (Lecroy style) to be plotted later has its own set of benefits and more closely matches your current memory architecture (from what you explained).

If memory is your cheap resource then some of the conventional assumptions are thrown out.

[nfmax]

- anti-aliasing filter. Looking at it I'm not sure whether a 7th order filter is a good idea due to phase shifts.
- single ended to differential amplifier and analog offset
- gain control block and ADC.

What's required  to preserve waveform fidelity is the flattest phase delay, a Bessel-Thompson filter.  I've spent a lot of time studying the subject.  It's not well treated in the literature, but well documented in scopes.  Of course, all high order analog filters are problematic to produce.  Though with an FPGA one need only get close and the FPGA can trim the last bit.

As the order goes up the Bessel-Thompson passband approaches the Gaussian passband.  So the impulse response of a 10th order Bessel-Thompson is approximately a time delayed Gaussian spike.

Tom is the reason I dropped work on hacking the Instek GDS-2000E after I blew the scope. It no longer made sense to replace it.

Have Fun!
Reg

There are a class of filters with a linear-phase (Bessel-like) passband and an equiripple stopband, originally described by Feistel & Unbehauen [1], for which Williams [2] gives some limited design tables: I have used these with success as anti-aliasing filters where waveform fidelity is important. There is a conference paper by Huard et al. [3] - which I don't have a copy of, unfortunately - that describes more recent progress in similar filter designs. Huard worked at Tektronix, which may be a clue about the applications being addressed!

[1] Feistel, Karl Heinz, and Rolf Unbehauen. Tiefpässe Mit Tschebyscheff-Charakter Der Betriebsdämpfung Im Sperrbereich Und Maximal Geebneter Laufzeit. Frequenz 19, no. 8 (January 1965). https://doi.org/10.1515/FREQ.1965.19.8.265.

[2] Williams, Arthur Bernard, and Fred J. Taylor. Electronic Filter Design Handbook. 3rd ed. New York: McGraw-Hill, 1995. ISBN 978-0-07-070441-1

[3] Huard, D.R., J. Andersen, and R.G. Hove. Linear Phase Analog Filter Design with Arbitrary Stopband Zeros. In [Proceedings] 1992 IEEE International Symposium on Circuits and Systems, 2:839–42. San Diego, CA, USA: IEEE, 1992. https://doi.org/10.1109/ISCAS.1992.230091.

[nuno]

First of all, as many others have said, very good job! Especially for a one man's band.

I totally agree with ntcnico's view on having more stuff be done on higher level processing, because the lower you go the less and less people will contribute to it. Ideally I would like to see minimal hardware and everything be done in software (I know it's not possible). It's also one way it can distinguish from the current low level entry scopes on the market.

It's totally understandable the use of the compute module, but newer versions seem to be able to break the interfaces.... so why not use the main RPI boards? It would be much more future proof as well as being more upgrade-friendly as new and more powerful RPIs come out. Just food for thought.

I always prefer to have a standalone instrument, because my computer (even phone) is always too busy,like running my development environment, browsing the web, email, etc... as it is it already has too little screen space available.

And although I'm not against touch screens and agree they may have an advantage say, handling (a lot of) menus, I also hate grease on my screens, as they interfere with readability. Touch is also bad at precision and there's no instant haptic feedback. As long as I can easily add some keys to the instrument (even if a custom USB keyboard), I'm OK with it.

I can see people designing their own cases and 3D printing them.

[Spirit532]

Have you considered implementing Andrew Zonenberg's glscopeclient for your UI?

[JohnG]

This is a fantastic bit of work, so I hope it takes off.

I can only contribute a couple requests, since this sort of work is way out of my realm. One request would be that if the front end is modular, it would be nice if it were flexible enough to accomodate some more unusual front ends, like a multi-GHz sampling scope or a VNA front end. The latter may not even make sense within the context of the project.

Again, really nice work!

John

[Zucca]

Nice feature would be to talk with the scope.

It is based again on a Raspi.

[ogden]

Still isn't adding USB-C adding on more complexity to an already complex project?

Right. Also USB-C will take time and resources off actual scope work! Those who suggest USB-C could start adapter development right now and share with author so he can copy-paste if he finds it useful.

To the *scope* wishlist I would add DDC (digital down converter) with configurable digital IF filter to implement (possibly but not necessarily) realtime spectrum analyzer. For those who wonder why plain FFT is not good enough, answer is: using just FFT you either get frequency resolution or performance, but not both. Calculating gazillion-tap FFT is slow - every user of FFT option of common scopes know. With DDC we downconvert frequency band of interest down to DC (0Hz) to use low order FFT, like 128-1024 taps. Further reading: Tektronix MDO scope info.

[rhb]

Shifting the dots is computationally simple even with sinx/x (which is not yet implemented).  It's just offsetting a read pointer and a ROT-64 with an 8-bit multiple, practically perfect FPGA territory.  In the present implementation I simply read 0..3 dummy words from the FIFO, then rotate two words to get the last byte offset.

Noting that triggers in modern scopes are aligned more finely than the sample rate (interpolation), with the reconstruction and interpolation methods also dependent on the front end characteristics. Expect the rendering speeds to collapse in a software/GPU approach once you put in that phase alignment and sinc interpolation.

As I understand it, and please DSP gurus do correct me if I am wrong, if the front-end has a fixed response to an impulse (which it should do if designed correctly), and you get a trigger at value X but intend the trigger to be at value Y, then you can calculate the real time offset based on the difference between these samples which can be looked up in a trivial 8-bit LUT (for an 8-bit ADC).   It's reasonably likely the LUT would be device-dependent for the best accuracy (as filters would vary slightly in bandwidth) but this could be part of the calibration process and the data burned into the 1-Wire EEPROM or MCU.

In any case there is a nice trade-off that happens as the timebase drops: you are processing less and less samples.  So, while you might have to do sinx/x interpolation on that data and more complex reconstructions on trigger points to reduce jitter, a sinx/x interpolator will have most of its input data zeroed when doing 8x extrapolation, so the read memory bandwidth falls.   I've still yet to decide whether the sinx/x is best done on the FPGA side or on the RasPi - if it's done on the FPGA then you're piping extra samples over the CSI bus which is bandwidth constrained, although not particularly much at the faster timebases, so, it may not be an issue.  The FPGA has a really nice DSP fabric we might use for this purpose.

I don't think it will be computationally practical to do filtering or phase correction in the digital side on the actual samples.  While there are DSP blocks in the Zynq they are limited to an Fmax of around 300MHz which would require a considerably complex multiplexing system to run a filter at the full 1GSa/s. And that would only give you ~60 taps which isn't hugely useful except for a very gentle rolloff.

Not sure the trigger interpolation calculation is a single 8bit lookup when the sample point before and after the trigger could each be any value (restricted by the bandwidth of the front end, so perhaps 1/5 of the full range). Sounds like an area you need to look at much more deeply, as the entire capture needs to be phase shifted somewhere or the trigger will be jittering 1 sample forward/backward when the trigger point lands close to the trigger threshold. Exactly where and how to apply the phase shift is dependent on the scopes architecture. This may not be a significant problem if the acquisition sample rate is always >>> the bandwidth.

Similarly if you think a 60 tap filter isn't very useful recall that Lecroy ERES uses 25 taps to obtain its 2 bits of enhancement. P.S. don't restrict the thinking to DSP blocks as 18x18 multipliers, or that they are the only way to implement FIR filters. Similarly while running decimation/filtering at the full ADC rate before storing to acquisition memory makes for a nice architecture concept suited to realtime/fast update rates, its not the only way and keeping all "raw" ADC samples in acquisition memory (Lecroy style) to be plotted later has its own set of benefits and more closely matches your current memory architecture (from what you explained).

If memory is your cheap resource then some of the conventional assumptions are thrown out.

Interpolation for sample alignment and display infill are fundamentally different even if the operation is identical.

High order analog filters have serious problems with tolerance spreads.  So sensibly, the interpolation to align the samples and the correction operator should be combined using data measured in production.

The alignment interpolation operators are precomputed, so the lookup is into a table of 8 point operators.  Work required is 8 multiply-adds per output sample which is tractable with an FPGA.  Concern about running out of fabric led to a unilateral decision by me to include a 7020 version as the footprints are the same but lots more resources.  I  am still nervous about the 7014 not having sufficient DSP blocks.

Interpolation for display can be done in the GPU where  the screen update rate limitation provides lots of time and the output series are short.  So an FFT interpolator for the display becomes practical.

As for all the other features such as spectrum and vector analysis we have discussed that at great length. 
The To Do list is daunting.

Reg

[tom66]

If anyone hasn't figured it yet, rhb (Reg) is the American contributor to this project - he's been a good advisor/counsel through this whole project

[dave j]

I don't know how familiar you are with GPU programming but if you're considering using the GPU for rendering it's worth noting that the various Pi GPUs are tile based - which can have significant performance implications depending upon what you are doing.

There's a good chapter on performance turning for tile based GPUs in the OpenGL Insights book that the authors have helpfully put online.

[tom66]

We did have an early prototype using the Pi's GPU but the problem was the performance even at 2048 points was worse than a software renderer.  We (me and a friend who is GL-experienced) looked into using custom software on the VPU/QPU but the complexity of writing for an architecture with limited examples put us off.  There is some documentation from Broadcom but the tools are poorly documented (and most are reverse engineered.)

One approach we considered was re-arranging the data in buffers to more closely represent the tiling arrangement of the GPU - this would be 'cheap' to do on the FPGA using a BRAM lookup.

Thanks for the link though, that is an interesting (and perhaps useful) resource.

[nctnico]

Perhaps an alternative could be a Jetson Nano module. Using the SO-DIMM format and costing $129 in single quantities it could be a good alternative with a GPU which is also useful for raw number crunching.

[tom66]

Interesting idea - but it would throw out the window any option for battery operation if that heatsink size is any indication of the power dissipation.

Whether that would be a killer for people I don't know?  I think it's a nice to have especially if the device itself is otherwise portable.

[nuno]

I wouldn't put portability as a priority - most scopes we use are not battery-operated-ready from factory.

[nctnico]

Interesting idea - but it would throw out the window any option for battery operation if that heatsink size is any indication of the power dissipation.

Whether that would be a killer for people I don't know?  I think it's a nice to have especially if the device itself is otherwise portable.

Well, it would simply need a bigger battery. Laptops aren't low power either. To me portability is lowest on the list though. Personally I'd prefer a large screen.

With ultra-low power you'll also be throwing out the possibility of creating a scope with >500MHz bandwidth for example. The ADC on your prototype has a full power bandwidth of 700MHz. Use two in tandem and you can get to 2Gs/s in a single channel in order to meet Nyquist. However supporting 500MHz will probably require several chips which will get warm.

The Jetson Nano seems to need about 10W of power while running at full capacity. There is also a (I think) pin compatible Jetson Xavier NX module with vastly better specs but this also needs more power. The use of these modules would create a lot of flexibility to trade performance for money.

[tom66]

It's certainly an option, but the current Zynq solution is scalable to about 2.5GSa/s for a single channel operation (625MSa/s on 4ch).  Maximum bandwidth around 300MHz per channel.

If you want 500MHz 4ch scope, the ADC requirements would be ~2.5GSa/s per channel pair (drop to 1.25GSa/s with a channel pair activated) which implies about 5GB/s data rate into RAM.  The 64-bit AXI Slave HPn bus in the Zynq clocked at 200MHz maxes out around 1.6GB/s and four channels gets you up to 6.4GB/s but that would completely saturate the AXI buses leaving no free slots for RAM accesses for readback from the RAM or for executing code/data.

The fastest RAM configuration supported would be a dual channel DDR3 configuration at 800MHz requiring the fastest speed grade, which would get the total memory bandwidth to just under 6GB/s.

Bottom line is the platform caps out around 2.5GSa/s in total with the present Zynq 7000 architecture,   and would need to move towards an UltraScale or a dedicated FPGA capture engine for faster capture rate.

So I suppose the question is -- if you were to buy an open-source oscilloscope -- what would you prefer

1. US$1200 instrument with 2.5GSa/s per channel pair (4 channels, min. 1.25GSa/s), ~500MHz bandwidth, Nvidia core, >100kwfm/s, mains only power
2. US$600 instrument with 1GSa/s multiplexed over 4 channels, ~125MHz bandwidth, RasPi core, >25kwfm/s, portable/battery powered
3. Neither/something else

[tautech]

So I suppose the question is -- if you were to buy an open-source oscilloscope -- what would you prefer

1. US$1200 instrument with 2.5GSa/s per channel pair (4 channels, min. 1.25GSa/s), ~500MHz bandwidth, Nvidia core, >100kwfm/s, mains only power
2. US$600 instrument with 1GSa/s multiplexed over 4 channels, ~125MHz bandwidth, RasPi core, >25kwfm/s, portable/battery powered
3. Neither/something else

FYI Very close to the specs of a hacked SDS2104X Plus for $1400

[tom66]

I suspect an instrument like this can't ever compete with a mainstream OEM on bang-per-buck - it has to compete on the uniqueness of being a FOSS product.

That is, you can customise it, you have modularity, you have upgrade routes and flexibility.  But it will always be more expensive in low volumes to produce something like this, that's just an ultimate fact of life.

[tautech]

I suspect an instrument like this can't ever compete with a mainstream OEM on bang-per-buck - it has to compete on the uniqueness of being a FOSS product.

That is, you can customise it, you have modularity, you have upgrade routes and flexibility.  But it will always be more expensive in low volumes to produce something like this, that's just an ultimate fact of life.

Or find a performance/features niche that's not currently being catered for.