R&S MXO3 review and tests

[nctnico]

Rohde & Schwarz MXO3 review
A while ago Rohde & Schwarz contacted me to ask if I'd be interested in reviewing their new MXO3. Sounds like fun and it has been a while since I did an oscilloscope review so let's do it!

Since the RTM3004 review the local Rohde & Schwarz office has moved to a brand new building in Utrecht so picking up the MXO3 gave me the opportunity to get a look at their new offices as well :-)

And it looks cool on my desk. Nice big screen and no less than 8 channels!



A quick summary with the most important base specs:
4 or 8 analog channels
1 external trigger input
<1ps trigger jitter
12 bit ADC
RIS acquisition mode

Options:
16 channel MSO option (5Gs/s, 300MHz bandwidth)
Segmented recording up to 500Mpts in total
Protocol decoding & triggering
50MHz Waveform & pattern generator (5Vpp into 50 Ohm / 10Vpp into high-Z)
Spectrum analysis mode
Power analysis

I'll be reviewing the 8 channel, 1GHz model with most common options enabled / present (including MSO) with firmware versions 2.8.2, 2.9.2 and 2.10.2

The MXO3 comes standard with 500MHz passive probes (one for each channel) and when the MSO option is ordered with two MSO probes. A front cover and a carrying bag where included with the demo unit I received.

What sets the MXO3 apart from the RTM3004 is more memory, much lower trigger jitter, zone triggering, the option to have 8 channels and last but not least, a much higher overall performance level. There are also some changes in the user interface. Where channel color settings are under the channel configuration on the RTM3004, on the MXO3 they live under main menu -> settings -> appearance. So expect a bit of a learning curve when upgrading from the RTB2004 / RTM3004 to an MXO3. Coming from the R&S RTM3004 myself I can't help myself to make a comparison here and there.

With the B105 option the memory gets expanded to a whopping 500Mpoints. However, the MXO3 uses double buffering so the maximum depth is only available when running in single shot acquisition mode or with half the channels enabled. The same goes for the samplerate. With half the channels enabled, the samplerate is 5Gs/s, with more than half of the channels enabled, the samplerate drops to 2.5Gs/s. Still, 2.5Gs/s is enough to achieve the maximum bandwidth of 1GHz. When the digital channels are thrown into the mix, the memory halves again. So with 8 analog channels and digital channels enabled, the memory depth is 125Mpts per channel. But keep in mind that you'll have a combined total of 24 channels on the MXO38! Also, when using the maximum record length there is enough internal memory to have 3 acquisitions in the memory (the current acquisition and two previous acquisitions in the history buffer).


Test plan
Per usual MO I have devised a bunch of tests to see where the limits are and how certain features work to solve real world engineering problems.

Tests in random order:
- Bandwidth / aliasing
- Fan noise level
- Low level signal triggering
- Trigger jitter
- Frequency (zone) triggering
- Sequence triggering
- Signal noise floor
- Overdrive recovery
- Math
- MSO inputs
- Protocol decoding, required over sampling and how much of the memory is decoded
- Deep memory and decimating long traces onto the display
- Automatic measurements
- FFT function / Spectrum analysis mode
- DVM application
- 12 bit usefullness and noise
- Saving images
- Cursors (outside screen?)
- Operating / using the scope
- Peak detect and roll mode
- Segmented recording and decoding
- Storing and manipulating reference waveforms
- Waveform generator
- Power rail measurements
- PDN analysis (power rail frequency response)
- XY mode
- Waveforms/s

As the manual for the MXO3 consists of over 1700 pages it should be no surprise there is much more explore. However, I had to make a selection of tests for items/features that I find relevant and differentiate one oscilloscope from the other.

The secondary goal is to use the oscilloscope for a while to get used to the operation and in order to spot stability problems / usability issues.


Shahriar (The Signal Path) already did a teardown and took a deep dive into RF performance and triggering. Forum member Martin72 also did a 'short' review on the MXO3:
https://www.eevblog.com/forum/testgear/rs-mxo3-a-short-review/

First impression
The first impression after turning it on: wow...   it is   bright! Even in a very well lit office. The front panel LEDs are bright and the screen is bright. Fortunately both can be adjusted. I dimmed the front panel LEDs to 15% and the screen to 80%. So there is plenty of headroom to turn the brightness up if needed. What also stands out is that the MXO3 has a matte screen. When the RTB2004/RTM3004 came out, a lot of people were worried the glossy screen would be a problem. R&S addressed these concerns and fitted the MXO3 with a matte screen.

On the front panel the knobs and indicators are neatly organised into groups for triggering, horizontal, vertical and auxiliary functions. Being used to touchscreen equipment, I must say I hardly use any of the buttons on such test equipment. I mostly use the rotary knobs to make quick adjustments. For the rest, the touchscreen is more versatile. I think R&S has ended up with a good balance between having the necessary buttons on the front panel without making it cluttered.

And of course the MXO3 has a single sensitivity (V/div) and position adjustment for the channels. Having 8 vertical sensitivity, setup and position controls would need a huge amount of space on a front panel. Which takes me to the size of the unit: it is nice and compact. Measuring about 37cm in width it takes up just as much bench space as my other daily driver scopes. The analog channels are connected at the front, the digital channels at the right. Unfortunately having 8 analog channels meant that the generator output and external trigger input are located on the back. The front panel does have two USB sockets though for a USB stick and/or to power a universal probe which are typically powered through USB nowadays.

What I'm missing on the front panel is a force trigger button. I use this regularly for some measurements. Fortunately it is possible to add this as a hot-key function on the touchscreen so this functionality isn't lost. I guess keeping the front panel minimalistic meant sacrificing some physical buttons and I'd agree that the force-trigger button would be the least used one.

For an oscilloscope with so many analysis features, the screen is always too small. On the MXO3 this is solved by having multiple tabs (workspaces) allowing the user to create virtual workspaces. After adding a new tab, the 'contents' can be dragged into the display area. This works by dragging one of the active signals (input, math, tracking, spectrum, etc) from the bottom bar into the display area. The display area will then highlight the position where the signal will be placed if you remove your finger. A signal can be placed into an existing grid or a new grid. This is not obvious from the UI but it works pretty well once you know it is there. If the traces are compatible (same X axis), they can be shown together in a single grid but it is also possible to create separate grids. The image below shows layout. A handy shortcut to add to the top bar is the waste bin. This allows to remove content from a tab. After having used the MXO3 for a while I can say the tabs are a great way to get more out of the screen real estate. And of course the tabs can be given a name so it is easy to see what is in which tab.

This image shows a tracking trace (frequency measurement) on a signal with a linear frequency sweep. The other tab shows 3 inputs and the spectrum analyser window.





Other inputs /outputs
At the back there are three more BNCs: 'trigger in', 'trigger out' and the generator output. The 'trigger in' connector is a regular external trigger input which can be configured like a normal input channel (50 Ohm / 1M Ohm, AC/DC coupling). So every input channel can be used to display a signal while having a 5th or 9th analog signal to trigger on (depending on whether you have the 4 channel or 8 channel version). The trigger output signal is a 5V (high-Z load) digital signal to notify other instruments a trigger event has occurred. The generator output speaks for itself.


