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

0 Members and 1 Guest are viewing this topic.

Offline Zucca

  • Supporter
  • ****
  • Posts: 3482
  • Country: it
  • EE meid in Itali
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #125 on: November 20, 2020, 09:34:03 am »
You guys are too smart for me, it's hard to follow.

Anyway some inputs from my side

1) Avoid anything which has Broadcom or Qualcomm chips = sporadic pain in the ass guaranteed.
2) As much RAM as possible
3) SATA port for proper SSD?

Great work!
Can't know what you don't love. St. Augustine
Can't love what you don't know. Zucca
 
The following users thanked this post: egonotto

Online nctnico

  • Super Contributor
  • ***
  • Posts: 21544
  • Country: nl
    • NCT Developments
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #126 on: November 20, 2020, 10:03:30 am »
You keep talking about offset in counts, but trigger interpolation is in time. There isn't a lookup because the slope of the signal isn't known a-priori, interpolating the trigger point on the time axis needs at least 2 points (more is preferable) which is already an impractical size for a LUT. Yes it can be done offline (as mentioned by Fungus above), but it still needs access to the raw ADC samples that created the trigger, which are not always what is stored in the acquisition buffer.

Yes, and every raw sample is piped into RAM and stored; nothing about the trigger data is thrown away.  1GSa/s sampling rate and 1GSa/s memory write rate.  The samples that generate the trigger are stored as well as pre- and post- trigger data.  No filtering, no downsampling at this point.

The principle is, if the input filter has the correct response (it needs to roll off before Nyquist so that you avoid the described Nyquist headaches) you can calculate slope from the delta from the presumed trigger point (which is at t=0 - centre of the waveform) and the actual trigger point at t=? ... the actual trigger point will be offset from the point that the oscilloscope triggered at by a fraction of the sample rate (0-1ns).  It will never be more than that fraction because then the next comparator would have generated the trigger instead.    When you are at the described mode where 1ns < 1pixel,  you can ignore this data because the waveform points aren't going to be plotted fractionally on the screen.  This is only needed for sinx/x modes.   You'd need LUTs for different timebases or channel configurations (1-4ch), but this is something that could be generated at 'production time' as part of the calibration process.
I'm afraid this approach is too simplistic. The trigger comparator needs to have threshold levels to filter out noise which also means you need to use multiple points (at least 4 but more is better) to determine the actual trigger point (=where the signal crossed the trigger point). A problem on many digital trigger oscilloscopes (Siglent is a good example) is that the trigger point becomes a focal point in the centre and smears out the edges of a signal.

I think in the end it may turn out that doing the comparator part digitally and the positioning in software (based on seperately stored samples around the trigger point) is necessary.
« Last Edit: November 20, 2020, 10:14:05 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Someone

  • Super Contributor
  • ***
  • Posts: 2737
  • Country: au
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #127 on: November 20, 2020, 10:09:27 am »
The principle is, if the input filter has the correct response (it needs to roll off before Nyquist so that you avoid the described Nyquist headaches) you can calculate slope from the delta from the presumed trigger point (which is at t=0 - centre of the waveform) and the actual trigger point at t=? ... the actual trigger point will be offset from the point that the oscilloscope triggered at by a fraction of the sample rate (0-1ns).
This is getting silly, you still can't provide a mathematical example of your proposed method. How can the slope be known a-priori? With an ideal AFE filter, any frequency (slope) less than the cutoff could be occurring around the trigger point.

Even with the trivial example of a perfect sine wave of constant frequency being sampled perfectly (and below Nyquist) shifting it with DC while keeping the trigger threshold static would present different slopes at the trigger point. Just the phasing of the points when the frequency isn't rational with the sampling frequency causes significant shifts and jitter as the waveform approaches the Nyquist rate.
 
The following users thanked this post: rf-loop, 2N3055

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4392
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #128 on: November 20, 2020, 12:11:15 pm »
I think there's a misunderstanding here as to how this would work,  there's no need to do any 'a-priori' calculation as *everything is done* after we have the *whole waveform captured and stored in RAM*.  We trigger 'roughly' and then correct the trigger point using the data we have around the trigger point.  That latter stage is software, performed well after the samples are gathered, just before any interpolation or rendering/plotting is performed.   I believe it could be done using one or at most two data points to calculate the slope of the signal at that point.  Let me go away and model it and see how wrong I am ... I've only done the calculations on paper so far so I'm prepared to admit I could be wrong here.

The present application does, in fact, support noise filters on the trigger, but the high and low thresholds are calculated beforehand as centred around the ideal trigger point.  Hysteresis can be set to any value within reason (1..max_sample).   So on a rising edge we trigger on the high trigger level,  and only when the signal goes below the low trigger level do we generate a falling edge.  Therefore, we can work out the level based on the type of edge that we intended to trigger on;  again, we don't need to store anything other than the waveform data (and the trigger edge that we used, in case we have a trigger engine that alternates edge types.)   

There isn't currently any bandwidth filtering on the trigger samples (i.e. LF/HF/AC);  I'm not certain of the best way to implement that yet.  They may have an effect on the jitter of the scope trigger, but the bandwidth of those filters tends to be quite low (~50kHz or so) which means trigger jitter of 1ns (uncorrected) should be insignificant in those cases.  I would like to see a scope that had adjustable filtering for the trigger signal (set the -3dB point for the trigger), I've been discussing this with Reg for some time and we have a few ideas on how to go about it even on realtime data.

Don't let perfect be the enemy of good.   If this gets realistic trigger jitter ~100ps or less for a 1ns ADC clock, then I'm prepared to accept it as a perfectly sufficient way to correct when interpolation is performed; the jitter would then be less than 1 pixel visible to the user.

The waveforms I have captured so far show a "visibly" jitter free capture down to 50ns/div without any trigger jitter correction thus far, on a variety of complex waveforms as well as simple sine waves.    ~100ps or less jitter would require the jitter correction to work down to roughly 10x interpolation (5ns/div).  And, the good news is, this is scalable with the sampling rate.  If the ADC is faster, then you can still do up to 10x interpolation without too many headaches.  I'm not too convinced that there is a great deal of benefit in going beyond 10x interpolation (at which point your scope is *really* lying to you about the signal, rather than just misleading you), but if so, there may need to be more thought as the ADC noise could start influencing the trigger slope detection,  which may require an adjusted algorithm.
« Last Edit: November 20, 2020, 12:13:50 pm by tom66 »
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 21544
  • Country: nl
    • NCT Developments
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #129 on: November 20, 2020, 01:42:24 pm »
A few things to look out for:
- the trigger point may be outside the acquisition data so you can't use the acquired data to calculate the trigger point
- it should be possible to trigger on very slow edges as well. Think tens of micro-Volts per second

There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: egonotto

Offline tautech

  • Super Contributor
  • ***
  • Posts: 22218
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #130 on: November 20, 2020, 01:49:35 pm »
I would say that once you are operating at an input frequency >> than the rating of the scope, you can't rely on the trigger being reliable, just as you can't rely on the amplitude being reliable.  My DS1000Z falls over on Fin > 130MHz, even though the amplitude is stable.
:o
2-3* rated BW for stable triggering is not an unrealistic expectation IME.

I'd certainly be setting my sights higher with a new design.
Avid Rabid Hobbyist
 

Offline tmbinc

  • Regular Contributor
  • *
  • Posts: 239
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #131 on: November 20, 2020, 02:47:22 pm »
tom66, thank you, this is super impressive work!

A few years ago I've worked a bit on the Siglent SDS1x0xX-E (https://github.com/360nosc0pe/fpga) reverse-engineer/hack. We've got it to a level where we can control the frontends (coupling, attenuation, BW), capture the ADC data, and push that to memory on the PL. On the PS, we had Linux and some test code to pull data out of RAM and display it; eventually the goal was to render into accumulation buffers in blockram (which is what Siglent does, hence the crappy resolution to make it fit), but didn't get that far - we never got further than basically driving the hardware correctly, but that part worked well.

