Author Topic: Rigol DS1054Z bandwidth  (Read 27329 times)

0 Members and 1 Guest are viewing this topic.

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26891
  • Country: nl
    • NCT Developments
Re: Rigol DS1054Z bandwidth
« Reply #25 on: December 20, 2016, 10:42:45 pm »
At 100MHz you won't have reflections unless you use cables >50cm. The biggest contributor to the error is the impedance of the capacitor. With (for example) a 15pf capacitance in parallel the total impedance gets lower so at 100MHz a 15pf capacitor parallel with a 50Ohm terminator at the input results in an impedance of 45 Ohms. This is a 10% error at a mere 100MHz.
« Last Edit: December 20, 2016, 11:01:11 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19468
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Rigol DS1054Z bandwidth
« Reply #26 on: December 21, 2016, 12:13:41 am »
Can someone try to confirm this -- possibly cable reflections might have affected my measurements?? A similar test without TG level compensation and a 50 Ohm terminator at the "free end" of the BNC T already showed soemthing like 263MHz 3dB single channel bandwidth on my DS1054Z, so the result may also well be accurate.

Generator -> 2m of 52ohm cable -> T-piece to scope 1Mohm//20pF -> 2m of 52ohm cable -> 50ohm terminator. Scope: 10ns/div, Tek 485.

Note the "notches" due to the 20pF, and other reflections due to the 52ohm/50ohm mismatch.

There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline MrWolf

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Rigol DS1054Z bandwidth
« Reply #27 on: December 21, 2016, 09:35:04 am »
Many thanks, TheoB! Good to see posts from someone who (a) knows what he is doing, and (b) gives a balanced view of the DS1054Z, putting things in perspective, mentioning strengths and limitations without much fanfare.

Slightly disagree, this thread is mostly about strengths. "Fanfare" usually starts when someone mentions limitations, some just wont shut up w/o good fight ;) Has been going on since scope came out if you use search button a bit. So just for newcomers I'm gonna make short actually balanced summary here: This scope is indeed good if you have actual need the speed. That means sitting in 5...20ns timebases (or according zoom level). If your actual needs are located below these timebases, horizontal precision is heavily crippled compared to almost any other modern DSO.  :popcorn:
 
The following users thanked this post: saturation

Offline MrWolf

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Rigol DS1054Z bandwidth
« Reply #28 on: December 21, 2016, 10:05:40 am »
CH #SincAverageRisetime
1OnNormal1.5ns
2OnNormal2.11ns
2OnAveraged2.09ns
4OffNormal4.61ns
4OnNormal2.83ns
4OffAveraged4.53ns
4OnAveraged3.34ns

From this good table showing effects of sampling rate on bandwidth another thing becomes evident:
Z would be a real kicker if it supported ETS. Because with ETS it would have full analog bw on all channels on repetitive signals.   Did not the old models have it? DS1102* 25GSa/s, DS1052* 10GSa/s. Good stuff if you know how to use it  :-+
Edit: Various scopes tested for risetime here (incl Rigol). Effective use of ETS vs RTS demonstrated (DSO7104B, 54831D):
https://youtu.be/mS3sCJd_GPk?t=15m36s
« Last Edit: December 21, 2016, 11:25:11 am by MrWolf »
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 4090
  • Country: fi
  • Born in Finland with DLL21 in hand
Re: Rigol DS1054Z bandwidth
« Reply #29 on: December 21, 2016, 10:44:18 am »
CH #SincAverageRisetime
1OnNormal1.5ns
2OnNormal2.11ns
2OnAveraged2.09ns
4OffNormal4.61ns
4OnNormal2.83ns
4OffAveraged4.53ns
4OnAveraged3.34ns

From this good table showing effects of sampling rate on bandwidth another thing becomes evident:
Z would be a real kicker if it supported ETS. Because with ETS it would have full analog bw on all channels on repetitive signals.   Did not the old models have it? DS1102* 25GSa/s, DS1052* 10GSa/s. Good stuff if you know how to use it  :-+


