Test and Measurement Forum

ps6000RunBlock setup time

Post your C and C++ discussions here

ps6000RunBlock setup time

Postby jowlo » Wed Nov 30, 2016 12:06 pm

Hello!

This is sort of a follow up on the thread https://www.picotech.com/support/post60001.html. My setup is pretty similar to Jansen's:
  • Device (connected over UART) that starts the process to be measured and also pulls a pin used as trigger high.
  • Picoscope 6404D running in rapid block mode capturing the waveforms when triggered.

It is essential for my application, that i capture all traces following a trigger. As in the linked thread, it seems that the oscilloscope is not ready to capture, when the delay between the call to ps6000runBlock and the first trigger is not large enough: The scope does not become ready, which I guess happens, because one (or more) of the first triggers are not captured by the scope.

If I add a delay of ~8ms between the call to ps6000runBlock and starting my device, the problem disappears.

I am trying to speed up the (hundreds of thousands) successive measurement as much as possible. Is there a way to find out, whether/when the scope is ready for the first trigger?
It would also be helpful, if there was any way to determine the minimal delay between the two calls.

Will the use of the GetOverlappedValues function be of any help, although the documentation seems to imply that this only saves the call (and its overhead) to the getValues function?
jowlo
Newbie
 
Posts: 0
Joined: Wed Nov 30, 2016 11:45 am

Re: ps6000RunBlock setup time

Postby Hitesh » Wed Dec 07, 2016 12:58 pm

Hi jowlo,

When the ps6000RunBlock() function is called, it takes a few milliseconds for the device to become ready to start the data capture as settings need to be applied to the device.

If as you have done, the input signal is started after a short delay the device should be ready for the first trigger event. Which is the second call that you are referring to in the 'minimal delay between the two calls'?

The ps6000GetOverlappedValues() function is for successive block captures as opposed to a rapid block acquisition and is designed to help speed up the process of acquiring separate blocks of data.

Regards,
Hitesh

Technical Support Engineer
Hitesh
Site Admin
Site Admin
 
Posts: 2497
Joined: Tue May 31, 2011 3:43 pm
Location: St. Neots, Cambridgeshire

Re: ps6000RunBlock setup time

Postby jowlo » Wed Dec 07, 2016 2:57 pm

Hi Hitesh,

thank you for taking a look into this.

Hitesh wrote:Which is the second call that you are referring to in the 'minimal delay between the two calls'?

I am referring to the function i am calling to start the device whose power is measured and triggers the scope. After all i am looking for a safe way to know when the scope is ready for the first trigger: either a constant time (see below), or a way to determine the delay for each block.

It seems, that the necessary delay is not constant. Especially, it appears to increase after many captures (~2K [rapid] blocks with ~5000 traces each): Although a delay of 40ms works for the first ~2K blocks, it does not continuously.

This is quite hard to debug - and i am not completely sure whether this an error in my measurement code, or the scope's setup time is actually increasing with the number of captured blocks. I do know, that the scope's driver is not calling the ps6000BlockReady-callback although all trigger events have occurred after the call to ps6000RunBlock.

So i was wondering, whether there is a way to check that the scope is actually ready and start the trigger events afterwards. This would help isolating the error.

Thanks for the help,
jowlo
jowlo
Newbie
 
Posts: 0
Joined: Wed Nov 30, 2016 11:45 am

Re: ps6000RunBlock setup time

Postby Hitesh » Tue Dec 13, 2016 2:45 pm

Hi jowlo,

I will raise a New Feature request for this.

When you refer to the delay increasing is that always after capturing 2000 sets of ~5000 traces?

Which version of the ps6000 driver are you using?

Something that you may wish to try is to trigger the signal generator output with a single shot of a waveform using the ps6000SigGenSoftwareControl() function after calling ps6000RunBlock() and then proceeding to start the third party hardware which provides the input signal. Can this device be triggered to start operating at all?

Regards,
Hitesh

Technical Support Engineer
Hitesh
Site Admin
Site Admin
 
Posts: 2497
Joined: Tue May 31, 2011 3:43 pm
Location: St. Neots, Cambridgeshire

Re: ps6000RunBlock setup time

Postby jowlo » Thu Feb 23, 2017 7:28 pm

Hi Hitesh,

sorry it took me eons to answer to this thread again.

Thank you for filing the Feature Request. For now, i settled with just having a 8ms sleep between the ps6000runBlock()-call and starting the operation on the device. Which - to answer your question - can be started via a UART connection.

The issue with the increasing delay turned out to be a programming error on my side, i am sorry for bothering you with that. Completely overhauling the my code made it disappear.

For the records:
I am using the linux driver from debian repos, currently libps6000 1.4.6-6r13 amd64.

Thanks again for your help in resolving this,
jowlo
jowlo
Newbie
 
Posts: 0
Joined: Wed Nov 30, 2016 11:45 am

Re: ps6000RunBlock setup time

Postby Hitesh » Fri Feb 24, 2017 9:09 am

Hi jowlo,

No worries :D

Good to hear things are resolved but if you need any further support, please feel free to post back.

Regards,
Hitesh

Technical Support Engineer
Hitesh
Site Admin
Site Admin
 
Posts: 2497
Joined: Tue May 31, 2011 3:43 pm
Location: St. Neots, Cambridgeshire


Return to C and C++

Who is online

Users browsing this forum: No registered users and 0 guests