new killer scope in town - a true game changer from R&S - RTB2002 & RTB2004

[Harjit]

When you are calibrating your RT-ZP03 probes, how clean is the top - right after the rising edge.

I calibrated all of mine and they are quite "ratty" i.e. lots of ringing. I was never able to get a clean waveform for the second step where you adjust the two trim pots near where the probe attaches to the scope.

[Zlotnik]

When you are calibrating your RT-ZP03 probes, how clean is the top - right after the rising edge.

I calibrated all of mine and they are quite "ratty" i.e. lots of ringing. I was never able to get a clean waveform for the second step where you adjust the two trim pots near where the probe attaches to the scope.

How long is a piece of string? I too have some residual ringing (or a slow edge), seems fine to me, however, and the "it's-okay-o-meter" on the right shows "spot on, green". The okay-o-meter does fluctuate quite a bit for the second step tough, and there are wildly different ringing-vs-risetime tradeoffs possible for the same "A-okay" readings, so I kinda eyeballed it for a good compromise.

Maybe show a screenshot of your probe adjustment?

[Zlotnik]

I'm fiddling with a new RTB2k that landed on my bench a few days ago 
Great scope, (quite) a bit more expensive than the Siglent competition, but so far I really like the comparably unquirky well thought out UI and the low noise 10bit frontend that were the differentiators for me. And despite the premium compared with the Chinese brands, the price was actually quite nice with the ongoing R&S promo and a good deal from my distributor (Batronix. Highly recommended!)

However, I'm struggling a bit with what seems to be some idiosyncrasies when protocol-analysing an I2C bus at the limit of sampling memory. The scope seems to highlight protocol errors where I think it should still decode fine based on the analogue channels, and upon closer inspection also the timing of the logic transitions detected by the protocol engine seems off.
To wit:

I've highlighted in red where (I think) the protocol engine thinks SDA changed while SCL was high, red-marking that entire part of the frame as error.
I've highlighted in blue that apparently the protocol engine has some -0.6us delay in the SCL logic edges wrt the SCL edges in Ch2.


Zooming right in and looking at dots with no interpolation and peak-detect mode, there really seems no reason why the edges should not be properly detected, the SCL and SDA edges seem to be sharp and some 5-6 samples apart:


And similar frames with similar timing are detected okay:

(Although the weird offset between logic edges and analog edges is seen also here)

Am I missing something obvious here, or is the timing really wonky in the protocol decoder?

[maxspb69]

You made the right choice, congratulations! 

[nctnico]

However, I'm struggling a bit with what seems to be some idiosyncrasies when protocol-analysing an I2C bus at the limit of sampling memory. The scope seems to highlight protocol errors where I think it should still decode fine based on the analogue channels, and upon closer inspection also the timing of the logic transitions detected by the protocol engine seems off.

I've highlighted in red where (I think) the protocol engine thinks SDA changed while SCL was high, red-marking that entire part of the frame as error.
I've highlighted in blue that apparently the protocol engine has some -0.6us delay in the SCL logic edges wrt the SCL edges in Ch2.

What does the I2C specification say about timing for 400kHz? I think your I2C bus might violate I2C timing.

[Zlotnik]

You made the right choice, congratulations! 

Thanks, in part, to your measurements and comments! And also in part thanks to the hissy fits people throw in some threads right now, justifying wonky Siglent UI choices that would annoy me to no end ;-)

[Zlotnik]

What does the I2C specification say about timing for 400kHz? I think your I2C bus might violate I2C timing.

Data Valid time for Data (i.e. SCL falling edge to SDA transition) in FS mode shall be t_VD;DAT>0.9us. In the above example we’re talking about of order 150ns.
So indeed, this device is not I2C compliant. Well spotted! (and to be clear, since this often does not get across on the net: I do not mean this sarcastically)

Be that as it may, we’re not talking about the DUT’s misbehaviour, but about apparent idiosyncrasies of the scope being used to debug the DUT’s noncompliance:

