R&S MXO3/04/05 - Reviews, Bugs & Wanted Features/Improvements Thread

[shabaz]

There's also a 200 Gbit/sec throughput processor (I believe two of them, i.e. 400 Gbit/sec on the MXO 5), it could need data flushing, or waiting for all to egress, or to reconfigure the features on the cores. I too generally don't like unnecessary animations in products, but in this case I like the main menu animation, it indirectly visibly reveals if there is a lot going on in the background, but it's still brief enough to not slow me down even when there's a lot happening, and it was probably low-hanging fruit which likely reuses some of the functionality that already exists, like the ability to drag and slide the menu elsewhere, and the transparent menu capability which is useful. I do drag the menu around, I never thought I'd want such a feature.

The spectrum analysis is a core part of working with these scopes, and has plenty of untapped potential for future features in my opinion, and it's enabled excellent workflows, e.g. I find it useful for EMC-related tests (especially if you're willing to script things up), or even just to simply see if amplifiers are misbehaving. Could be very worthwhile getting the 1 GHz or higher models if it's a work purchase.

[core]

Speaking of blind time, I’d be very curious to know what it is.

All the documentation mentions a re-trigger time of 21 ns, but says nothing about the time required to refresh the screen.
Either this happens in parallel, so it’s not noticeable, or it takes milliseconds like on any oscilloscope, in which case it’s just marketing.

[MASCH]

I also had the Magnova as a demo unit before the MXO3 and I can say that the Magnova is waaaaay faster and much more pleasure to interact with.

I feel like R&S missed a chance here by designing a user interface which can keep up with the user himself.

BTW, the MXO3 missing encoder steps does not only happen when turning the knobs fast, sometimes also when only adjusting one step during working with it...and that is really frustrating.

Here is another video showing the slow response.....it's painful....



...try this with a Magnova and you will be amazed of what is possible.

[shabaz]

Or better yet, an abacus.. easy to slide things for instant satisfaction when one paws at that.

[core]

Here is another video showing the slow response.....it's painful....



...try this with a Magnova and you will be amazed of what is possible.

This is very interesting ! Thanks for information.

[2N3055]

Speaking of blind time, I’d be very curious to know what it is.

All the documentation mentions a re-trigger time of 21 ns, but says nothing about the time required to refresh the screen.
Either this happens in parallel, so it’s not noticeable, or it takes milliseconds like on any oscilloscope, in which case it’s just marketing.

Did you just asked if scope refreshes screen 4,5 Million times per second?
Of course it does not. It refreshes it 50-60 times per second. Like any normal screen... It combines cca 80000 captures and render one screen refresh. And on.

If you managed to somehow buy IXian bionic eyes that can see the difference and resolve millions of frames per second individually please let us know. I would like a pair too.

[core]

Either way, there’s no excuse for this delay for those of us who don’t already have it 

Considering how long the MXO series has been on the market, this should have been fixed by now.
Or, as they say, if users aren’t asking for it, it must not be important to them. Maybe none of the people who have it are complaining, or not enough of them are 

[core]

Speaking of blind time, I’d be very curious to know what it is.

All the documentation mentions a re-trigger time of 21 ns, but says nothing about the time required to refresh the screen.
Either this happens in parallel, so it’s not noticeable, or it takes milliseconds like on any oscilloscope, in which case it’s just marketing.

Did you just asked if scope refreshes screen 4,5 Million times per second?
Of course it does not. It refreshes it 50-60 times per second. Like any normal screen... It combines cca 80000 captures and render one screen refresh. And on.

If you managed to somehow buy IXian bionic eyes that can see the difference and resolve millions of frames per second individually please let us know. I would like a pair too.

I was referring to how much emphasis is placed on the fact that it has this extremely short retrigger time.  As if there were no refresh time.
When in fact it’s normal, resulting from the nature of how this type of trigger is implemented.
Magnova has 70 ns only because it has a lower sampling rate.

From this perspective, there’s nothing extraordinary about it; it’s natural given its nature.

On the other hand, there are situations where a “classic” trigger is better.

[Martin72]

Here is another video showing the slow response...

Signal source and scope settings please...
 

[2N3055]

Speaking of blind time, I’d be very curious to know what it is.

All the documentation mentions a re-trigger time of 21 ns, but says nothing about the time required to refresh the screen.
Either this happens in parallel, so it’s not noticeable, or it takes milliseconds like on any oscilloscope, in which case it’s just marketing.

Did you just asked if scope refreshes screen 4,5 Million times per second?
Of course it does not. It refreshes it 50-60 times per second. Like any normal screen... It combines cca 80000 captures and render one screen refresh. And on.

If you managed to somehow buy IXian bionic eyes that can see the difference and resolve millions of frames per second individually please let us know. I would like a pair too.

I was referring to how much emphasis is placed on the fact that it has this extremely short retrigger time.  As if there were no refresh time.
When in fact it’s normal, resulting from the nature of how this type of trigger is implemented.
Magnova has 70 ns only because it has a lower sampling rate.

From this perspective, there’s nothing extraordinary about it; it’s natural given its nature.

On the other hand, there are situations where a “classic” trigger is better.

What does screen refresh has to do with blind time where scope is not triggering? Did you not understand?
Scope triggers 80000 times, 80000 times it takes a full screen of data, and saves it into screen buffer. After 1/60th of second, after 80000 such acquisitions, a display frame consisting of all of those 80000 captures is pushed into the screen. And another 80000 are getting prepared. You are talking like scope is triggering without doing anything, and then only 60 triggers in second get shown on the screen. They are all shown, all 4,5 Milion in a second are on the screen, shown 60 times a second in chunks of 80000.

21 ns is very short retrigger time. Magnova has lower sample rate? What does it have to do with anything? If anything scope with higher sample rate will in same time acquire more data points and will have more processing to do. So it should be slower not faster.

Keysight 3000T has min blind time of a bit less that 1µs. I would say 21 ns is quite much less blind time than that.

Problem with MXO3 is that trigger rate drops to mere thousands per seconds as soon as you enable basic measurements. While Keysight will not slow down. So 21ns is marketing gimmick here, because of that. It will keep that rate only with basic screen display, with nothing else on.
But a scope that would have 21ns blind time and could process data and measurements in real time would be big deal.

[MASCH]

Here is another video showing the slow response...

Signal source and scope settings please...

Input signal was a swept sine form the internal generator.
Sweep time 10ms.

All other setting are visible on the screen....what else do you need?

As you can see, even only resizing the windows vertically is super laggy

If using a mouse for control of the scope, the mouse pointer is also lagging....no joy to use....

[core]

What does screen refresh has to do with blind time where scope is not triggering? Did you not understand?
Scope triggers 80000 times, 80000 times it takes a full screen of data, and saves it into screen buffer. After 1/60th of second, after 80000 such acquisitions, a display frame consisting of all of those 80000 captures is pushed into the screen. And another 80000 are getting prepared. You are talking like scope is triggering without doing anything, and then only 60 triggers in second get shown on the screen. They are all shown, all 4,5 Milion in a second are on the screen, shown 60 times a second in chunks of 80000.

What does screen refresh has to do with blind time where scope is not triggering? Did you not understand?
Scope triggers 80000 times, 80000 times it takes a full screen of data, and saves it into screen buffer. After 1/60th of second, after 80000 such acquisitions, a display frame consisting of all of those 80000 captures is pushed into the screen. And another 80000 are getting prepared. You are talking like scope is triggering without doing anything, and then only 60 triggers in second get shown on the screen. They are all shown, all 4,5 Milion in a second are on the screen, shown 60 times a second in chunks of 80000.

Yes, I get it.
That's exactly what I asked. Let me give you an example because I think something is lost in translation due to the language barrier.

On an SDS2100X Plus I measured a maximum rate of about 125kwfs/s at 50ns/div.
So about 8us allocated for each 500ns screen.
500ns would be the acquisition itself, and 7.5us would be the re-trigger time.

At the end of an acquisition burst (of about 30ms) there is a pause of about 3.5ms. This pause between two bursts (I called it blind time) is for refresh and probably data processing.

Does this pause also exist in the case of an MXO, or is the processing and display performed in parallel with the acquisition and there is no pause? That's what I meant.

If it appears, it cannot have a 99% acquisition rate even if it only has a 21ns re-trigger time.

I have attached some pictures for the given example.


P.S. Of course, for the above example the total blind time on an acquisition cycle is 3.5ms + 7.5us x the number of samples in the burst (the 30 ms).

[Martin72]

.what else do you need?

Horizontal settings, vertical settings, memory settings, FFT settings....
If you've done a sweep, please provide the start frequency, stop frequency, and step size.
Or you can just upload the setup file from the settings here, and then I can import it directly into the MXO.

For real compare, I need to set the same parameters; thanks.

[tooki]

Just to note, when you change settings like that on timebase, scope actually reconfigures FPGA processing of datastream. That might take a moment, depending on what reconfig is, and what memory size and timebase it is. As for vertical, it also have to reconfig front ends, and rescale all the values etc.
Everybody likes how Keysight 3000A/T/G series are fast in responding to user. But they forget they have puny little ACQ memory, low res screens, and only 8 bits of datapath.

I don't think anyone forgets that. The fact is that Keysight did a stellar job at designing a system architecture that delivers fantastic perfomance. The fact that it's outdated by today's standards is not relevant: competing scopes from when those were new were also much slower. As are many that came later with similar specs!

And in the new Keysights, they more or less maintained that responsiveness.

[2N3055]

Just to note, when you change settings like that on timebase, scope actually reconfigures FPGA processing of datastream. That might take a moment, depending on what reconfig is, and what memory size and timebase it is. As for vertical, it also have to reconfig front ends, and rescale all the values etc.
Everybody likes how Keysight 3000A/T/G series are fast in responding to user. But they forget they have puny little ACQ memory, low res screens, and only 8 bits of datapath.

I don't think anyone forgets that. The fact is that Keysight did a stellar job at designing a system architecture that delivers fantastic perfomance. The fact that it's outdated by today's standards is not relevant: competing scopes from when those were new were also much slower. As are many that came later with similar specs!

And in the new Keysights, they more or less maintained that responsiveness.

How conveniently you gaze over "puny memory" parameter here.
I did not mention it to hint of modernistic or not. It is math.
SDS800 has literally 25x more memory than msox3000T. Actually 50X because 16 bit datapath.
It is not fantastic architecture, it is literally 50x less work.

[KungFuJosh]

I also had the Magnova as a demo unit before the MXO3 and I can say that the Magnova is waaaaay faster and much more pleasure to interact with.

It is awesome. I made a video and put it in the other thread: https://www.eevblog.com/forum/testgear/magnova-oscilloscope/msg6223301/#msg6223301

[tooki]

Just to note, when you change settings like that on timebase, scope actually reconfigures FPGA processing of datastream. That might take a moment, depending on what reconfig is, and what memory size and timebase it is. As for vertical, it also have to reconfig front ends, and rescale all the values etc.
Everybody likes how Keysight 3000A/T/G series are fast in responding to user. But they forget they have puny little ACQ memory, low res screens, and only 8 bits of datapath.

I don't think anyone forgets that. The fact is that Keysight did a stellar job at designing a system architecture that delivers fantastic perfomance. The fact that it's outdated by today's standards is not relevant: competing scopes from when those were new were also much slower. As are many that came later with similar specs!

And in the new Keysights, they more or less maintained that responsiveness.

How conveniently you gaze over "puny memory" parameter here.
I did not mention it to hint of modernistic or not. It is math.
SDS800 has literally 25x more memory than msox3000T. Actually 50X because 16 bit datapath.
It is not fantastic architecture, it is literally 50x less work.

You didn’t understand my point.

I’m not ignoring the small memory, I’m saying that the small memory isn’t why it’s fast. It’s fast because they designed it to be that way. Other scopes from 2013 had similarly small memory, but didn’t come close to achieving the performance of the Keysight. You can design a slow scope with small memory and only 8 bits, and indeed many before and many since were.

It only got worse as higher bit depths and deeper memory became common.

Computing resources have come a long way since the MegaZoom 4 ASIC was introduced in 2013. It should be eminently possible to make a fast architecture with modern memory and bit depth. Oh wait, it is, because the Keysight HD3 with the new MegaZoom 5 is also really snappy, and it’s a 14-bit scope. (Its 100Msa memory is definitely not the deepest out there, but its way more than before...)

And from what I hear, the Magnova is snappy. So are the Windows-based LeCroys. So are Windows-based LeCroys from 15 years ago, with much weaker CPUs than modern ones.

It’s all about the architecture: what do you do in hardware (ASIC or FPGA) vs in the CPU/GPU, how are the ASIC/FPGA connected, etc. What you want for good responsiveness is for the CPU/GPU to do as little as possible on the signal processing side of things. Its job should be to draw the UI and control the acquisition/signal processing hardware. Anything else and performance plummets.

It also depends on the software architecture running on said CPU/GPU: if you have a sluggish windowing/UI library, the UI will never be snappy.

[KungFuJosh]

I’m not ignoring the small memory, I’m saying that the small memory isn’t why it’s fast. It’s fast because they designed it to be that way.

Not exactly accurate. At the time it was fast compared to slower scopes, true. However, if you want to compare it to modern scopes, reduce the memory size on the modern scopes and you will see a difference in speed. It takes time to fill memory.

[tooki]

I’m not ignoring the small memory, I’m saying that the small memory isn’t why it’s fast. It’s fast because they designed it to be that way.

Not exactly accurate. At the time it was fast compared to slower scopes, true. However, if you want to compare it to modern scopes, reduce the memory size on the modern scopes and you will see a difference in speed. It takes time to fill memory.

Nope, you’re also not getting it! A sluggish UI architecture is sluggish no matter what is, or isn’t, being done. An MXO4 is never as snappy as a Keysight, no matter what the settings are.

