N52xx.py driver bug

[alebrunoeth]

Steps to reproduce

1.Run python code from notebook and sweep over around 12500 * n points or more (n integer). 2.Wait for measurements. 3.Plot measurement results and analyse trace result.

code (also attached in the text file):

import numpy as np
from matplotlib import pyplot as plt
import qcodes

qcodes.Instrument.close_all() 
from qcodes.instrument_drivers.Keysight.N52xx import PNABase
VNA=PNABase(name = 'test', address='TCPIP0::Localhost::hislip0::INSTR',min_freq=10e6,max_freq=20e9,min_power=-100,max_power=0,nports=2)

probe_start  = 4e9
probe_stop   = 8e9

probe_pwr = 0 # in dBm
num_points=20001
if_bandwidth=10000
timeout=100000

VNA.set('power',probe_pwr)
VNA.set('start',probe_start)
VNA.set('stop',probe_stop)
VNA.set('points',num_points)
VNA.set('timeout',timeout)
VNA.set('if_bandwidth',if_bandwidth)
VNA.set('trace','S21')
VNA.get_idn()

VNA.traces.tr1.run_sweep()
values=VNA.real()+1j*VNA.imaginary()
coordinates=np.linspace(probe_start,probe_stop,num_points)
plt.plot(coordinates, 20 * np.log10(np.abs(values)))

print(values[12400:12415])
plt.plot(coordinates[12400:12415],values[12400:12415])

Expected behaviour

Result is just the expected trace response.

Actual behaviour

Every (approximately) 12500 points, an outlier occurs composed of four points (with amplitude respectively close to 1e-45, 2, 1e-43, 1e-7). This is not from the physical measurement and we would like to not use any functions to delete this manually. (In our case the first points are number 12405 to 12408)

System

operating system Windows 10 64-bit qcodes version 0.23.0

PNABase_bug.txt

[astafan8]

@alebrunoeth do you mind attaching a plot with that data and those outliers (as an image)? for a visual aid

[alebrunoeth]

dB plot over whole spectrum. zoomed plot in absolute value

[alebrunoeth]

dB plot using 60000 points (4 features appear)

[jenshnielsen]

@spauka I think you originally wrote this driver. Have you ever seen anything like this?

@alebrunoeth before doing anything else I would suggest that you ensure that the instrument is updated to the latest firmware version. It seems at least possible that this is an issue with the instrument firmware

[alebrunoeth]

I already did update the firmware And this problem is not present in the GUI of the instrument

[jenshnielsen]

@alebrunoeth thanks for the update unfortunately I don't think the fact that the issue is not present in the gui can be used to establish where the issue is. The driver is using CALC:DATA? FDATA to read back the data from the instrument. It will require some debugging to establish why the data contains some wrong samples but it seems most likely that those datapoints are already present in the data read back at this stage

[alebrunoeth]

Thank you, I will try and debug and try to see if the problem arises while using VisaInstrument as well

[spauka]

@jenshnielsen @alebrunoeth I have indeed seen this same issue - although it was on an Infinium scope and not on a PNA. The issue arose when we tried to transfer >100000 pts from the scope in a single measurement. It seemed like the instrument was inserting some random characters in the middle of the data.

I'm just asking around to ask if we had a better solution than to break the measurement down into multiple smaller acquisitions 😆

[alebrunoeth]

@spauka Thanks for sharing this issue! But do you know at what level it was inserting it? Because if you use just the PNA you do not get this problem.

[spauka]

Hi @alebrunoeth - just wondering if you're still seeing this issue? I'm not able to reproduce it any more on my scope of DSO so it may have been fixed somewhere?

[spauka]

@jenshnielsen I'm regularly taking 50001 point traces on the PNA and not seeing this issue. I suggest we can close it?

[jenshnielsen]

@spauka agreed @alebrunoeth if you still can reproduce please let us know and we can reopen