1) The same noncompliant timing is not flagged as error one segment later, so it clearly is not an out-of-spec flag.
2) The same noncompliant timing is not flagged as error at a higher sample rate, but this limits the capture length. (Here the Siglent could actually have an advantage due to the RTB having “only” 10MPts)
3) The RTB should have sufficient samples to properly decode at this sample rate, the edges are cleanly resolved and separated. Looking at the data, I don’t think this should be borderline for the scope.
4) The RTB shows a weird delay in the timing of the detected logic levels underlying the protocol decode wrt the analogue channels that drive the protocol decoder. This is actually of an order of magnitude that would make spotting the exact I2C noncompliance you spotted difficult, if you don’t keep the analogue channels on-screen - which kinda defeats the purpose of the brilliant “bits” display R&S came up with.

Originally I figured maybe I’m “holding it wrong”, eg that maybe I’d have to fiddle with thresholds more. No dice. (Thresholds are displayed in my screenshots).
Or that maybe there was some noise or slow edges. Nope, peak-detect signal without interpolation shows a clean edge.

So the question is: is this expected behaviour? How much sample margin does one need to rely on the decoder? Can one trust the timing of the displayed “bits”?

Do you see this in your RTBs (&RTM in the case of Nico)?
In the case of Max: would you know how this stacks up to your SDS2k+?

[nctnico]

From my tests it seemed that I2C decoding works up to 40Mbit/s at the maximum samplerate of the RTM3004. The minimum oversampling factor turns out to be around 62.5. So your 41Msamples/s translates to a decoding samplerate of about 656kHz (this is a very crude estimate). Be aware though that the protocol decoding feature is a decoder and not a protocol timing verification tester. If you increase the samplerate you should be seeing better decoding results though.

[Zlotnik]

