| Products > Test Equipment |
| Trying to display bandwith via Math on Siglent SDS2k+/2kHD/800X HD |
| << < (4/19) > >> |
| gf:
--- Quote from: Martin72 on May 14, 2022, 09:08:21 pm ---At work I checked this with three different scopes from lecroy. -Waverunner 9054, 500Mhz, 20GSa/s -HDO6034A, 350Mhz, 10GSa/s -Wavesurfer WS3024Z, 200Mhz, 4GSa/s --- End quote --- The spectrum in the WS... image also looks a bit strange in the 900-1000 MHz region. I wouldn't expect it to ascend again. Since you just display FFT(C1), there is no d/dx in the play which could garble the spectrum. I suggest to check how it looks up to 2GHz (half sample rate). And the time domain trace shows some ripple as well (~10 cycles / div => ~1GHz), which is too regular to be random noise. |
| gf:
--- Quote from: Martin72 on May 16, 2022, 03:16:34 pm ---What else can we do to manifest that this is a bug ? --- End quote --- One key aspect seems to be the definition of a "point". --- Quote from: Handbook ---The range of “dx”in the d/dtmenu is2~20. The measurement unitsarepointand thecorresponding time difference range is 0.02~0.20div. “div” indicates the number of the pixel points that each division has and is 100 for the SDS2000X Plus. If dx = 10 points, the time difference is 0.01*10 = 0.1div Then the differential operator calculates the average slope in10 points of the selected sourceand dx represents the time difference between the 10 sampled points. --- End quote --- On the one hand it talks about pixel points, on the other hand it talks about sampled points (which I would associate with samples). So what is really a "point" :-// At 1us/div, 4 "pixel points" were 40ns, and at 2us/div, 4 "pixel points" were 80ns (according to the definition in the handbook: 1 div = 100 pixel points). But that's not what we see. The spectrum with the two big lobes tells us that the actual dx was 2ns, at all timebases >= 50ns/div. And 2ns are 4 samples @2GSa/s. So the implementation obviously assumes that dx is in samples, and the stuff in the handbook regarding div and pixel points seems to be wrong an just leads to confusion. Nevertheless, "number of samples" is still an incomplete time specification if the sample rate of these samples is not specifed as well. For your experiments at > 50ns/div, the scope obviously assumed the raw sample rate of 2GSa/s, even if the d/dt operator is applied to interpolated samples @40GSa/s. While this could be considered correct, if it were unambiguously documented, I still find it a significant limitation, since It hiders you to do what I intended to do. [ Similiar to a camera in "auto" mode, which does whatever it thinks -- just not what the photographer wants it to do ;) ] For <= 20ns things still need more investigation. Could you please capture a single shot of say 4,000,000 raw samples (@2GSa/s) of this signal (I guess 200µs/div gives you that many points?), save them to an ASCII file, and post a link to the file? I would like to get a feeling for what can be extracted from these data, and what to expect. |
| Martin72:
Now I got a appx 125MB csv. file on the stick.. What your post with the WS concerns, I want to repeat this thing, because a day before it was different(FFT, last pic from the first post here): (see pic below) Can´t believe it´s only because the samplerate was 2GSa/s at this time (nice "trap" : Measure-paras were active...). |
| Martin72:
https://drive.google.com/file/d/1vUSKhswd9ki8PlOd07ZWp-cu3aet98cf/view?usp=sharing csv-file |
| gf:
Thank you. I'll take a look. It can take a while until I find some free time... |
| Navigation |
| Message Index |
| Next page |
| Previous page |