First picture on EEVblog of the new R&S MXO4 series oscilloscope :)

[pdenisowski]

I don't know what firmware the unit had that I was testing.

I spent 7 days trying to make it decode a perfectly valid SPI stream (very long 256K transaction), and could not make it work.

I stand by my review.  It was not able to do any decoding, neither analog nor digital.

I am glad to see you guys are looking in to it.

Well, I can't say we're looking into it because we have lots of people using the SPI decode (myself included) and none of them have reported any issues

If you do get a chance to reproduce the issue, please let us know.  Unfortunately, without screenshots, settings, or a more detailed description of your setup, etc. there's no way for us to know why it wasn't working for you.  I'm assuming you didn't contact tech support?

Silly question:  did the MXO4 you were using have the low speed serial decode option (MXO-K510)?  If your MXO4 didn't have the software option, it would explain why you saw the signals but never saw a decode.

[Sighound36]

Never had that issue on the demonstration unit I loaned at all, I know there has been a few firmware updates since March

[nctnico]

256k transactions may be too long for the decoding buffer to store.

[shabaz]

Hi,

I wonder if the 256k bytes is related to reading or writing the entire contents of SPI memory. I tried capturing and decoding all at once, and for sure after about 110K bytes the decoding slows down a lot. However, in practice, perhaps it is far more likely to want to be able to traverse the data at boundaries, for instance grouped transactions of a higher-level protocol, or (if it is SPI memory) perhaps in pages of say 256 bytes. In that case, the MXO shines because of the history feature, to make it practical to thumb through, and it works very fast for that. I just tried that, in my case pages of 320 bytes, for a total of 800 pages, which is 256k total bytes (see image attachment). My SPI code (running on a Pi Pico) was coded to send groups of 8 bytes of data, with a start header (0x00, 0x00, 0x00, 0xaa) followed by a 4-byte sequence number, so I could easily see if anything was missed (it was not).
That was with SPI, but in the past I have also tried RS-485, with 600k bytes (again using the history feature, to make it practical to view data). That is handy for DMX, where each payload is 512 bytes, but there could be hundreds of such payloads that need to be examined, moving forward/backward through every payload using forward/rewind buttons on the MXO History menu, like a tape recorder.
 

[luudee]

Well, I can't say we're looking into it because we have lots of people using the SPI decode (myself included) and none of them have reported any issues

If you do get a chance to reproduce the issue, please let us know.  Unfortunately, without screenshots, settings, or a more detailed description of your setup, etc. there's no way for us to know why it wasn't working for you.  I'm assuming you didn't contact tech support?

Silly question:  did the MXO4 you were using have the low speed serial decode option (MXO-K510)?  If your MXO4 didn't have the software option, it would explain why you saw the signals but never saw a decode.

I would have assumed that the scope would have told me if the decoding feature was not available.

I am pretty sure it was, as I was doing all kind of setting up ...

One more, thing, the guys who are playing with SPI captures now, try to keep SPI_CS always low (asserted).
See if it still locks and decodes.

luudee

[shabaz]

Hi,

I have tried *CS permanently low from the first byte to the last byte, and it makes no difference, it works for me. Please see the attached screenshot.
As mentioned, this is making use of the History feature, so I can page through the content, and the performance and decode is fast (I can take a video of it if required).
If I do not use the history feature, as mentioned further up, I do see performance struggle with about 100k bytes of the decode. With the history feature, I have not seen any issue with 600k bytes (that's the max I have tried in the past, although that was with RS-485. With SPI, I have just tested 256k).
If you have an example scenario that you can simulate with (say) a Raspberry Pi or Pi Pico, and a screenshot or video of what you see on your current setup, then anyone can try to set it up so that a precise comparison can be made if you like? Because otherwise, for all I know, unfortunately my SPI configuration or speed, or a dozen other things, may be completely different to what you used.

[luudee]

Hi,

I have tried *CS permanently low from the first byte to the last byte, and it makes no difference, it works for me. Please see the attached screenshot.
As mentioned, this is making use of the History feature, so I can page through the content, and the performance and decode is fast (I can take a video of it if required).
If I do not use the history feature, as mentioned further up, I do see performance struggle with about 100k bytes of the decode. With the history feature, I have not seen any issue with 600k bytes (that's the max I have tried in the past, although that was with RS-485. With SPI, I have just tested 256k).
If you have an example scenario that you can simulate with (say) a Raspberry Pi or Pi Pico, and a screenshot or video of what you see on your current setup, then anyone can try to set it up so that a precise comparison can be made if you like? Because otherwise, for all I know, unfortunately my SPI configuration or speed, or a dozen other things, may be completely different to what you used.

Thank you for the test.

I don't know what to say.  It does look like it is working for you. I wonder if I indeed had some very old
firmware, which is also odd, why would R&S give me a scope with useless FW ?!

In any case, my test case is a custom product I designed for a client., It has a CPU booting from SPI
FLASH. We were trying to see where it was stopping to read the SPI FLASH, hence huge capture, etc ...
At the end got it all working ...

One more thing, what's the speed of your SPI bus ?   In my case, it was running at 20 MHz.


luudee

[jusaca]

From the screenshot saying "Bitrate:  991600 kbps" I would assume the SPI clock to be set to 1 MHz

[shabaz]

Just out of curiosity I tried using the analog channels today, to see what difference there is, using a 20 MHz (approx.) SPI clock. It is in the file called spi-using-analog-channels.jpg. This example has 256,000 bytes of SPI data as before.

The MXO 4 allows the creation of additional views of the data (called layouts in R&S terminology), and the next screenshot shows the SPI SCK line on a separate view to blow it up to see more detail (sch-magnified-view.jpg).

What's neat is that it is possible to see any anomalies during the entire acquisition. In that example, a 100 pF load was deliberately applied to the SCK line part-way through the transfer, and it is possible to see the impact the load had on the analog signal as well as locating the data corruption (if the analog signal is significantly distorted).

It's easy to find the anomaly, by dragging the slider (see anomaly-located.jpg) until the visible waveform shows the corruption, and then the page of data has been identified.

The final attached image just shows a temperature-colored view to see how much consistency there was for the SCK signal over time.

[nctnico]

I assume the MXO4 also has reverse brightness. This makes an anomaly stand out even better (at least on the RTM3004 it does).

[shabaz]

That did it! It is in a different menu to the RTM3004, but found it amongst the settings options.
There's several other options too, I've attached a screenshot of them.
This is the definition of them in the user manual:

• "False colors": color changes gradually in a wide color spectrum.
• "Single Event": single events and very seldom events appear yellow, a higher
  cumulative occurrence is shown with blue color. This view helps to identify specific
  events.
• "Spectrum": colors display the wavelengths of the light. Low cumulative occurrence
  is displayed blue like high wavelength.
• "Temperature": color changes gradually from blue (low temperature) to red (high
  temperature) with increasing cumulative occurrence.

[Martin72]

Not a bad scope..

[shabaz]

Hi, there's a new MXO 4 firmware update (version 1.4.2.2) since the end of last month! One feature that is great is the log-frequency-axis for the spectrum analyzer functionality. It seems to work well, here's a 4-minute video containing some quick experiments with it:

[pdenisowski]

It seems to work well, here's a 4-minute video containing some quick experiments with it:

Nice video - thanks!

[tv84]

It seems to work well, here's a 4-minute video containing some quick experiments with it:

Beauty. It almost seems you have a demoboard to show off the MXO. Very instructive examples and explanations. 

[shabaz]

Hi,

Thanks! For the signals, Matlab was used to create some of them (and then stored them in the MXO 4), it directly accepts CSV format waveform files, provided there is a 43-line header (which can be copy-pasted from any waveform saved from the MXO itself). The 10 MHz signal was from an AD9954 chip (it was a custom PCB, but there are some ready-made modules on AliExpress, although I have not tried them).
For the audio signals, it was using a cheap ADAU1401 DSP board (from AliExpress), the details are on GitHub. It is a low-cost way to create all sorts of tones/filters etc, all controlled from a Pi.  (It could be done using a sound card and Matlab but I was planning to use the DSP chip for a standalone speech processor eventually, and be able to instruct it to notch out up to several tones simultaneously, and adjust bandwidth etc). The chip doesn't have a lot of processing power, there are better DSP modules on AliExpress, although they need a separate ADC/DAC (that is built-in to the ADAU1401 chip).

[mawyatt]

@ shabaz. Nice video, and good selection of the waveforms to demo the new MXO4, well done

Very impressive display of the MXO4 SA type capabilities. The log frequency scale and speed of the performed Fourier Transform (not sure if it's an FFT or CZT) are very nice indeed.

Wish we could afford one!!

Best

[pdenisowski]

Thanks! For the signals, Matlab was used to create some of them (and then stored them in the MXO 4), it directly accepts CSV format waveform files, provided there is a 43-line header (which can be copy-pasted from any waveform saved from the MXO itself). The 10 MHz signal was from an AD9954 chip (it was a custom PCB, but there are some ready-made modules on AliExpress, although I have not tried them).
For the audio signals, it was using a cheap ADAU1401 DSP board (from AliExpress), the details are on GitHub. It is a low-cost way to create all sorts of tones/filters etc, all controlled from a Pi.  (It could be done using a sound card and Matlab but I was planning to use the DSP chip for a standalone speech processor eventually, and be able to instruct it to notch out up to several tones simultaneously, and adjust bandwidth etc). The chip doesn't have a lot of processing power, there are better DSP modules on AliExpress, although they need a separate ADC/DAC (that is built-in to the ADAU1401 chip).

Wow ... just wow.  Very impressed. 

[maxwell3e10]

Can the units of vertical scale be changed to V/sqrt(Hz) and plotted on log scale? Can the spectrum be averaged and then saved to a data file or to a reference spectrum?

[shabaz]

Hi,
It supports a total of four options for the vertical scale (one is linear, in Volts, the rest are log power and voltage). The spectrum can be averaged, and the averaged spectrum can be saved to a data file, and to a reference spectrum. The data file format is CSV, possible to decode for instance with Python (see the spectrum_tool.py read_csv function on line 46), including all the spectrum analyzer settings (including resolution bandwidth, window type setting, etc).

[Wolfgang]

... In reality, there are never 18Bits. What counts is the effective number of bits, and a measurement of this reveals that the effective bits are below 11, regardless of what they claim. Look here:

https://electronicprojectsforfun.wordpress.com/to-enob-or-not-to-enob/

The other manufacturers (and also R&S for their better scopes) give ENOB values in their specs. For the MXO, there are none (for a good reason).

[maxwell3e10]

... In reality, there are never 18Bits. What counts is the effective number of bits, and a measurement of this reveals that the effective bits are below 11, regardless of what they claim. Look here:

https://electronicprojectsforfun.wordpress.com/to-enob-or-not-to-enob/

The other manufacturers (and also R&S for their better scopes) give ENOB values in their specs. For the MXO, there are none (for a good reason).

Thanks for an amazing level of analysis! I think it's interesting to compare the spectra of the scopes directly. Picking only one largest peak obscures how "clean" the spectrum is and the level of white noise. In many cases having a second or third harmonic due to a non-linearity is not so bad. Also high resolution is often useful to see small features at the end of a large signal (like tail end of a decay) in a single shot. So SNR and DR  can be useful characteristics in addition to SINAD and can also be converted to an ENOB, where "effective" has a different meaning.

[Martin72]

The other manufacturers (and also R&S for their better scopes) give ENOB values in their specs.

Right, Siglent for example, but also (and of course) Lecroy, even Rigol....
For the HDO4000, for example, it was afaik 8.5 bits (without further details).
Lecroy specifies between 8.4 and 8.7, depending on the bandwidth of the model (WS 4000HD), Siglent also.
And Siglent are the only ones who write which parameters they used for this:

1：99.99 MHz input(100 MHz model uses 49.99 MHz)，-0.5 dBFS，20 mV/div，50 Ω input impedance

I assume that lecroy measures similarly.
And nobody knows how Rigol measured it.
I would like to repeat your measurements on my siglent, but unfortunately I don't have the equipment(only a SDG2122X).
But you described a self-built oscillator for this purpose, is there any more information about it?
Gladly in a separate thread, otherwise this will be too offtopic here.

[Wolfgang]

The other manufacturers (and also R&S for their better scopes) give ENOB values in their specs.

Right, Siglent for example, but also (and of course) Lecroy, even Rigol....
For the HDO4000, for example, it was afaik 8.5 bits (without further details).
Lecroy specifies between 8.4 and 8.7, depending on the bandwidth of the model (WS 4000HD), Siglent also.
And Siglent are the only ones who write which parameters they used for this:

1：99.99 MHz input(100 MHz model uses 49.99 MHz)，-0.5 dBFS，20 mV/div，50 Ω input impedance

I assume that lecroy measures similarly.
And nobody knows how Rigol measured it.
I would like to repeat your measurements on my siglent, but unfortunately I don't have the equipment(only a SDG2122X).
But you described a self-built oscillator for this purpose, is there any more information about it?
Gladly in a separate thread, otherwise this will be too offtopic here.

Hi Martin,

the ENOB test oscillator schematics is at the bottom of the ENOB page.

regards
  Wolfgang

[Wolfgang]

... In reality, there are never 18Bits. What counts is the effective number of bits, and a measurement of this reveals that the effective bits are below 11, regardless of what they claim. Look here:

https://electronicprojectsforfun.wordpress.com/to-enob-or-not-to-enob/

The other manufacturers (and also R&S for their better scopes) give ENOB values in their specs. For the MXO, there are none (for a good reason).

Thanks for an amazing level of analysis! I think it's interesting to compare the spectra of the scopes directly. Picking only one largest peak obscures how "clean" the spectrum is and the level of white noise. In many cases having a second or third harmonic due to a non-linearity is not so bad. Also high resolution is often useful to see small features at the end of a large signal (like tail end of a decay) in a single shot. So SNR and DR  can be useful characteristics in addition to SINAD and can also be converted to an ENOB, where "effective" has a different meaning.

Hi,

I think different. A discerned "spike" in the spectrum corresponds to a perceivable "wiggle" in the time domain, and that, IMHO, hurts more than just a randomly increased noise level, as it can be mistaken for a "real" signal.
It all depends on what kinds of signal you are working with.

regards
  Wolfgang