Linux example stops with error

[pfandfrei]

Compiled firmware and flshed it as described.
When trying the linux example it stops with the following message:

$ python examples/example_linux_scopevis.py
Traceback (most recent call last):
File "examples/example_linux_scopevis.py", line 28, in
pylab.plot(timing_data, voltage_data, color='#009900', label='Raw Trace')
File "/usr/lib/pymodules/python2.7/matplotlib/pyplot.py", line 2987, in plot
ret = ax.plot(_args, *_kwargs)
File "/usr/lib/pymodules/python2.7/matplotlib/axes.py", line 4137, in plot
for line in self._get_lines(_args, *_kwargs):
File "/usr/lib/pymodules/python2.7/matplotlib/axes.py", line 317, in _grab_next_args
for seg in self._plot_args(remaining, kwargs):
File "/usr/lib/pymodules/python2.7/matplotlib/axes.py", line 295, in _plot_args
x, y = self._xy_from_xy(x, y)
File "/usr/lib/pymodules/python2.7/matplotlib/axes.py", line 237, in _xy_from_xy
raise ValueError("x and y must have same first dimension")
ValueError: x and y must have same first dimension

My system runs with Ubuntu 14.04.03 LTS

[lambertdw]

I get around this problem by trying a few times. In particular, here is
a code change with a bit of pre-context:

voltage_data = ch1_data or scope.scale_read_data(ch1_data, voltage_range)
timing_data, _ =
scope.convert_sampling_rate_to_measurement_times(data_points,
sample_rate_index)
scope.close_handle()

if len(timing_data) != len(voltage_data):
w = sys.stderr.write
w('data lengths differ!\n')
w(str([(s,len(eval(s+'_data')))for s in 'timing voltage'.split()]))
w('\n')
exit(1)

In other words, if the amount of data collected isn't correcthave the
python code exit with a failure code. Then I run the program in a
shell (bash) loop:

$ while ! python examples/example_linux_scopevis_private_version.py ; do
sleep 0.2 ; done

On 10/19/2015 12:37 PM, pfandfrei wrote:

Compiled firmware and flshed it as described.
When trying the linux example it stops with the following message:

$ python examples/example_linux_scopevis.py
Traceback (most recent call last):
File "examples/example_linux_scopevis.py", line 28, in
pylab.plot(timing_data, voltage_data, color='#009900', label='Raw Trace')
File "/usr/lib/pymodules/python2.7/matplotlib/pyplot.py", line 2987,
in plot
ret = ax.plot(/args, */kwargs)
File "/usr/lib/pymodules/python2.7/matplotlib/axes.py", line 4137, in plot
for line in self._get_lines(/args, */kwargs):
File "/usr/lib/pymodules/python2.7/matplotlib/axes.py", line 317, in
_grab_next_args
for seg in self._plot_args(remaining, kwargs):
File "/usr/lib/pymodules/python2.7/matplotlib/axes.py", line 295, in
_plot_args
x, y = self._xy_from_xy(x, y)
File "/usr/lib/pymodules/python2.7/matplotlib/axes.py", line 237, in
_xy_from_xy
raise ValueError("x and y must have same first dimension")
ValueError: x and y must have same first dimension

My system runs with Ubuntu 14.04.03 LTS

—
Reply to this email directly or view it on GitHub
#21.

[tr0043t]

Is there any obvious reason that this code shouldn't work with the 6022DL? From what I've seen the main difference for access is using the original DLL supplied for the DL rather than the one for the BE. At least in theory. Any other obvious issues? Thanks.

[jhoenicke]

@laurenweinstein1 you should probably create a new issue for this.

You can try to run wireshark/usbpcap under windows to get the USB dump when connecting with the supplied software. It should have a different firmware; I have seen nothing in the firmware that handles the digital inputs. Also the commands to read the digital inputs would need to be reverse engineered. I guess it shouldn't be too different from the 6022BE, though.

There is a chance that the current code works out of the box. You would not be able to read the digital inputs though.

[tr0043t]

At this stage I'm thinking in terms of the scope access, not the logic analyzer side. I've seen references to DLL differences between the BE and DL, with notes to substitute the DLL provided by Hantek for the latter to use open source BE scope packages. I actually don't have the unit in hand yet -- arrives in a few days. Thanks.

[rpcope1]

@laurenweinstein1
It may very well work, but I don't have one, I can't verify that the internals are similar enough to say definitively. You may try running the code with the probes attached to the reference signal and see if it matches what you would expect.

@ALL
I know I haven't been watching this project very carefully the last nine months or so (been tied up with a couple other make or break projects). I think a major overhaul of this library is in store soon, and hopefully I should be able to address these issues.

[tr0043t]

I'll give it a try when I have the unit in hand, later this week. Thanks.

On Mon, Feb 15, 2016 at 1:39 PM, Robert P. Cope [email protected]
wrote:

@laurenweinstein1 https://github.com/laurenweinstein1
It may very well work, but I don't have one, I can't verify that the
internals are similar enough to say definitively. You may try running the
code with the probes attached to the reference signal and see if it matches
what you would expect.

@ALL https://github.com/all
I know I haven't been watching this project very carefully the last nine
months or so (been tied up with a couple other make or break projects). I
think a major overhaul of this library is in store soon, and hopefully I
should be able to address these issues.

—
Reply to this email directly or view it on GitHub
#21 (comment)
.