I have been having trouble with a hang on transferring data out of the scope for some combinations of timebase, store length and triggering mode. This is using PS2000sdk_r6_4_28.
The problem can be duplicated with ps2000con.c and a couple of changes, the modified file is attached. There are a few extra casts added to get it through Visual Studio 2010, but the only functionally relevant changes are:
Increased buffer size (line 51) to 8064.
#define BUFFER_SIZE 8064
Set trigger on CH A with auto trigger after 200ms (line 334, 335)
auto_trigger_ms = 200;
ps2000_set_trigger ( unitOpened.handle, PS2000_CHANNEL_A, 0, PS2000_RISING, 0, auto_trigger_ms );
Now if we run the resulting exe and use i to pick a timebase of 14 or faster, then b to acquire some data it works:
Operation:
b
Collect block immediate...
Press a key to start
timebase: 14 oversample:1
First 10 readings
Value
time unit: 3
(ns)
-1
-1
-1
etc
But if we press i and pick timebase 15 or slower it will now hang on the next b like this:
Operation:
b
Collect block immediate...
Press a key to start
timebase: 15 oversample:1
No data appears, the console application is locked up and wont even respond to ctrl-c. I find unplugging the scope to be an effective way of clearing the freeze.
I noticed if I drop the store length to 4032 bytes, I can step down one slower timebase. 15 and below now work, but 16 and above lock up!
Now I know this there is one less change to make to the sample code to reproduce the lockup. You can leave the store length at the default of 1024 and see the problem with a time base selection of 18.
Thanks for the reply Robyn. Am guessing from your comment about triggering that you didn't make this change:
Set trigger on CH A with auto trigger after 200ms (line 334, 335)
auto_trigger_ms = 200;
ps2000_set_trigger ( unitOpened.handle, PS2000_CHANNEL_A, 0, PS2000_RISING, 0, auto_trigger_ms );
With that alteration (to collect_block_immediate) B does use the trigger, and should time out after 0.2 sec and acquire data in the absence of a trigger being present.
Sticking with the store length of 1000, taking option 17 from the 'i' menu makes B complete after 2.6 seconds. Taking option 18 means its still hung after 60 seconds, at which point I killed it. Presumably I shouldn't have to wait much more than twice as long as I go up 1 extra timebase.
It does look like there is a bug somewhere causing the device to not auto-trigger. I found that the unit would trigger if I applied a signal. Is this the case for you?
Its defiantly different. I can now run a 1000 byte store at any timebase, which is better.
However if I increase the store size to just 2000 bytes, I cannot operate any timebase, which is worse. It hangs earlier than before too, the end of the transcript looks like this:
Operation:
Collect block immediate...
Press a key to start
Previously the hangs were after it printed the line:
timebase: 10 oversample:8
I have just tried changing the #define BUFFER_SIZE up to 8000 (the 2204 has 8 kS of memory) and it appeared to be working correctly.
As the line "timebase: 10 oversample:8" is not being printed, it sounds like ps2000_get_timebase is always returning zero (not that the driver is hanging), indicating that one or more of the parameters are out of range. Can you check the values being passed to ps2000_get_timebase and confirm that the program is stuck in this loop?
Thanks for that, you hit it exactly.
I had an 8x oversample set so only a 1k store length would work on this scope.
So with the new dll appear to be free of lockup problems now.
Incidentally, are there other Picoscopes that don't force a tradeoff between oversampling and store length?
I assume this happens because you are doing the oversample after the data has been written to the acquisition stores. If it was done on the write in (by hardware obviously), the trade off would not be needed.