Take true pure sine wave and measure true BW again. You are perhaps in the Fourier trap with edge what is undefined. Sure is that it is not pure step as in "school books". Also you need know that Z box Sin(x)/x function is real joke. (evidences published here in forum many times.
Edge risetime measurement can use for rough BW estimation but all calculus are based for step what follow fourier serie perfectly (and with pure gaussian BW shape). Now you measure so that you do not know nearly anything what is true signal shape exactly in BNC input connector. 
You really do not know how to "fool" scope so that it display faster risetime than true BW.  7 pints wink: Think harmonics what are effective in BNC input connector and think levels. Do you know if all what input see  goes like example: 1/3, 1/5, 1/7, 1/11  and so on...

Theory is nice. But, if practice differs from theory: Theory as it is used is wrong.

« Last Edit: December 21, 2016, 10:51:04 am by rf-loop »
I drive a LEC (low el. consumption) BEV car. Smoke exhaust pipes - go to museum. In Finland quite all electric power is made using nuclear, wind, solar and water.

Wises must compel the mad barbarians to stop their crimes against humanity. Where have the wises gone?
 

Offline TheoBTopic starter

  • Regular Contributor
  • *
  • Posts: 62
  • Country: nl
Re: Rigol DS1054Z bandwidth
« Reply #30 on: December 21, 2016, 01:21:20 pm »
Quote
From this good table showing effects of sampling rate on bandwidth another thing becomes evident:
Z would be a real kicker if it supported ETS. Because with ETS it would have full analog bw on all channels on repetitive signals.   Did not the old models have it? DS1102* 25GSa/s, DS1052* 10GSa/s. Good stuff if you know how to use it  :-+
Yes ETS (Equivalent Time Sampling, I had to look this one up :-) ) is what my old Philips PM3320A used to have. Fine for repetitive signals. The scope had only 250Msa/s but a bandwidth of 200MHz. I must say, I'm more happy with my little Rigol. Much less noisy, smaller, real time sampling up to 1Gs, 24M deep memory, I love it  :-+. Adding ETS would help in the case you need accurate timing with four channels. But that's only for risetimes/delays outside of the spec of the scope (7ns!!). So we cannot complain can we?

If you have a 2ns rise time you get 2 samples at 1Gsa/s. But since the scope does not trigger on the analog input signal, the two points are positioned somewhere randomly on the edge. If you capture, say 10 times, you have 20 points along the edge. The issue is now that the scope needs to decide from each set of two points found on the slope where the trigger moment is. With lower sample rate, the edge start to wobble (see earlier screenshots). There are often no samples on the edge anymore:
Vector display:

Dots display:

Still the scope triggers on the transition. This increases the jitter a lot.
With ETS a scope must trigger on the input signal itself and then take a sample somewhere on the edge with a known but random delay for each capture. More expensive scopes might trigger before the digitizer. I think the Rigol does everything in the digital domain.
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 4090
  • Country: fi
  • Born in Finland with DLL21 in hand
Re: Rigol DS1054Z bandwidth
« Reply #31 on: December 21, 2016, 01:43:04 pm »
More expensive scopes might trigger before the digitizer. I think the Rigol does everything in the digital domain.

Imho not today. Lot of scopes (today) do digital side trigger what have lot of advantages compared to analog side pathway old trigger system as example in Rigol DS1000E and many many similar.
(yes, analog sidepathway trigger system _Can do_  also very good but it is not easy and cheap (Example in some very advanced LeCroy models))

Read example Rohde&Scwarz RTO about this and about "oversampling" and fine interpolation for perfect horizontal positioning.

With well made full digital side trigger system trigger jitter is really small. Look example how Siglent works.
No one want old crap cheap scopes analog trigger system. These exist only in museum.

 
I drive a LEC (low el. consumption) BEV car. Smoke exhaust pipes - go to museum. In Finland quite all electric power is made using nuclear, wind, solar and water.

Wises must compel the mad barbarians to stop their crimes against humanity. Where have the wises gone?
 

Offline MrWolf

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Rigol DS1054Z bandwidth
« Reply #32 on: December 21, 2016, 02:03:42 pm »
Adding ETS would help in the case you need accurate timing with four channels. But that's only for risetimes/delays outside of the spec of the scope (7ns!!). So we cannot complain can we?

