When installing on Ubuntu I also had to run "apt-get install picoscope" twice in order to get a clean installation. When connecting the picoscope 3206 (not an "a" model) it was not recognized at all,, so hoping this will be supported at some point.
Anyway its great that there is now picoscope software for linux and we are looking forward to the final release. keep up the good work Pico !!
great job. I have spent part of my last weeks working on a linux software for our product (some testing equipment) myself and i would love to switch to your "standard" software. And since this might interest more people than just me, i wanted to ask here.
Do you have a roadmap for this software? Or actually a more precise question: Do you have any idea when you will have the software configurable over command line/ macros? This would help tremendously integrating the measurements into other software.
is there any chance you can tell when this software will be configurable over the command line (like macros, option /a)?
I have worked partly on a software for linux myself but since your product would be much more sophisticated i would like to switch to your "standard" software. So i will have to make the decision soon.
Woud be great if you can make that happen...
Kind regards,
Henning
--- sorry for the double post: i didnt read the info at the end that the post is going to be reviewed before actually appearing here
Upgraded to the latest release and I can report that my 3206 is now working on my Ubuntu (12.04)system.
I also installed the latest version on a system with Linux Mint (15) using the original installation instructions and that worked without a glitch.
I'am testing the features the 3206 as much as possible and so far works as expected; the only thing not working is the signal generator. The button to turn on the generator seems clickable but no menu appears. Is this a bug or just not implemented yet?
Many thanks ,
I have
[*]a picoscope 5244B
[*]a laptop runing Ubuntu 12.04 LTS
kernel 3.8.0-35-generic x86_64 GNU/Linux
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1(rev 04)
Every time I plug the picoscope to the USB port the LED turns red and it is listed in the lsusb output. Then, when I start the picoscope software and it tries to connect the scope, the LED flashes green twice or three times producing a "commuting relay" sound but suddently it turns OFF and no data is acquired. The application continues running with no means to reconnect scope unless it is unplugged physically from the USB port and plugged back. Again, LED is red and the process is repeated.
On other laptop it runs OK with an ehci_hcd driver.
Are Enhanced Host Controller and ehcd equivalent? Can I use them? How? Currently, there are no ehci_hcd entries on /sys/bus/pci/drivers . There is an entry called ehci-pci and the xhci_hcd.
The solution I've seen is to recompile kernel with xhci and ehci as modules. Then, blacklist the xhci driver and bind the ehci_hcd driver. Could it work? Is there any other simpler way?
Yes, I can confirm bug for sig gen menu not appearing for 3206.
Oscar,
This is strange, as xhci is USB3.0 controller, while PS5244B is USB2.0 device. The message for xhci seems unrelated. You can always try to unload xhci_hcd:
In /opt/picoscope/share/doc/libps5000a/ example consol program can be found. Can you compile it, run and check if this one works?
This advice should work for any device - /opt/picoscope/share/doc/ directory has a collection of example programs for each range. Testing your device through this would help us understand whether the problem is in PicoScope or in the driver. Further, running the application as root (via sudo) can help us understand whether the problem is with permissions.
I've had a few problems plugging in USB2 devices into USB3 ports. Can you check if that that is the problem? I feel like this is a general Linux bug that needs to be fixed.
$ cd /opt/picoscope/share/doc/libps5000a
$ ./usbtest
Pico USB device found: /dev/bus/usb/003/009
- It belongs to root (which is not you) who has permissions rw-
- The members of group pico (which you are in) have permissions rw-
- Everyone else has permissions r--
- You can write to this device and so will be able to use it.
$ sudo ./autogen.sh
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:31: installing `./config.guess'
configure.ac:31: installing `./config.sub'
configure.ac:10: installing `./install-sh'
configure.ac:10: installing `./missing'
Makefile.am: installing `./depcomp'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking whether make sets $(MAKE)... (cached) yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking operating system... Linux
checking whether make supports nested variables... yes
checking for pthread_atfork in -lpthread... yes
checking for ps5000aOpenUnit in -lps5000a... yes
checking for ANSI C header files... (cached) yes
checking stdio.h usability... yes
checking stdio.h presence... yes
checking for stdio.h... yes
checking for sys/types.h... (cached) yes
checking for string.h... (cached) yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking for sys/types.h... (cached) yes
checking for unistd.h... (cached) yes
checking for stdlib.h... (cached) yes
checking libps5000a-1.1/ps5000aApi.h usability... yes
checking libps5000a-1.1/ps5000aApi.h presence... yes
checking for libps5000a-1.1/ps5000aApi.h... yes
checking libps5000a-1.1/PicoStatus.h usability... yes
checking libps5000a-1.1/PicoStatus.h presence... yes
checking for libps5000a-1.1/PicoStatus.h... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for working volatile... yes
checking for pid_t... yes
checking for size_t... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
$ sudo make
make all-am
make[1]: Entering directory `/opt/picoscope/share/doc/libps5000a'
CC PS5000Acon.o
CCLD ps5000acon
make[1]: Leaving directory `/opt/picoscope/share/doc/libps5000a'
$ sudo make install
make[1]: Entering directory `/opt/picoscope/share/doc/libps5000a'
test -z "/opt/picoscope/bin" || /bin/mkdir -p "/opt/picoscope/bin"
/bin/bash ./libtool --mode=install /usr/bin/install -c ps5000acon '/opt/picoscope/bin'
libtool: install: /usr/bin/install -c ps5000acon /opt/picoscope/bin/ps5000acon
make[1]: Nothing to be done for `install-data-am'.
make[1]: Leaving directory `/opt/picoscope/share/doc/libps5000a'
When running ps5000acon :
Signal Generator option works OK.
Immediate Streaming, captures 100000 samples and it looks OK. When plotting the output file data, it agrees with the expected shape set in the function generator. I can not check now timing.
However, every time I try any of the Triggered options it doesn't trigger. The signal is suppose to be big enough (by default it says that triggers at 999mV and signal has +2V to -2V amplitude).
Trying the same with the Picoscope software, a continuous line (like no data) is displayed on the screen. The generator panel opens and it is possible to tick and set the parameters (not sure if it actually generates the waveform), and when I try to set channel A to something different than default AUTO, the screen freezes.
I still haven't tried the kernel compilation to set xhci and ehci as modules.
After hmaarrfk post I realized what problem we are dealing here with. You are plugging in USB2.0 device into USB3.0 port. In this case kernel will still use xhci_hcd to control this. I have just tested this setup and ran into same difficulties.
There is known issue with libusbx libusb_cleat_halt() call - symptoms are as described. In USB3.0 devices we've worked around by not calling this command at all, yet while implementing this fix didn't think about above situation. I'll try to implement same fix (if it works) in the next release. Sadly, it affects all USB2.0 devices...