I've been experimenting with the example C code for the PS6403 but have run into problems with the examples which use a trigger to start collecting data (the examples which don't use the trigger seem to work OK). The program is able to get to the point where ps6000RunBlock or ps6000RunStreaming is called, but the callback is never called and the g_ready flag is never set, suggesting that the scope is never triggered. This seems to be a problem common to all the examples using the trigger. Has anyone experienced this before or does anyone have any suggestions (maybe I've just missed something obvious)?
I am using the unmodified ps6000 series example C code (PS6000sdk_r10_1_0_17) compiled with Visual Studio C++ 2010.
I am using a PS6403 with a 5v 1kHz square wave connected to channel A through a 1x probe - so I believe this should trigger the scope as set up in the examples (which set a 100mv level trigger on channel A)?
The scope and triggering works fine with the PicoScope 6 software so I don't think it's a hardware problem.
I have just tried this with the unmodified code, selected Triggered Block, pressed a key to prepare it for triggering and then when I applied a signal (1kHz 1V Square Wave) it triggered as shown
PS6000 driver example program
Version 1.1
Opening the device...
Handle: 16384
Device opened successfully, cycle 1
Driver Version: 1.0.0.208
USB Version: 2.0
Hardware Version: 1 1
Variant Info: 6404
Serial: AP487/001
B - Immediate block V - Set voltages
T - Triggered block I - Set timebase
E - Collect a block of data using ETS A - ADC counts/mV
R - Collect set of rapid captures
S - Immediate streaming
W - Triggered streaming
G - Signal generator
X - Exit
Operation:
Collect block triggered...
Collects when value rises past 99mV
Press a key to start...
BlockDataHandler:ps6000SetDataBuffers(channel 0) ------ 0
BlockDataHandler:ps6000SetDataBuffers(channel 1) ------ 0
BlockDataHandler:ps6000SetDataBuffers(channel 2) ------ 0
BlockDataHandler:ps6000SetDataBuffers(channel 3) ------ 0
timebase: 2 oversample:1
BlockDataHandler:ps6000RunBlock ------ 0
Waiting for trigger...Press a key to abort
BlockDataHandler:ps6000Stop ------ 0
BlockDataHandler:ps6000GetValues ------ 0
Ten readings after trigger
Value (mV)
0 157 314 472
-314 0 472 314
0 157 314 314
-157 157 314 157
-157 157 314 314
0 157 472 472
0 0 472 314
0 157 472 472
0 157 629 314
-157 157 314 157
B - Immediate block V - Set voltages
T - Triggered block I - Set timebase
E - Collect a block of data using ETS A - ADC counts/mV
R - Collect set of rapid captures
S - Immediate streaming
W - Triggered streaming
G - Signal generator
X - Exit
Operation:
If you are still having problems please email support@picotech.com and the technical team can look into this for you
Thanks for getting back to me. Having run some more tests I have in some instances experienced the behavior that you report. However, frequently on running triggered block (or another triggered mode) for a second or third time (in the same session) the problems are experienced. I'd be very grateful if you could try repeating the test with multiple runs of one of the triggered modes (without closing the program in between runs). If nothing different happens I'll have to look more closely at my setup.
Thanks for your help with this. I thought I'd let you know that I've now found the cause of the issue and have resolved it - there wasn't a problem with the example code provided in the SDK.
The problem was that I did not take into account the hysteresis on the trigger. Because the trigger is set to 100mv in the example code, I expected my squared wave signal 0-5v to cause a trigger. But because the hysteresis is set to about 400mv in the example file the voltage would actually have to drop to about -300mv before rising again in order for a trigger to occur. Obviously this wouldn't happen with a 0-5v signal. After raising the threshold to a higher value the code functioned as expected.