Well DS1054Z is all about operating outside of spec :) And it's not so much about complaining, but supplying young players with best possible information about all the options and possibilites in the world of scopes so they could make informed choice.
ETS is indeed not very well known since it was mostly high-end DSO stuff. Now high-end slowly moves off the ETS, not because it's bad but because high-end has now good enough realtime sample rates. For example cannot find ETS in Tek MDO4024C (200MHz) spec, but it has 2.5GSa/s on all four. For 0.25GSa/s all four scope it would be most welcome. It is not expensive technology in itself, can be found on scopes cheap as ~100€.
So ETS is like warp drive for scope. You do not have much control but can go to places no amateur has gone before, just point in right direction before launch :P Another clever tool in toolbag so to speak...
 

Offline saturation

  • Super Contributor
  • ***
  • Posts: 4787
  • Country: us
  • Doveryai, no proveryai
    • NIST
Re: Rigol DS1054Z bandwidth
« Reply #33 on: December 21, 2016, 02:06:15 pm »
This thread has gotten busy!

This data is very interesting, but is this right, memory depth is <= 30 pts?? can confound the readings markedly.  Any chance you can repeat it what you did on the link and keep memory depth consistent throughout at the highest the 1054z allows? 

https://www.eevblog.com/forum/testgear/rigol-ds1054z-bandwidth/msg1095425/#msg1095425

Enjoy.
Best Wishes,

 Saturation
 

Offline TheoBTopic starter

  • Regular Contributor
  • *
  • Posts: 62
  • Country: nl
Re: Rigol DS1054Z bandwidth
« Reply #34 on: December 21, 2016, 02:45:44 pm »
Quote
This data is very interesting, but is this right, memory depth is <= 30 pts?? can confound the readings markedly.  Any chance you can repeat it what you did on the link and keep memory depth consistent throughout at the highest the 1054z allows? 
Yes, that's just the time you see times the sample rate (5ns*12*250M=15 points from left to rigth). I indirectly choose the sample rate by enabling more channels. In vector mode it really looks ok, but that's the interpolation. Has nothing to do with samples measured :-). The two screenshots in my previous shows that more clearly.
The maximum at 5ns is 5 samples per division (1Gs/s) or 60 samples per trace. But averaging helps here.
« Last Edit: December 21, 2016, 03:00:28 pm by TheoB »
 
The following users thanked this post: saturation

Offline saturation

  • Super Contributor
  • ***
  • Posts: 4787
  • Country: us
  • Doveryai, no proveryai
    • NIST
Re: Rigol DS1054Z bandwidth
« Reply #35 on: December 21, 2016, 03:05:18 pm »
Some general comments:

Tr  vs RF generator:  yes, as mentioned small Tr errors lead to large estimates in frequency response, so great care must be made in measurement.  But a fast edge is easier and cheaper to obtain today than a confirmed flat RF source. 

You can easily obtain a >= 1ns edge using any clock from fast digital logic to test systems with bandwidths to ~500 MHz. 

ideal vs real: the more instruments used deviate from ideal, the less the idealized calculations apply.

A pulse test assumes the system response is uniform throughout, for all timebases and amplification, thus an ideal DSO.

Since the Tr is assumed constant, it can easily be confirmed how far the DSO remains constant regardless of the timebases selected and amplification. 

If the rise time calculation varies by timebase, and/or vertical amplification it becomes difficult to generalize one setting for all the more the deviation occurs from the original data point, and it needs to be confirmed by an RF generator approach.

Or, you can apply a statistical approach to the response deviation and determine the degree of uncertainty in the measure you can tolerate.
« Last Edit: December 21, 2016, 03:13:37 pm by saturation »
Best Wishes,

 Saturation
 

Offline saturation

  • Super Contributor
  • ***
  • Posts: 4787
  • Country: us
  • Doveryai, no proveryai
    • NIST
Re: Rigol DS1054Z bandwidth
« Reply #36 on: December 21, 2016, 03:12:53 pm »
Thanks Theo, I understand.  Do you know or have the published datasheet rise time of your EH 122 Pulse Generator?


Quote
This data is very interesting, but is this right, memory depth is <= 30 pts?? can confound the readings markedly.  Any chance you can repeat it what you did on the link and keep memory depth consistent throughout at the highest the 1054z allows? 
Yes, that's just the time you see times the sample rate (5ns*12*250M=15 points from left to rigth). I indirectly choose the sample rate by enabling more channels. In vector mode it really looks ok, but that's the interpolation. Has nothing to do with samples measured :-). The two screenshots in my previous shows that more clearly.
The maximum at 5ns is 5 samples per division (1Gs/s) or 60 samples per trace. But averaging helps here.
Best Wishes,

 Saturation
 

Offline TheoBTopic starter

  • Regular Contributor
  • *
  • Posts: 62
  • Country: nl
Re: Rigol DS1054Z bandwidth
« Reply #37 on: December 21, 2016, 03:37:24 pm »
Thanks Theo, I understand.  Do you know or have the published datasheet rise time of your EH 122 Pulse Generator?
I just have the instrument lying around. No datasheet. Could also not find anything on the internet. It supposed to be able to generate pulses as narrow as 2ns. But I cannot measure that with the rigol scope to confirm. At work I have all the tools I could ever dream about, but at home it's just for hobby  :). So I could measure it, but it's heavy and I have to carry it a long way then.
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 16607
  • Country: us
  • DavidH
Re: Rigol DS1054Z bandwidth
« Reply #38 on: December 21, 2016, 05:48:54 pm »
Thanks Theo, I understand.  Do you know or have the published datasheet rise time of your EH 122 Pulse Generator?

Even more importantly, does it have the specifications for aberrations?

One reason I have a real sampling oscilloscope is for calibrating my fast transition reference level pulse generators.  Without this, a transient response and bandwidth measurement using a fast edge is of questionable accuracy.  These measurements of the DS1054Z input bandwidth are not consistent with earlier measurements using a leveled signal generator and probably reflect the poor quality of the signal source.
 

Offline TheoBTopic starter

  • Regular Contributor
  • *
  • Posts: 62
  • Country: nl
Re: Rigol DS1054Z bandwidth
« Reply #39 on: December 21, 2016, 06:44:54 pm »
Thanks Theo, I understand.  Do you know or have the published datasheet rise time of your EH 122 Pulse Generator?

Even more importantly, does it have the specifications for aberrations?

One reason I have a real sampling oscilloscope is for calibrating my fast transition reference level pulse generators.  Without this, a transient response and bandwidth measurement using a fast edge is of questionable accuracy.  These measurements of the DS1054Z input bandwidth are not consistent with earlier measurements using a leveled signal generator and probably reflect the poor quality of the signal source.

Agree. I clame no accuracy. With the limited resources I have I just share my observation. That's what this thread started about:
Quote
Anyone else noticed this difference in bandwidth as a function of vertical gain?
Most likely answer is that the bandwidth is limited as some amplifier is enabled for gain settings <= 200mV
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 16607
  • Country: us
  • DavidH
Re: Rigol DS1054Z bandwidth
« Reply #40 on: December 21, 2016, 10:58:24 pm »
Quote
Anyone else noticed this difference in bandwidth as a function of vertical gain?
Most likely answer is that the bandwidth is limited as some amplifier is enabled for gain settings <= 200mV

I do not remember which one it is but there is a variable gain amplifier used to drive the digitizer similar to the National LMH6518 used in the DS2000A series.  Whichever chip Rigol used (LMH6514 or LMH6515?), I doubt that it would cause the bandwidth to change with vertical gain in such a low bandwidth design.

The single ended to differential conversion stage however has a pair of switched equalization networks and for some reason a tail current adjustment.  On one hand while that *could* cause changes in bandwidth, it seems unlikely.  On the other hand, it is not clear why the switched equalization networks exist or why the tail current is adjustable.  My guess is that the tail current is used to adjust the common mode voltage going into the variable gain amplifier and the equalization has something to do with the separate bandwidth limiter stage.

If the bandwidth really is changing at different volt/div sensitivities, I would consider it a flaw unless it is listed as part of the specifications and even then, it is a rather annoying behavior.  In some high bandwidth designs, there is just no good way around it but at 100 MHz, it should not be an issue.  I do not know if anybody has made reliable measurements of the DS1054Z bandwidth over a wide range of volts/div settings; while it is straightforward to do, it takes a leveled signal generator, reference level pulse generator, and almost always some DC to RF attenuators to do properly.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26891
  • Country: nl
    • NCT Developments
Re: Rigol DS1054Z bandwidth
« Reply #41 on: December 21, 2016, 11:20:34 pm »
If (some) gain is needed then it is hard to make a good (flat frequency curve, low distortion) amplifier even at 100MHz.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 4090
  • Country: fi
  • Born in Finland with DLL21 in hand
Re: Rigol DS1054Z bandwidth
« Reply #42 on: December 22, 2016, 05:31:46 am »
Also Rigol total junk Sin(x)/x can be one trap.

