Author Topic: new killer scope in town - a true game changer from R&S - RTB2002 & RTB2004  (Read 491354 times)

0 Members and 2 Guests are viewing this topic.

Online maginnovision

  • Super Contributor
  • ***
  • Posts: 1738
  • Country: us
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.
 

Offline stafil

  • Regular Contributor
  • *
  • Posts: 194
  • Country: us
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?
 

Online maginnovision

  • Super Contributor
  • ***
  • Posts: 1738
  • Country: us
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.
« Last Edit: April 21, 2020, 09:24:12 pm by maginnovision »
 
The following users thanked this post: stafil

Offline exe

  • Supporter
  • ****
  • Posts: 1666
  • Country: nl
  • self-educated hobbyist
It also doesn't use linux

Oh, wow, what does it use?
 

Offline Nixfried

  • Contributor
  • Posts: 10
  • Country: de
It also doesn't use linux

Oh, wow, what does it use?

My guess would be FreeRTOS...
 
The following users thanked this post: maginnovision

Online maginnovision

  • Super Contributor
  • ***
  • Posts: 1738
  • Country: us
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.
 

Online Fred27

  • Supporter
  • ****
  • Posts: 619
  • Country: gb
    • Fred's blog
A quick check of the RTM3000 shows FreeRTOS (under Device Information / Open Source Acknowledgement)/
 
The following users thanked this post: exe, maginnovision

Offline egonotto

  • Frequent Contributor
  • **
  • Posts: 296
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
 
The following users thanked this post: exe

Online maginnovision

  • Super Contributor
  • ***
  • Posts: 1738
  • Country: us
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.
 

Offline Minter

  • Contributor
  • Posts: 5
  • Country: us
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 19755
  • Country: nl
    • NCT Developments
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?
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 2638
  • Country: hr
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..
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 19755
  • Country: nl
    • NCT Developments
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Minter

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 2638
  • Country: hr
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...
 

Offline Minter

  • Contributor
  • Posts: 5
  • Country: us
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.
« Last Edit: April 27, 2020, 10:32:43 am by Minter »
 
The following users thanked this post: EEVblog, Someone, egonotto, skench, 2N3055, thinkfat

Offline Someone

  • Super Contributor
  • ***
  • Posts: 2467
  • Country: au
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.
 

Offline porker1972

  • Contributor
  • Posts: 21
  • Country: gb
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.  :wtf:

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

Offline porker1972

  • Contributor
  • Posts: 21
  • Country: gb
..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.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31414
  • Country: au
    • 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.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12135
  • Country: gb
    • Mike's Electric Stuff
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
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline thinkfat

  • Supporter
  • ****
  • Posts: 1076
  • Country: de
    • Matthias' Hackerst├╝bchen
/* this boolean can be true, false, or -1 */
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 19755
  • Country: nl
    • NCT Developments
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.
« Last Edit: May 22, 2020, 02:02:50 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Bics

  • Newbie
  • Posts: 2
  • Country: ca
Greetings All,

Just thought I'd share my recent service experience with Rohde & Schwarz when my RTB2004 suddenly died earlier this month. I've had the scope a little over a year and have been very happy with it's performance and functionality. A couple weeks ago I sat down at the bench and booted everything up to do a bit of work. After about 15 minutes, I happened to look over at the RTB scope and saw it was reporting a temperature sensor error. This was a first as I'd never had an error message pop up before. The scope sits on its own corner of the bench with lots of breathing room and I had nothing connected to any of the channels at the time, so I was really puzzled. I clicked through the error and when I connected a probe, I was unable to obtain a trace on any of the 4 channels. I gave it a power cycle and on boot-up was presented with a number of error messages, all related to a failed FPGA configuration. Really strange. The scope's operating system seemed fine so I tried reflashing the firmware, which went well, but the fault condition persisted. At that point I decided to contact R&S to see what my options were. I was happy when I found that I was 15 months into the 3 year warranty, and was hopeful this repair would be covered.

I've been a bit spoiled as Keysight has a service depot located in my home city of Calgary, so when there was a factory recall for my Keysight bench power supply, I was able to drive over to their shop and hand the unit directly to a technician. Although R&S does have a Canadian presence in Ottawa, I soon found out that I would be dealing with their facility in Maryland, USA. Overall, I was very pleased with my dealings with R&S throughout the repair process. They were very responsive in their email communications, which was nice. They arranged for prepaid FedEx shipping to their Maryland shop and total turnaround time was about 2 weeks. They replaced the entire scope with a new unit, which they calibrated before it left Maryland and included a full calibration report. There was no indication in the service report as to what the cause of the fault was, only that they were able to recreate the fault and were issuing a replacement unit. I really hope this was an isolated "one-off" failure. As a hobbyist, this scope was a major purchase for me and I'd like to get many years service from it. So in closing, 2 thumbs up to Rohde & Schwarz for standing behind their product and getting my scope back up and running. 
 
The following users thanked this post: edavid, BU508A, bayjelly, JxR

Offline KaneTW

  • Frequent Contributor
  • **
  • Posts: 446
  • Country: de
Speaking of---Rich, any idea when the next firmware update is coming? I reckon stuff got delayed a lot by COVID measures.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf