Products > Test Equipment

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

<< < (29/71) > >>

tom66:

--- Quote from: 2N3055 on November 20, 2020, 06:07:28 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.)"?

--- End quote ---

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. 

nctnico:

--- Quote from: 2N3055 on November 20, 2020, 06:07:28 pm ---
--- Quote from: tom66 on November 20, 2020, 05:40:51 pm ---
--- Quote from: 2N3055 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.

--- End quote ---

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.)

--- End quote ---

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.)"?

--- End quote ---
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.

tom66:
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".

dave j:

--- Quote from: tom66 on November 20, 2020, 06:38:43 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.

--- End quote ---
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.

tom66:

--- Quote from: dave j on November 20, 2020, 08:14:24 pm ---
--- Quote from: tom66 on November 20, 2020, 06:38:43 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.

--- End quote ---
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.

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

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