Just do not trust any thing what you see on Rigol display.

Of course BW shape can be also different with different V/div settings. I do not remember exact V/div step(s) where it change input circuit.

Even with high quality RF generator with perfect flatness it is not so simple to measure BW shape. This is because there is not available 50ohm impedance. There need be calibration grade precision splitter and calibrated level meter assembled in scope input. (or generator what have leveled output "head" what can directly connect to scope input.)
 And if there is 15pF (+ 3pF) input capacitance parallel with terminator. It is far away from 50 ohm impedance specially if use pulse edge what have say example < 1ns risetime. And more fun. There is not 50ohm resistance and 15pF capasitance. There is "magpie's nest" network what include all, series and parallel connected resistances, inductances and capasitances and then "miracles". Whole system  can interact how ever with unknown fast edge and how it is connected.  Do not try accurate things with "GHz"  RF if really do not have knowledge and enough experience with any things but near DC. (near DC is  all <100MHz) There can drop in trap more fast than you can blink your eye.

It is NOT 50ohm impedance if you use feed thru terminator ot using T and terminator.

Edge risetime based BW wondering is... may I say. Total waste of time (in this case and with these all user errors and unknowns) . All results are wrong and more miracles to peoples who do not have any real experience with RF things. More fast edge may lead more severe and well hidden errors, example due to ringing and due to interact with system weakness. In this case this Rigol some joke design. Note that there can be also interaction with this bullshit Sinc.

Here is one example what this "1000Z-box for nice images"  can include
 https://www.eevblog.com/forum/testgear/rigol-ds1074z-weird-signal-level-problem/msg563208/#msg563208

In theory and in practice. Say example if there is real 3 - 4ns risetime in some scope. How easy it is fool rising speed test result using adjustable rise speed edge and (not visible ringing - overshoot) if other person do not know what method is used he/she stay fully fooled.  It is very easy to get total junk result than near truth if do not know signal. As long as anybody do not know what is exactly in scope input connector these wondering with strange results and accurate numbers looks like just playing fun.

With unknown pulse edge there in scope input ((it is not same as pulse output).  It is same as we measure BW shape using RF generator what flatness is highly unknown.

Unknown edge is roughly same as RF generator unknown sweep flatness in  this case. 
If you do not know generator levels with different frequencies  how you use it for define scope BW. 
« Last Edit: December 22, 2016, 05:41:59 am by rf-loop »
I drive a LEC (low el. consumption) BEV car. Smoke exhaust pipes - go to museum. In Finland quite all electric power is made using nuclear, wind, solar and water.

Wises must compel the mad barbarians to stop their crimes against humanity. Where have the wises gone?
 

Offline MrWolf

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Rigol DS1054Z bandwidth
« Reply #43 on: December 23, 2016, 08:48:46 am »
While Dave dissects their bodies, I seem to have taste for their brain contents :-DD This puppy's brains are now properly torn apart and splattered across some graphs. Initially just wanted to check if there is risetime difference <=200mV/div & >=500mV/div. Kink there is in graph. But noticed that Sin(x)/x causes noticeable overshoot.

Teaser image from PDF:


Did risetime test across vertical setting ranges in 1GSa/s and 250MSa/s Sin(x)/x ON/OFF modes.
OFF mode looked a bit more logical than wavy CGI in ON mode.





So I did the second test using Testec TT-DE 112 950MHz demodulator probe as scalpel.

20, 40, 60, 80, 100, 120MHz sine.
350mVpp and 3500mVpp signal levels.
1GSa/s Sinxx=ON; 250MSa/s Sinxx=ON; 250MSa/s Sinxx=OFF

- Looked at gen output after test cable & 50ohm pass-thru using demod and Agilent U1272A. No level dropoff with rising freq, gen is good then.
- Did run first testset (1GSa/s) with demodulator and scope after pass-thru. Level dropoff detected with rising freq just like it should be over scope input.
- Compared if demodulator affected scope readings - near zero effect.
- Did run all testsets (3x2x6) w/o demodulator, recorded voltages and risetimes.

Adjusted demod amplitudes to start of each testset 20MHz reading in Excel.
Graphed demod voltages with scope voltages.

Teaser image from PDF:


Noticed:
- Sinxx has heavy effect on risetime only when looking at step response, not when looking at stable sine.
- 50mV/div and 500mV/div have so large relative voltage differences with Sinxx=ON that seem to belong to different scopes. 500mV/div overshoots big time when looking at normalized graphs.
- With Sinxx=OFF normalized response graphs are almost identical.

Conclusion:
Everything happening with Sinxx on just pure CGI. Probably Sinxx=OFF is not a filter, but (more closer to) true response that gets hack-o-boosted big time. How else to explain massive sine Vpp overshoot, especially in 250MSa/s case?

Think I had my way with this thing now. Maybe should cook it instead of christmas turkey  :-DD
« Last Edit: December 23, 2016, 09:54:12 pm by MrWolf »
 

Offline guenthert

  • Frequent Contributor
  • **
  • Posts: 712
  • Country: de
Re: Rigol DS1054Z bandwidth
« Reply #44 on: December 24, 2016, 12:02:06 am »
But noticed that Sin(x)/x causes noticeable overshoot.
Uhm, I guess that has been discussed to death elsewhere already  :horse: and isn't specific to the DS1054Z.  You might know that the signal is a square wave and hence consider the flatter graph more faithful, however given the limited sampling rate, the oscilloscope cannot know this.  For the available data and input bandwidth the sin(x)/x interpolation is the most faithful representation the oscilloscope (any oscilloscope) can give you.  Connecting the dots (samples) using straight lines implies higher frequency components which weren't (couldn't be) sampled or passed the input low pass filter.  Showing those is kind of lying.

I like the compromise the analogue discovery software (WaveForms 2015) chose: it offers Sin(x)/x ("smooth") graphs as option, but defaults to straight lines, however if the displayed graph contains few data points (much fewer than horizontal pixel?) than those are explicitly drawn as a hint to the observer that those lines in between are just made up.
 

Offline MrWolf

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Rigol DS1054Z bandwidth
« Reply #45 on: December 24, 2016, 12:07:45 pm »
Uhm, I guess that has been discussed to death elsewhere already  :horse: and isn't specific to the DS1054Z.

Gasoline engine is not specific to Ferrari either. Can be found in Robin Reliant.  ::)

For the available data and input bandwidth 

According to available data (provided in the PDFs) Z box behaves in somewhat faithful way only in <=200mV/div vertical settings. This is confirmed by taking independent readings directly from scope input with live signal, using non-obtrusive probing. In >=500mV/div setting it artificially boosts the signal to look like more high bw scope. Once again programming, not hardware failure.

the sin(x)/x interpolation is the most faithful representation the oscilloscope (any oscilloscope) can give you

Most faithful representation is given by excessive sampling rate, either RTS or ETS. Once gain - real data.

 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26891
  • Country: nl
    • NCT Developments
Re: Rigol DS1054Z bandwidth
« Reply #46 on: December 24, 2016, 12:47:26 pm »
the sin(x)/x interpolation is the most faithful representation the oscilloscope (any oscilloscope) can give you
Most faithful representation is given by excessive sampling rate, either RTS or ETS. Once gain - real data.
Even better: understand the math behind sin(x)/x and you'd know/understand you don't get any extra information from an excessive sampling rate where fs/2 lies beyond the range of the anti-aliasing filter.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline MrWolf

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Rigol DS1054Z bandwidth
« Reply #47 on: December 24, 2016, 01:32:53 pm »
Even better: understand the math

Even better: understand the reality (has to do with experimental data etc  ;)):
ETS (raw data) superiority vs RTS+Sin(x)/x demonstrated in real word, on hightech hardware:
https://youtu.be/mS3sCJd_GPk?t=20m52s
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26891
  • Country: nl
    • NCT Developments
Re: Rigol DS1054Z bandwidth
« Reply #48 on: December 24, 2016, 01:41:15 pm »
The only thing I hear in that video is could be... could be... could be... could be...  which means that he is making a nice video but has no idea what he is yabbering on about.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline MrWolf

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Rigol DS1054Z bandwidth
« Reply #49 on: December 24, 2016, 02:00:11 pm »
he is making a nice video but has no idea what he is yabbering on about.

Not everyone is Dave, he just shows it best he can. Anyway from your point of view Agilent did include ETS just because they are stupid and do not read EEVBlog.  :-// Dunno, maybe, think gonna go make some cookies now  ::)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf