MDO4034 transfer of full RF waveform

With the SCPI CURVe? command, my MDO4043 can transfer the full record length (up to 20M points) of the analog waveforms, even if the displayed waveform does not have the details.

However, when I use CURVe? to transfer an RF trace (any one), I always get 1001 points in the trace, regardless of how many it should have. For instance, a trace for a span of 500 MHz with a resolution of 5 KHz should have 100K points, but I only seem to get the displayed 1000. I have gone over the manual (which mentions that the spectrum could have up to 2M points but is decimated to display 1000), and the programmer manual, but I see no information at all about the length of RF traces.

Any ideas?

Thanks!

Pablo B.

Hi Pablo,

No, I don't believe this is possible.

Thanks Alfonso for the answer.

It is a bit disappointing, to be honest. I have also tried to save the RF trace to a reference, or to a file, but in all cases I always get 1001 data points. It seems a bit pointless to generate the spectrum data with high resolution and then lose all that resolution just to display it (I don't mind the loss of resolution in the display, but the fact that the data to be downloaded is the displayed data only, and not the full one.

It would seem that the only way to get the full data is to save the IQ baseband data (with that, I seem to get 237500 samples for a trace with a span of 500 MHz and 5 KHz resolution. Would you know what is the format of the IQ data in the Matlab format? Would you know if the IQ data saved to a Matlab file includes the corrections made by the scope?

Thanks!

Pablo B.

Hi Pablo,

Correct, the IQ data is the only way to get the full spectrum data (followed by proper windowing, FFT, etc).

The IQ data in the .mat file is an array of complex single precision values (matlab should automatically recognize it when you try to open it), plus a few more values of metadata.

Which corrections are you referring to?

Hi Alfonso!

I read somewhere that the MDO4000 includes "amplitude and phase vector calibration and correction" (as opposed to the MDO 3000). So I don't know if the oscilloscope is doing anything beyond the windowed FFT and decimation to show the spectrum.
I also checked the TIQ format, and there is a large XML header with lots of information.

Do you know if there is an official command to download through SCPI the IQ data?

Thanks!

Pablo.

Hi Pablo,

There are several steps of "calibration and correction" on all of our modern scopes, I would need more details to know what exactly you're referring to.

In terms of saving the IQ data through SCPI: you can use the *SAV command to save a .tiq file on the scope and then transfer it with FILESystem:READFile .

Hi Alfonso!

Regarding the corrections, my question is if hardware corrections are applied to the IQ data before it is available for saving, or after while it is being processed for display. If the former, then after proper processing (windowing and FFT) I should be able to get essentially the same data as displayed (but with higher resolution).

As for saving, when I try to save the baseband data, I cannot seem to do it without external storage connected to the scope. Does that make sense?

Thanks for all your explanations and help!

Pablo B.

Hi Pablo,

There's several layers of corrections, that's why your question is hard to answer. There's also not much public documentation on this, so I'd just suggest trying it, that's the fastest way.

And yes, that makes sense. The only internal memory for saving waveforms are the 4 REF slots, which you could also try using.

Hi Alfonso!

Saving to a file and then reading it through SCPI worked out well. I just needed to wait a little bit after saving before asking the scope for the file. Otherwise I would get a timeout. Now I wonder if you know how the IQ data is stored in the TIQ file. since I think I'd try to get it from there rather than from the Matlab file.
The TIQ format is XML, and there is a Data tag with the binary data. Would that be the I and Q as 2-byte floating point values each, interleaved?

Thanks,

Pablo B.

Hi Pablo,

The TIQ format is not publicly documented, but I suspect it's single precision floating point (32 bit) or 16 bit integer data, with samples interleaved as you said.

Let us know what you find!

Hi Alfonso!

I managed to get some data out of a TIQ file. It is essentially an XML file describing the data with the binary data attached after it (not in a tag or anything, just following it). The data type is described in the XML, and in the files I got it is 32-bit integers. The XML also includes a scaling factor to convert the integers to the floating-point IQ values. The I and Q values are effectively interleaved (ie I for the first time point, then Q for that same time point, then I for the second one, Q for the second one, etc.).

After writing some rough Python code to decode the data, I got from the TIQ file essentially the same IQ values I could get from the Matlab file (with some small differences in the least significant bits due to floating point rounding, I assume).

The XML has a million different parameters which I don't understand, but could eventually be useful (or maybe not).

Now I need to get the windowing and FFT right to get the spectra.

Pablo B.

Hi Alfonso!

I am now running into problems when doing the FFT of the IQ data. Based on my understanding of IQ data, and information I found online, it seems that the procedure should be straightforward: Make a complex array of I+jQ, compute its FFT and plot the magnitude square of the FFT as the power spectrum. The frequencies should be those given by the FFT (from -sample_rate/2 to sample_rate/2, separated by Npoints/sample_rate) plus an offset for the center frequency.

My calculated spectra look right in the vertical axis (quite similar to what the scope gives me in terms of peaks), however my frequencies are off.

My spectrum acquisition settings are a center frequency of 250 MHz, a span of 500 MHz (so I can go from 0 to 500 MHz), and a resolution bandwidth of 5 KHz.
I input a sine wave with a frequency of 10 MHz (well within the span), and the scope shows a strong peak at 10 MHz, with some harmonics separated at 10 MHz (due to "spectral leakage").
The peaks in the FFT of my baseband signal appear at 52.5 MHz and 72.5 MHz instead at 10 MHz and 20 MHz (so they seem separated by 20 MHz instead of 10 MHz). If I were to add the 250 MHz offset, I would then get way off.

The sample rate is reported as 625 MHz, which does not seem enough to cover the whole span (the Nyquist frequency for 500 MHz should be 1 GHz, right?), so my FFT goes from -312.5 MHz to 312.5 MHz (the negative side does not seem to show many features). I am also getting 1487500 IQ points instead of the 1 million the record length is set to.

So I'm certainly doing something wrong in terms of computing the frequencies, and any help (or pointer to technical information that could help) would be very welcome.

Thanks!

Pablo B.

Hi Pablo,

IQ data has half the sample rate (but double the data per point, so still same amount of data), hence the 625 MS/s sample rate is enough to cover a 500 MHz span,

Before computing the FFT, you should recreate the IF, here's a good description of how to do that:https://panoradio-sdr.de/how-to-convert-between-real-and-complex-iq-signals/
 

Hi Alfonso!

I finally got it working, I just had messed up the shift of the frequency axis (I was shifting the FFT so that the zero frequency was in the center and I had forgotten to also shift the frequencies. Once that was fixed, the FT gave me the 10 MHz signal at -240 MHz, so that when I added the center frequency of 250 MHz it fell very nicely at 10 MHz.

Something I noticed is that, with the same acquisition settings of 250 MHz center frequency, 500 MHz span, and 5 KHz RBW, some signals resulted in 237500 points being acquired and others in 1487500. I'll have to check to make sure the settings were the same, but it seems strange.

I have to take a look at the link you sent me to write some code to reconstruct the original signal  based on the IQ data (which could be useful).

Thanks!

Pablo B.