Magnova oscilloscope

[blackdog]

Hi tautech, 

I had forgotten to include the "HD" after the model number in my posts; I've already updated as many of them as possible.
So the oscilloscope I used for the measurements is the: SDS2104X HD.

I'm aware of the limitations of the Siglent SDS2104X Plus oscilloscope; I have this oscilloscope on my second workbench, and what you describe regarding the bit depth and bandwidth is correct.
The Siglent SDS2104X Plus oscilloscope was not used in the measurements shown here.

Sorry for the confusion.

Kind regards,
Bram

[tautech]

Hi tautech, 

I had forgotten to include the "HD" after the model number in my posts; I've already updated as many of them as possible.
So the oscilloscope I used for the measurements is the: SDS2104X HD.

I'm aware of the limitations of the Siglent SDS2104X Plus oscilloscope; I have this oscilloscope on my second workbench, and what you describe regarding the bit depth and bandwidth is correct.
The Siglent SDS2104X Plus oscilloscope was not used in the measurements shown here.

Sorry for the confusion.

Kind regards,
Bram

Massive difference, thanks for clearing this up. 
SDS2000X HD is also 500 MHz design and 12bit native with an additional 4 bits ERES.....nice DSO and vey quiet.

[blackdog]

Hi rf-messkopf,

I'm aware of the "issues" that can arise when decoupling, especially, high-speed electronics and the circuit board.

I’ve personally tried using very short connections and SMD components to generate pulses with very little distortions.
With BNC and SMA connectors, you quickly reach the limits set by the bonding wires, the inductance of your capacitors, and your connections themselves.

Given the information you’ve all shared with me, I can’t make any further progress on testing with the equipment I have available for measurements about pre-ripple.
It’s also going to take me a little while to fully process and understand all of this. 
Thank you, everyone, for helping me "see the light" regarding pre-ringing.

And I'll continue with other tests using the Magnova scope.

Kind regards,
Bram

[Sorama]

Hi tautech,

My Siglent scoop is as show here is: SDS2104X HD and is 10Bit en 500MHz.

Kind regards,
Bram

So you might think.

SDS2000X Plus used in 10bit mode will give measurement errors over 100 MHz.....in all models !
The oversampling acts as a BW limiter.
Dave Jones (EEVblog) discovered this fact when reviewing this range at release some years ago.

While SDS2000X Plus are a 500+ MHz 8bit design the BW for each model is limited by SW in the same IC that performs the 20 MHz BW limit.
SW sets BW and even the 500 MHz SDS2054X Plus is limited to 350 MHz when 3 or more channels are active.
You can see the Full (BW) change to 350 MHz in the channel tab when 3 channels are active.

Carry on.... 

It’s not an X Plus model, but an HD (so full 12 bits).

[Bernd_2]

Please apologize if this is off-topic, but for comparison I took a few screenshots using the Bodnar Pulser LBE-1322 on a 2 GHz oscilloscope. The LB-1322 was connected with the included SMA-BNC-Adapter to the Scope.

As you can see, with a 2 GHz bandwidth and Sin(x)/x interpolation, there is significant pre- and post-ringing, with linear interpolation, there is already significantly less, but the edge steepness also decreases slightly compared to Sin(x)/x.

At a channel bandwidth (setting in the Channel menu) of 500 MHz, pre-ringing decreases significantly and  almost disappears entirely at 350 MHz.

Best Regards,
Bernd

[blackdog]

Hi Bernd, 

Thank you for the time to do some extra measurements to make it more clear what filtering the bandwith is doing on the pre-ringing.
I observed the same effect with my function generator when I slowed down the edge rate.
However, my function generator can't go any lower or faster than 3 nsec, but it's sufficient to observe the effect you're demonstrating.