Probes and accessories
The MXO3 comes with probes for each channel. The probes are fixed 1:10 and have tips with a pogo pin (a spring loaded pin). The cable is flexible and the probe itself has a slim design so it is easy to reach difficult spots. The color coding clips that come with the probes only have 4 colors though.

The digital channels need special digital probes. These use a display-port style connector. The RTM3004 uses a wide HDMI style connector. It would have been nice if the RTM3004 and MXO3 digital probes were interchangeable but I assume the wide HDMI connector has become obsolete in the meantime. There is also some room for improvement on the probe leads. It would be nice if these would come pre-numbered (and color coded) instead of needing to put stickers on them yourself.

Fan noise
If you look at the back of the MXO3 you'll notice it has a huge fan. I estimate it is a 140mm diameter fan. As a result the MXO3 is whisper quiet so it is not annoying to use in my rather quiet lab. However (as Shahriar has noted as well), the BNCs feel quite hot when the MXO3 has been on for a while. I wouldn't object to the fan running a bit faster just to keep the internals of the MXO3 cooler. When the MXO3 is pushed with long traces and heavy measurements, the fan speed does increase a little bit (according to my very sensitive ears). But the sound level stays very far away from becoming annoying.


Vertical
The vertical controls allow setting an offset based on divisions or absolute voltage. A voltage offset keeps the signal centred on the display when changing input sensitivity. A division offset keeps the zero level of the signal on screen. The voltage per division can be adjusted in 1-2-5 steps or variable. One thing to keep in mind is that there is a separate DC offset and trace position. The DC offset typically spans a much larger range compared to the trace position so the DC offset is a useful tool to bring the trace on screen in case the trace position isn't sufficient. In case of the MXO3, the trace position spans 10 divisions. However, the MXO3 has a setting which allows the vertical position knob to either control the trace position or the DC offset so you can set this to your preference. From the channel menu you can adjust both.

What confuses me in the channels dialog is that when disabling a channel, the dialog jumps to the next active channel. Having quick trigger fingers I immediately try to disable the channel because I get the impression the touch was missed. And there seems to be little logic as to which active channel is chosen to display the settings for. I think it would be better that when a channel is disabled, the dialog for that channel stays open. At least that is predictable behaviour.

It is worth mentioning the MXO3 has a very large DC offset range (compared to other oscilloscopes) which reduces the need to use special probes (like a power rail probe) or differential probes in certain situations. Below 60mV/div the DC offset range is +/-3V while above 1V/div, the offset range is +/-250V DC. Together with the 12 bit resolution, this enables to use common probes or even have direct connections to do measurements which would require special (expensive) probes on oscilloscopes with a lesser DC offset range and less resolution (less bits).

Channel labels
Every channel can be given a label. The input not only allows to use an on-screen keyboard but it also allows to input the characters by drawing the characters one by one with your finger. This works quite well. There is also a hot-key to add a smiley to the text :-)


Horizontal
The horizontal (time/div) setting goes to 200ps / div. Given the very steady triggering I'd say it wouldn't hurt to make the lowest setting 100ps/div. The post-trigger delay can be up to 5000s which is more than large enough. For time critical measurements the accuracy of the timebase will need to be taken into account though as the MXO3 doesn't have a frequency reference input. If necessary, an alternative way to compensate for time offsets needs to be used. Like measuring a 10MHz reference clock along with the signal under test so an event can be related to the 10MHz reference precisely (either visually or through a measurement). I have found that when setting the horizontal position to 1s, the signal drifts by about 1ns per second on the unit I have tested with.


Bandwidth / aliasing
Let's get an RF generator hooked up. First thing I want to look at is how the sin x/x reconstruction holds up at 2.5Gs/s. It turns out the sin x/x reconstruction works up to 1.1GHz before serious distortion starts to happen. Interestingly the MXO3 has the same small signal behaviour as the RTM3004 when the input signal is above the bandwidth. But when testing the RTM3004, it doesn't seem like a big problem after all. All in all it looks like the MXO3 has the same signal post-processing system.

I measured the bandwidth on channel 5 at 5Gs/s with averaging enabled to get a clean signal. I measured using a -20dBm and a +9dBm signal. The reason for using 2 different amplitudes (levels) is that for small signals, there has to be an amplification of the signal which could affect the bandwidth and frequency response. For higher amplitude signals the signal path is likely direct (or even attenuated). During the measurement of each input level the same V/div setting is used (kept constant) as to make sure the same attenuation / amplification is in effect. I used 10mV/div and 200mV/div. The bandwidth is measured compared to the level at 10MHz.

This is the resulting graph:


Deep memory
With a maximum of 500Mpts (half channels, no digital channels) the MXO3 has plenty of memory. Although the MXO3 can slow down a lot when deep memory is enabled. It can take a little bit of juggling to find the right tradeoff between setting the right memory length versus getting most speed. The latter is especially true when a measurement is enabled as the MXO3 bases its calculations from acquired data.

The amount of memory available depends on how many channels are enabled. From testing I derived the following list: 500Mpts with digital only OR half the analog channels only, 250Mpts with half analog channels + digital, 125Mpts full channels.

Acquisition modes
The MXO3 has four acquisition modes: sample, peak-detect, envelope and averaging. HD (High definition / High-res) mode which uses oversampling to get more bits from the ADC at the expense of bandwidth, can be enabled separately regardless of the acquisition type. To make things easy, the bandwidth can be adjusted so you have a good insight in what to expect from the measurement. In my opinion defining HD mode as a bandwidth limit is a good choice as it is immediately clear what the effect on the signal will be. I'm more interested in what part of the original signal will be included and what part will be lost rather than the number of bits. The status information does indicate the number of effective bits based on the setting.

In averaging mode the number of averages has to be set in the N-single field which is also used in the history / segmented recording setup. What I like is that the average trace remains when the horizontal position and time/div are changed after acquisition has been stopped. So you can analyse an averaged trace in more detail.

The same menu also has the settings for the samplerate (SR) and record length (RL). By default these are set to manual to achieve the fastest waveform update rate while using the highest samplerate to fill the screen. But it is possible to set either. Setting the samplerate and record length allows to have full control over the timespan an acquisition takes regardless of the time/div setting. A useful situation is looking at a specific part of a signal (say an I2C transaction) and when it fails, there is a long trace which can be analysed to figure out what lead to the failure and what happens afterwards.

Of course the MXO3 supports history and segmented recording where history is an automatic segmented recording mode which simply uses the remaining acquisition memory to store previous acquisitions. Segmented recording has the typical settings for record length and number of acquisitions to make before the segmented recording session is complete.

Peak detect and roll mode
Something I like to test is whether peak-detect works in roll mode. For this test I created a 10ns pulse which repeats every 200ms. By forcing the memory length short, I made the MXO3 undersample the signal. With peak detect enabled, the pulse still showed up in roll mode so this test is a pass. The reason I find this test important is because I like to check whether interrupts on a microcontroller fire on time (through toggling in I/O pin). The interrupts take nanoseconds to execute nowadays and may not be very frequent. Using roll-mode gives a nice realtime overview of how the system behaves.


