Trace opened 11/23/2022.Application 'PicoScope 7 T&M Early Access' (version 7.0.113.13201 X64) starting.2966D0D28EE892F10F5455575B95DAA2User is not GuestNo Administrator PrivilegesOS Version - Linux Debian GNU/Linux.net Version - 4.0.30319.42000Settings file version - 11.5.1Preferences file version - 2.0.0Probes file version - 1.0.0Data file binary header version - 1Loaded libusb-1.0 ver. 1.0.24.11584USB Hotplug availableUsing default culture: English (United States).Attempting to load ps2000.dll from '/opt/picoscope/lib/libps2000.so'Checking driver '/opt/picoscope/lib/libps2000.so' exists in executable path '/opt/picoscope/lib/Finished loading ps2000.dllAttempting to load ps2000.dll from '/opt/picoscope/lib/libps2000.so'Checking driver '/opt/picoscope/lib/libps2000.so' exists in executable path '/opt/picoscope/lib/Finished loading ps2000.dllOpening device using DLL ps2000.dllNoDataGlobalDeviceManager.Close()
Can anyone provide some pointers about what might be wrong or where I should go next? Annoyingly, one time I could see the Picoscope device listed but greyed out, and the OK/Cancel buttons were also disabled.
I've got my scope working with a dedicated Linux machine, so I'm guessing my problem was related to the fact that Chromebook exposes Linux in a container (and I assume the USB data is somehow being mangled). So this request is no longer urgent, but I'd be happy to be a guinea pig if Chromebook compliance is desired.
This is probably related to the two step start up process for a PicoScope. Initially they are identified as a simple PicoTech USB device as seen by your Chromebook, but then when opened by the software the firmware is loaded onto the device, it then disconnects and reconnects on the USB bus, and re enumerates. The timing of this process may be the issue on the Chromebook.
I'm seeing something similar. I'm running Picoscope T&M Early Access 7.0.117.13870. My picoscope is a 2204B MSO (serial # JZ232/0116).
I have two MacBook Pro laptops. One is an Intel-based 2016 (running Monterey 12.6.3) and the other an M1MAX-based 2021 (running Ventura 13.1)
The Intel-based machine can recognized and load the scope when directly connected and most of the time when through a USB hub -- but not always.
The M1-based machine has more difficulty. It recognizes and load the scope after a fresh reboot when directly connected -- no intervening hub. I've rarely seen it identify the scope through a hub.
After booting and using it with a direct connection, then exiting the app, it becomes increasingly unlikely it will successfully load after being identified. When a hub is connected, it typically doesn't even identify -- although I have seen it work once or twice (identify and successfully load) with a hub.
Generally, if I futz around enough, I can get things working going back to direct connection and after rebooting. That's often when I have many windows up and am deeply nested in a trouble-shooting context so it makes for some pain to have to reboot.
I'm now to Picoscope and if there is anything I should be doing to collect helpful data or help make this work more reliably. on my newer machine -- and through hubs in generally -- do let me know.