A good architecture separates the UI from the signal processing, so that even if the signal processing hardware is busy, the UI remains responsive. For example, on many scopes, the 0V indicator (little triangle or whatever) moves up and down smoothly, even if the waveform itself cannot.

But even if that aspect has been done properly, if the UI architecture itself is not snappy, you have a ceiling on how snappy the UI can ever be. The MXO UI just isn’t snappy: there is always a slight delay. Good touch UI design requires 60-120Hz update rates and motion that tracks fingers within a few milliseconds. The MXO fails at this. It’s not as though we’re talking about a second of delay (usually), but it does lag by enough milliseconds that it always feels a bit… sticky.

[KungFuJosh]

Nope, you’re also not getting it! A sluggish UI architecture is sluggish no matter what is, or isn’t, being done. An MXO4 is never as snappy as a Keysight, no matter what the settings are.

I do understand what you're saying, though I've owned neither brands' scopes to compare.

However, in modern scopes, both UI response and measurement response can be affected by scope setup and how much is going on. Lower memory set = faster acquisition, and less active stuff will often result in better UI response. The combination of both can effect each other as well.

If Keysight's UI is more to your liking than R&S, then you should go with KS if the scope meets your needs.

I also value a snappy UI.

[tooki]

Nope, you’re also not getting it! A sluggish UI architecture is sluggish no matter what is, or isn’t, being done. An MXO4 is never as snappy as a Keysight, no matter what the settings are.

I do understand what you're saying, though I've owned neither brands' scopes to compare.

However, in modern scopes, both UI response and measurement response can be affected by scope setup and how much is going on. Lower memory set = faster acquisition, and less active stuff will often result in better UI response. The combination of both can affect each other as well.

Yes, they usually are, but they shouldn’t be. Keysight managed to properly decouple things so that the UI is never held back by the measurement system.

If Keysight's UI is more to your liking than R&S, then you should go with KS if the scope meets your needs.

I thoroughly evaluated (i.e. had loaner units of, not just a paper analysis) all the major brands when I was tasked with buying a new scope at work. I ended up going with the MXO4 because I thought it best complemented the existing LeCroy. However, having now had it for two years, I think I would have been happier overall with the Keysight, despite its smaller, lower-res screen and meager memory. The MXO4’s sluggishness (and IMHO poorly thought out menu structure) are constant annoyances.

In the end, the spectrum analyzer in the MXO4 ended up being one of the deciding factors, as is the MXO4’s fantastic browser-based remote control interface. So I don’t think I made a bad decision, but it doesn’t mean I can’t complain about the MXO4’s UI. Because it really could, and should, be better, even if they have added in many of the missing features that it should have had from day 1.

[CRTbrain]

fyi... there are no GUI animations in normal use of the scope.  The only animations are ones in a menu that lets the user get an idea of what each tool in the tool bar does.  Other than this, there is no animations.

[skander36]

fyi... there are no GUI animations in normal use of the scope.  The only animations are ones in a menu that lets the user get an idea of what each tool in the tool bar does.  Other than this, there is no animations.

I see no animation at all in MXO4 menus. Only static icons. Even in demos included. Maybe the term "animation" was misused, means graphic representations?

[core]

fyi... there are no GUI animations in normal use of the scope.  The only animations are ones in a menu that lets the user get an idea of what each tool in the tool bar does.  Other than this, there is no animations.

I see no animation at all in MXO4 menus. Only static icons. Even in demos included. Maybe the term "animation" was misused, means graphic representations?

In normal use, does it react slowly to commands?
Or in what situations have you encountered this?

From other comments I understand that especially the encoders are read with a delay and not the commands on the touch-screen.
In normal use, do these things occur or only if it is rotated at an unnaturally high speed?
I use Siglent and Rigol, so these could be the comparisons I am used to. These do not seem too slow to me.

[skander36]

...

In normal use, does it react slowly to commands?
Or in what situations have you encountered this?

From other comments I understand that especially the encoders are read with a delay and not the commands on the touch-screen.
In normal use, do these things occur or only if it is rotated at an unnaturally high speed?
I use Siglent and Rigol, so these could be the comparisons I am used to. These do not seem too slow to me.

In usual use cases, it reacts at touch and knob commands as the Rigol DO1000 HD so pretty fast. But when on screen are present more measurements (as in Power Quality test - 12 parameters) the results (ex. increase or timebase or vertical) on screen appear with some slowness. Encoders are readed fast no doubt, but processing the requested commands and displaying the results is a little slow in such use cases. The encoder cannot be read more slowly even if the scope is busy, it has a separate controller that is doing his job apart from the rest of the system.