Author Topic: A High-Performance Open Source Oscilloscope: development log & future ideas  (Read 8910 times)

2N3055 and 2 Guests are viewing this topic.

Offline snoopy

  • Frequent Contributor
  • **
  • Posts: 741
  • Country: au
    • Analog Precision
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #150 on: November 21, 2020, 11:04:07 pm »
The trade off with ETS is that your waveform rate has to fall because you need to hop the PLL frequency often.

The ADF4351 I'm using takes about 80us to lock in "Fast Lock Mode" which is intended for fast channel changes, not including the time required to write the registers on the device over SPI.  In the most optimistic case, that sets your acquisition rate at 12,500 wfm/s.   Faster devices do exist but they would still end up being the ultimate limit in the system. 

ETS is making up for poor sinx/x interpolation,  you can do everything ETS does, and arguably more accurately, with a good interpolator.  (Assuming your input is correctly bandlimited for the normal ADC sampling rate.)

Working on the Python sampling model now.

Yes ETS requires many bites of the cherry to reconstruct the waveform so therefore waveform update rate suffers and the incoming waveform needs to be stable during this time. However am I right in saying that with ETS you don't get any phase shift from an interpolation filter which is never perfect ?
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 20149
  • Country: nl
    • NCT Developments
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #151 on: November 21, 2020, 11:30:03 pm »
ETS is making up for poor sinx/x interpolation,  you can do everything ETS does, and arguably more accurately, with a good interpolator.  (Assuming your input is correctly bandlimited for the normal ADC sampling rate.)
Actually the whole point of ETS is to go (far) beyond the Nyquist limit of the ADC. One could even envision adding a sampling head which together with the 14bit version of the ADC could result in a very unique device. But implementing ETS and sampling in itself isn't that interesting. The real challenge is to be able to trigger accurately on a signal which has a very high frequency (several GHz). Several of the older high frequency DSOs (Tektronix TDS820 and Agilent 54845a for example) can't trigger on high frequency signals.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4166
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #152 on: November 22, 2020, 08:52:55 am »
That's true, at that point you'd essentially be implementing something similar to a sampling scope, to achieve ~500MHz repetitive bandwidth.

I think it's a different project, but there's no practical reason an ETS-capable variant (perhaps a software change, with hardware lacking B/W filters) could be developed.

Not the focus for the first version but one of the goals for this project is upgradeability and customisability. 
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4166
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #153 on: November 23, 2020, 09:07:32 pm »
I modelled the triggering prototype using a Python script and Numpy/matplotlib.  See attached for the script, for anyone interested. 

Overall quite impressed - triggering jitter was relatively low but I need to tweak the search range and coefficients somewhat to get performance to be similar across all trigger levels.  I think I should move towards a sinc interpolator for the trigger predictor, but this simple linear predictor (using the error at the trigger point and the local slope based on 4 samples) gets to ~360ps jitter for a 1ns sample period with 1.5LSB ADC noise simulated.

The biggest problem seems to be that my predictor is much less accurate at certain trigger levels - it seems to be some kind of quantisation effect.  I will have to continue tweaking to see if I can improve this.

This implementation could be performed with less than 16 bytes memory per trigger point (5 samples + 1 timestamp) and so should be practical for long post-trigger delays where samples are normally outside of acquisition memory.  The slope approximation should be possible to do with an 8-bit LUT.
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 3374
  • Country: cn
  • Born with DLL21 in hand
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #154 on: November 24, 2020, 06:03:51 am »
Think  if you are scope manufacturer and you need write datasheet.

Imho, this jitter what you show do not look good at all. Without further knowledge and analyze  but 300ps or 600ps numbers give just first feel: horrible.

Here some pick-ups from some scopes data sheets, note also sampling interval and adjust these for 1ns interval sampling.

These are just random examples. Some are good, some are "acceptable".
All these are 8bit ADC scopes.  Least these numbers, without further thinking, looks bit different and better or more nice.

Some  1Gsa/s 0.5k$ scope
Trigger Jitter: < 100 ps 


Some 1k$ 2Ch and 1.5k$ 4Ch,  2Gsa/s scope
Trigger Jitter: CH1 - CH4: <10 ps rms, 6 divisions pk-pk, 2 ns edge
(EXT trig: <200 ps rms ) My note: This EXT trig is simplest old traditional analog pathway / comparator trigger.


