Possible serious bug in RTO1024 or RTO1000 series scope?

[JohnG]

Fellow RTO1000 series scope owners, I think I have found a fairly serious bug in the scope, or at least in mine.

Conditions:
2ns/div
all 4 channels at 50 ohms
waveforms on channels 1, 2, 4
External trigger
Probe attenuation manually to 20V/V on channel 1
Probe attenuation at 1V/V for all other channels

Problem:
When I set the probe attenuation manually to 20V/V on channel 1, if the vertical scale knob is set anywhere from 100 mV/div to 1V/div, the channel 1 trace moves to the right by 600 ps! The blue trace (channel 1) shows what I mean.

Correct waveform:
[ Specified attachment is not available ]

Incorrect waveform:
[ Specified attachment is not available ]

In fact, if I set the gain to anything other than 1V/V, I will see the same thing at one or more settings of the vertical scale.

I can replicate this on any channel by setting its attenuation to something other than 1V/V, and it occurs at other horizontal scales as well.

This is a really serious problem, as I have been trying to analyze the timing relationship of some waveforms, and it has cost me many days wondering what the hell is going on. There is absolutely no way a change in probe attenuation factor should shift the waveform in time.

Anyone else see this, or is it just me?

I have the latest firmware and Win 7 on the scope.

John

[jjoonathan]

Hmm, I can't replicate the problem. What are your Deskew settings?

Mine look like this before and after going into Probe Settings and changing Channel 1 to 20V/V:

C1: (checked) User skew offset 0s     Probe skew offset (off)
C2: (checked) User skew offset 0s     Probe skew offset (off)
C3: (checked) User skew offset 0s     Probe skew offset (off)
C4: (checked) User skew offset 0s     Probe skew offset (off)

[JohnG]

Thanks for checking.

All my deskew values were set to zero (I checked). Probe skew offsets were disabled, and user skew showed the problem whether enabled or disabled, but always set to zero.

However, if I switched the inputs to 1Mohm, the problem goes away. It only shows when the input is set to 50 ohm.

John

[pdenisowski]

Have you contacted our technical support center?   Phone: 1-888-837-8772 (1-888-Test-RSA), email: customer.support@rsa.rohde-schwarz.com.

[jjoonathan]

Yeah, I had the inputs at 50ohm and Ch4 inverted. I tried to replicate the other settings, at least to the level of active/not.

Have you run File>Selfalignment recently? I have to wonder if your last self alignment slipped up somewhere.

[JohnG]

Yep, ran self alignment and self test, no change. I can reset the scope to defaults, same problem.

I will try to reset again, and run my scenario immediately afterwards to see if it is something that appears after some time. I can also provide an instrument setup file.

TBH, I have had a nagging feeling about this for some time but figured there was some issue with my setup. I finally dug in this week, and was able to narrow it down to something that appears as described above.

Won't be able to do this until next week.

Really odd and frustrating problem.

John

[JohnG]

Have you contacted our technical support center?   Phone: 1-888-837-8772 (1-888-Test-RSA), email: customer.support@rsa.rohde-schwarz.com.

Thanks, I will do so next week.

John

[egonotto]

Hello,

what is, when you connect ch3 parallel to ch1?
Is than a skew between ch3 and ch1?

Best regards
egonotto

[JohnG]

The skew between channel 1 and channel 3 appears to be about 2 ps. Why do you ask?

John

[egonotto]

Hello,

I want know whether the signal is wrong on the BNC connector of ch1 or is right on the BNC connector of ch1 and the scope shows a wrong signal.

If the signal is correct on the BNC connector of ch1, than you can test it with a function generator with the same signal on ch1 and a other channel. Than you should see the error.

Best regards
egonotto

[JohnG]

I get the same problem as above, using a single source with a splitter. If the probe attenuation is set to 1x, there are no problems. If it is set to a higher value, then the delay shift error described above occurs.

It also occurs even if I use the trigger output of the generator connected to the external trigger input on the scope, with the same symptoms described above.

The time shift error is also about 600 ns every time, no matter what the input signals and source signals.

It can happen on any channel, no matter what the trigger source is.

It is such an odd error, I initially assumed I had a setup problem, bad connector or something. When I finally dug in, I found it was a scope error. If I do the exact same setup on my other Lecroy scope, I have no problem.

John

[nctnico]

Is this purely related to the external trigger? Maybe this problem is related to the recovery time of the external trigger input somehow. What happens if you use a regular channel instead of the external trigger?

[JohnG]

Is this purely related to the external trigger? Maybe this problem is related to the recovery time of the external trigger input somehow. What happens if you use a regular channel instead of the external trigger?

No, I first noticed it using a channel trigger.

The problem occurs on any channel that has the probe attentuation factor set to some value other than 1 V/V. In fact, the range of vertical scale factors for which the problem occurs increases for higher scale values.

For example:
2V/V, problem occurs at 10 mV/div
5V/V, problem occurs at 20 mV/div through 50 mV/div
10V/V, problem occurs at 40 mV/div through 200 mV/div
20V/V, problem occurs at 100 mV/div through 1V/div.

I can make it occur on any channel, and it follows the above pattern. It does not appear to be affected by signal amplitude, and the measured delay is always 600 ps when the problem occurs. This is using the scope measure delay function, so it a few ps longer than 600, same whether measured on rising or falling edges.

Only happens with inputs set to 50 ohm Zin.

I have replicated the results with rectangular pulses from my pulse generator.

It does not happen when I remove the cables from the RTO scope and put them on my SDA6020.

John

[nctnico]

I don't think this is a bug but something is broken in your oscilloscope. I'm wondering what R&S has to say about this.

[JohnG]

I don't think this is a bug but something is broken in your oscilloscope. I'm wondering what R&S has to say about this.

I will find out soon enough. I have had it repaired 1.5 years ago at considerable expense, due to some mainboard communication error.

It is a very odd problem.

John

[egonotto]

I don't think this is a bug but something is broken in your oscilloscope. I'm wondering what R&S has to say about this.

Hello,

what hardware part error has an effect like this?
An eeprom error, that cause a firmware error?

To set the probe attenuation manually is in my opinion a firmware only action.

Best regards
egonotto
   

[nctnico]

I don't think this is a bug but something is broken in your oscilloscope. I'm wondering what R&S has to say about this.

Hello,

what hardware part error has an effect like this?
An eeprom error, that cause a firmware error?

To set the probe attenuation manually is in my opinion a firmware only action.

In the end the amplification & offsets change in the hardware. It could be a recovery problem due to a broken amplifier (or other part) or an issue with a supply rail being bad causing a shift in the trigger level. Maybe even something simple like a bad connection somewhere causing a control line having the wrong value.

[JohnG]

Looks like a hardware issue. My local rep happened to have the same model, and could not duplicate the problem, after which he shipped it to me, and I could not cause the same problem on the loaner.

Unfortunately, my scope is out of warranty and I have already had one out-of-warranty repair. My employer does not have the appetite for another repair on this scope. The local rep is lending me the scope in the meantime (thanks, Mike!) so I can complete at least some work.

One thing he speculated was that something was not getting switched during the autocal sequence, so that certain attenuation values were getting autocal'd incorrectly. I may try to open the scope and see if I can clean and reseat connectors between the acquisition board and the mainboard. That won't happen anytime soon, though. This possibility is in line with nctnico's suggestion:

Maybe even something simple like a bad connection somewhere causing a control line having the wrong value.

John