After stopping the capture, it is usually impossible to return to "running" without restarting the application.
However, maybe one time in twenty or thirty, it does actually work on the first attempt.
If it doesn't work on the first attempt (clicking or otherwise), it never goes back to "running"
Otherwise, the scope is superb.
Details:
Model: PicoScope 2405A
Serial Number: DX092/0012
USB Version: 2.0
Calibration Date: 29 March 2016
Hardware Version: 1
Driver Version: PS2000A Linux Driver, 1.1.6.18
Firmware Version: 1.3.3.0 / 1.0.32.0
I've run the software on Ubuntu 14.04 using the settings file but am unable to reproduce the problem.
Are you using the supplied blue USB cable, and if you are using a desktop PC, are you using the front or rear USB ports? Are the USB ports USB 2.0 or USB 3.0?
If you do experience another occasion where the software only starts again after 20 or so clicks, please close the software, capture the trace.xml file and post it here, or e-mail it to support@picotech.com.
The PC is a Macbook Air 7.2. Running lsusb and lsusb -D shows that USB 2.0 is being used. The same problem occurs regardless whether other devices are connected, or if it is run via a hub (various permutations tested).
The problem is nearly 100% consistent, and only once out of maybe fifty times, did the scope restart today. IIRC, the problem wasn't present when I first used it a couple months ago, and it may be due to an Ubuntu upgrade (or possibly some complication with the MB hardware). I would recommend trying it out on Ubuntu 16.04, as this is going to be an increasingly widely used Linux distribution anyway.
As a temporary work-around, I have found that clicking the "Home" button will reliably restart the scope (obviously the current settings are lost, but it's better than closing the app and restarting).
I've been using a 2205MSO PicoScope in Linux for over 18 months and it has worked well. However, I just tried using it and am now running in to what I think is this same issue. I uninstalled all PicoScope related packages and reinstalled them, without any improvement.
To reproduce the problem:
1. Enable D0 and D1 logic lines
2. Set Trigger to Repeat
At that point it goes into the Stopped state and cannot be restarted without restarting the program or clicking the Connect Device option on the File menu (which resets all the trigger settings).
My system is Ubuntu 16.04 on a 64 bit system.
I'm happy to say though I resolved the issue for now. After looking through my APT log I discovered that the picomono package was updated back in June. I downgraded this package to 2.10.8-1r01 (instead of r02), which can be found here: https://labs.picotech.com/debian/pool/m ... _amd64.deb
It is now working again. So there is something wrong with the newer r02 version of this package and Ubuntu 16.04.
I spoke too soon. The issue is still occurring, seems it just worked a couple times and is now back to doing the same thing again. I also noticed that even when it did work and captured some data on a trigger, the scope would suddenly disconnect and stop working. It seems it also does this with analog triggering (falling edge for example).
I tried it on another Linux system also with Ubuntu 16.04 and a slightly older version of PicoScope. I was able to get it to work somewhat, but it also suffers from the disconnect issue.
I also have this problem, Here is how I reproduce it:
Start PicoScope
Set trigger to single
Fire my signal (which is captured nicely)
Click the start button (the green one with an arrow on in the lower left corner) (the scope starts to run again)
Fire my signal (which again is captured nicely)
Click the start button and it wont start.
So basically I can capture two signals before I have to restart the program.
Toshiba L750, Pentium B960, 4GB ram, Debian 8
Picoscope version 6.11.13.3 (installed with apt-get 2016-Aug-10)
Edit: Forgot to tell it is a PicoScope 2203
Last edited by emandersson on Sat Aug 27, 2016 2:37 pm, edited 1 time in total.
Can you post a psdata file for this, we can then run it here to see what the issue is. If you are using the siggen for the signal it will be included in the file, if not please describe what the signal is.