Some 5Gsa/s scope 
Trigger Jitter: <9ps RMS (typical) for ≥300MHz sine and ≥6 divisions peak to peak amplitude for vertical gain settings from 2.5mV/div to 10V/div.
Trigger Jitter: <5ps RMS (typical) for ≥500MHz sine and ≥6 divisions peak to peak amplitude for vertical gain settings from 2.5mV/div to 10V/div.

Some expensive 5 Gsa/s scope
Trigger jitter: full-scale sine wave of frequency set to –3 dB bandwidth < 1 ps (RMS) (meas.)

Some expensive 10Gsa/s scope
Trigger and Interpolator Jitter: ≤ 3.5 ps RMS (typical)


Low trigger jitter is one extremely important in scopes. How can measure example signal time jitter if scope own trigger jitter is horrible.
Good scopes may also have measurement functions what can measure and display jitter distribution over more or less long time. It is waste of time if scope own jitter is bad.

As I told my opinion in my previous message, whole trigger engine is one of most important part of good scope. All can draw nice looking images to screen but all can not do High Performance trigger engine.

Here topic name include  "High performance".  Why.

Now you tell "Overall quite impressed - triggering jitter was relatively low..." and show this some kind of simulation about trigger jitter with horrible looking numbers.

When you go forward with this trigger engine and things relative it...  you can do some training with this: imagine you are manufacturer and you need reach Trigger engine performance you can write Trigger jitter least <20ps  rms   to data sheet.
 
What ever nice things and nice looking waveform draw scope have and even high performance this and that but if it do not have High Performance trigger engine it is just more or less nice looking thing for decorate lab. And same for analog front end quality and sampling quality. All know... garbage in - garbage out... 


Still it looks nice project... but there read "High performance"... so try keep it. Least related to trigger, what is perhaps most difficult parts of oscilloscope, when try "High performance" < "High End" < "State of art" class where need be more or much more better than normal.
If practice and theory is not equal it tells that used application of theory is wrong or the theory itself is wrong.
-
Harmony OS
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4166
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #155 on: November 24, 2020, 08:23:47 am »
The trigger prototype here is intending to demonstrate the concept of a trigger based on data around the digital trigger - and it is not necessarily the final implementation.  In the best cases the trigger jitter is <20psrms but there is presently an unresolved dependency on the trigger level.

You are not wrong that 300ps would not be ideal for a 'real scope'. The initial goal of the prototype is to replicate the performance of a 1GSa/s oscilloscope,  at a ~$500 price point, so 100ps or less is a fair goal, and "High Performance" in this regard refers to the *state-of-the-art* for existing open-source oscilloscope projects, many of which are based around PC oscilloscope platforms or sample at 10 MSA/s, not 1GSa/s. 

If I am to aim for something around the 2.5GSa/s oscilloscope benchmark, then I need to make the jitter better, of course.

31ps is the level at which the jitter becomes indistinguishable on the display surface, assuming a 1080p display so there is little point (at a minimum timebase of 5ns/div) in achieving anything better, for a 1GSa/s oscilloscope.  If a 2.5GSa/s oscilloscope has a 2ns/div or 1ns/div setting, then the requirements drop to around 5-10ps.
« Last Edit: November 24, 2020, 08:27:30 am by tom66 »
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 20149
  • Country: nl
    • NCT Developments
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #156 on: November 24, 2020, 08:51:09 am »
The trigger prototype here is intending to demonstrate the concept of a trigger based on data around the digital trigger - and it is not necessarily the final implementation.  In the best cases the trigger jitter is <20psrms but there is presently an unresolved dependency on the trigger level.

You are not wrong that 300ps would not be ideal for a 'real scope'. The initial goal of the prototype is to replicate the performance of a 1GSa/s oscilloscope,  at a ~$500 price point, so 100ps or less is a fair goal, and "High Performance" in this regard refers to the *state-of-the-art* for existing open-source oscilloscope projects, many of which are based around PC oscilloscope platforms or sample at 10 MSA/s, not 1GSa/s. 
I agree. AFAIK the R&S RM3000 doesn't even specify trigger jitter and from judging how fat a trace gets around the trigger point it isn't very good. But then again this oscilloscope isn't made for jitter analysis.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: tom66

Online asmi

  • Super Contributor
  • ***
  • Posts: 1433
  • Country: ca
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #157 on: November 24, 2020, 07:07:03 pm »
"High Performance" in this regard refers to the *state-of-the-art* for existing open-source oscilloscope projects, many of which are based around PC oscilloscope platforms or sample at 10 MSA/s, not 1GSa/s. 
Oh, so that explains some things. I also had a question in my mind of what exactly is "high performance" about 1 GSa scope. Initially I thought that it was ETS with very high analog bandwidth, but now it appears that it simply means "less of a crap compared to what's already out there in the open source sphere".

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4166
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #158 on: November 24, 2020, 08:36:04 pm »
Perhaps you should read the opening post?    :-//
 

Offline rhb

  • Super Contributor
  • ***
  • Posts: 3084
  • Country: us
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #159 on: November 25, 2020, 12:26:11 am »
"High Performance" in this regard refers to the *state-of-the-art* for existing open-source oscilloscope projects, many of which are based around PC oscilloscope platforms or sample at 10 MSA/s, not 1GSa/s. 
Oh, so that explains some things. I also had a question in my mind of what exactly is "high performance" about 1 GSa scope. Initially I thought that it was ETS with very high analog bandwidth, but now it appears that it simply means "less of a crap compared to what's already out there in the open source sphere".

This started as an open source version of a product that Micsig now has on the market at a price point a bit higher than Tom's initial goal.  We certainly won't try to undercut the Chinese.   My aborted "Scope Wars" thread was an attempt at documenting the results of my market research of what we viewed as competitive product:  Rigol, Instek, Siglent.  At the time Micsig was not on the radar.

Once I got involved it morphed into a "beat the crap out of HPAK, Tek & R&S" project for me. And I *think* I have almost sold Tom on that.

The current goal is under active discussion.  A lot has changed in the last 18 months.

The canonical response to "I want "high performance" is, "How much money would you spend?"

Have Fun!
Reg
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7570
  • Country: us
    • SiliconValleyGarage
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #160 on: November 25, 2020, 12:55:22 am »
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.
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.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4166
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #161 on: November 25, 2020, 09:01:53 am »
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.)
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4166
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #162 on: November 28, 2020, 10:20:34 pm »
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.
 
The following users thanked this post: egonotto, DEV001

Online nctnico

  • Super Contributor
  • ***
  • Posts: 20149
  • Country: nl
    • NCT Developments
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #163 on: November 28, 2020, 10:26:16 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4166
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #164 on: November 29, 2020, 06:49:24 pm »
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. 
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4166
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #165 on: November 29, 2020, 06:50:17 pm »
Questionnaire for those interested in the project.  

I'd appreciate any responses to understand what features are a priority and what I should focus on.

https://docs.google.com/forms/d/e/1FAIpQLSdm2SbFhX6OJlB834qb0O49cqowHnKiu7BEsXmT3peX4otOIw/formResponse

All responses will be anonymised and a summary of the results will be posted here (when sufficient data exists.)
 

Online Marco

  • Super Contributor
  • ***
  • Posts: 4934
  • Country: nl
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #166 on: November 29, 2020, 07:09:02 pm »
HMCAD1520

Analog really doesn't seem too interested in selling these. Those lead times ...

In an ADC market filled with boutique rip off prices these always stood out a bit too much.
 

Offline rhb

  • Super Contributor
  • ***
  • Posts: 3084
  • Country: us
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #167 on: November 29, 2020, 09:52:54 pm »
HMCAD1520

Analog really doesn't seem too interested in selling these. Those lead times ...

In an ADC market filled with boutique rip off prices these always stood out a bit too much.

Other customers?  Perhaps?
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4166
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #168 on: November 30, 2020, 08:09:37 am »
Analog really doesn't seem too interested in selling these. Those lead times ...

In an ADC market filled with boutique rip off prices these always stood out a bit too much.

Yes, it is an odd part, but I've heard from a few people familiar with the market for ADCs and if you know who you are talking to, you can get inexpensive Chinese parts with surprisingly decent performance that easily beat Western equivalent parts in terms of performance per buck.  A great deal of that has been driven by the budget oscilloscope and test equipment market, as well as cheaper RF SDR and amateur radio kit.  Digi-Key and the likes only tend to capture mainstream parts that are worth stocking.

Fundamentally there's not much that's too specialised about ADC design now - these designs are decades old and we have audio cards with 24-bit ADCs running at 192kHz ... this is sort of like the opposite end of the performance spectrum - it's a process problem, not a design problem.

The HMCAD1520 is available on Digi-Key, they have decent stock (~299 parts) and a 14 week lead time for more, which seems OK to me.     I had no issue buying the HMCAD1511 when building the first prototypes, though I only bought two.