Without going too much into the topic of creating new hardware vs. hacking existing hardware, I think the design shares a lot of the same choices so for an open source oscilloscope, I would be very interested in cooperating and/or potentially porting your code to this platform.

Also, nice work on the CSI-2 interface! How does your CSI-2 Phy look on the FPGA side? Do you need to implement LP support or only high-speed? This is a very elegant, cheap and fast solution to capture lot of data into a RPI. (I've so far always used an FT2232H in FIFO mode, but it adds significant cost and especially on a RPi3, the USB alone eats a full CPU core due to the bad USB controller design.) I assume receiving data on CSI-2 doesn't take up a lot of CPU resources on the RPi if you can DMA large blocks.
 
The following users thanked this post: tom66

Online tv84

  • Super Contributor
  • ***
  • Posts: 2377
  • Country: pt
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #132 on: November 20, 2020, 03:08:39 pm »
Getting interesting...  :popcorn:
 

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 3922
  • Country: hr
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #133 on: November 20, 2020, 04:15:50 pm »
With 100MHz and 1GHz sampling, it is customary to have 5ns/div and no visible triggering jitter. Picoscope with those specs has 3 ps RMS trigger jitter specified.. That should be target.
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4392
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #134 on: November 20, 2020, 05:39:46 pm »
- the trigger point may be outside the acquisition data so you can't use the acquired data to calculate the trigger point

The trigger point will always be within acquisition data.  That is a limitation of this approach if you want to correct the trigger point using data available.  You'll notice that on a Rigol DS1000Z the pre-trigger is limited to roughly the waveform length (so the trigger point is at the far right hand side of the display.)  Now, that seems to be a self-imposed limit (they might be using BlockRAM for the pre-trigger or have some software limitation) and no such limit will exist in this design, but there is still the requirement to have the trigger within the data set, as that is the transition point from pre- to post-trigger state.  Post-trigger could be set to only a couple of samples - the current engine supports a minimum of 2 words or 16 samples for either the pre- or post-trigger buffers.   But, you will have to have some data around the trigger point to be able to correct it.

Even the Agilent DSOX2012A I have has a limit of -250us pre-delay in 1GSa/s sampling mode (2ch active) ... coincidentally (or not) exactly 500kpt of data?  The limit only changes when the timebase requires the ADC sample rate to drop.  The pre-trigger window stops exactly at the moment of the trigger plus a few samples.

In all cases you should have data from around the trigger ... I can't think of a DSO that does not have such a limitation.     I suppose it would be plausible to record 16 words of data either side the trigger if it so happens that the trigger is outside of the acquisition window,  but I'm not sure if this additional complexity would be worth it for a fairly unusual use case.  I will consider it, though.

- it should be possible to trigger on very slow edges as well. Think tens of micro-Volts per second

That shouldn't be an issue.  This trigger correction only starts to have an effect when the rise time is <50ns or so.  Outside of that window the naive assumption that first triggered word = trigger point is more than adequate.  The current hardware supports DC to >100MHz triggering, although the AC coupled front end obviously limits the lower end.

2-3* rated BW for stable triggering is not an unrealistic expectation IME.

I'd certainly be setting my sights higher with a new design.

Remember, this prototype runs at 1GSa/s with a rated 100MHz bandwidth.  In multiplexed mode, it has a Nyquist bandwidth of just 125MHz (4 channels enabled).  That's essentially the same as a Rigol DS1104Z or Siglent SDS1104X-E.  If the ADC is faster and you have more data, then the trigger could reliably go beyond the rated B/W of the scope,  but the B/W of a scope is an upper bound.  Most signals will have a fundamental far below the rated bandwidth.  You wouldn't look at a 50MHz square wave on a 100MHz oscilloscope and expect perfect reconstruction.  Looking at a 300MHz sine wave on a 100MHz scope and complaining that the trigger is a bit jittery would be silly, in my opinion.

I'd be curious how the competition performs here.  I may get my Zynq board to output a 200MHz clock to see how well my Rigol can trigger on it with a rated B/W limit of 100MHz.
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4392
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #135 on: November 20, 2020, 05:40:51 pm »
With 100MHz and 1GHz sampling, it is customary to have 5ns/div and no visible triggering jitter. Picoscope with those specs has 3 ps RMS trigger jitter specified.. That should be target.

5ns/div implies (assuming a 1920-wide canvas and 12 divisions, is that fair?) about 31ps per 'virtual' sample.  How could you determine if the trigger jitter was any better than 31ps in that case?  AFAIK Picoscope doesn't plot sub-pixels (same as most scopes.)
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 21544
  • Country: nl
    • NCT Developments
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #136 on: November 20, 2020, 05:54:55 pm »
- the trigger point may be outside the acquisition data so you can't use the acquired data to calculate the trigger point

The trigger point will always be within acquisition data.  That is a limitation of this approach if you want to correct the trigger point using data available.  You'll notice that on a Rigol DS1000Z the pre-trigger is limited to roughly the waveform length (so the trigger point is at the far right hand side of the display.)  Now, that seems to be a self-imposed limit (they might be using BlockRAM for the pre-trigger or have some software limitation) and no such limit will exist in this design, but there is still the requirement to have the trigger within the data set, as that is the transition point from pre- to post-trigger state.  Post-trigger could be set to only a couple of samples - the current engine supports a minimum of 2 words or 16 samples for either the pre- or post-trigger buffers.   But, you will have to have some data around the trigger point to be able to correct it.

Even the Agilent DSOX2012A I have has a limit of -250us pre-delay in 1GSa/s sampling mode (2ch active) ... coincidentally (or not) exactly 500kpt of data?  The limit only changes when the timebase requires the ADC sample rate to drop.  The pre-trigger window stops exactly at the moment of the trigger plus a few samples.

In all cases you should have data from around the trigger ... I can't think of a DSO that does not have such a limitation.
Well, I can not think of a DSO which limits the pre-trigger range to the length of the acquisition record  ;) For example: My GW Instek allows me to set the pre-trigger point far outside the acquisition record. It is pretty much a requirement for being able to do jitter measurements so I'm rather surprised there are DSOs out there which have limited pre-trigger abilities.
« Last Edit: November 20, 2020, 06:00:26 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4392
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #137 on: November 20, 2020, 06:06:54 pm »
- the trigger point may be outside the acquisition data so you can't use the acquired data to calculate the trigger point

The trigger point will always be within acquisition data.  That is a limitation of this approach if you want to correct the trigger point using data available.  You'll notice that on a Rigol DS1000Z the pre-trigger is limited to roughly the waveform length (so the trigger point is at the far right hand side of the display.)  Now, that seems to be a self-imposed limit (they might be using BlockRAM for the pre-trigger or have some software limitation) and no such limit will exist in this design, but there is still the requirement to have the trigger within the data set, as that is the transition point from pre- to post-trigger state.  Post-trigger could be set to only a couple of samples - the current engine supports a minimum of 2 words or 16 samples for either the pre- or post-trigger buffers.   But, you will have to have some data around the trigger point to be able to correct it.

Even the Agilent DSOX2012A I have has a limit of -250us pre-delay in 1GSa/s sampling mode (2ch active) ... coincidentally (or not) exactly 500kpt of data?  The limit only changes when the timebase requires the ADC sample rate to drop.  The pre-trigger window stops exactly at the moment of the trigger plus a few samples.

In all cases you should have data from around the trigger ... I can't think of a DSO that does not have such a limitation.
Well, I can not think of a DSO which limits the pre-trigger range to the length of the acquisition record. My GW Instek allows me to set the pre-trigger point far outside the acquisition record. It is pretty much a requirement for being able to do jitter measurements.

Both the Rigol DS1074Z and the Agilent DSOX2012A I have do this.

The Rigol limits it to the current memory setting (on Auto, it would be 600 pts at 50ns/div).
The Agilent limits it to the total memory of the scope (~500kpts/channel).

See video from my 1000Z:


This is a necessary function of a scope with pre-trigger, since you don't know when the trigger will occur your pre trigger going further back in time requires more memory.

Nothing I am suggesting here is unusual ... it seems pretty much every DSO manufacturer has come across similar limitations.

