Big Jim

Hi Afonso,

The big endianness was indeed the problem.

Thanks for helping resolve this.

An issue in changing center/span in the Spectral Mag commands for the math channel:

When I run commands to alter the center/span frequencies (instead of letting them autoset), I get the attached plots. There is a skew to the peak height for the FFT/Spectral Mag that means the peak doesn't match the input frequency, 30MHz in this case.

On the left, you can see the typical peak (unzoomed) for a large span at 30MHz. On the right, I set 1MHz span and 30MHz center frequencies and get a weird skew of the peak frequency.

Any ideas on what I am doing wrong? I'm not sure what I need to alter the incoming y-values by to unskew the data upon changing the center/span freq.

Thanks again for the guidance,
"Big" Jim

Afonso, 

Please make sure you read my lengthy inquiry above your comment. You posted right after me so I just want to make sure you see it. It is most important to solve this for our research applications.

I have been able to fourier transform the data independently via scipy/numpy, and with mathematical formulation, however pulling the fourier transform data into a plot straight from the math channel has stumped me.

Thank you for your work with me thus far and thanks for having the manual corrected.

Best and thanks,
"Big" Jim

Hi again Afonso,

Despite now having the right float binary output from the scope to my python script, I'm still getting a bad plot. Please see the attached picture. 

There is a discrepency between the .csv output by the saved math function waveform on the scope and the data I get into my python script. Firstly, I only get Y values from the FFT function. This is OK as I can create an x function via: 

X_WAVE = np.linspace(2.75*10**7, 3.24921875*10**7, num=len(Y_WAVE), endpoint=False)

However, I don't know how to get the start and stop values without checking the output csv by the scope. This is an issue.

I can solve this with some hard work. What I can't seem to solve is why the values coming in from the scope into my python script are different from the values output by the scope's CSV. They are fine when I run the normal (non-math, standard channel 1) waveform into my script, but when I alter what I described above (encoding, bin_wave datatype, np.array datatype) to float binary anticipation it's not giving me the values I expect. 

With a 30MHz waveform that should fourier transform to a peak with an x-value at 30MHz, I get a plot as shown in attached image. 

Thus, my two inquiries are: how do I get the starting and ending x-values for the fourier transform data? In the csv generated by the scope, both x and y are included. When I get the waveform data in my python script, only incorrect y values are included. What am I doing wrong to get the wrong y-values from the math channel? I've changed the encoding type, changed the bytes expected to 4, changed the query_binary_values datatype to float, changed the np.array values to float, and still no dice.

Thanks,
"Big" Jim

 

"SRFBinary is the same as RFBinary except that the byte order is swapped, meaning that the least significant byte is transferred first. This format is useful when transferring data to PCs"
Page 2-97 from the Programming Manual DPO7000 series. 

Looks like there's a typo in this regard. 

Thanks,
"Big" Jim

Afonso,

What are exactly the settings required to get the SpectralMag(CH1) data into my python plot? I'm getting really weird values and I'm not able to match the plot that I get from saving the data from the oscilloscope directly into CSV and plotting it in excel. 

When I set:

scope.write('MATH1:DEFINE "SpectralMag(CH1)"')
scope.write('SELECT:MATH1 1')
scope.write('header 0')
scope.write('data:encdg SRFBINARY')
scope.write('data:source MATH1') # channel
scope.write('data:start 1')
record = int(scope.query('horizontal:recordlength?'))
scope.write('data:stop {}'.format(record)) # last sample
scope.write('wfmoutpre:byt_nr 4') # 1 byte per sample

and then:

bin_wave = scope.query_binary_values('curve?', datatype='f', container=np.array)

I get 640 values in my np.array with 20k record length. But the values are not matching what they should be. There's some weird conversion going on I can't solve. 

Here's my NI I/O Trace (I've been toying with the settings since I wrote above) attached but don't take this too serious.

I can post my entire code but I'd really just appreciate the commands needed to get the SpectralMag(CH1) data in proper float form.

Thank you tremendously for your help this far,
"Big" Jim



 

 
"Big" Jim back with an update.

I found I needed "SELECT:MATH<x> 1" to turn the MATH to ON state. It's a shame these things aren't more clear in the manual, it takes some time to find + troubleshoot.

Now I can play with the float point settings and see if I can get everything to line up in a plot. 

Thanks,
"Big" Jim
 
 

"Big" Jim back with an update.

I found I needed "SELECT:MATH<x> 1" to turn the MATH to ON state. It's a shame these things aren't more clear in the manual, it takes some time to find + troubleshoot.

Now I can play with the float point settings and see if I can get everything to line up in a plot. 

Thanks,
"Big" Jim

Hi Afonso, 
 
I am having connectivity issues as detailed below. I have posted more details in the other thread. 

Thanks,
"Big" Jim

Hi Afonso, 

Attached is the NI IO Trace. For some reason I'm getting a timeout error today. It was running fine yesterday and I didn't change anything this morning. It's possible someone else using the scope changed some settings but I reset it and it still is timing out.

I can get the CH1 to run fine, just not the MATH1. I also discovered I need to use SRFBinary and 4 bytes instead of 1. But neither of these changes helps the time out error.

Thanks,
"Big" Jim

Hi Afonso, 

I'm now using a DPO 7354 oscilloscope with the curvestream function as opposed to the 1000 series. Thus, I'm inquiring if the FFT() function on the DPO7354 is still slower than a python script would be. I ask this because we are building calibration functionality where the max() of the FFT is taken to determine where the best signal is along shifting frequencies and a moving mirror if that makes sense. Thus, timing and speed are important.

If the 7000 series can handle this fast enough, I have posted my current code in another thread as a response to your other answer to my previous question.

Thanks,
"Big" Jim