I'd imagine ADI only keep these parts and don't develop additional variants because they have existing customers that are happy with them from when they bought Hittite (the part actually comes from Arctic Silicon's "Blizzard" family of ADCs.  They are/were a Norwegian firm that Hittite acquired before ADI acquired them.)  But, it would be nice to see more lower cost parts.

My plan is to figure out a multiplexing arrangement where two ADC chips could be used to sample at 2.5GSa/s.  I have already managed to get a HMCAD1511 stable at >1.2GSa/s.  That would enable a realistic 2.5GSa/s oscilloscope (400ps sample period) with say 350MHz per channel B/W in 1 channel mode.  I also suspect that the '1520 features might only be lasered out (or they may not be disabled at all!) on the '1511,  as the two ADCs seem to use very similar cores/structures - though I am yet to confirm this. 
« Last Edit: November 30, 2020, 08:11:33 am by tom66 »
 

Online gf

  • Regular Contributor
  • *
  • Posts: 235
  • Country: de
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #169 on: November 30, 2020, 07:06:38 pm »
From HMCAD1520 datasheet:
Quote
High speed Modes (12-bit / 8-bit)
Quad Channel Mode: Fsmax = 160 / 250 MsPs
Dual Channel Mode:  Fsmax  = 320 / 500 MsPs
Single Channel Mode: Fsmax = 640 / 1000 MsPs

I'm wondering whats up with the 640 MSPS?
The AC specifications of the HMCAD1520 are only given up to 640 MSPS, but not for 1000.
And Max. Conversion Rate is specifed as 640 as well (1 ch).
When do the 1000 apply? Do they only apply in HMCAD1511 compatibility mode (8-bit)?
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4166
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #170 on: November 30, 2020, 07:12:11 pm »
I'm wondering whats up with the 640 MSPS?
The AC specifications of the HMCAD1520 are only given up to 640 MSPS, but not for 1000.
And Max. Conversion Rate is specifed as 640 as well (1 ch).
When do the 1000 apply? Do they only apply in HMCAD1511 compatibility mode (8-bit)?

Yes, it's 1GSa/s in 8-bit mode, 640MSa/s in 12-bit and 160MSa/s in 14-bit mode.
IMO 14-bit mode is a bit useless but probably a consequence of the internal 14-bit core (which HMCAD1511 shares)
 

Online gf

  • Regular Contributor
  • *
  • Posts: 235
  • Country: de
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #171 on: November 30, 2020, 09:26:06 pm »
I guess you mean 105 MSa/s in precision mode, do you? (160 is obviously for 12-bit high speed @4ch)

I don't think that precicion mode is really useless.
The main point of precision mode are IMO not the 14 bits, but the following:

Quote
the high speed modes all utilize interleaving to achieve high sampling speed. Quad channel mode interleaves 2 ADC branches, dual channel mode interleaves 4 ADC branches, while  single  channel  mode  interleave all 8 ADC branches. In precision mode interleaving is not required and each ADC channel uses one ADC branch only.

This eliminates interleaving spurs, leading to a significantly better SFDR and SINAD.

The cost is a maximum sampling rate of 105 MSa/s - but with all 4 channels enabled.
So with 4 channels enabled, the precision mode sampling rate is only by a factor ~1.5 lower than the 160 MSa/s for 12-bit 2-fold interleaved high speed mode. I find this trade-off not too bad.
« Last Edit: November 30, 2020, 09:29:23 pm by gf »
 
The following users thanked this post: tom66

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4166
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #172 on: November 30, 2020, 09:36:02 pm »
I guess you mean 105 MSa/s in precision mode, do you? (160 is obviously for 12-bit high speed @4ch)

That's what I get for not double checking the datasheet and quoting from memory.

Quote
the high speed modes all utilize interleaving to achieve high sampling speed. Quad channel mode interleaves 2 ADC branches, dual channel mode interleaves 4 ADC branches, while  single  channel  mode  interleave all 8 ADC branches. In precision mode interleaving is not required and each ADC channel uses one ADC branch only.

This eliminates interleaving spurs, leading to a significantly better SFDR and SINAD.

The cost is a maximum sampling rate of 105 MSa/s - but with all 4 channels enabled.
So with 4 channels enabled, the precision mode sampling rate is only by a factor ~1.5 lower than the 160 MSa/s for 12-bit 2-fold interleaved high speed mode. I find this trade-off not too bad.

OK, that's actually a really good point and one I didn't consider. Thanks! 
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf