PicoScope 7 Software
Available on Windows, Mac and Linux
Trigger timeout on 2205A scopes
Trigger timeout on 2205A scopes
Hi,
I'm communicating with a 2205A scope from my own C code running on Ubuntu Linux. The driver is reported as: PS2000 Linux driver, 3.0.105.3345
I'm making data collections in block mode following the guidance in the picoscope-2000-series-programmers-guide pdf. When I enable a trigger, by making a call to ps2000_set_trigger2(), and then make a collection in which the input doesn't cause the trigger to fire, I find that the timeout I get is less than that I set in the 'auto_trigger_ms' argument of ps2000_set_trigger2(). So, for example, I might set the timeout as 1000ms, but then get a total collection time (time until ps2000_ready() returns > 0) of something like 600ms. If I increase the timeout the time the scope waits increases, but is always less than requested.
Given the description of the meaning of this argument in the above pdf ("the delay in milliseconds after which the oscilloscope will collect samples if no trigger event occurs") I'd have thought that the total collection time should be greater, not less, than the value passed. Or am I missing something?
I've tried all sorts of things to see if I can work out what's wrong, but without success. Using ps2000_set_trigger() instead, for example, produces exactly the same behaviour. I also have a couple of 2205A units and find they both behave in exactly the same way. Is this a known issue and if so is there a workaround?
Thanks, Ian.
I'm communicating with a 2205A scope from my own C code running on Ubuntu Linux. The driver is reported as: PS2000 Linux driver, 3.0.105.3345
I'm making data collections in block mode following the guidance in the picoscope-2000-series-programmers-guide pdf. When I enable a trigger, by making a call to ps2000_set_trigger2(), and then make a collection in which the input doesn't cause the trigger to fire, I find that the timeout I get is less than that I set in the 'auto_trigger_ms' argument of ps2000_set_trigger2(). So, for example, I might set the timeout as 1000ms, but then get a total collection time (time until ps2000_ready() returns > 0) of something like 600ms. If I increase the timeout the time the scope waits increases, but is always less than requested.
Given the description of the meaning of this argument in the above pdf ("the delay in milliseconds after which the oscilloscope will collect samples if no trigger event occurs") I'd have thought that the total collection time should be greater, not less, than the value passed. Or am I missing something?
I've tried all sorts of things to see if I can work out what's wrong, but without success. Using ps2000_set_trigger() instead, for example, produces exactly the same behaviour. I also have a couple of 2205A units and find they both behave in exactly the same way. Is this a known issue and if so is there a workaround?
Thanks, Ian.
Re: Trigger timeout on 2205A scopes
Sorry if I've wasted anyone's time with this but I think I've found the problem.
I thought that the nanosleep() call, which I'm using to wait for the scope to be ready, paused a thread by the requested time. Not sure where I got that from because of course it turns out that, like usleep(), it does no such thing. It pauses it by at least the requested time. When I time the scope's timeout with a couple of clock_gettime() calls everything all of a sudden makes sense.
As ever, I should have read the manual. The most dangerous thing is when you think you know something and so don't need to.
Ian.
I thought that the nanosleep() call, which I'm using to wait for the scope to be ready, paused a thread by the requested time. Not sure where I got that from because of course it turns out that, like usleep(), it does no such thing. It pauses it by at least the requested time. When I time the scope's timeout with a couple of clock_gettime() calls everything all of a sudden makes sense.
As ever, I should have read the manual. The most dangerous thing is when you think you know something and so don't need to.
Ian.