I could only find one function on my 8-bit Hameg/R&S oscilloscope
that allowed me to vary the bandwidth (and by that, I don't mean the 20 MHz button), but the Hameg apparently has almost no pre-ringing.

Kind regards,
Bram

[Bernd_2]

Hello Bram,

Thank you very much.

If you're interested, I can perform the same measurements with the other bandwidth settings.

The MXO5 has three areas where the input bandwidth can be adjusted: two in the Channel menu—one for the channel itself and a second in the Probe submenu—both of which can be set independently of each other. The third option is in the HD submenu under the Acquisition menu.

Another thing I could try is to see if there's a difference in ringing when using FIR or IIR low-pass filters.

Unfortunately, the only function generator I have is an SDG2120X with a minimum rise time of 9 ns—just like the built-in function generator in the MXO5—so it's not comparable to your function generator.

Best Regards,
Bernd

[FloBX]

Hi Bram,

having had some time to look further into the behavior related to your observations, we'd like to update a few points we addressed earlier.

Counter limits
Regarding the maximum measurable counter input frequencies, we were able to further optimize the counter behavior with hysteresis enabled. This will allow us to increase the specified frequency limits starting with the next firmware update.

Setting hysteresis to 0% already allows the counter to operate up to the higher frequencies.

Display behavior, averaging and measurement results

With a 200 MHz sine wave and approximately 100 mV rms applied to the oscilloscope, I again see something that shouldn't be there at a time base of 50 nsec.
See the two images below with different time base settings.
[...]
200MHz ~100mV RMS and 2nSec time base

.

Same signal and now 50nSec time base, and no there is no modulation on the signal from my HF generator.

And Andre77, wat about this picture witch a showd before, is it possible to correct this.
is it possible to adjust this behavior so that it matches the behavior of other scoops—that is, not to display amplitude modulation when it isn't present?

Thanks for bringing this up again, and especially for pointing out the Vrms measurements. The issue was already brought up and discussed earlier, but at the time we classified it as a display-only issue related to interpolation-based rendering.

This is right at the transition point where the oscilloscope switches from showing raw samples to using interpolation (in this case Sinc interpolation). In this “edge case,” small features such as narrow spikes can appear unstable or seem to shift because they fall "between display pixels" and the interpolated points vary depending on the time offset.

The Vrms measurements showed that the effect can also have an impact on measurement results, something we had not taken into account in our earlier assessment and which we now want to correct.

In your case, changing the time scale of the main waveform window, using Zoom mode (here: >1x), or even switching the Measurement display mode to "Compact" and thus changing the utilized screen width should change how strongly the observed effect impacts both the displayed waveform and the resulting measurements.

That said, we agree that the waveform shown in your screenshot should not appear that way in the first place, and that the interpolation should not negatively influence the resulting measurements in this manner.
We have therefore addressed this by improving the interpolation behavior for these specific display and measurement scenarios, resolving the observed issue in the upcoming firmware update.

While the observed behavior may become visible when using Average mode in this particular setup, it is not caused by the Averaging mechanism. Averaging operates as a sampling mode, in your case at 1.6 GSa/s, and is internally processed at the maximum interpolated sample rate of up to 819.2 GSa/s, so it is not affected by the limitation discussed above.

Please feel free to bring up any further questions or observations you would like to discuss.

Best regards
Florian
Batronix

[john74]

Has anybody a clue what the "E0" button is for, when changing the number of digits for a hardware counter?

[Performa01]

Has anybody a clue what the "E0" button is for, when changing the number of digits for a hardware counter?

Setting up an exponential number format?

[john74]

Setting up an exponential number format?

yes I thought the same, but the allowed number range here is: 6..15
so not much need for an exponential expression I would say.
(maybe a test artifact?)

[Performa01]

... the allowed number range here is: 6..15
so not much need for an exponential expression I would say.

Well, that means you can define the counter precision in the range of 6 to 15 digits, but that has nothing to do with the display format.

What happens when you tap that mysterious E0 button?

I have an old frequency counter that does only 8 digits or so, but still outputs the result in Engineering format.

For instance, 99.999999 MHz would be displayed as 99.999999 (e)+6. (the "e" is not actually displayed, since this is a good old fashioned LED 7 segment display, hence i've put it in parenthesis)

Apart from the fact, that even a 7-segment display can handle this, another advantage is the ease of reading. "3", "6" and "9" are sometimes easier to recognize and relate at first glance even from a distance than "kHz", "MHz" or "GHz" - especially on small displays.

[john74]

Well, that means you can define the counter precision in the range of 6 to 15 digits, but that has nothing to do with the display format.

What happens when you tap that mysterious E0 button?

ah, I see your point....but in the Magnova counter GUI you only define the number of digits the hardware counter shall be represented during the measurement.
In the screenshot you see two frq-counter, each with 12 digits, one is measuring a 1kHz signal the other is measuring a 1MHz signal.

The display format is always the same, but the number of decimal places can be adjusted from 6 up to 15.

And the "E0" button is closing the input GUI in the same way the "ok" button would do.
(at least I can't see any other impact)

[Sorama]

Dear Batronix people,

While using UART decoding I noticed that in the decoding list, the LF (LineFeed) nor CR (Carriage Return) are decoded correctly (both shown as ?) while it is decoded correctly in the frames under the waveform.

Why?
Shouldn't the result list at the left not also show CR and LF as that is what the data really is?

Please see attached.

[john74]

Why?
Shouldn't the result list at the left not also show CR and LF as that is what the data really is?

That would be indeed a nice feature. The "?" is a wildcard I would assume, for all "non-printable" ascii characters.

[Sorama]

Why?
Shouldn't the result list at the left not also show CR and LF as that is what the data really is?

That would be indeed a nice feature. The "?" is a wildcard I would assume, for all "non-printable" ascii characters.

Well, I don’t print anymore, I just want to read it 
Tnx.

[john74]

And another minor request (not sure somebody already mentioned it):

At the moment you can't fully control the Bode-Plot just with a mouse,
because the "right mouse click" to switch between "Cursor A/B" and "Start/Stop" is not working.
Also "drag&drop" to move and "mouse-wheel" to zoom inside of the Bode-Plot window is not working.

Direct control at the scope with touch and knobs works just fine.

[Andre77]

Has anybody a clue what the "E0" button is for, when changing the number of digits for a hardware counter?

And the "E0" button is closing the input GUI in the same way the "ok" button would do.

Thanks for pointing this out.

As Performa01 already suspected, “E0” is the shorthand for an exponent of zero in scientific notation, i.e. ×10⁰.

In this particular case, it is not useful, since the number of counter digits can only be set between 6 and 15. We will therefore remove the E0 option here.

Some background: Magnova’s numeric input editor automatically provides suitable prefixes and units depending on the parameter being edited. For example, when entering a voltage, it may offer µV, mV, V, kV, etc., while for time values it may offer ps, ns, µs, and so on.

For dimensionless values, the editor can instead offer suitable exponential notation as a shortcut. It automatically determines which exponents make sense based on the valid input range.

Selecting one of these shortcuts accepts the entered value immediately and closes the editor, which is why pressing E0 currently behaves the same way as pressing OK.

So in this case, the behavior is technically intentional, but the E0 option itself should not be shown for the counter digit setting. Thanks for catching it.

And another minor request (not sure somebody already mentioned it):

At the moment you can't fully control the Bode-Plot just with a mouse,
because the "right mouse click" to switch between "Cursor A/B" and "Start/Stop" is not working. Also "drag&drop" to move and "mouse-wheel" to zoom inside of the Bode-Plot window is not working.

Direct control at the scope with touch and knobs works just fine.

Thank you very much for pointing that out! We will fix the missing mouse controls in the Bode plot, including the right-click functionality for switching between Cursor A/B and Start/Stop, as well as drag-and-drop and mouse-wheel zooming, in one of our upcoming updates.

[Andre77]

While using UART decoding I noticed that in the decoding list, the LF (LineFeed) nor CR (Carriage Return) are decoded correctly (both shown as ?) while it is decoded correctly in the frames under the waveform.
Why? Shouldn't the result list at the left not also show CR and LF as that is what the data really is?

Thank you very much for the feedback.

One possible reason is that the table view was originally designed around a fixed data width, which may be why CR and LF are currently shown as “?”.

We will look into how we can improve this so that CR/LF are also displayed correctly in the list, just as they are in the waveform view.

[jusaca]

Is it possible to export trend charts of measurements in a csv file?
I had a long-ish measurement running over a few hours, plotting the RMS values of two channels as trend charts. But I could not find an option to export these as anything else but a screenshot. Would be nice to get the raw numbers of the measurements in a csv as well.

[FloBX]

Hi Jusaca,

exporting the trend charts is not possible yet, but the feature is already on our list of future extensions. 

Best regards
Florian

[ZPeterZ]

Hi all,
while trying to make minimal differences of 2 signals visible via the math channel, I found some behaviour I can not explain. The differences I searched for where visible, but the math channel was overlaid by RF peaks. I terminated the inputs with 50 ohm BNC resistors the RF peaks were still there. Then I changed the scale for the contributing channels from 100mV/div to 10mV/div and the RF peaks on the math channel where also downscaled. The DVM AC rms values for ch 3 and 4 where also reduced from 530µV to 70µV while the input signals where not changed (inputs still terminated with 50 ohm). I repeated this with math=ch1-ch2 and got even slightly higher peaks. Setting the input filters to 20MHz makes the RF peaks slower in frequency but does not cancel them.
Even shorts on the inputs do not change this behaviour - only grounding the input channels internally makes the math channel quiet.
Did I ran into some numerical processing limits? I guess I need your help...
Firmware is 1.9.6

- b.r. Peter

[ZPeterZ]

I put some 8 bit boatanchor on the bench and found similar peaks on the math channel. So, the reason seems to be noise on the contributing channels even with shorted inputs. So the use of sub mV scales is not feasible for this usecase. What still seems to be a flaw is the influence of the scale-change from 100mV to 10mV/div on the DVM and the math display (because it's scale setting stayed at 500µV/div).
Furthermore it would be still desirable to make further characterisation of the math channel possible via FFT.
b.r., Peter

[ZPeterZ]

To give an impression of the usecase: For simplicity I made a comparision of very similar 1KHz signals on ch 2 and 3. So the math is simple substracting ch 2 - ch 3, but due to the very small differences the math scale needs to be set to 500µV/div which introduces a lot of noise peaks. Is there a function to further smooth the math output? A LF filter could do but can this be applied by math functions?
b.r., Peter

[ZPeterZ]

HiRes to 16 bit and Average 10 both activated produce a better picture but I am still not sure, if this is the way to go...