I used version 3.6.4.6 of ps3000.dll, see attachment.

Rename to ps3000.zip and unzip

If I understand your question right the answer is:
The trigger is disabled once the device has triggered or you call stop.
It is reenabled next time you call run.

ps3000_ready returns a short with the following values.

Hi Bane,

You need to do a run (or get values) to get the connection state of the device.

The signal generator is unfortunately not supported in PicoScope5.

PicoScope5 running on Ubuntu/Wine with hardware support (PS3000).
Note the running label down in the left corner.

I have created a wine built-in dll.so which uses our linux driver.

Have you had a look at

http://sourceforge.net/projects/picodotnet

The linux drivers we have for our USB scopes do not run in kernel mode.
They are user mode drivers and use usbfs, this is not likely to change with updated kernel versions so the drivers should not break.

For the USBTC08 (temperature logger) we have already released the driver open source.

Hi JMa, I think understand what your problem is. It is not a hardware/device problem. When opening a unit our driver creates a software lock to prevent it beeing opened by another process. If close_unit() is not beeing called, this lock will not be released until you unplug the unit. Unless you can ...

in block mode you only need to call stop if you want to abort a capture. get_values will call stop internally in the driver. if you still want a stop call in there call stop before you call get_data. Are you keeping the unit open whie your application is running or are you trying to close/reopen bet...

Are you running under windows/linux?
Are you using streaming mode at all?
Are you checking all of your return values from the driver calls?
Have you tried reading an error code using ps3000_get_unit_info with PS3000_ERROR_CODE?

I believe the overflow flags are actually overrange flags. They indicate that the voltage measured on that channel will be clipped at the min and max values specified in the driver.

The data will not be corrupted other than the clipping.

I believe this bug has been fixed in the latest driver (ps3000.dll v3.6.3.7).
This version will be available with the next release of PicoScope.

We currently do not have any software for decoding serial data.
What type of serial protocol do you want to look at and which PicoScope do you have?