Now where there is a difference is post-trigger.  That can be done without memory, so I expect the manufacturers are saving some segment of the trigger samples to do the trigger de-jitter.  In which case, I retract a bit of what I said before about this being an edge case, that is wrong,  it is a normal use case and it will need to be supported.
 
The following users thanked this post: egonotto

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 3922
  • Country: hr
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #138 on: November 20, 2020, 06:07:28 pm »
With 100MHz and 1GHz sampling, it is customary to have 5ns/div and no visible triggering jitter. Picoscope with those specs has 3 ps RMS trigger jitter specified.. That should be target.

5ns/div implies (assuming a 1920-wide canvas and 12 divisions, is that fair?) about 31ps per 'virtual' sample.  How could you determine if the trigger jitter was any better than 31ps in that case?  AFAIK Picoscope doesn't plot sub-pixels (same as most scopes.)

Pico 3406D supports up to 20GS/s in ETS mode, so needs triggering that can cope with that.
I'm afraid I don't understand what you mean by "doesn't plot sub-pixels (same as most scopes.)"?
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4392
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #139 on: November 20, 2020, 06:27:22 pm »
tom66, thank you, this is super impressive work!

A few years ago I've worked a bit on the Siglent SDS1x0xX-E (https://github.com/360nosc0pe/fpga) reverse-engineer/hack. We've got it to a level where we can control the frontends (coupling, attenuation, BW), capture the ADC data, and push that to memory on the PL. On the PS, we had Linux and some test code to pull data out of RAM and display it; eventually the goal was to render into accumulation buffers in blockram (which is what Siglent does, hence the crappy resolution to make it fit), but didn't get that far - we never got further than basically driving the hardware correctly, but that part worked well.

Without going too much into the topic of creating new hardware vs. hacking existing hardware, I think the design shares a lot of the same choices so for an open source oscilloscope, I would be very interested in cooperating and/or potentially porting your code to this platform.

Also, nice work on the CSI-2 interface! How does your CSI-2 Phy look on the FPGA side? Do you need to implement LP support or only high-speed? This is a very elegant, cheap and fast solution to capture lot of data into a RPI. (I've so far always used an FT2232H in FIFO mode, but it adds significant cost and especially on a RPi3, the USB alone eats a full CPU core due to the bad USB controller design.) I assume receiving data on CSI-2 doesn't take up a lot of CPU resources on the RPi if you can DMA large blocks.

Interesting project! I am impressed someone managed to do that. 

There may be some 'scope' for collaboration, so let's keep talking and see if we can help each other out.  Not sure how much would be reusable, but maybe some would be.

Regarding CSI-2.  I was able to write a PLL register on an authentic Pi camera to get clock down to 12MHz ... image goes bad (too dark because shutter times etc wrong) but you can then switch the camera into a test pattern mode.  Using this, you can reverse-engineer the protocol on as little as a Rigol DS1074Z.  I built a board to allow me to do this - it sits between a Pi camera and a Pi and allows me to 'snoop' on the bus between the two (see attached)

The CSI-2 Phy on the FPGA side is an implementation of Xilinx XAPP894 using the Passive circuit they suggest with custom Verilog driving a pair of OSERDESE2 blocks and a bloody complex FSM to manage the whole process of generating packets and data streams.  I prototyped this on a smaller PCB in the first run and spent a few months reverse engineering the protocol using what documentation I could find.    It is something I really need to re-engineer at some point.  It was initially designed with a BlockRAM interface i.e. data would be copied into BRAM and output from there.  That was sufficient for testing but eventually I ended up bolting on an AXI stream interface.  So you set up a transfer of X lines of video data each with 2048 bytes and the AXI DMA manages the rest of this.  To simplify things, the two lanes terminate at the same moment (i.e. odd data lengths are fundamentally unsupported.)  But I want to add the capability (as CSI-2 supports) for odd line lengths and jumbo packets at some point.

Annoyingly with a Pi it is 'all or nothing'... if you don't get it all right it doesn't work at all.

One consequence of this design choice is all packets have to be 2048 byte multiples - if they are not they are padded with null bytes.  So not useful for small packets - those are sent over the SPI bus right now. But the protocol is fairly robust.  I can reliably transfer 180MB/s from Zynq RAM to the Pi for hours on end with zero bit errors.

I don't implement the true LP protocol as the Pi camera doesn't use it so I don't support e.g. lane turnaround or low speed communication over that.  I do of course implement the start-of-transmission and end-of-transmission signals, and the small packet header format for SoF/EoF and the larger packet format.  Presently the CRC is set to all zeroes ... the Pi doesn't seem to use this and it makes the logic easier.

I also implement start and end on the clock lane, putting the clock lane into LP when not transmitting.  There is no need in the specification to do this, but it improves reliability if the Pi failed to sync onto the first SoT packet it would never see any data for the duration of operation.  It also saves power (about 0.1W).

One interesting way you can determine if a device is actually utilising the checksum is to deliberately degrade the link.  In my case I added some 10pF to D1+ D1- pair,  I had plenty of bit corruption,  but all lines were appearing on the data and the frame was otherwise intact.  That told me Pi ignores the checksum (or sets an ignorable error flag/increments some counter) which meant I could avoid implementing that part of the specification.

You are correct that on the Pi side this is all DMA driven so the data essentially arrives in memory at a given point and you can read it from there.  You need to be careful of a few things:
- Pi and transmitter need to both know how big the packet is (so if you send 2045 lines, set the receiver to 2045 lines) otherwise an odd effect where the first few lines get offset with garbage occurs
- The Pi needs to be 'ready' to receive before the FPGA starts otherwise the CSI core gets into an error state

At present only the process that uses MMAL can access the data at a given pointer, which creates a few headaches.  That would be good to solve.  If you want to share the data between processes, it requires a memcpy :( because the MMAL data is private to a given process.  There is a Linux-kernel solution to this that a friend was looking into for me, but I need to awaken that. 
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4392
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #140 on: November 20, 2020, 06:38:43 pm »
Pico 3406D supports up to 20GS/s in ETS mode, so needs triggering that can cope with that.
I'm afraid I don't understand what you mean by "doesn't plot sub-pixels (same as most scopes.)"?

Right - OK, I didn't consider ETS.  I'm not planning on implementing it, I don't see a major benefit from it.  It may be possible to do it at lower wfm/s but at higher rates it would require the PLL to hop frequency too often. 

But, even if you have ETS, at the end of the day, when you have a sample to plot, say, at 50ps in time... it is going to land on exactly one pixel.  Fractional plotting does not appear to be implemented by any mainstream OEM, I have tried Tek 3000 series, Siglent 5000X, Agilent/Keysight 2000X and 3000X,  and various Rigol scopes. 

If you have a 50ns/div timebase (12 divs so 600ns span), and 1920 pixels to plot your waveform points on, then each pixel would represent 31ps of time.  You cannot represent finer than this: you do not have the pixels to do so. So, there is no benefit to achieving any better than pixel-perfect representation, so in this case, anything better than 31ps jitter is no better information.

This applies for sinx/x too, as a sinx/x interpolator works like a regular FIR filter with most of its inputs set to zero. (10x interpolator would have 9 samples at zero and 1 sample at your input value) so you can only shift by interpolated-sample intervals. 

« Last Edit: November 20, 2020, 06:42:06 pm by tom66 »
 
The following users thanked this post: 2N3055

Online nctnico

  • Super Contributor
  • ***
  • Posts: 21544
  • Country: nl
    • NCT Developments
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #141 on: November 20, 2020, 07:22:02 pm »
With 100MHz and 1GHz sampling, it is customary to have 5ns/div and no visible triggering jitter. Picoscope with those specs has 3 ps RMS trigger jitter specified.. That should be target.

5ns/div implies (assuming a 1920-wide canvas and 12 divisions, is that fair?) about 31ps per 'virtual' sample.  How could you determine if the trigger jitter was any better than 31ps in that case?  AFAIK Picoscope doesn't plot sub-pixels (same as most scopes.)

Pico 3406D supports up to 20GS/s in ETS mode, so needs triggering that can cope with that.
I'm afraid I don't understand what you mean by "doesn't plot sub-pixels (same as most scopes.)"?
At 100ps/div you'll definitely see a 31ps difference in delay. But then again having a 3ps RMS trigger jitter is pretty impressive. That is >US$20k oscilloscope territory. I'm not sure whether extremely low trigger jitter specs are something to aim for right now. At some point noise of the system is going to contribute a lot to the trigger jitter and it may need external circuitry to produce a clean, low jitter trigger.

Regarding pre/post trigger. It may be that I got those the wrong way around (semantics) but the point is that it should be possible to move the trigger point way to the left and have data AFTER the trigger after a very long delay.
« Last Edit: November 20, 2020, 07:23:37 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4392
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #142 on: November 20, 2020, 07:37:42 pm »
Yes, for post-trigger it will need to be implemented.   I will get the present implementation working with just post-trigger in memory but will consider how to enable this to work for long post-trigger delays.  The same principle should be usable for both cases, just need to keep a local record of samples around the trigger point if they are outside of the memory depth.

I have some DIY to catch up to on the weekend, so maybe won't get that much time to look at this specifically, but will still give it some "brain time".
 

Offline dave j

  • Regular Contributor
  • *
  • Posts: 90
  • Country: gb
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #143 on: November 20, 2020, 08:14:24 pm »
If you have a 50ns/div timebase (12 divs so 600ns span), and 1920 pixels to plot your waveform points on, then each pixel would represent 31ps of time.  You cannot represent finer than this: you do not have the pixels to do so. So, there is no benefit to achieving any better than pixel-perfect representation, so in this case, anything better than 31ps jitter is no better information.
Just because you can only plot using pixels doesn't mean you don't need to store waveform points to a higher resolution. Consider the attached image. The white lines are at five times higher pitch than the orange ones. If you were only storing points at the lower pitch the orange lines would appear identical. Not a problem for horizontal traces but for nearly but not quite vertical ones, such as fast edges, you could clearly see a difference.
I'm not David L Jones. Apparently I actually do have to point this out.
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4392
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #144 on: November 20, 2020, 08:41:22 pm »
If you have a 50ns/div timebase (12 divs so 600ns span), and 1920 pixels to plot your waveform points on, then each pixel would represent 31ps of time.  You cannot represent finer than this: you do not have the pixels to do so. So, there is no benefit to achieving any better than pixel-perfect representation, so in this case, anything better than 31ps jitter is no better information.
Just because you can only plot using pixels doesn't mean you don't need to store waveform points to a higher resolution. Consider the attached image. The white lines are at five times higher pitch than the orange ones. If you were only storing points at the lower pitch the orange lines would appear identical. Not a problem for horizontal traces but for nearly but not quite vertical ones, such as fast edges, you could clearly see a difference.

Right - but here's the thing - the data is there.  Nothing is being lost -- it's just not being reconstructed, if that makes sense.

This is relating to how the data is reconstructed into a real signal.    At any given zoom level there is little benefit in going beyond the display resolution of your display device (you cannot get more pixels than there are actually on the panel.)  So, there is no point in showing <31ps jitter, for instance, if the minimum display resolution is 31ps, because nothing will ever make that usefully visible to the user.

If you zoom in one step then, yes, you do want to make that visible at that stage.
 

Offline Someone

  • Super Contributor
  • ***
  • Posts: 2737
  • Country: au
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #145 on: November 20, 2020, 09:32:41 pm »
Fractional plotting does not appear to be implemented by any mainstream OEM, I have tried Tek 3000 series, Siglent 5000X, Agilent/Keysight 2000X and 3000X,  and various Rigol scopes.
The reconstruction (plotting) filter in the megazoom IV is matched to the expected bandwidth of the front end so it may be difficult to see with the slower models. But on faster models the plotting is most certainly not hard aligned to the trigger, and can be seen to move with at least 1 px of precision at 2ns/div (64px, 31ps). Noting that scope uses an analog trigger so there is additional jitter from that hardware which isn't eliminated as would be with a digital trigger.
 

Offline rhb

  • Super Contributor
  • ***
  • Posts: 3167
  • Country: us
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #146 on: November 21, 2020, 01:39:30 am »
The principle is, if the input filter has the correct response (it needs to roll off before Nyquist so that you avoid the described Nyquist headaches) you can calculate slope from the delta from the presumed trigger point (which is at t=0 - centre of the waveform) and the actual trigger point at t=? ... the actual trigger point will be offset from the point that the oscilloscope triggered at by a fraction of the sample rate (0-1ns).
This is getting silly, you still can't provide a mathematical example of your proposed method. How can the slope be known a-priori? With an ideal AFE filter, any frequency (slope) less than the cutoff could be occurring around the trigger point.

Even with the trivial example of a perfect sine wave of constant frequency being sampled perfectly (and below Nyquist) shifting it with DC while keeping the trigger threshold static would present different slopes at the trigger point. Just the phasing of the points when the frequency isn't rational with the sampling frequency causes significant shifts and jitter as the waveform approaches the Nyquist rate.

Old military electronics tech trick:    Measure the harmonics of a square wave on the spectrum analyzer to determine the slew rate.

All of this is a basic application of the Fourier transform and causality.

We have given much thought to triggering and I think we can do better than anyone else.  Not implemented yet, but nothing difficult to do.  I spent quite a bit of time on the subject. The limitation is free time to devote to the project.

If anyone wants to commit their time to working on the task I shall be pleased to advise.  It's actually quite easy if you know how.

Have Fun!
Reg
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 21544
  • Country: nl
    • NCT Developments
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #147 on: November 21, 2020, 01:53:46 am »
It would be better to just explain the math in detail so people know what they are getting into instead of pulling up smoke screens. Open source means full disclosure  ;D
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Someone, egonotto

Offline snoopy

  • Frequent Contributor
  • **
  • Posts: 743
  • Country: au
    • Analog Precision
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #148 on: November 21, 2020, 06:51:05 am »
Pico 3406D supports up to 20GS/s in ETS mode, so needs triggering that can cope with that.
I'm afraid I don't understand what you mean by "doesn't plot sub-pixels (same as most scopes.)"?

Right - OK, I didn't consider ETS.  I'm not planning on implementing it, I don't see a major benefit from it.  It may be possible to do it at lower wfm/s but at higher rates it would require the PLL to hop frequency too often. 

But, even if you have ETS, at the end of the day, when you have a sample to plot, say, at 50ps in time... it is going to land on exactly one pixel.  Fractional plotting does not appear to be implemented by any mainstream OEM, I have tried Tek 3000 series, Siglent 5000X, Agilent/Keysight 2000X and 3000X,  and various Rigol scopes. 

If you have a 50ns/div timebase (12 divs so 600ns span), and 1920 pixels to plot your waveform points on, then each pixel would represent 31ps of time.  You cannot represent finer than this: you do not have the pixels to do so. So, there is no benefit to achieving any better than pixel-perfect representation, so in this case, anything better than 31ps jitter is no better information.

This applies for sinx/x too, as a sinx/x interpolator works like a regular FIR filter with most of its inputs set to zero. (10x interpolator would have 9 samples at zero and 1 sample at your input value) so you can only shift by interpolated-sample intervals.

Tek TDS7XX, TDS7XXX, TDS5XXX all offer ETS. The TDS7XXX, and TDS5XXX also offer real time sinx/x interpolation probably because it has much more computational power compared to the earlier TDS7XX scopes. The ETS works extremely well on these scopes. I don't think any other vendor does it as well as Tek does. The downside to ETS is that it requires a repetitive waveform :(

cheers
« Last Edit: November 21, 2020, 06:53:39 am by snoopy »
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 4392
  • Country: gb
  • Electron Fiddler, FPGA Hacker, Embedded Systems EE
Re: A High-Performance Open Source Oscilloscope: development log & future ideas
« Reply #149 on: November 21, 2020, 10:24:51 am »
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.
« Last Edit: November 21, 2020, 10:26:38 am by tom66 »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf