Test and Measurement Forum

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.

Any thoughts on why this happens appreciated.

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.

Hi

I have not been able to re-create this either by changing the buffer to 8064 or by using a timebase of 18.

There is a longer delay when using longer timebases. How long are you waiting before aborting?

Also, you mentioned changing the trigger settings, but these are not used when you select option 'B'.

Robin

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.

Hi

Sorry, I should have read your post properly!

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?

Robin

Hi

We believe we have found and fixed the problem.

I have attached an updated driver. Please let me know how you get on with this.

Robin

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

Now it doesn't get that far.

Hi

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?

Robin

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.

Hi

All scopes use oversample * 'store length' of memory.

However, our 4000, 5000 and 6000 series scopes have significantly more memory (up to 1 GS).

http://www.picotech.com/oscilloscope-specifications.html

Robin