Signal display (colors and persistence)
The signal display settings have been 'hidden' in the settings menu. I did some tests around various trigger modes. I found that with persistence mode off, I still get two overlaid acquisitions every now and then. With persistence enabled, the previous acquisition is shown dim. This feature can be handy when wanting to compare a new measurement with an old measurement quickly (without going into the history and so on). The previous acquisition can be removed from the screen when moving the position a little bit.

Several overlapping acquisitions:


The last one (after wiggling the horizontal position):


In addition to persistence on / off it is also possible to set the persistence time or have infinite persistence. In normal trigger mode, the persistence only fades with new triggers. It doesn't fade if there are no new acquisitions which I think is a good thing. Without new information, it makes little sense to remove the information which is already there.

The display modes for a trace are located in the setup menu under appearance -> colors. Besides the analog channels, the way all possible traces are displayed can be configured. The MXO3 offers various ways to color a trace based on where a trace spends most or least of its time. Besides temperature, spectrum and false colors there is also a single-event setting which makes rare / random events stand out. The screenshots below show a signal where 1 in 50000 pulses has a different duty cycle.

First using normal display mode:


Now with single event mode. The pulses with the alternate duty cycle are very clearly visible!


Histograms
The histogram function can be used to show where a signal spend most of the time. Both vertical and horizontal histograms are supported. It is also possible to define a window for the histogram function so a part of a trace can be examined in more detail. I would have liked it if there is some (temporary) visual hint about the size of the window but maybe I got too used to visual hints. The size of the histogram itself can be adjusted as well.

No window:


With a window:


Waveforms per second
This is always a hot item on the forum. Martin72 has already touched this subject in his review and determined the MXO3 does achieve the over 4 million waveforms/s spec. Hardly a surprise with a company like R&S making the claim. Still, it is not all about waveforms/s but how much of a signal is captured. In the acquisition menu there is a menu item called speed. This lists the number of waveforms/s, blind time and percentage of the signal being captured. The latter is the most useful piece of information here IMHO as it tells me how complete the picture is. With some tweaking of the time/div and memory depth, percentage can be brought very close 100% which means whatever the signal looks like, very little remains hidden. Interestingly, getting close to 100% is not where the highest number of waveforms/s is!





Triggering
Triggering is just rock solid. The trigger jitter spec is below 1ps RMS. A nice feature of the trigger system is the ability to adjust the hysteresis window. This helps to reduce the trigger lensing effect and get a more realistic view of how a signal would be seen by an input (like a digital signal which has relatively large threshold). Together with the ability to deskew the channels, the MXO3 allows to make very accurate (low tens of ps level) delay measurements between signals. Better than you'd get from a typical time interval counter (which typically can't measure below 50ps and/or has a large assymmetry between the input channels).



The minimum trigger level to get a stable trigger on a 100MHz sine wave is 1/5th of a division (20mVpp at 100mV/div). This is with the hysteresis set to 0 manually. The automatic hysteresis setting requires about half a division of signal. But this is good enough. At 1/5th of a division a signal is basically a flat line unless zoom is used.



Zone triggering is helping to qualify whether a trigger event should lead to updating the trace on the display. With zone triggering it is super easy to trigger on malformed parts of the signal or just to find gaps. But keep in mind that zone triggering is not a trigger in itself. The fact the MXO3 is put into sequence triggering mode gives that away. The first step is to find a trigger event (which can be any of the trigger types like edge, runt, width, slew-rate, etc). The next step is to qualify the trigger event using the zone triggering conditions. This can be used to define rather complex trigger conditions using multiple zones and logical combinations between zones (including using the frequency spectrum!).

As a third alternative the trigger system has a sequence mode which is typically found on older logic analysers. The sequence mode uses two conditions (A and B) which must become true sequentially for the trigger event to 'happen'. These conditions also include a counter. A third (R) condition can reset the trigger state. So this basically is a programmable state machine to detect a very specific combination of events. As each condition can be set to use one of the trigger modes, the possibilities are endless. This is probably not a feature you'd use every day but if you have a problem which occurs very rarely, having sequence triggering can be worth more in saved time than the purchase price of the MXO3. Spoiler alert: Unfortunately the sequence triggering can only be used with the analog channels.

A special feature of sequence triggering is combining a regular trigger event and bus decoding. This can be used to check the response of system on an input. For example: a user presses a button (input goes low) and the system sends a message. Using sequence triggering, the A event can be the button input and the final trigger event can be the start of the message. This allows for triggering on very specific conditions and getting rid of irrelevant data.

Another feature is to let the MXO3 freerun without trigger. It will just capture & display without caring about where the trigger point is.

What is not there, is a short trigger hold-off delay after a trigger in auto trigger mode. Having this helps to keep a trigger event on screen for a short while when the trigger is set to auto mode. This way you can see the signal when it is idle and see trigger events happening. IIRC the RTM3004 does have this feature. There are pros and cons to both approaches and I guess most of R&S' customers didn't like the delay after a trigger in auto trigger mode. Since I like this feature for some of the measurements I make, I was kind of hoping this could be configured somewhere in the trigger menu in the hold-off section but I have not been able to find it. To me the most logical place for this setting would be the trigger hold-off menu.

While on the topic of trigger hold-off: the trigger hold-off function does have some interesting settings though. Besides setting a fixed time delay before a new trigger is accepted (which is the standard hold-off function of many oscilloscopes), you can choose between ignoring a number of trigger events (instead of a time delay), a random time (between two limits) and a time delay based on the horizontal time/div setting.

Sequence triggering in action
As mentioned above sequence triggering only works on analog channels. Nevertheless I found it interesting enough to dig into it a little bit deeper. So I created a pattern consisting of a 0.5MHz square wave with missing pulses (channel 3) and a signal with seemingly random pulses (channel 1). Something you can't get a stable trigger on very easily.

The sequence state machine goes from idle to state A (trigger event A), from state A to state B (trigger event B) OR from state A to idle through a reset trigger condition or timeout. Once state B is entered, the trigger conditions are met and a trigger is fired. There is a little bit more to it as it is also possible to set a delay when in state A before starting to look for triggers that take the sequence to state B.

My first thought was to trigger on the missing pulses and then look for the longer pulse. However, the event counter only works for trigger condition B, not trigger condition A. Still I wanted to test this feature. So I setup a trigger to look for a minimum width pulse on channel 1 using trigger event A. Once in state A, 4 missing pulses need to be detected using trigger condition B. I setup trigger condition B to fire when the signal stays low for more than 2.5us. If trigger condition B is not met within 100us, the reset timeout kicks in and the trigger sequence goes back to idle.

This seems to work OK-ish. A problem I spotted is that every now and then the trigger fires after 3 events instead of 4. I don't see why this happens. It would be nice if the trigger A condition also had an event counter. After all, sequence triggering implies looking for a sequence of events. In my example it is only possible to trigger on missing pulses after a pulse. Not the other way around.





Still, for a real world project sequence triggering worked like a charm. I needed to look at a protocol for which each message starts with two wide pulses. Sequence triggering was the answer to get the start of the frames triggering rock solid.


Spectrum zone triggering example
One of the features of the MXO3 is that it can qualify a trigger based on the frequency spectrum of the signal through zone triggering. For this you need to setup spectrum analysis, draw a zone trigger box around the frequency spike of interest and set the triggering to zone triggering. What happens is that the MXO3 triggers on the input signal but also checks whether the zone conditions are met. This allows for rather complicated trigger setups. As a test I used an RF generator which I set to alternate between 1.1MHz and 2.1MHz (so a 100ms burst of 1.1MHz and a 100ms burst of 2.1MHz). In addition I used a function generator to feed in bursts of a 333kHz sine wave. Using the zone triggering I can trigger when the 1.1MHz signal is present AND when the 333kHz signal is present. But it is also possible to trigger on the 1.1MHz when the 333kHz signal is NOT present. Now this feature isn't an alternative for alternate triggering. With the triggering setup to trigger when the 1.1MHz signal AND the 333kHz are both present at the same time, it depends on the trigger source channel which waveform is displayed as a stable waveform on screen. Using the single trigger mode can help to get both signals stable at the expense of needing to press the button for every acquisition. For some reason it is not possible to set a trigger hold-off time combined with zone triggering. If you can slow the trigger rate down using trigger hold-off, you could see both signals stable at the same time.










12 bit usefulness
The specifications of the MXO3 has a long list with noise floor levels at various sensitivities and bandwidths so I'm not going to dive deep into that. In the end I'm interested in whether 12 bit can help to get more details in a signal so let's throw a real world problem at it! A few years ago (time flies!) I tested a Korad KEL2010 DC load which has a 50Hz ripple of about 1mApp at the output (after I did some modifications to the KEL2010). In that test I used a 10m Ohm current shunt. This means that the signal (=measure current) going into the oscilloscope has an amplitude of 10uV peak-peak. At 1mV/div and having 10 divisions, the range is 10mV. As a 12bit ADC has 4096 discrete steps, each bit spans about 2.4uV. So in theory the input signal amplitude should be detectable by the ADC. On the Yokogawa DL708 scope I used for that test (also 12 bit) I had to enable low-pass filtering, line triggering and averaging to get a visible trace. On the MXO3 doing the same measurement is not a problem at all when using HD (high-res) mode to have low-pass filtering combined with averaging (and line triggering). The only limitation I have found is that the trace offset and cursors move in steps of 10uV so you can't make a cursor measurement in the zoom window at uV levels.



The harmonics also show up in the frequency spectrum:



Overdrive recovery
There is a limit on the signal amplitude you can apply to the input of an oscilloscope before you get distortion in the signal. The time it takes to recover from such a situation is something to keep in mind when using an oscilloscope in a situation where the amplitude may exceed the range. Because the MXO3 has a large DC offset range, it can handle large amplitudes before being overdriven. However, when overdriven it takes about 500us before the input circuitry recovers according to the test shown in the screendumps below.

The same signal. first normal, then overdriven.




Saving images
Saving images is a matter of pressing the button with the camera on the front panel. By default the images end up on a USB stick if that is plugged into one of the two USB ports on the front panel. It just works out of the box.


Measurements
One of the first things I like to know about measurements is whether these are taken on acquired data or whether decimated data is being used. A quick check is to input a signal (preferably a square wave) and let a DSO measure the rise time. If the risetime starts to increase (or show that it can't be measured) with increasing time/div settings, it is a sign that the oscilloscope is using decimated data ((even though the samplerate / memory depth are high enough to resolve the risetime properly). When testing the MXO3 it turns out the measurements are performed on acquired data. Nice! I did find something odd though. I tried the pulse counting function and found out that the maximum number of pulses that can be counted is 1 million. At first I thought the samplerate was too low but after increasing the memory depth it was still hitting this limit. After a bit more testing & tweaking it turned out the limit for pulse counting really is 1 million pulses. It would have been nice though if this result would be flagged as invalid or overrange. With deep memory enabled, it is easy to get more events in the memory than can be counted.

For measurements which use edges, the reference levels can be adjusted as well. The reference levels can't be adjusted directly but must be selected from a defined set of reference levels. This allows the same reference levels to be used across several measurements instead of setting the reference level for each measurement.

The same goes for selecting the part of a signal which is measured (gating). The MXO3 has separate gate configurations which can be applied to a group of measurements.

Zoom mode
Zoom mode just works. Besides drawing a rectangle in the main window to select the zoom area, it is also possible to use the time/div and horizontal position knob for finer adjustments which is handy when wanting to zoom in deep into a signal. I have added some images in this review showing zoom mode in action. The fact that the zoom window has an adjustable size makes it possible to have sensible tradeoffs between the amount of original signal being visible versus the amount of zoomed-in signal.


MSO inputs
The 16 digital inputs are divided over two 8 bits pods. A nice feature is the adjustable hysteresis. One of the problems I had with an MSO from Agilent was that it would create false pulses because the hysteresis was too small to deal with a slow edge from an I2C bus which in turn (annoyingly) disrupted protocol decoding. The digital pods come with special miniature probes (one for each channel) with a short wire attached to it which can be pushed onto a header pin. A ground wire can be attached to each probe as well in cases where improved signal integrity is needed.

For testing I created a clock signal and a 4 bit counter with the pattern generator. The digital inputs can be grouped into logic groups. A group can be displayed as a bus. It is also possible to define one input as a clock signal so jitter between the signal doesn't cause false values in the bus display. So far so good. Unfortunately, it is not possible to share digital inputs between groups; an input can only be used once for display. However, it is possible to share the digital input which is used for the clock.

Unclocked parallel bus:


Clocked parallel bus:


Something I was looking forward to test is sequence triggering in combination with the digital channels. It turns out this isn't possible. Sequence triggering only works when using analog channels. Bummer! I was hoping the sequence triggering was able to replace more complex triggering like you find in a real logic analyser. A real logic analyser has a programmable trigger state machine where you can define events to either advance to the next state, go back to the previous state or get to the last state where the trigger occurs. This is very helpful to find more complicated problems and is still relevant for doing FPGA development work. The sequence triggering in the MXO3 is a simplified version of having a trigger state machine but it could still be very useful for digital channels.

But overall the integration of the digital channels is good. The height can be increased / decreased and it is clear whether a signal is high (green) or low (purple). Alternative a single color (user configurable per digital channel) can be used as well. In case of the single color, a thick horizontal line means high a thin horizontal line means low. The minimum height for 8 digital channels is 2 vertical divisions. And of course it is possible to display less channels if needed.

Cursors
Of course the MXO3 has cursors. The cursors are referenced to the time and voltage of the acquired trace and not to the location on the screen. This means you can expand a signal and place a cursor very precisely on a point in the signal. After that you can contract the signal and move over to a different point to place the second cursor. It doesn't matter if this causes a cursor to become off-screen. In the cursor menu there is an option to bring a cursor back onto the screen in case it is 'lost' somewhere in the acquisition. This workflow allows to make precise measurements using the cursors on an oscilloscope.

In addition it is also possible to have the same cursor measure across multiple sources so -for example- the voltage difference between two (or more) signals can be measured. I have already used this feature while using the MXO3 for a project I'm working on.

[nctnico]

Decoding
The MXO3 has 4 decoding instances (busses B1 to B4). Each bus decoding instance can be used for a different protocol. One of the complaints about previous R&S oscilloscopes is that (for example) decoding a UART connection requires the use of 2 decoder instances to decode both RX and TX. R&S paid attention to these complaints and the MXO3 does not have that limitation so even though there is still a maximum of 4 bus decoding instances, the MXO3 doesn't run out of steam quickly.

For these tests I used a digital pattern generator which is part of a TLA715 logic analyser. With its maximum bit-rate of 250Mbit it can easily create very high speed digital signals; typically beyond the ability of what serial protocol decoders can handle.

I2C decoding
Let's start with something relatively easy: I2C decoding. Triggering on an I2C start seems to be no problem. The first impression is that R&S managed to improve display of decoding even further compared to the already excellent way the RTM3004 shows decoded data. A decoded I2C transaction shows the direction (read or write) and the address across the length of the decoded I2C transaction. This helps to keep track of what you are looking at even better. The way decoding is displayed is really sophisticated (gorgeous would be another way of putting it). Per usual MO for R&S, the MXO3 tries to keep the decoded data visible as much as possible allowing to have as much data as possible on screen along with the signal.

Time for some over sampling tests... I generated a 1MHz I2C signal and checked at what (lowest) sample rate the MXO3 starts to decode properly. The result is that it turns out decoding works even if the visible signal is very undersampled. This means that the decoder engine has to have its own path from the ADCs which ensures the data / signal going into the decoder has a high enough samplerate to do meaningful decoding regardless of the samplerate used to display the signal. This is a very nice feature for when you want to make really long recordings with decoded data and don't care so much about what the signal looks like.

Here is an undersampled I2C signal with a valid decoder result:


Keep in mind here that decoding the displayed signal from the screendump won't work. It is nothing like the original signal. In this case decoding will only work while acquiring the signal.

The maximum I2C clock frequency at which I got I2C decode to work correctly is about 1.5MHz.

I2C decoding also allows for filtering the packets which show up in the bus decoding table. I tried this with feeding packets with different addresses into the MXO3. The packet on which the MXO3 triggered on is always shown in the bus table regardless of the filter settings. So there is always an 'anchor' to relate the decoded data to.


SPI decoding
SPI decoding is easy enough to setup. And as with I2C only 1 decoder instance is needed to have both MISO and MOSI. The decoder also works without needing a CS (select) line and can use a configurable time-out on the SCLK (SPI clock) line. I tried to push the limits a bit. With a 50Mbit/s SPI datastream, the maximum number of messages that can be stored is around 17900. With this amount of messages in the decoder buffer, the MXO3 starts to slow down a lot though.

I also played around a bit with the data display formats. Besides the usual hex, binary and ASCII it is also possible to display the value as a signed or unsigned integer. The latter is super useful when checking SPI communication with a sensor, ADC or DAC.





Just like on the RTM3004, the way decoded data is displayed as a trace is geared towards maximising the amount of readable information on screen.

To test the upper frequency (bitrate) limit of the SPI decoding I have used the logic probes. I hadn't setup the normal probes to have a decent enough signal integrity. The spec says SPI is supported up to 50Mbit/s. I managed to get to 70Mbit/s so there is some wiggle room provided the SPI signals are 'clean'. Keep in mind I'm testing with a logic pattern generator which produces super clean digital patterns.

And there is also coupling between the bus decode table and the zoom window. When a row is selected in the bus decoding table, the part of the signals that produced the row is shown in the zoom window. As the screenshot shows, the display is getting quite crammed with info so I setup a second tab with only the signals visible. Unfortunately selecting a row from the bus decoding didn't change the position in the zoom window of the second tab. It would be nice if that worked though. You can have one screen for looking at the decoded data and the other for looking at the signals in detail.

It is possible to change decoding parameters after the acquisition has stopped. With I2C decoding I had the SDA signal connected to channel 3 and channel 5. When I change channel 3 to channel 5 in the decoding parameters, the decoded trace is updated immediately. There is a small twist though. Channel 5 needs to have a high enough samplerate for the decoding to work as the MXO3 has no other signal source than the data sampled into memory. So when changing decoding parameters after an acquisition, the acquired signal needs to have enough detail for the decoder the work with. Being able to change decoding parameters in stop mode is an advantage.


UART decoding
As the decoding supports changing the parameters after doing an acquisition, I wanted to see how far I can push this when it comes to UART decoding. Especially when dealing with UART signals it can be helpful to be able to tweak the settings to find the right baudrate, stop bits and parity. And some systems even use different (alternating) baudrates depending on their state.

I created a special test sequence for UART decoding: data at 115200 baud, data at 115200 baud with shorter stop bits (75% of what they should be), data at 57600 baud, data at 9600 baud and a last segment at 9600 baud with gaps between the characters. The result is a mixed bag. Only the highest baudrate content gets decoded. For the other baudrates you have to set the baudrate in stop mode. In that case the decoder tries to decode the acquired data but this is limited to the section which is on screen. With characters half off the screen it is pretty easy for the decoder to lose track of the start bits and it starts to display wrong data. So this mode suffers from the typical issues you get when a scope tries to decode on-screen data instead of the entire memory. I also noticed I can't enter 115.2kbps but must enter 115200 bps to set the baudrate. For some reason the dot is disabled in the bitrate entry screen. R&S told me they want to fix that.





The bus-table also shows the bitrate on each line. I can see this can help when there are multiple decoders enabled and there are several bus decoding tables available. I wanted to try if the bus table bitrate would show the actual bitrate so I adjusted the bitrate of the 115.2kbaud by about 1% but the bus table still displays 115.200kbps.

I cut back my test a little bit because 3 different baudrates is not making the decoder very happy. With 115.2kbaud and 57.6kbaud UART data, the decoder won't decode 57.6kbaud in run mode. The decoder needs to be tickled to go into 'after the fact' decoding for it to show data. Decoding the 115.2kbaud signal does work. All in all the decoder gets confused by higher frequency content in the signal even though the idle time is many bit times long. Playing with the packet separation mode (off or time-out) doesn't help. I'm asking too much here.

What does work though is decoding characters back-to-back. Also the shorter stop bits aren't a problem. So there is some leeway in the decoder to deal with UART data with poor bit timing.

Triggering on decoded packets
The trigger can be set to trigger on decoded data. In that mode the hold-off function is also disabled. Typically you'd use that to try to make the oscilloscope trigger on the start of a stream in case the data comes in a sequence. But there is an option to trigger on the start of a packet which works better compared to trying to make the trigger hold-off do that. Triggering on a sequence of characters send (back to back) by a UART works perfectly.

It is also possible to use the sequence triggering. This means that before triggering on decoded data, a trigger event on an analog channel needs to take place. This can be handy to capture only decoded data for very specific events. Like something in a circuit tripping and catching the message which has information on what has been tripped. This is not only useful for fault finding but also verification of circuits.

Some remarks about decoding
Playing around with decoding a little bit more also revealed a downside of the bus-table to zoom-coupling mode. The bus table shows all decoded packets in memory which is good; if packet number 10 has a problem then this will always remain packet number 10. You don't need to remember a time offset with a longwinded number like 7124.7658ms However, when selecting a packet to show in the zoom window, you can only select packets which are visible in the main window. To me this is a weird limitation. I'd expect the main window to also move along if a packet is outside the view range OR only the zoom window gets updated with a different packet. The way it works now makes the main window of limited use when dealing with lots of packets. It would be better if selecting a packet from the bus table simply puts the beginning of the packet at the reference point of the main window or some kind of cursors moves along. The zoom window could follow the same time offset but you could also do without the zoom window entirely if the main window hops along.

Interestingly protocol decoding can't be enabled when peak-detect or envelope acquisition modes are enabled. It is not the end of the world but it took me some time to figure out why decoding was suddenly disabled.

Something else I wanted to take a look at is how decoding works together with segmented recording. One of the things I liked about the Agilent MSO7104A I used to own is that it can list the decoded data from all segments in a single table. This means you can set a trigger for a specific message and cram as much relevant data into the memory as possible using segmented recording. The MXO3 on the other hand, sees every acquisition in history as a separate item and shows only the displayed frames in the bus decoding table.

All in all the basic functionality of the protocol decoding is good and the displaying of information is excellent for as long as you deal with the decoded data which has been collected during the acquisition. As soon as you start playing with the decoder settings and the MXO3 goes into 'decoding after the fact' mode, the decoding function needs some more polishing.

What is nice though is that decoding also works on math and reference traces. The latter allows to save acquisitions and open them later for further analysis (or comparison).

Math
The MXO3 has a total of 8 math channels. The math channels can be used as an input for the next channels. It is also possible to enter a free-form formula which further enhances the usefulness math traces. On some scopes you can use a math channel for one operation only. So needing a more complex equations eats up math channels quickly. But not on the MXO3; you can dedicate a single math channel for a specific math function. One thing to keep in mind is that the equation editor checks whether the units match. Doing something like C1 + C2 * C3 results in an error because C2 * C3 results in V^2 as a unit which is incompatible with Volts. By default the unit of a channel is in Volt even when no unit is specified in the probe setup. It is possible to force one of the pre-defined units to the channels but even then it won't solve the situation of the equation C1 + C2 * C3. This could become problematic in some cases as an input signal may not be representing volts at all; it could be a temperature translated to volts before it is fed into the MXO3. IMHO forcing units in the math equations makes things overcomplicated and cumbersome for the user.

The math trace input can be limited (gated) to a partial piece of the trace. This not only speeds up things a lot with deep memory enabled but also allows to pick a piece of a signal which actually worth analysing in more detail.


Filtering
One of the things which interest me about math channels is filtering because this has become handy in some occasions. The low-pass filter function has a lower cut-off frequency of 1/100th of the sampling frequency. At 5Gs/s this is 50MHz. So if you want to filter to lower frequencies, the samplerate needs to be lowered. This is logical as digital filters with large samplerate / cut-off frequency ratios suffer from rounding errors and limits of fixed point calculation. When I need to implement a digital lowpass filter with a large samplerate / cut-off frequency ratio, I implement it as several cascaded filter / decimation sections.

Anyway... let's see if we can get the decoder to work on signal with lots of unwanted HF contamination (decoding also works on math traces!) As a test I setup the pattern generator to produce a UART stream at 57600 baud. This goes into a resistive splitter / combiner through a 20dB (10x) attenuator. So the UART signal arrives at the MXO3 with a significant attenuation. At the other end of the combiner I feed in a 5Vpp 1.2MHz sine wave so the UART signal is completely swamped. In order to get a low enough lower cut-off frequency I forced the samplerate to 20Ms/s (here is a situation where setting a limit to the samplerate comes in handy!). I set the cut-off frequency to 200kHz and choose the brickwall filter as I'm not interested in retaining the shape of the signal; I want maximum suppression of the unwanted frequency.



The screendump shows the result. The math traces recovers the UART stream nicely and the decoder manages to decode the data. Note how 12 bit resolution helps to retain the shape of recovered waveform. On an 8 bit oscilloscope the filtered version of the filtered signal is much more coarse due to limited vertical resolution.



FFT and spectrum analyser mode
The FFT function can be setup using start/stop or center/span frequencies. The RBW (receiver bandwidth) can be adjusted as well down to below 1Hz. This depends on the acquisition settings though. Setting the record length to automatic, the record length limit to maximum and the minimum sample rate to the minimum in the acquisition menu gives the most freedom to setup the FFT. I tested using a 1.23MHz sine with FM modulation. With the RBW set to 1Hz, the MXO3 uses 475Mpts for FFT. In that case FFT doesn't get annoyingly slow at all. Say about 1 to 2 seconds for each update. With RBW set to 1kHz (10Mpts record length), the waveforms/s counter says the MXO3 is doing 200 acquisitions per second. That is a pretty awesome speed for FFT on an oscilloscope!



Function generator
The internal function generator (included in the option bundle) is a basic generator with the usual features (commonly used waveforms, sweep, modulation and noise). It is nice it works up to 50MHz. Even though the output amplitude is limited to 10Vpp into a hi-Z load (5Vpp into 50 Ohm), having 50MHz opens up a whole range of measurement abilities. Especially when combined with the FRA (bode plotting) function. One thing I like to check on function generators is the log-sweep function. On some digital function generators the log-sweep is actually a stepped sweep. So when sweeping a narrow filter quickly, this can give wrong results. However, the function generator in the MXO3 passes the log-sweep test with flying colors. Using a measurement tracking trace, it is easy to see that the frequency ramps up exponentially along a smooth graph.



Unfortunately still no triggering from the function generator. It would be so nice to trigger at the start of a sweep.

DVM application
The DVM application can measure DC (average), RMS (called DC RMS) and AC RMS (standard deviation). The measurement unit (Volt, Ampere or Watt) follows with what has been configured for the probe. What makes the DVM application different from a measurement is that the DVM application is measuring the actual signal going into the MXO3. It is always active even when the acquisition is stopped. This is handy to keep an eye on signal levels. Another neat feature is that the filter cut-off can be adjusted from 200kHz to 20MHz in 1-2-5 steps and the measurement time can also be adjusted.


Segmented recording / history mode
R&S has combined history and segmented recording into one function called history mode. What history mode does is keep the previous acquisitions available for viewing. History mode works automatically in the background. It basically loops through the acquisition memory without interfering with anything. If a specific number of segments is needed, the MXO3 can be set to acquire a number of segments before stopping. There is a hot-key for setting the maximum number. As the number of available segments depends on the memory length of each acquisition, the number of available segments is variable. So selecting the maximum can be a good default when in doubt (or at least give an idea of what the limit is).


Reference traces
Reference traces are like a notepad to keep track of what happened and hold new results against old results (or a golden standard). The MXO3 allows to have 8 reference traces. When creating / saving / restoring a reference trace you get an actual copy of the original signal. No loss of information at all (unlike other oscilloscopes which do decimation and store a crippled version of the original signal to save space). The reference traces can be used as input for math, spectrum analysis and decoding. On top of all of that, the reference traces are retained across power cycles. The screendump shows the screen of the MXO3 after I turned it on again. It jumped right back into showing and decoding the reference trace. The downside is that the size of the saved reference trace can become huge.



Of course I had to test with a 500Mpts long record. With such a long record, things become slow. And for a good reason as a lot of memory needs to be processed. However, even with 500Mpts the MXO3 doesn't cut corners and uses the full 500Mpts for the reference traces.

Another neat feature is the ability to rescale a reference trace both horizontally and vertically. In the screenshot I set the vertical scale to 3x (3 times bigger) and the horizontal scale to 0.9. The (gated) measurement shows the measurement on both the original signal and the scaled reference trace. Handy in case you want to match a reference trace with an acquisition with different amplitude and/or frequency.



Power analysis
Power analysis is a software option on the MXO3. It allows to do various tests when it comes to mains power testing (harmonics), switching losses, converter efficiency. As I already explored the power analysis features using the RTM3004, I decided to test a feature I didn't test when doing the RTM3004 review: DC-DC converter efficiency.

DC-DC converter efficiency analysis
At the moment I'm evaluating some chips for a new design, including a 1V 8A DC-DC converter to power a beefy FPGA. So I decided to use the converter efficiency module of the power analysis and see what it does. For this test 4 channels are needed at least. Two for input / output current and two for input / output voltage. The design / board I'm testing uses a tiny synchronous buck DC-DC converter chip from MPS. It is supposed to turn 12V input to 1V output at 8A. To measure the current I used two current shunt resistors (one 5m Ohm and one 10m Ohm) which have a direct connection into an oscilloscope. Because the current shunts have a direct connection I had to make sure the ground of the board is well connected to the current shunts to avoid a large imbalance between the MXO3's inputs.



For this measurement I wanted to use 50 Ohm termination for the output voltage measurement. Normally this would be a matter of flicking the 50 Ohm termination on and done. On the MXO3 this turned out to be a bit more involved to prevent the operator from turning 50 Ohm termination on by accident (and fry the input circuit). Before it is possible to turn on 50 Ohm termination the 'user-defined' probe type has to be selected AND then select custom probe from the 'predefined' probes. OR the probe type has to be set to 'None'. By the way, when the probe type is 'user-defined and the 'custom probe' is selected, every parameter (like unit and attenuation) of the probe configuration can be adjusted.

Anyway, when I got the channels configured correctly it was time to apply power. Lo and behold: the converter circuit just worked! 12V in, 1V out. Bingo! I used a DC load to draw various currents from the board while keeping an eye on efficiency and output ripple. The DC-DC converter can deliver 8A without any problems. The large DC offset range of the MXO3 really shines for these kind of measurements. I can look at the output at 2mV/div, trigger on the ripple (6mV peak-peak) and see if the output voltage drops (or not) and whether the ripple becomes larger. All this without needing a special power rail probe. The DC-DC converter chip works like a charm so the result is rather boring. Having multiple tabs helps to keep an eye on the current and power traces while the output voltage ripple (together with some measurements) can be observed in a different tab.





The DC-DC converter efficiency analysis works but it is important to keep the traces visible on screen vertically (ADC input range!). So keep an eye on those ever so useful overrange indicators. A total of 3 outputs can be monitored. For voltage + current pairs, this would require 8 channels (2 channels for input, 6 channels for 3 outputs). However, if the voltage is fixed, a math channel with a fixed voltage could be used to set the voltage and only measure the current. It would be nice to have the power loss as a number as well.

FRA / bode plotting
When I went through the specs of the MXO3 one application just jumped straight into my mind: PDN (power distribution network) analysis! Having 12 bits and a 50MHz generator gives the MXO3 enough frequency range and dynamic range to do meaningful PDN analysis. One part of PDN analysis is to measure the impedance and flatness of a power distribution network on a board. Typically PDN is specified up to 20MHz and sometimes 100MHz. Beyond these frequencies, the internal / on die decoupling takes over; there is little a circuit board design can change to that. The idea behind the impedance measurement is simple: inject a known AC current into a board's power supply net and measure the AC voltage across it. On a network analyser you'd typically use a 50 Ohm output and define the current as amplitude divided by 50 Ohm. Because the MXO3's FRA measures the ratio between two voltages (input and output), I had to go for a more complicated setup.

I used two 100 Ohm resistors to split the input signal into two branches (2x 100 Ohm parallel gives a 50 Ohm load). One branch goes into a 1 Ohm resistor. This is the input (reference). The other branch goes into the circuit under test (DUT). This circuit is a crude way to inject current into a circuit. There is of course an error depending on the impedance as the voltage divider ratio between the 100 Ohm resistor and the impedance of the DUT varies. But this error is small compared to the tolerance of typical capacitors so no problem.

The circuit diagram looks like this:



The reference is the 1 Ohm resistor. So -6dB (half the amplitude) means the impedance is 1 Ohm / 2 = 0.5 Ohm. At -20dB (factor 10) it means the impedance is 1 / 10 = 0.1 Ohm (etc). It would have been nice to have a math trace available so a simple formula can be used to get the impedance vs frequency readout. Below the graph from Kemet for a similar 4.7uf 1206 capacitor and the measured value.





When measuring a 4.7uf 1206 capacitor, the impedances match nicely with the calculated impedance and impedance graph.

The FRA setup is straightforward: select the start & stop frequencies and number of points is in the main screen. In the FRA setup you can set the generator, what is being displayed and do a calibration. When measuring a feedback loop (like an amplifier), it is also possible to display the phase margin. If the phase margin is too small, the feedback loop may be prone to overshoot or oscillation. The calibration allows to normalise the response. So if you are measuring through a transformer which alters the phase / amplitude response, this can be nulled.



With the simple verification done, let's measure a real life application. I'm using the same DC-DC converter from the efficiency measurement. Let's see what the impedance is with the DC-DC converter on and off:

Off:


On:


With the DC-DC converter on, the impedance at low frequency drops due to the control loop. At higher frequencies, the ripple from the DC-DC converter distorts the measurement.

In the situation above, the DC-DC converter has 3x22uf at its output. With the PSU on, the measurements from about 1MHz are affected by the switching frequency at which the DC-DC converter operates. An interesting thing to note is that the signal going into the MXO3 is DC coupled so the MXO3 gets a signal with a DC offset. For the FRA this is no problem; the offset is measured and the DC offset is adjusted accordingly with the autoscale option enabled (FRA setup -> advanced settings). Of course the DC level should be within the MXO3's offset range AND be within the limits of the 50 Ohm termination resistor of the input. In case DC voltages of more than 3V need to be measured, an option is to use an external attenuator with a high enough power rating. Assuming the power draw is not loading the power supply too much. An alternative would be to use a DC block but that would hamper the lower frequency dynamic range.

For the tests I have used a generator output level of 1.5Vpp. Care must be taken to not exceed the maximum limits of the power supply net. When measuring low voltage nets (in this case 1V), the limits are narrow. With the DC-DC converter off, the impedance at low frequencies can be several Ohms. Assuming 5 Ohm, the peak-peak voltage injected into the power net is 5/ (100 +5) * 1.5V = 71mVpp. With the DC-DC converter on the maximum impedance is around 33 milli Ohm. In that case the amplitude of the injected voltage is 33m / (100 + 33m) * 1.5V = 0.5mV .

When using a FRA / network analyser I also like to see the phase graph as well. When the phase graph is getting erratic, this is a sign the system is exceeding the dynamic range or something else is going on. For passive circuits an erratic phase plot typically means the amplitude of the signal going into the DUT is not sufficient to get a decent signal at the output. So either the input level needs to be increased or the output signal needs to be amplified before going into the oscilloscope or network analyser. In case of measuring an active circuit where other signals may be present (like the ripple of a DC-DC converter), an erratic phase plot can indicate the presence of signals disturbing the measurements.

The phase plot showing there is insufficient signal level for the measurement:


All in all I'm very pleased with the results. For PDN analysis you would typically need a network analyser with a decent dynamic range at low frequencies. Low frequency network analysers are rare and expensive. Being able to use the MXO3 for this job adds value and versatility. I took PDN analysis a lot further using AI in this thread where I used the MXO3 to match simulated results with real world results: https://www.eevblog.com/forum/eda/claude-code-for-pcb-design/msg6344844/#msg6344844

A sweep from 1kHz to 50MHz with 10 points per decade in HD mode with medium RBW takes less than 2 minutes. The advanced settings of the FRA allow to select between normal (12 bit) or HD sampling mode and between 3 RBW settings. A narrower RBW gives more dynamic range at the cost of speed (slower).

XY mode
The MXO3 supports having up to 4 separate XY mode displays. These can use any of the channels. In my test I used a 10MHz from a GPSDO and two signals from a waveform generator which is synchronised to the GPSDO to create some inputs. This is another situation where having the display tabs really shines. Several display tabs can be made with the input signals, XY plots next to each other and/or combined with the inputs. The XY mode also supports color grading to reveal even more details like where the XY plot spends most of the time. What is really nice is that there is a free choice between any of the channels for XY mode; you don't have to plan ahead to which channels you have to connect the input signals. It is also possible to swap X and Y in the XY display setup.





Mask testing
With mask testing an oscilloscope can compare a mask against an acquired signal. The mask can be defined by drawing or inputting coordinates to form areas where the signal shouldn't enter. Firmware version 2.10.2 has a feature to create a mask automatically but I have not managed to make this work. It also seems the mask is compared against decimated (display) data. When the signal is compressed too much by cranking the time/div up, the mask will start to fail due to lack of resolution of the decimated data. In case of a pass or fail there are many ways to deal with that situation. Among them: saving the data automatically, sounding a beep and/or the produce a pulse on trigger output.


Remote control
According to the MXO3 manual VXI-11 and HiSlip are supported for remote control. However, when I tried to open a telnet connection to port 5025 (the SCPI raw socket port) this worked as well. Using SCPI means you can send commands (in plain text) over a network socket directly without needing VISA libraries. For some this can make life a lot easier as dealing with VISA libraries is not always free of problems. When a network connection is made, the MXO3 goes into remote mode and hides the signal on the screen. Instead a message is displayed telling which IP address is controlling the MXO3 remotely. However, the signals can be made visible again directly from the screen. I did not dig deep into the remote commands. The user manual has an extensive section with examples and details on each command.

In addition to remote control intended for automated testing, the MXO3 also supports VNC and a web interface. The web interface allows to set the network configuration, manage the files on the MXO3 and... control it remotely. The waveforms show as quickly as they do on the MXO3 itself (probably done through a video stream). The control from the mouse pointer is a bit laggy though. By default the display area and front panel are shown in the web interface. But it also allows just the oscilloscope screen. Great for doing a presentation showing live signals on a big monitor. Last but not least, at the bottom of the information page (home) there is a toggle to show a message on the screen of the MXO3. This allows to quickly identify which MXO3 is being accessed without changing any of the settings.

I tested VNC access as well using Remmina and it works right out of the box. However, the screen update rate is nowhere near as quick as through the web interface. My guess is that VNC support is there as a legacy.

Keep in mind that none of the remote operation is protected in any way. So connecting the MXO3 to a large, company wide network is not a good idea. Everyone in the company can access it freely over the network. This is not a shortcoming of the MXO3 specifically, it is due to how LXI remote control over networks has been designed in general.

I tried remote control through AI (Claude) and with the help of the manual the AI had no trouble fetching data from the MXO3. I did some testing with this by letting Claude code fetch frequency analysis data from the MXO3 using raw SCPI over port 5025. This worked without a hitch:




The rest...
The MXO3 has a self alignment procedure and the user is -more or less- forced to run this after a firmware update; the MXO3 shows a reminder to run the self alignment after a firmware upgrade. Running the self alignment procedure is good to do every now and then on every oscilloscope. Especially when doing measurements on low level signals. Due to aging effects, DC offsets may wander around.

What I didn't get to test is USB decoding (option K570) as this wasn't installed on the unit I got.

The MXO3 has a built in demo mode plus a pattern generator to explore various functions. I didn't use these for testing though.


Issues
During my rigorous testing I did find some small issues and areas where I think some improvements can be made. I have reported these to R&S. But frankly there aren't issues that really get in the way of working with the MXO3. I think the most annoying one is having to key in the full number when setting the UART decoding baudrate.

Conclusion
As I have used the R&S RTM3004 for several years already I couldn't help making a comparison between the RTM3004 and the MXO3 here and there during testing. Diving into the nitty gritty details has made it clear to me the MXO3 is a huge step up from the RTM3004. For me the vastly better trigger jitter compared to the RTM3004 is a big plus. The RTM3004 can't hold a candle to the MXO3 in that aspect. All in all the MXO3 is proof that oscilloscopes keep evolving into more versatile instruments. If I look at the equipment I have, the MXO3 can replace an LF network analyser for PDN analysis and replace the older high-end oscilloscopes due to having low trigger jitter. Signal filtering is also one of the weaker spots of the RTM3004 which has been addressed in the MXO3.

Though, at some points the MXO3 is a bit cumbersome to setup. Like setting up probes and checking units in math equations. Also it would be nicer if the color and trace display setup would be under in the trace configuration menu and not in the general 'appearance setup'. However, overall the functions are easy to configure and the user interface has clear images / diagrams explaining what is going on.

Besides my tests I have been using the MXO3 for over half a year for various tasks and it works well. Several of my tests are designed so they push or exceed the limits in order to find out what the capabilities are. Also, 8 channels may seem as overkill but I do have a project at the horizon that can benefit from having more than 4 analog channels. One might argue that having more than 4 channels is overkill but I think we'll be seeing more scopes with over 4 channels in the near future. Just like 12 bit ADCs have become the new standard in the past couple of years.

[Martin72]

Hi,
I'm glad that, following my review:

https://www.eevblog.com/forum/testgear/rs-mxo3-a-short-review/msg6218489/#msg6218489
There is now a second, much more detailed thread.
Unfortunately, I wasn't allowed to keep the Scope for very long....
But even after just a few weeks, it was clear to me that this is a very good scope, and the question of whether I'll really need 8 channels no longer even comes up for me.
For one thing, because with the Siglent 8-channel oscilloscope, I have a scope that is currently the only one that can hold its own against the MXO3; for another, because we've already had several situations at work where the four channels of a scope weren't enough—and we probably aren't the only ones.