R&S RTM3004 The Swiss-Knife-Oscilloscope

[KlausF]

I use firmware 1.5 and I do have the Autoset bug. It is definitely not fixed.
I also could reproduce most of the other bugs with firmware 1.5.

Please follow Dave´s advice and argue with facts not with feelings.

[BU508A]

I use firmware 1.5 and I do have the Autoset bug. It is definitely not fixed.
I also could reproduce most of the other bugs with firmware 1.5.

Please follow Dave´s advice and argue with facts not with feelings.

Could you provide any screenshots, please?

[nctnico]

Even better: a step by step guide on how to reproduce. Amongst others I think the people at R&S will be keen to know this.

[KlausF]

R&S is reading and responding to the mikrocontroller.net discussion and already knows about the videos.
There is no need for you to call R&S and tell them about bugs revealed in these Youtube review.


Wanted to make a screenshot today, but the follow up video with firmware 1.5 was faster than me.
My RTM does the same.

Video is a comparison between Fw v.1.3 and v.1.5.





Bye for now, greetings from holiday   

[nctnico]

I can't reproduce the autoset bug shown in the video on the RTM3004 I have here. I tried all the acquisition modes, pressed the autoset button dozens of times but it works perfectly every time. Perhaps the BNC cable used for the test is faulty, try change the oscilloscope language to English, hit preset to set everything to default or the update didn't work? I can't think of anything else what could cause this.

[Herbertl]

 



I m much surprised.

[lem_ix]

Hi all,

Does the RTM3000 have only LF probe compensation or HF as well? The probe compensation window only allows the selection of probe channel, displays how to do LF comp, there's no arrow to switch to HF as I saw on some RTB2000 video. Signal doesn't seem to change when changing the time base either ( was that way on Hameg if i remember correctly).

Additional note in case someone from R&S is reading: I didn't seem to notice ampere seconds (there was A/s) in the units window, while it's not a big deal it would be nice when integrating current waveforms.

[Herbertl]

Really ? Improved ? Maybe it means it was better with old firmware   

 





 

I am surprised more and more.

[phase90]

Rich,
Why is it that the spectrum analysis (RTM-K18, or RTA-K18) is not available in North America?

[boeserbaer]

Hi All,

I just purchased a new RTM3004com4 package.  I have been testing the scope under some of my use cases, and I am finding that there is either a problem with my scope, or a bug in the position mode (looking at either pre-trigger memory, or post trigger)  I have attached a pair of screen shots to show the issue.   

I can work with this "bug" if it is not indicative of a PLL problem on my unit, and hope that a FW update fixes it, otherwise, I have the hassle of returning the unit.

My FW version is 1.550

Steps to duplicate:
1. input a stable frequency, and set up trigger.  In this case it is the 10MHz out of my spectrum analyzer. 
2. Adjust the display position (second row from top second to last setting) to 500 us.
3. select infinite persistence.
4. hit run/stop to stop acquiring.
5. hit run/stop to re-start.    this should look like "after_run_stop.png".
    this looks like PLL or math to calculate which samples to display is off.  I would guess PLL.   
6.  Now hit clear screen, sometimes twice is required.   this should look like "after_clear_screen.png"

Do other RTM 3004s have this issue?  Does my unit have a HW problem?

--mike

[boeserbaer]

Further testing of the Spectrum Analyzer mode, seems to point even more to bad HW, but why would hitting clear screen in scope mode clean things up?  Here I have 10MHz 250mV p-p sine wave from dg4062 going to the scope high impedance, tee'd to the SSA3021X.  The results are attached.  I added a third screen shot showing the current state of the FFT from the RTM3004, indicating that sometimes all is OK.

It is possible that the periodic problems in the FFT are due to the FFT being fed discontinuous data occasionally, or it could be that the PLL on the RTM3004 is acting up. 

I paid the premium for the R&S scope for three reasons:

1.  I need an instrument I trust,  I can make most of the measurements I need on my hacked Rigol MSO2302 (2072 -> 2302) combined with the Siglent SSA3021X (again hacked to SSA3032X).  I am designing  4 GSPS ADC boards with single digit ps level time stamping.  I use the scope and spectrum analyzer to study jitter, and of course the scope is generally used as a scope.

2.  I hate noisy (as in fan noise) instruments.  The R&S is quiet.

3. I wanted a made in the EU or USA instrument.

I really like the features, and the UI of the RTM3004, but I am not yet finding that I can get reliable measurements in the area of  interest.  Again my question is, is my unit faulty?

-- mike



 

[nctnico]

Did you try a different cable yet? You could be looking at a cabling problem. If the problem is in the scope then I'd expect it to be always wrong or at least wrong at periodic intervals.

Besides that I don't think you will be able to resolve very low jitter with the RTM3004. It is a nice general purpose scope but  the trigger jitter isn't that good. If you want to get into ps level jitter you'll need a different instrument (a phase noise analyser).

[boeserbaer]

Hi Thanks for the reply.  BTW I sent a e-mail trying to buy some of your diff probes.  I have tried other cables, and have yet to get the instrument into a single behavior mode. I.e.  always good, or always bad.   In reply #184, I showed the jitter far from the trigger.  The first figure very repeatably presents after either run/stop or trigger threshold adjustment.  The extreme jitter is not just present at the change, but continues until clear screen.  Cabling could be the cause on the spectrum results, but gently shaking the cables when in the "good" mode does not seem to influence the measurement. 

The fixed frequency check I alluded to in #184 is easy to make (not valid if using the internal signal generator), reliably fails, and I am hoping someone can verify whether it works or not on their scope.

-- mike

[maginnovision]

If you could get one on loan the 4000 has ±0.5/1.0 ppm timebase.

[nctnico]

Hi All,

I just purchased a new RTM3004com4 package.  I have been testing the scope under some of my use cases, and I am finding that there is either a problem with my scope, or a bug in the position mode (looking at either pre-trigger memory, or post trigger)  I have attached a pair of screen shots to show the issue.   

I can work with this "bug" if it is not indicative of a PLL problem on my unit, and hope that a FW update fixes it, otherwise, I have the hassle of returning the unit.

My FW version is 1.550

Steps to duplicate:
1. input a stable frequency, and set up trigger.  In this case it is the 10MHz out of my spectrum analyzer. 
2. Adjust the display position (second row from top second to last setting) to 500 us.
3. select infinite persistence.
4. hit run/stop to stop acquiring.
5. hit run/stop to re-start.    this should look like "after_run_stop.png".
    this looks like PLL or math to calculate which samples to display is off.  I would guess PLL.   
6.  Now hit clear screen, sometimes twice is required.   this should look like "after_clear_screen.png"

Do other RTM 3004s have this issue?  Does my unit have a HW problem?

I have just tried it using the output of a GPDSO and I get similar effects on the RTM3004 I have here (with firmware 1.501) when I follow your steps. Seems like a bug to me.

Edit: pressing the 'Auto norm' button seem to clear the problem.

[egonotto]

Hi,

I tried it similar with the RTA4004.

The generator is a picoscope 5243A (200MHz DDS) with 10MHz square.

The 5ns is the picoscope 5243A generator.

I don't know if the other jitter is from the generator or from scope.

But the Agilent DSO6104L shows it similar.

Best regards
egonotto

[2N3055]

Hi,

I tried it similar with the RTA4004.

The generator is a picoscope 5243A (200MHz DDS) with 10MHz square.

The 5ns is the picoscope 5243A generator.

I don't know if the other jitter is from the generator or from scope.

But the Agilent DSO6104L shows it similar.

Best regards
egonotto

Is scope side 50 Ohm terminated for these captures?

[nctnico]

A DDS based generator usually has a few ns of jitter so the jitter shown is definitely the generator.

[Fred27]

Why is it that the spectrum analysis (RTM-K18, or RTA-K18) is not available in North America?

When I dug into this it seemed to be down to a patent. Whilst a version for NA that didn't fall foul of the patent was mentioned, it's been long enough that I think we can assume it isn't being worked on.

[egonotto]

Hello,

@2N3055: No it was 1 MOhm.

Another thing I wonder. The RTM3000 and RTA4004 have low noise in 1mV range compared to other scopes.

But perhaps in 1V range the picture change dramatic.

All in 50 Ohm and 1 GHz:

                             1mV/div        1V/div

RTA4004                 0.11mV         31.4mV
HDO6104A             0.145mV         4.9mV
Tektronix MSO44    0.260mV        13.0mV

Best regards
egonotto

[nctnico]

That is because the noise of the ADC is multiplied by the input attenuator setting. If you select 10V/div (or higher) you'll likely see another increase. However relative to the maximum amplitude of the signal the noise stays -more or less- the same. There will be differences between various oscilloscopes due to a different attenuator setup / ratios.

[Performa01]

Another thing I wonder. The RTM3000 and RTA4004 have low noise in 1mV range compared to other scopes.

But perhaps in 1V range the picture change dramatic.

All in 50 Ohm and 1 GHz:

                             1mV/div        1V/div

RTA4004                 0.11mV         31.4mV
HDO6104A             0.145mV         4.9mV
Tektronix MSO44    0.260mV        13.0mV
 

With an ideal noise-free frontend, the measured noise comes from the ADC (and subsequent signal processing) exclusively and will be strictly proportional to the V/div setting, no matter how the various input gains are implemented (PGA/Attenuator).
At 1V/div you will measure ten times more noise than with 100mV/div for example.

Any real frontend will exhibit some base noise, hence there is a lower limit. In case of the RTA4004 you should get 31.4µV noise at 1mV/div in theory, but the frontend noise takes over and it’s actually 110µV. I’d expect the noise will not change much up to 3.5mV/div and then start rising with the V/div number.

What you see here is essentially the different quality of the individual ADCs:

LeCroy HDO6104A is 12 bit and only 4.9mV noise at 1V/div, which is equivalent to about 2.5 LSB.
Tek MSO44 is also 12 bit, but its 13.0mV noise is more like 6.5 LSB.
R&S RTA4004 is 10 bit and 31.4mV is roughly equivalent to 3.75 LSB, which would be equivalent to 15 LSB for a 12 bit ADC.

Now draw your conclusions. Assuming your tests are correct, the HDO6104A sets the benchmark and the MSO44 misses that by quite a margin, but is still better than the 10 bit RTA4004.
You can also look at it this way: if the HDO6104A was restricted to 10 bits, its noise would be only 0.625 LSB (1.62 LSB for the MSO44).

Just as a comparison, the 8 bit ADC in the Siglent SDS5104X exhibits 18.9mV noise at 1V/div and 1GHz bandwidth (1Mpts, 5GSa/s), which is just 0.6 LSB.

This is also where the ENOB discussion comes from. With a high advertised number of bits for the ADC you certainly get more data, but it does not tell much about how useful the additional data actually are.

[nctnico]

Actually it is more complicated than that. Measuring noise at a high bandwidth like 1GHz is useless. The jitter of the sample clock will contribute a lot to the noise when using an ADC with >8 bits so these tests are best done with the 20MHz bandwidth limiter on and while going through all the attenuator settings.

[Performa01]

Actually it is more complicated than that. Measuring noise at a high bandwidth like 1GHz is useless. The jitter of the sample clock will contribute a lot to the noise when using an ADC with >8 bits so these tests are best done with the 20MHz bandwidth limiter on and while going through all the attenuator settings.

Sample clock jitter is certainly an additional source of noise when acquiring high frequency signals - and this would warrant a dedicated test.

Sample clock jitter is irrelevant for DC signal acquistion. Measuring the base noise of an acquisition system is equivalent to measuring a zero (DC) signal.

[nctnico]

Actually it is more complicated than that. Measuring noise at a high bandwidth like 1GHz is useless. The jitter of the sample clock will contribute a lot to the noise when using an ADC with >8 bits so these tests are best done with the 20MHz bandwidth limiter on and while going through all the attenuator settings.

Sample clock jitter is certainly an additional source of noise when acquiring high frequency signals - and this would warrant a dedicated test.

Sample clock jitter is irrelevant for DC signal acquistion. Measuring the base noise of an acquisition system is equivalent to measuring a zero (DC) signal.

You are right. Still DC noise should be measured while going through all the attenuator steps. I think this will show a different picture where each oscilloscope has it's own sweet spot.