This repository was archived by the owner on Feb 2, 2026. It is now read-only.
This repository was archived by the owner on Feb 2, 2026. It is now read-only.
Description
I was wondering what is the reason that the scopes return waveform data as a list of tuples instead of two arrays (one for time one for voltage) in _measurement_fetch_waveform? I can not see a case where one would prefer data in this format (e.g. for plotting one always wants separate arrays for x and y).
Some background on why I'm asking this. I have an application where I want to fetch and display the waveform as close to real time as possible. The way the x and y waveforms are generated at the moment is of the form of
data = [ ((i * xincr) + xzero, ((y - yoff) * ymult) + yzero) for i, y in enumerate(y_data)]
or similar. This is very slow. Compared to the following code:
xdata = np.arange(len(y_data))*xincr + xzero
ydata = (y_data - yoff)*ymult + yzero
data = xdata, ydata
It is a factor 100-1000 times slower for 1e5 or 1e6 points (disregarding having to convert the output to an array for further processing, which adds a large additional processing time).
I would really prefer the second method (or at least the ability to configure this somehow), I'm happy to create a pull request if this would be accepted.
Reactions are currently unavailable
I was wondering what is the reason that the scopes return waveform data as a list of tuples instead of two arrays (one for time one for voltage) in _measurement_fetch_waveform? I can not see a case where one would prefer data in this format (e.g. for plotting one always wants separate arrays for x and y).
Some background on why I'm asking this. I have an application where I want to fetch and display the waveform as close to real time as possible. The way the x and y waveforms are generated at the moment is of the form of
or similar. This is very slow. Compared to the following code:
It is a factor 100-1000 times slower for 1e5 or 1e6 points (disregarding having to convert the output to an array for further processing, which adds a large additional processing time).
I would really prefer the second method (or at least the ability to configure this somehow), I'm happy to create a pull request if this would be accepted.