Magnova oscilloscope

[core]

I don't know if Batronix is considering it, but it would be interesting if in the future this oscilloscope would have the ability to run customer created applications.

It could become an open platform, and will be adopted by customers in many, many industries.

The latest generation of oscilloscopes from GW Instek has the ability to run Python scripts, it even has a built-in Python GUI library.
No idea how well they are implemented, though.

[nctnico]

I don't know if Batronix is considering it, but it would be interesting if in the future this oscilloscope would have the ability to run customer created applications.

It could become an open platform, and will be adopted by customers in many, many industries.

The latest generation of oscilloscopes from GW Instek has the ability to run Python scripts, it even has a built-in Python GUI library.

I have been thinking about suggesting something similar but didn't. I'm not so sure whether such programmability would achieve a reasonable performance level and how useful it actually is to a large group of users. The programming language would likely be some kind of script language like Lua or Python. One of the problems is going to be debugging such scripts while running on the oscilloscope. How about debug output (text) and single stepping? Batronix would have to provide a rather complete development & simulation system for creating extensions to make sure there is a small learning curve. Otherwise the use would be limited to people who have good skills in debugging techniques and know how to write good software from the get go. The latter excludes quite a few electronics engineers.

A long time ago (> 10 years) I wrote disassembler plugins to decode SPI and I2C protocols for the Tektronix TLA700 series logic analysers. This was based on reverse engineering by somebody else and me. Despite the source of my work being published widely, I'm not aware anyone else used the information to create other protocol decoders.

IMHO GW Instek went a bit overboard to make everything programmable to a point where you could implement things like curve tracing or frequency analysis. Last time I checked the documentation looked a bit light and it would take some trial & error to get things going. The thing is that if you want to program complex functions by yourself, you are better of developing & running the software on a PC. From there it is a small step to look at post-processing software like ngscopeclient or sigrok which likely already have such functions.

What I could see working on a DSO are small loadable plugins in the form of Python or Lua scripts which implement a protocol decoder or a math function (just like the plugins on the Tektronix logic analyser). Both use acquired data as input (time & value) and output new data in a certain format (again time & value). But still the potential debugging issues would remain. Perhaps a way to use saved data in a test bench and run the plugins in a test-bed on a PC could partially solve this but I think user programmable plugins will still be prone to error and it take a decent amount of software development skills to implement a plugin properly.

As far as I know, Tektronix only made their plugin APIs available to professional third parties who develop extensions to their logic analysers. Not to generic customers directly.

[Martin72]

Hi-Res mode:
It would be good to be able to see that it is active.
Some kind of indication on the screen.
If, like me, you had set it to 16bit the last time you used it and forgot to switch it back, you save yourself the half-hour troubleshooting because you can no longer see a 10Mhz signal....

[woody]

Factory Default is my friend whenever I'm baffled by the scope. Bit crude, but at least it gives me a known point to start from

[Martin72]

I had managed it with that, and then the memory came back...

[Martin72]

I'm currently in the process of recreating the frequency response of the scope using the max hold function of the FFT, with a little fine-tuning still to be done.

[Martin72]

Well, now it's better.
What you can see in the photos in the previous post is what happens when you don't specify enough sweep points....
65k points make you grow a beard, so I took 16k.
What you shouldn't do during the sweep is make a quicksave (FFT_1).
You can see that clearly in the frequency point (FFT_2 and the following ones), because the save routine must have briefly disturbed the recording.
I couldn't find a split/exclusive mode on the Magnova, but you can make the FFT window larger(FFT_3, FFT_5).
After the sweep, I determined a -3dB point of 440Mhz using the FFT cursors(FFT_4, FFT_5).

Martin

[Verticon]

Hello Martin72,

these are very significant and useful results. The wavelike progression of the transmission curve indicates a mismatch in the signal chain, isn't it.

[Martin72]

Hello Verticon,
It is, and I wasn't finished playing around with it yet either.
Pictures with an attenuator in between will follow.

[Martin72]

Here the pictures with a -3dB attenuator in between.

[nctnico]

