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

[goaty]

I have tested again, this time with the Rigol DG4000 as signal source. Now the normal history mode works as well. Each of the 21 data packets is recorded. The Peak Detect mode is slower, one should also consider.
I will test again with the internal pattern generator.
Peter

Is it really possible that the delta time is always exactly the same to the last nanosecond ? This looks very strange to me.
(RTB2004-PulseBurst-1-21-Sample.png)

[2N3055]

I have tested again, this time with the Rigol DG4000 as signal source. Now the normal history mode works as well. Each of the 21 data packets is recorded. The Peak Detect mode is slower, one should also consider.
I will test again with the internal pattern generator.
Peter

Is it really possible that the delta time is always exactly the same to the last nanosecond ? This looks very strange to me.
(RTB2004-PulseBurst-1-21-Sample.png)

Delta time is probably rounded up to sample rate at the time.
10,620224 ms is exactly 26,55055E6 cycles of 2,5GHz sampling clock, for instance..

But it is not all the same, there are 224, 217, 337 as last 3 decimal places..

And even that jitter is probably from AWG, not scope.
In Fast Sequence mode it should be very deterministic..

[goaty]

Because of the trigger re-arm uncertainty I´m getting a bit suspicious about what the scope software is showing me.
I rember the DS1054Z showing a trigger delay of 10.00000000456ps or so.

[2N3055]

Because of the trigger re-arm uncertainty I´m getting a bit suspicious about what the scope software is showing me.
I rember the DS1054Z showing a trigger delay of 10.00000000456ps or so.

Well, your suspicions should go in other direction..  456 *10e-23 sec is a nonsensical precision....
Trigger rearm to ready time is separate form internal time base. Scope is showing exactly what time it was between triggers. It knows. It is simply not ready to get another sample at all times in exactly same interval. That is true for all scopes..

[goaty]

And I think I understood another thing now.

R&S have the Single button in Trigger, but it really is single acquisition, not single trigger.

On DS1054Z, I pressed Single, it was single trigger regardless whether before Auto or Manual was chosen.

Makes sense now, but is slightly different behaviour.

As you said, I really should study the manual more in depth.

Trigger rearm to ready time is separate form internal time base. Scope is showing exactly what time it was between triggers. It knows. It is simply not ready to get another sample at all times in exactly same interval. That is true for all scopes..

I know the scope knows, but that is not the point. The point is that I need to know the time it _will_ need in order to decide if I need Fast Segmentation or not.
If I have no idea, how long the time is before next trigger is possible, how can history be of any use ? Only and only with very long times between trigger (>100ms) or use Fast Segmentation.
Still not quite convinced this is a optimal implementation.

[2N3055]

And I think I understood another thing now.

R&S have the Single button in Trigger, but it really is single acquisition, not single trigger.

On DS1054Z, I pressed Single, it was single trigger regardless whether before Auto or Manual was chosen.

Makes sense now, but is slightly different behaviour.

As you said, I really should study the manual more in depth.

Trigger rearm to ready time is separate form internal time base. Scope is showing exactly what time it was between triggers. It knows. It is simply not ready to get another sample at all times in exactly same interval. That is true for all scopes..

I know the scope knows, but that is not the point. The point is that I need to know the time it _will_ need in order to decide if I need Fast Segmentation or not.
If I have no idea, how long the time is before next trigger is possible, how can history be of any use ? Only and only with very long times between trigger (>100ms) or use Fast Segmentation.
Still not quite convinced this is a optimal implementation.

I don't remember how DS1000Z does it, but most other scopes will wait in Single for trigger. On new Siglents you can press Single twice to force trigger (they are missing Force Trigger button).

History is just that, history of previous triggers, as they where, with no determinism. If you need deterministic retrigger time, you need to use Fast mode. That is just it..

RTB 2000 is not a scope that is fastest in that regard. It has other pluses though. There will always be compromises.. Even with 100k USD scopes...

[goaty]

There is another thing I´ve noticed:
When I have a 3MHz squarewave and switch from 20ns/div to 40ns/div,
after a second or so, the waveform update rate goes up to more than 50000 waveforms/s,
but gets smoothed and one does not see it jiggle around anymore.

First with 20ns does show noise on squarewave.
Here waveform update is slow (150Hz)


Second at 40ns/div shortly shows noise as before, but then a second or so it´s gone.
Update rate shows 56000 on external counter.



All very fishy

[goaty]

Ah, my fault, 5Mhz it is.

I swear I had 0,150kHz on the PM6622 counter.
Just tried it again and now cannot reproduce.

I´ll try again after the weekend.

Thank you PeDre and 2N3055 for your patience !

[goaty]

Has anyone ever got a reply or solution for the strangely low waveform update rates as described in this post ?

https://www.eevblog.com/forum/testgear/new-killer-scope-a-true-game-changer-from-rs-rtb2002-rtb2004/msg1405398/#msg1405398

I´m seeing the same problem.
The roughly expected update rate in the 20us to 200us/div range - about 2kHz to 200Hz - is not reached.

I love the scope, but I need to find out what I´m doing wrong.

[goaty]

Excellent idea with the pulses, so one can verify it did not miss one. Thank you very much for trying that out.
As I said, I have not been able to achieve this with 10ms distance at 200us/div.

Probably I´ll contact R&S for a repair, because I see no other reason why it is not working for me.

Ah, can you maby post the hardware revision of the mainboard of yours. Maby there´s a change.
My RTB2004 was purchased in 12/2020.

Oh, and the pulses are generated from the internal generator ?

[goaty]

For me, it´s currently the main use of the scope decoding serial data, where segmentation is really useful.
It worked perfectly with the Rigol 1054Z, only it could not decode the data (only the data when not segmenting).
So I was happy to find the R&S can decode the history (if enabled before capture, not afterwards).
But now I´m having trouble with the missing triggers.
Maby I´ll try the Siglent some time and sell the R&S.


Device Information is unter Setup and has hardware information as well.

[goaty]

Man I really appreciate the help you provide because this scope is so full of bugs...

Just tried to restore the squarewave for the probe cal after arbitrary. Switch to square, set 10kHz, but it does not reset the period of 120ms. Gawd.


Also, it does never ever record the 21 pulse sequences, when I do a single run of the pattern gen.

Tried on ch1 instead of ch4, no difference.


Set pat gen to 1x

[goaty]

I have observed the trigger out with another oscilloscope and I have noticed errors.
Immediately after starting a recording there are gaps in the trigger. Only after a short time is triggered on each packet. Of course this can become a problem.

This is exactly my problem. I tried a full factory reset, re-flashed the 2.300 firmware and did a full self-calibration, but that does not change anything.
I guess the Software and FPGA design in there is not fully asynchrounous and introduces some blockage when first triggers hit in Norm-Mode.
I really hope there´s room for improvment.

[goaty]

Excellent test, thank you again PeDre.
Yes, your arguments are correct. I was just stumbling upon just this problem on basically first measurements I was doing,
so you may forgive me being a bit annoyed first.

I have made a ticket with R&S, but I doubt there will be a solution or update anytime soon (or ever).

[bayjelly]

With the Logic Analyzer option (RTB-B1), does anyone know how the digital channels factor in with the memory depth? The RTB2000 datasheet found here says the following about memory depth in general:

10 Msample memory depth is available on each channel if all channels are active. When interleaved, 20 Msample are available.

I was not actually aware that the 10Msample would be per channel, but it now also makes sense why it's 20Msamples when interleaved: You get the memory of two channels for the interleaved channel.

But what does that mean for the digital channels? I would be surprised if it's also 10 Msamples per each of the digital channels, for 16 channels that would be a lot of unused memory otherwise, or does it? (Although not that much more: Assuming that the scope (hopefully) only saves a bit per sample of a digital channel, all channels together would use 16 bits per sample, which is just 1.6 times the cost of a 10 bit analog channel.)

Is it dependent of how many analog channels are enabled, i.e. you get to use memory that would otherwise be used by the other analog channels? If so, what happens if all analog channels are enabled (or two are enabled interleaved)? Finally, is there potentially also some compression (e.g. long strings of zeroes or ones are saved in an efficient manner)?

EDIT: The datasheet reminds me that with the segmented memory option (that I have), the total sample memory is 160 Msamples, albeit still with 10 Msamples per capture (i.e. segment). I guess this means it would not be too surprising if extra memory for 10 million 16bit samples is available, at the cost of fewer segments maybe, but the datasheet seems to make no mention either way of that. Maybe someone with RTB-B1 can experiment?

[bayjelly]

That's great, thanks Peter. So essentially, it's always 10 Msamples, unless interleaving can be applied, then it's 20 Msamples.

The only thing I'm missing now is what happens when 1+2+3+4 and both pods are enabled. Or is that not possible at all? Though the list also does not have 1+2+3+4 by itself, so it could just be an omission.

But it seems like I'll have at least 10 Msamples in most situations that matter for me already, so I ordered my RTB-B1.

[bayjelly]

I now also found this "fact sheet": https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_common_library/dl_brochures_and_datasheets/pdf_1/Option_sheet_-_RTx-B1_mixed_signal_analysis_v1.10.pdf

It says there is "no consumption of analog channels", and that the memory depth is "10 Msample". This contradicts the 20 Msamples table entries for when only analog channels 1 or 1+3 are active (probably just understating the capabilities), but it does also further suggest that all 4 analog channels can be enabled with any number of digital channels, and that there will always be at least 10 Msamples for all of those. On some signals, I might be able to reach up to 160 Msamples total with the proper triggers and fast segmentation.

There is also no indication of any compression scheme that would allow longer capture of sparse signals, like e.g. Saleae logic analyzers tend to have (those are just streaming to a computer, so it's pretty much up to the computer to store it however it sees fit). So if the signal is really sparse, you might waste a lot of capture memory, as I don't think variable segment lengths are a thing either?

Well, once the probes arrive, I will just try it out and set the record straight once and for all...

[nctnico]

MSOs don't have compression like most logic analysers. The reason is that compression won't work for analog signals AND you will need extra memory for timestamps. Compression doesn't fit in the memory model of a DSO.

[bayjelly]

I don’t think it’s impossible (or extremely hard) to implement for the digital channels only in an FPGA, without waste of memory even. You’d capture non-sparse by default, but once the number of running zeros or ones exceeds the length of two timestamp plus a sentinel value, you instead[1] emit that sentinel value to indicate that sparse capture is happening now, followed by the current timestamp, and then a second timestamp once the value changes again.

That seems like a simple enough state machine. But it’s also more to handle in software and testing, including wrt history mode, data export and so on. So I think it’s probably those second order implementation costs that made R&S not implement it, not concerns about feasibility and memory usage.

EDIT: But I made a lot of assumptions about FPGAs being in the right path here, and how much they do. If ASICs are doing the capture instead, or there are ASICs which require certain memory layouts, then they would need to support that, too.

[1] For a simpler implementation, don't buffer at all before emitting but just switch to sparse mode at some more arbitrary run length. While you can get unlucky and use more memory with that alternative scheme, you'll still save memory for signals that are "sparse enough".

[nctnico]

I don’t think it’s impossible (or extremely hard) to implement for the digital channels only in an FPGA, without waste of memory even. You’d capture non-sparse by default, but once the number of running zeros or ones exceeds the length of two timestamp plus a sentinel value, you instead[1] emit that sentinel value to indicate that sparse capture is happening now, followed by the current timestamp, and then a second timestamp once the value changes again.

Capturing the data is 1% of the complexity of a modern DSO. There is so much else at play that supporting compression will make the system as a whole extremely complex.

[bayjelly]

That's what I said: It's not the extra memory for timestamps, or that it would not apply to analog signals, but the implementation cost of supporting that scheme downstream of the capture. I think it's debatable how complex the system really would get if you set your mind to design it with compression for digital channels from the start, but I'm not surprised nor terribly disappointed that DSOs usually don't do it.

[egonotto]

I now also found this "fact sheet": https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_common_library/dl_brochures_and_datasheets/pdf_1/Option_sheet_-_RTx-B1_mixed_signal_analysis_v1.10.pdf

It says there is "no consumption of analog channels", and that the memory depth is "10 Msample". This contradicts the 20 Msamples table entries for when only analog channels 1 or 1+3 are active (probably just understating the capabilities), but it does also further suggest that all 4 analog channels can be enabled with any number of digital channels, and that there will always be at least 10 Msamples for all of those. On some signals, I might be able to reach up to 160 Msamples total with the proper triggers and fast segmentation.

Hello,

I believe that in the document is a error.
Memory depth (one logic probe) 10 Msample
is perhaps wrong. It should be 20MS.

Furthermore I believe that R&S dont't exhaust in RTB, RTM and RTA all the potential of the hardware.

Sometimes high resolution is not possible.

Best regards
egonotto

 

[kcbrown]

MSOs don't have compression like most logic analysers. The reason is that compression won't work for analog signals AND you will need extra memory for timestamps. Compression doesn't fit in the memory model of a DSO.

Well, it would if it were fast enough.  But that's the problem: it has to be fast enough to keep up with the sampling rate (end to end, for anything that otherwise already is able to keep up with that).  And memory is cheap enough that it's just not worth it.  By the time you've spent the money to get yourself enough additional processing power, you've probably more than paid for enough additional memory to negate the advantages.   Not to mention that it makes the amount of data you can safely store unpredictable, since data compressibility varies with things like the randomness of the data.

And you'd have to decompress for any operation you might want to perform against the capture.  Again, you could make up for that with sufficient additional CPU horsepower, but there's not much point to it if you can just add RAM for roughly the same cost (less cost in the end, I'd wager, since there'd be less in the way of development costs to add RAM).

[analogRF]

I recently bought a RTB2004 300MHz and I truly love this thing  . Hands down "the" best user experience among the many scopes that I have had. The dynamic range of this thing in High Res mode is unbeatable I guess with any other scope in this range/class and it shows specially in FFT app.
However (that doesn't sound good! ) today I discovered something odd. The scope emits bursts of 213kHz pulses that you can easily catch with a simple small antenna on an spectrum analyzer and also on the scope itself.
If I dont attach anything to the ports, there is absolutely nothing on channels down to 1mV/div, Very clean and low noise (better than my Keysight 3000A as expected). But as soon as I connect a small 20-30cm antenna to the scope, I can easily catch the bursts of pulses emitting from the LCD display even at 50mV/div (see the pictures). I can also catch them on my Keysight 3000A with a magnetic loop and also on SA.

I have done some tests and I know for sure the pulses are coming from the LCD display. In the pictures you also see that when I turn the antenna away from screen they become much smaller
I also noticed that if I put my finger somewhere on the screen, the pulse train becomes continuous instead of bursts.

I dont think this is a defect in my scope. I was hoping someone else could experiment and see if this is a general issue.

[analogRF]

the bursts are about 5msec long but every now and then there is a very long one (see the picture in the previous post)

I wonder how this could pass EMC/EMI compliance tests?