EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: euzer on June 17, 2022, 10:04:35 am
-
I'm getting bad rising and falling edge reproduction on one channel of a Agilent DSO5014A (N2863A probes). The waveforms show a bad (green) and good (purple) of the same front of scope test signal. The response stays with the channel rather than the probe. The edge is not exponential as can be seen in the third capture (_174 green trace at 2us/div resolution. Any suggestion on how to resolve this would be appreciated.
-
Is it possible that the bandwidth limit is enabled for the green channel?
-
I'm not familiar with that model but can you run a calibration for each channel with probe in place? Also, that's a much newer probe but as long as you can adjust the comp it's probably fine.
-
Definitely run a self-test! Like @ozkarah said maybe check the BW limit & channel settings for that channel. You mentioned that it doesn't follow the probe, but make sure you're swapping any connector/ BNC T pieces, too.
-
Along with Daniel's suggestions, toggle the BW switch on and off and see if it changes the waveform on each channel. Perhaps the logic that drives the BW function or maybe an analog switch are broken. That's if the BW limit is done in analog fashion at the front end and not in signal processing.
-
That looks far too slow to be a bandwidth filter. It also is not the correct shape for an intentional bandwidth filter.
Were it not the same in both directions I would suspect that some push-pull driver had lost its push or pull. But it is not that. Hard to guess without seeing schematics but I still reckon a hardware failure.
-
That looks far too slow to be a bandwidth filter.
Surely a scope of this quality and heritage would show in any BW limiter was activated....or would it ? :-//
-
That looks far too slow to be a bandwidth filter.
Surely a scope of this quality and heritage would show in any BW limiter was activated....or would it ? :-//
Its not some military/nuclear device that has inspectable physical indication/interlocking on the function. So if there was a fault that caused the bandwidth limit to operate unexpectedly (as suggested in other posts above) the scopes indication would be irrelevant....
but since the time constant is so different to the bandwidth limiters of the scope, that sort of problem can be discarded. As that poster is pointing out.
-
That looks far too slow to be a bandwidth filter.
Surely a scope of this quality and heritage would show in any BW limiter was activated....or would it ? :-//
Its not some military/nuclear device that has inspectable physical indication/interlocking on the function. So if there was a fault that caused the bandwidth limit to operate unexpectedly (as suggested in other posts above) the scopes indication would be irrelevant....
but since the time constant is so different to the bandwidth limiters of the scope, that sort of problem can be discarded. As that poster is pointing out.
Sure but displayed signal rise time is very relevant to how the scope has been set.
Attached with the probe menu showing is a selection of screenshots of a Leo Bodnar 30ps pulser on a 2 GHz scope with direct to the input connections and a 10x probe with the pulser.
While 2GHz BW it's nowhere fast enough to accurately resolve a 30ps RT and instead reports ~300ps but look what it does with a 500 MHz probe connection, 200 and 20 MHz BW limiters.
The OP's DSO5014A is just a 100 MHz DSO so anything fast will look pretty ordinary anyways and not displaying a BW limiter and give results like it is suggests it's broken as the first sanity check using the probe compensation output is apparently being used yet the fault stays with the channel that indicates it's probably been overvolted.
-
The first step is to run a self-test. Anything else is just speculation. Having owned a few Agilent scopes myself, I'm quite sure that will come up with an error pointing into the right direction.
-
That looks far too slow to be a bandwidth filter.
Surely a scope of this quality and heritage would show in any BW limiter was activated....or would it ? :-//
Its not some military/nuclear device that has inspectable physical indication/interlocking on the function. So if there was a fault that caused the bandwidth limit to operate unexpectedly (as suggested in other posts above) the scopes indication would be irrelevant....
but since the time constant is so different to the bandwidth limiters of the scope, that sort of problem can be discarded. As that poster is pointing out.
Sure but displayed signal rise time is very relevant to how the scope has been set.
So what does that have to do with your post? Or is it just shit-stirring bringing up heritage/quality? As I recall the bandwidth limits have dedicated LED indicators on the scope in question (or was that only the 6000?).
-
That looks far too slow to be a bandwidth filter. It also is not the correct shape for an intentional bandwidth filter.
Were it not the same in both directions I would suspect that some push-pull driver had lost its push or pull. But it is not that. Hard to guess without seeing schematics but I still reckon a hardware failure.
From the screenshot you can see that the bandwidth of the green channel is even as low as hundreds of kilohertz, and the datasheet says that the only selectable bandwidth limit of this oscilloscope is 25MHz.
-
The first step is to run a self-test. Anything else is just speculation. Having owned a few Agilent scopes myself, I'm quite sure that will come up with an error pointing into the right direction.
Yeah, self-test is always step 1
-
Does the response change with V/ change ?
-
How does it look like, if you set the scopes input channels to 50 Ohm and send a signal from a function generator that is also set to 50 Ohm?
-
Thanks for all the input everyone. I've tried a self-test and nothing was reported, although the second run of the self-test doesn't pick up both the intensity dial or the calibration protection slide switch on the rear, during the input button/dial test. I suspect there may be a potentiometer for the intensity which is damaged as it didn't feel too smooth. Not sure about the reason for the calibration protection not being picked up. We have our kit calibrated at a test house so there was a tamper label covering this switch. I was considering doing a user calibration but it will invalidate our calibration and also I'd have to get the necessary BNC bits in to perform this.
It's the same behaviour on different vertical resolutions, and I have tried toggling the bandwidth setting for the suspect channel. I forgot to try the 50R setting.
-
To be clear: you did not run the test that requires to connect the BNC output from the rear to the front panel inputs? In order to find your problem, you really need to run that test! Your calibration is void either way because the equipment isn't working properly, so don't care about that at this point.
-
That's correct, I didn't connect the BNC from the rear to the front. I'll try and assemble the kit to try it out.