Products > Test Equipment

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

<< < (27/71) > >>

tautech:

--- Quote from: tom66 on November 20, 2020, 09:08:31 am ---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.

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

tmbinc:
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.

tv84:
Getting interesting...  :popcorn:

2N3055:
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.

tom66:

--- Quote from: nctnico on November 20, 2020, 01:42:24 pm ---- the trigger point may be outside the acquisition data so you can't use the acquired data to calculate the trigger point

--- End quote ---

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.


--- Quote from: nctnico on November 20, 2020, 01:42:24 pm ---- it should be possible to trigger on very slow edges as well. Think tens of micro-Volts per second

--- End quote ---

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.


--- Quote from: tautech on November 20, 2020, 01:49:35 pm ---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.

--- End quote ---

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.

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