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

[maginnovision]

I actually keep being tempted to get the RTA deal but I keep talking myself out of it at the same time. It's a good deal and has good noise specs even at full bandwidth which would be useful for me. The RTM isn't much cheaper for the deal right now. I believe SOMEONE was selling an RTB, I think a launch unit, for a decent price. Check the B/S/W section.

[stafil]

It's unfortunate that no hack exists but I'm not regretting my RTB-COM4 purchase, except maybe that I should've gotten a RTM.

Is it because nobody bothered, or did R&S kindly ask not to?

[maginnovision]

I think nobody bothered. The first of us who bought them got the launch bundle for 2k anyway which included anything. People buying them now take into consideration the price and features so usually aren't looking to hack it. It also doesn't use linux like most of the hacked scopes so it may not be as easy since there may not be as many people as familiar with the system.

EDIT:

https://www.eevblog.com/forum/buysellwanted/fully-loaded-rohde-schwarz-rtb2004-com-4-300-mhz-4-ch-all-options-inc-bode/

Here is the FS link. Damn near launch bundle pricing.

[exe]

It also doesn't use linux

Oh, wow, what does it use?

[Nixfried]

It also doesn't use linux

Oh, wow, what does it use?

My guess would be FreeRTOS...

[maginnovision]

Yea. It's some RTOS variant which is why it's so quick to boot. I'm sure the licensing files would shed some light on that.

[Fred27]

A quick check of the RTM3000 shows FreeRTOS (under Device Information / Open Source Acknowledgement)/

[egonotto]

Hello,

maginnovision wrote:

"
... and has good noise specs even at full bandwidth which would be useful for me
"

This is correct for the sensitive range.

But look for 1GHz and 1V/div:
RTA4004:                50Ohm 31.4 mV  1MOhm 45.6 mV (only 500MHz)(10 divs overall)
Infiniium S-Series:    50Ohm 6.8 mV
Tektronix MSO64:     50Ohm 10.8 mV
lecroy HDO6104A:    50Ohm 4.90 mV

Best regards
egonotto

[maginnovision]

Yes, it's not perfect but for my low noise measurements I would need low level measurements, far from 1V/div. I'd have to build/buy a new amplifier to get the levels that high.

[Minter]

Another logic analyzer-related annoyance - very short pulses have a tendency to disappear and reappear from view when scrubbing the horizontal axis. Any state changes should be a minimum of 1 pixel width regardless of zoom level, otherwise it's very easy to miss important events. I attached an animated gif showing the issue with pulses on D2 and D3 as I adjust the horizontal position.

[nctnico]

Another logic analyzer-related annoyance - very short pulses have a tendency to disappear and reappear from view when scrubbing the horizontal axis. Any state changes should be a minimum of 1 pixel width regardless of zoom level, otherwise it's very easy to miss important events. I attached an animated gif showing the issue with pulses on D2 and D3 as I adjust the horizontal position.

What happens if you set the acquisition mode to peak-detect?

[2N3055]

Another logic analyzer-related annoyance - very short pulses have a tendency to disappear and reappear from view when scrubbing the horizontal axis. Any state changes should be a minimum of 1 pixel width regardless of zoom level, otherwise it's very easy to miss important events. I attached an animated gif showing the issue with pulses on D2 and D3 as I adjust the horizontal position.

What happens if you set the acquisition mode to peak-detect?

Peak detect shouldn't have influence on digital channels..

[nctnico]

Another logic analyzer-related annoyance - very short pulses have a tendency to disappear and reappear from view when scrubbing the horizontal axis. Any state changes should be a minimum of 1 pixel width regardless of zoom level, otherwise it's very easy to miss important events. I attached an animated gif showing the issue with pulses on D2 and D3 as I adjust the horizontal position.

What happens if you set the acquisition mode to peak-detect?

Peak detect shouldn't have influence on digital channels..

Why not? I can't test it right now but I'd say a proper MSO implementation also has peak detect on the digital channels. After all peak-detect records the extremes within one sample interval and there is no reason why this can't apply to digital channels.

[2N3055]

Another logic analyzer-related annoyance - very short pulses have a tendency to disappear and reappear from view when scrubbing the horizontal axis. Any state changes should be a minimum of 1 pixel width regardless of zoom level, otherwise it's very easy to miss important events. I attached an animated gif showing the issue with pulses on D2 and D3 as I adjust the horizontal position.

What happens if you set the acquisition mode to peak-detect?

Peak detect shouldn't have influence on digital channels..

Why not? I can't test it right now but I'd say a proper MSO implementation also has peak detect on the digital channels. After all peak-detect records the extremes within one sample interval and there is no reason why this can't apply to digital channels.

I'm not saying it can't be made or that it is a bad idea. I'm just saying that peak detect setting in acquisition mode seems to be analog only related. If you check on your RTM3000 that would be very interesting information...

[Minter]

I wanted to respond to confirm that not only does peak-detect mode affect how the digital channels are acquired, it affects how the current contents of the digital channels in acquisition memory are displayed.

The pulses I'm looking at are roughly 100ns in duration, so while short in comparison to my buffer length (20MS) they are still long compared to my acquisition rate (62.5Msps, 16ns sample period). As a result the pulses are always detected and present in acquisition memory regardless of the selected acquisition mode. They're just not always visible in the traces when zoomed out.

However, if for example I acquire some data in single-sample mode, stop the acquisition and then select peak-detect mode, the missing pulses appear in all my trace data. Additionally, if I drop the acquisition sample rate down to something like 1MHz I can still detect every 100ns pulse using peak-detect mode.

While IMO the digital traces should follow the convention of most other logic analyzers I've encountered and enforce a minimum width for state transitions, switching to peak-detect mode works, even on previously acquired data.

[Someone]

The pulses I'm looking at are roughly 100ns in duration, so while short in comparison to my buffer length (20MS) they are still long compared to my acquisition rate (62.5Msps, 16ns sample period). As a result the pulses are always detected and present in acquisition memory regardless of the selected acquisition mode. They're just not always visible in the traces when zoomed out.

There is something odd with the waveform rendering, your example gif had similar short transients coming and going from the analog trace too. An effective anti-aliasing method shouldn't do that.

[porker1972]

R&S decimate the acquisition memory that gets displayed, probably to try and improve waveform update rate.
If you have a glitch, even if you have 20M points of memory, you won't see it. Looking for a pulse stream? You won't see it.
So while the sample rate remains at 10Gs/Sec or whatever, what you see is the waveform sampled at 10MS/Sec. 

Now here's me thinking a scope is a tool to look at a signal.... 

[porker1972]

..but MSO channels are just 1 bit, so by definition is peak detect. You won't get amplitude info, only 1 or 0 as set by the logic threshold.

[EEVblog]

I wanted to respond to confirm that not only does peak-detect mode affect how the digital channels are acquired, it affects how the current contents of the digital channels in acquisition memory are displayed.

I'm amazed that peak detect would have any effect on the digital channels.

[mikeselectricstuff]

I wanted to respond to confirm that not only does peak-detect mode affect how the digital channels are acquired, it affects how the current contents of the digital channels in acquisition memory are displayed.

I'm amazed that peak detect would have any effect on the digital channels.

Seems reasonable - normal mode samples on each time interval and shows either high or low, peak mode samples at the highest rate and shows high, low, or a mixture of both

[thinkfat]

/* this boolean can be true, false, or -1 */

[nctnico]

I wanted to respond to confirm that not only does peak-detect mode affect how the digital channels are acquired, it affects how the current contents of the digital channels in acquisition memory are displayed.

I'm amazed that peak detect would have any effect on the digital channels.

Seems reasonable - normal mode samples on each time interval and shows either high or low, peak mode samples at the highest rate and shows high, low, or a mixture of both

Indeed! R&S just followed the definition of peak-detect for displaying 'digital' signals too and that isn't wrong. From a functional point of view a digital channel is sampled using 2 discrete states instead of 1024 (or more/less depending on the ADC) but it still is a signal.

[KaneTW]

Speaking of---Rich, any idea when the next firmware update is coming? I reckon stuff got delayed a lot by COVID measures.

[Kittel99]

Yesterday I asked in Munich for a new firmware release date for RTB2004 and today I got a fast response from the customer support center:
It was planned to give a new release in 2. quarter, but due to pandemic it is shifted now to autumn.

Best regards

[maximevince]

I'll take the opportunity to plug a request again,

An event A followed by an event B trigger, channel and pattern. Maybe the same or related to the edge A/B request below.

Thanks Rich,

Joel

Hi all,


- new Trigger types: Runt, Rise time, Edge A/B
  (here I contacted already R+S Munich and I have got a feedback: reserved for RTB3000...
   sorry, but all other 400,-€ scopes can do this...)

Thanks.  I'll make sure Munich hears this again. 

And just an update on the next RTB2000 firmware.  No firm date, but one is in progress.  As I get more details I'll post them up.

-Rich

Hi Rich, any update on the new firmware?
The latest one on the website ( www.rohde-schwarz.com/firmware/rtb2000 ) is still indicating:
R&S®RTB2000 Firmware Version 02.202    46 MB    02.202    04-Dec-2018

Thanks for any updates!