Be aware that using the max-hold function, you also include the peak of any noise in the measurement. So the result is on the high / positive side and even more so as you seem to use rather low amplitudes compared to full-scale. Noise will be a relatively large part of of the signal amplitude. A more accurate method is to use amplitude measurement and look at the average value in the statistics display. But this takes making quite a few measurements to produce a detailed frequency response graph.

[Njk]

BTW, there is another non-standard but simple method for frequency response measurement, by using a white noise input signal, as discussed in the correlator thread https://www.eevblog.com/forum/testgear/vintage-hp-3721a-correlator-repair-restoration-and-enhancement/msg5656607/#msg5656607. The FFT max hold function can be helpful as well

[Martin72]

The method with FFT Max Hold works quite well, but of course it is not perfect.

[jusaca]

Hi-Res mode:
It would be good to be able to see that it is active.
Some kind of indication on the screen.

Not only Hi-Res mode, I think that about almost all settings all the time.
Good all times when you could see all settings in one glance at the front panel. I'm aware that this is not possible anymore with all the feature-packed devices, but a more complete overview in the normal scope screen would be really nice.
I would LOVE a constant display of aquisition mode, filter bandwidth, probe attenuation, trigger type (preferably even a constantly usable toggle button for auto/normal and positive/negativ edge, like many R&S scopes have), ...

[Andre77]

Here is a ‘quick and dirty’ method for determine the frequency response:

• Connect a function generator with sufficient bandwidth to one of the channels using a high-quality 50 Ohm cable.
• Set the generator to a sine sweep. The sweep should start near DC and go up to the desired upper frequency. For the following screenshot I used 500 MHz, 100 ms sweep time, 0 dbm/632.45 mVpp)
• Trigger on the rising edge below the maximum and activate the trigger hold-off time (~80 ms).
• Limit the acquisition memory to e.g. 100 kpts, activate the peak value detection and deactivate the display interpolation in order to only see the two outer lines of the frequency response.
• Set the horizontal cursors to 70.71% of the signal amplitude (+- 223.6 mV)
• Set the vertical cursors to the start point of the sweep and to the point at which the frequency response crosses the horizontal cursors.
• Since we have a 500 MHz sweep with a sweep time of 100 ms, the cursor position of 86.3 ms indicates a bandwidth of 431.5 MHz (500 MHz * 86.3 ms / 100 ms = 431.5 MHz)

Please note: The frequency response also includes the frequency response of the generator and the cable.

By the way: The Magnova has a built-in correction filter to optimise the frequency response. This can be found in the channel filters (amplitude) and is switched on for the second (red) channel in the screenshot. However, this filter also leads to a preshoot / overshoot with fast edges (<= 2 ns) and is therefore not switched on by default.

[KungFuJosh]

@Andre77,

Is there a plan to add a web server for remote viewing/control? I know for myself, and a lot of others, not having that feature would be a deal breaker.

An app is not a substitute for a web server. The ability to go on any system and any browser and control a scope without any special effort is priceless.

Thanks,
Josh

[Martin72]

Here is a ‘quick and dirty’ method for determine the frequency response:

An interesting alternative that I will try out soon.
Nevertheless, my “graph” hardly differs from the ones shown.

[Andre77]

Is there a plan to add a web server for remote viewing/control? I know for myself, and a lot of others, not having that feature would be a deal breaker.
An app is not a substitute for a web server. The ability to go on any system and any browser and control a scope without any special effort is priceless.

We are aware of the value and high demand for web access capabilities and remote control functionality in general.

Therefore we are currently focusing on finalizing and documenting remote control via SCPI (REST-API, SCPI-RAW, USBTMC), as well as on some requested smaller functions and improvements with perceivable impact. Once this work is completed, the LXI integration and the web server will be given top priority.

On the hardware side, the finalization of logic analyzer and generator modules currently has the highest priority. These accessories (along with already available corresponding software capabilities) will also be usable in their current state at electronica trade fair in November (Munich, November 12-15).

We are planning on releasing firmware version 1.1.0 within the next two weeks.