Yep, the protocol decoder is not a compliance tester. (I don't plan to use it as such). Still would be handy to have some more info about why it thinks a specific frame has an error. The UI gives only fairly generic error codes like "Data+Stop", and the SCPI commands to check a frame's status (eg BUS1:I2C:FRAM4:STAT?) are not much better: INC,UNEX. Would have been nice to see where exactly the decode went wrong. Not for compliance checking, but debugging. But this is wishful thinking, if I think about having to implement something like this... /me shudders.

Still, my 400kHz bus seems to decode reliably with 62.5MSa/s, but not with 41.7MSa/s. A 100kHz bus decodes with 41.7MSa/s, but not with 15.6MSa/s. So from this, it seems the oversampling the RTB's decode engine needs is rather of order 150 than 62.5 I mean: it's good to know the limits, and I'll certainly be able to use it, but looking a the data I'm surprised we'd need so many samples to decode without flagging an error.

About the delay in the bits shown in the decode: The logic channels don't show a similar delay wrt the analogue channels, but a bus decode using the logic channels shows the same delay between the "bits" and the logic channels. So this is quite definitely not due to any threshold issues, noise, jitter what have you.
Looks like a bug to me, tbh. Can another RTB user confirm this?

[MikeP]

Somebody else had the luck?

[Zlotnik]

Somebody else had the luck?

Could you be a bit more explicit what the issue is (N/A timebases?) and what the circumstances were?

[MikeP]

 Of course, the lack of five digits! No circumstances other than the latest firmware. If I'm not mistaken, this is the first time I used this menu after FW installation.
 That is, this problem no one sees?

[Zlotnik]

For me, the shortest time-bases do appear in the menu.
What's weird is that you appear to be at 2ns per div. Does that mean you can access the shortest time bases by turning the vertical scale knob?

I don't mean to be obnoxious, but it would really help if you could describe the circumstances in more detail. I don't know - maybe there's some setting active that limits sample rate and hence the shortest time bases are unavailable?

What happens if you hit "preset"? Do the time bases appear in the menu then?

[MikeP]

 I decided to investigate the problem. To my surprise it was not possible to find the problem.
 Experts read our messages, I hope that my case will be useful.

[seronday]

RTB2004  Horizontal Position adjustment.

I had the use an RTB2004 for a job recently and noticed that at horizontal timebase settings of 40ns/div and faster, the Horizontal Position
control moves in steps of 400ps.
This means that at a setting of 1ns/div, the horizontal position moves in steps of 0.4div., which is very coarse.

I am curious if this is normal for these instruments, or if this particular device has a fault or is there a setting to change this ?

Regards.

[maxspb69]

It's the exactly same for my scope. This is not a malfunction, but a feature of these devices.
Probably because the 10, 5, 2 and 1 ns timebase is an artificial "stretching" of the waveform from 20 ns and has a fixed offset step is 400 ps

[KaneTW]

400ps is 1/2.5GS, so it probably doesn't make a lot of sense to have steps that are less than the sample interval.

[seronday]

maxspb69,   Thanks for confirming this behaviour.

Other DSO's that I have used generally use steps of 0.01 of the time/div setting for the horiz position on all ranges.
( Tek, Agilent, Siglent, Rigol )

I wonder if this was intentional in the RTB2004 or is a mistake in the firmware ?

[maxspb69]

Interestingly, if you record the waveform to REF, then it can be horizontally shifted with a much smaller step. I think that R&S programmers just didn’t bother with a smooth horizontally shift at fast timebase.

[bayjelly]

Yeah, I think so too. For the user, it totally makes sense to have smaller steps than the sample time: They just want to align stuff on the screen.

But for the software, this now likely means that there would be two ways, in two layers, to shift waveforms: The more "hardware" close one that shifts samples, and the "soft" one that shifts representation by smaller units, with potentially some tricky edge cases (beginning and end of the capture buffer), and support throughout the system.

Does not mean that it's not possible or not feasible, just seems that R&S chose not to add that complexity. Might be a good thing if that complexity increased likeliness for bugs, slow down development, and maybe even preclude other features from existing because making them work would now be too complex. But maybe it would be trivial... without knowing the architecture and code in detail, who knows.

[maxspb69]

The FFT function still has significant bug. Display of false harmonics of the SinC signal depending on the start and end frequencies of the displayed bandwith. Does not depend on RBW parameter, only on the selected BW. Same on other channel. A serious problem that does not allow you to trust the "spectrum analyzer" on the RTB2000. Firmware - last 2.300. BW of oscilloscope - 200MHz (Option).
Signal from internal Gen, SinC, 1MHz, 1Vpp. No depend of signal freequency and amplitude. Same on some other waveforms - false harmonics.

Rich, if possible, inform the programmers.

https://youtu.be/zsDhQz4P1ro

[KaneTW]

What window are you using?

[bayjelly]

Yeah, this just sounds like the fundamental problem that Fourier Transforms always have, mathematically? That's why windows exist, and that's why you have to choose windows based on the parameters you care about (there is no single "perfect" window).

If you choose a rectangular window for example, then you effectively convolute your spectrum with the sinc function, leading to significant side lobes:
https://ccrma.stanford.edu/~jos/sasp/Rectangular_Window_Side_Lobes.html

You can choose other windows that reduce the side lobes, but usually at the expense of resolution.

[maxspb69]

It is independent of the window. Any of these: FlatTop, Hanning, Rect etc. gives the same false harmonic result. Each RTB2000 owner can verify this on his own.

For comparison, Siglent SDS2000X+ and Keysight DSO3034 provides an adequate spectrum for all settings and situations.

[bayjelly]

Here's a simple thought experiment that may illustrate intuitively that's going on:

Imagine a continuous signal. Whether it be a simple sinusoid or the sinc function you chose, does not matter very much. Now take a window (i.e. a part) of this waveform, picking your start and end arbitrarily, but pick something where the ends don't taper off, i.e. where the curve is in "mid swing".

Now pretend that the part of the signal you've taken out is not part of a larger signal, but stands on its own, generated exactly like that. Starting and ending abruptly. Since the waveform starts and/or ends in "mid-swing", the first or last data point will be an abstract jump from 0 to wherever the curve starts or ends, with basically infinite slope. But that's a high frequency signal component.

Window functions like Hann, Hamming, Blackman et al help by usually "tapering" the part of the signal you chose at both ends. But this is not perfect. There is no generic perfect solution, unless you capture an infinite signal. Just how you cannot know all frequency components of a signal without sampling it with an infinitesimally small sample size.