Can you specify exactly which delays you are trying to take data at, and the delay/number of commands at which you start seeing an error (for e.g. a trigger holdoff of 50 ns and at 500 ns)? This will help us when trying to reproduce your error.
To clarify what you mean by "behaves the same:" are you referring to the need to start our software first, or that you are seeing errors past some number of samples? If the former, then the extra parameters to the R command should have resolved the issue. If the latter, then the level settings are likely not related to the root cause.
When you perform your Gaussian fit, you truncated the CDF within 10-90%) then mirror the CDF, then fit to that shape? I assume you are not fitting to the CDF's S shape directly.
Good catch!! It is now working as expected. 2ns of recording a 2GHz signal with 10ps resolution. Calibration is ran every half second with linear interpolation.
I would like to know more about how you perform the fit.QuoteWhen you perform your Gaussian fit, you truncated the CDF within 10-90%) then mirror the CDF, then fit to that shape? I assume you are not fitting to the CDF's S shape directly.
We don't mirror the CDF, but instead apply the inverse CDF to the data, such that a perfect Gaussian error CDF would become a straight line. When you do this, the points on the edges will have their noise significantly amplified, and you need to weight them by 1 over the squared derivative of the inverse CDF to avoid blowing up the fit. The points are truncated to the 10-90% CDF region, as well as dropping any points that are more than 2 standard deviations from the central value determined via the interpolation method.
Checked your specified rise time. 35 and change, pretty impressive. Plan is to run this through that coax filter and see if you can de-embed it.
So if you do 1 Tsample/s at 12 bits, thats 12 Tbits/sec ?! How do you transfer that over a 40 gb/s USB ?!
rudi
Checked your specified rise time. 35 and change, pretty impressive. Plan is to run this through that coax filter and see if you can de-embed it.
https://www.eevblog.com/forum/testgear/show-us-your-square-wave/msg5284957/#msg5284957
1 TS/s refers to the timing resolution of the reconstructed waveform. To be fair these are sort of meaningless numbers once you get to timing resolutions this high, the 6GHz bandwidth is the impressive part.
Actual sample rate is 25MS/s since this is a sampling scope, not a real time scope.
Checked your specified rise time. 35 and change, pretty impressive. Plan is to run this through that coax filter and see if you can de-embed it.It looks like you appreciate this device
Apart from your exchange with SJL vs high level stuff (please go on, it is usefull whatever our level in the field)
=> what's your feedback about the perf of the GigaWave you got (2/4/8 CH ?)
I'm on the waiting list... waiting for EU approval
you said earlier : Shahriar's review is queuing... and we reveiw is expected in "a while"
Speed up the process and send your product to any guys (many experts, with many posts & high reliability) in this forum. Pretty sure sure they will do a far better review than Shahriar, because quick & relevant vs the potential of your device for hobbyist.
Don't get me wrong, Shahriar reviews are 1st-class... but it's all about "pro" stuff @ price tag way above the hobbyist budget (see its last videos) ; but any hobyist can learn form him, and that's ok.
All the best
Checked your specified rise time. 35 and change, pretty impressive. Plan is to run this through that coax filter and see if you can de-embed it.
https://www.eevblog.com/forum/testgear/show-us-your-square-wave/msg5284957/#msg5284957Thanks! Yep, the typical rise time on the datasheet is conservative.
S-parameter import is working with live de-embedding in the software. UI still in progress (we'd like to show the reconstructed step response, display the calculated the system risetime, etc), but at its core you just click "de-embed" and import an s2p file. Should be out by Sunday.
Are you planning to allow one Touchstone file for each channel? For the coax model, did you allow to enter a single value for the insertion loss?
Are you going to support a variable gain rather than just having it fixed?
Could you clarify what you mean? For splitters/attenuators/cable insertion loss/etc you will be able to enter in the loss in dB.
As the setup gets more complex, having a way to save all the settings (including the links to the Touchstone files) becomes more important.
If you get everything done on the list and are looking for something to add, please consider some sort of auto edge search. The software would start with some defined sweep range, using very low resolution, search for a edge. Center around that and increase the resolution. Maybe you could also support searching for the highest or lowest peak. Other? It's a bit of a pain to hunt down signals. I set the samples to 4 with several ns per division, find what I want, drag it to the center, manually zoom in a bit, fine tune the center, rinse and repeat until I get what I want. Having a way to automate this would be handy IMO.
As far as I know, your software only allows a fixed volts per division for the vertical axis. I want to be able to set this to what ever I want. I will use this with my scopes to make better use of the plot area or overlay different channels that have signals with different gains. Once we moved away from mechanical clunky rotary switches, I suspect most DSOs supported this.
With LabView sorted, I can have a look at temperature drift. Manual states 50C operating...
Showing the GigaWave with attached delayline. LiteVNA was used for a signal source. Shown with the delayline set to its minimum and maximum values.
As promised, SJL has provided me with a pre-release which supports s-parameter de-embedding. I used the LiteVNA + Solver64 to sweep my delayline from 5kHz to 8GHz to create a Touchstone file. The LiteVNA uses harmonics above 6GHz and the data is pretty poor. Still, importing the file into their GigaWave software, it appears to work correctly. For the review, I'll use my Agilent PNA to properly characterize the delayline.
... as I like to trigger a LVCMOS edge and analyze the variations of like 20%..80% rise time over time as also some Chatter.
My software does not make use of the glitch detection mentioned in the latest manual, although it was my collecting over long periods like this that raised the question about the glitches.
the issue can be circumvented by discarding and retaking CDF data that meets either of the following two criteria:
• Two neighboring voltages V1, V2 satisfy V2−V1 >5 mV and F(V2;Δt)−F(V1;Δt) < −0.1.
• Two neighboring voltages V1, V2 satisfy V2 > V1 and F(V2;Δt) − F(V1;Δt) > 0.9.
I had thought about implementing their error checking/recovery but I wasn't sure how to interpret the manual. Using their example in 4.3.2, where they show 15 pairs, I would assume they run through all four conditions for 14 sets. This assume "either of" meant to "OR" the two "ANDed" checks. An example would have helped remove any ambiguity.Quotethe issue can be circumvented by discarding and retaking CDF data that meets either of the following two criteria:
• Two neighboring voltages V1, V2 satisfy V2−V1 >5 mV and F(V2;Δt)−F(V1;Δt) < −0.1.
• Two neighboring voltages V1, V2 satisfy V2 > V1 and F(V2;Δt) − F(V1;Δt) > 0.9.
The one concern I have raised was how they plan to de-skew the channels.