[ralphrmartin]

Good to see some of the promised updates are soon to be rolled out!  Keep up the good work!

[Performa01]

Here the pictures with a -3dB attenuator in between.

3 dB is not much. It should be at least 6 dB or even bettr 10 dB. And it is most important to place the attenuator at the output of the generator (before the cable) - not at the input of the DSO (after the cable).

Explanation: the matching of a proper 50 ohm input is quite good, usually with a VSWR < 1:1,5 up to the full bandwidth and often much better at lower frequencies. By contrasst, the output impedance of a signal generator can be off quite a bit, as we've already seen with your R&S-device. Your new Siglent isn't going to be any better in this regard - it's just the nature of a wideband power output stage with little to no attenuation.

Don't get allienated by the usual wannabe expert comments. Nobody who has a remote understanding how an FFT works would worry about noise in such a measurement. All the more so at a signal level of -3 dBm, which is quite high. For anyone not familiar with dBm, a quick look at the channel setting should make it obvious: 100 mV/div is about the most insensitve setting of any serious 2-attenuator design frontend.

The max-hold is a perfectly valid and accurate method to measure frequency response. Yes, we see some spurious responses (which actually shouldn't be there at such low sensitivities), but they are easily identifyable and don't prevent us from getting the true frequency response.

[Martin72]

3 dB is not much. It should be at least 6 dB or even bettr 10 dB. And it is most important to place the attenuator at the output of the generator (before the cable) - not at the input of the DSO (after the cable).

I know, but I only have either 3 or 20dB and then only BNC-BNC.
I figured it was better than nothing.
And you can see a tendency towards improvement...

[nctnico]

Don't get allienated by the usual wannabe expert comments. Nobody who has a remote understanding how an FFT works would worry about noise in such a measurement.

The max-hold is a perfectly valid and accurate method to measure frequency response. Yes, we see some spurious responses (which actually shouldn't be there at such low sensitivities), but they are easily identifyable and don't prevent us from getting the true frequency response.

Try it and you'll see that adding noise to a sine wave can easely create a 1dB offset / error in the FFT result when using max-hold. Again, looking at Martin72's screendumps you can see the amplitude is quite low compared to  full scale so the signal to noise ratio is quite poor. Also the roll-off typically isn't very steep around the 3dB point so it takes a carefull measurement method which eliminates the influence of noise from a signal in order to determine the -3dB point precisely. An error of 0.5dB can mean you are tens of MHz off. In the end FFT doesn't eliminate noise or hide at all; that is not the function of FFT. And as noise is broadband by nature, it will show up (add) in every frequency bin and there is no guarantee that the frequency distribution is even. On the R&S RTM3004 I have here, a max-hold on an FFT of the noise floor does not result in a straight line (for example). So all in all, I have to respectfully disagree that max-hold FFT is an accurate method under any circumstance.

[2N3055]

Don't get allienated by the usual wannabe expert comments. Nobody who has a remote understanding how an FFT works would worry about noise in such a measurement.

The max-hold is a perfectly valid and accurate method to measure frequency response. Yes, we see some spurious responses (which actually shouldn't be there at such low sensitivities), but they are easily identifyable and don't prevent us from getting the true frequency response.

Try it and you'll see that adding noise to a sine wave can easely create a 1dB offset / error in the FFT result when using max-hold. Again, looking at Martin72's screendumps you can see the amplitude is quite low compared to  full scale so the signal to noise ratio is quite poor. Also the roll-off typically isn't very steep around the 3dB point so it takes a carefull measurement method which eliminates the influence of noise from a signal in order to determine the -3dB point precisely. An error of 0.5dB can mean you are tens of MHz off. In the end FFT doesn't eliminate noise or hide at all; that is not the function of FFT. And as noise is broadband by nature, it will show up (add) in every frequency bin and there is no guarantee that the frequency distribution is even. On the R&S RTM3004 I have here, a max-hold on an FFT of the noise floor does not result in a straight line (for example). So all in all, I have to respectfully disagree that max-hold FFT is an accurate method under any circumstance.

Accurate for what?
You cannot just admit you misunderstood what we are talking about here?

BW measurement is relative measurement.
We are not trying to accurately measure single frequency level.

You can have 3 or 6 dB error in absolute level, and it does not matter. All it matter is the SHAPE of BW curve.
Then you take 1st cursor, set it to level that , say, 1MHz is and with another cursors you find delta of -3dB and that is your BW. White noise will make same contribution to whole BW.

Signal generator level is important only because, based on level, scope front end will work in different atten/amplifier combinations that might have different BW curves..

Not to mention that you shifted goalpost from (very low) internal scope noise to deliberately injecting large amounts of noise  from signal generator. If you deliberately inject agresor signal into any measurement you can make things go wrong. Duh.

But in this case, even if you mix sweeping generator output with 30% white noise BW measurement with hold will be equally perfect as with clean sinewave. In fact, if you have good quality noise source that is all that you need, you don't need sweep signal at all...

So, yes, if you are trying to accurately measure level of single tone, noise will interfere.
But, no, noise won't have a bit of influence on measuring shape of BW of scope channel. In fact, it can be used for such purpose as a valid test signal.

[nctnico]

Re-read what I wrote very carefully and you'll understand why using FFT in max-hold introduces measurement uncertainties.

Again: frequency distribution of noise (no guarantee of white noise) and poor signal to noise ratio (so no, I didn't shift any goalposts).

And I know perfectely well that BW measurement is best done as a relative measurement to cancel the uncertainty of the (levelled) generator as much as possible.

[Performa01]

Interesting push of alternative truth. I won’t get into arguments, just let the real facts speak for those educated enough to understand the implications.

First of all, there cannot be any doubt about the level, hence SNR. -3 dBm is – 3 dBm, full stop. Once again, for those unfamiliar with dBm, it might be useful to know that -3 dBm is equivalent to 158 mVrms into 50 ohms, which in turn means 448 mVpp. At 100 mV/div, this is 56% of full scale, hence optimally levelled – more is just not possible without overdriving the input.

Some might understand now why I always stated I’d never get a DSO without permanently visible trigger frequency counter. Because if the Magnova had one, even the less bright might have realized that the signal frequency was far outside the scope bandwidth, hence heavily attenuated at the moment the screenshot was taken.

Suddenly we are desperate about up to 1 dB error (which is utter nonsense btw), because that could cause tens of MHz difference in -3 dB bandwidth. Apart from the fact, that sample variation alone might cause some 10 MHz differences in bandwidth, since when do we care whether a DSO has e.g. 380 or 420 MHz bandwidth – has this ever mattered in practice? Then add the fact that the flatness of an average signal generator can be as bad as +/- 1 dB and every coax cable adds additional attenuation at higher frequencies. But most importantly, the claimed 1 dB error has no counterpart in the real world of facts, as shall be shown here:

Here is the frequency response measurement from 1 MHz to 1 GHz at 100 mV/div with a -3 dBm signal. Screenshot taken at only 34 MHz, so that even the inexperienced can see what -3 dBm actually means in the time domain.


SDS2504X_HD_FR_-3dBm

In the frequency domain, we can see a relatively flat response up to some 520 MHz, then slowly decreasing. In any case, we get a level of -3 dBm to -4 dBm up to 500 MHz, which is the specified bandwidth of the DSO – which proves to actually be the -1 dB bandwidth.

Now we turn off the generator in order to see the noise:


SDS2504X_HD_FR_NF

Suddenly we see a flat noise level of -73 dBm, thus resulting in a SNR of 70 dB.

It is also worth noting how we can see only a single spur at 500 MHz, which happens to be a sub-harmonic of the sample clock – and even that is quite low in the single digit nanowatts when full scale is more than one milliwatt.

Now I’m looking forward to the desperate attempt to explain how a -73 dBm noise floor can affect a -3 dBm signal in a way that causes up to 1 dB error – relative or absolute. Understanding some of the fundamentals could certainly help, such as the difference between noise level and noise density and how the noise level depends on the RBW, whereas the signal level does not.