Using ps4000GetValuesTriggerTimeOffsetBulk64 with 4227 Scop

Post your C and C++ discussions here
Post Reply
blaenks
Newbie
Posts: 0
Joined: Thu Jul 01, 2010 10:42 am

Using ps4000GetValuesTriggerTimeOffsetBulk64 with 4227 Scop

Post by blaenks »

Hi,

I´m trying to find out the time between two triggerevents (time between two captures) in Rapidblock mode. So I think I have to use the 'ps4000GetValuesTriggerTimeOffsetBulk64' function after reading the segments form the scope.

But when I use the function, i just get some wired values.

Is the TimeOffset the time between two triggerevents, or from beginning of the measurement?

Maybe you can post a short code how I use it correctly

Thanks for your help!

Mathias

Robin
Advanced User
Advanced User
Posts: 558
Joined: Fri Sep 19, 2008 10:17 am

Re: Using ps4000GetValuesTriggerTimeOffsetBulk64 with 4227 S

Post by Robin »

Hi Mathias

This time is the difference between the first sample in a block and the trigger event, found by linear interpolation. This is why you will get both positive and negative values.

It can be used to minimise trigger jitter. I don't think this is what you are after.

Robin

pmulroy
Newbie
Posts: 0
Joined: Wed Jun 23, 2010 8:31 am

Re: Using ps4000GetValuesTriggerTimeOffsetBulk64 with 4227 S

Post by pmulroy »

Hi,

I think I have the same problem here. I´m trying to get the difference in trigger times between samples collected in rapid block mode. Is there a way to do this?

I have tried both of the following but they appear to be as you say the offset from each trigger event rather than an absolute trigger time or at least a trigger time relative to first one.

ps4000GetValuesTriggerTimeOffsetBulk64(unit->handle, times, timeUnits, 0, 9);
ps4000GetValuesTriggerChannelTimeOffsetBulk64(unit->handle, times, timeUnits, 0, 9, PS4000_CHANNEL_A);

Is there any way to get the actual trigger times?

Regards,

Patrick

Chris
Site Admin
Site Admin
Posts: 169
Joined: Tue Aug 17, 2010 9:00 am
Location: St. Neots

Re: Using ps4000GetValuesTriggerTimeOffsetBulk64 with 4227 S

Post by Chris »

There is no API to do this


You'll need to use GetTickCount in the Callback function, and calculate the elapsed time.

msagues
Newbie
Posts: 0
Joined: Fri Feb 24, 2012 7:44 pm

Re: Using ps4000GetValuesTriggerTimeOffsetBulk64 with 4227 S

Post by msagues »

Hello!

I am having some similar problem to the one described here.

I am working with a PicoScope PS 5203, so that the API I am using is "PS5000", but I guess it should work in a similar way to the PS4000.

I want to retrieve the time offset between trigger times and the first sample in its memory segment (Rapid Block Mode). My aim is to reduce the effect of the jitter, which is a mayor problem in our application.

To do this I am using the function "ps5000GetValuesTriggerTimeOffsetBulk64". The function seems to work fine, but all I get in response in the "times" field are zeros.

An important thing: I am using AN EXTERNAL TRIGGER signal. Is there any problem with this?

I see in the description of "ps5000GetTriggerTimeOffset" that this does not work with the external trigger, and I am starting to think that the same condition may apply to "ps5000GetValuesTriggerTimeOffsetBulk64".

Thanks in advance for your time,

Mikel

Martyn
Site Admin
Site Admin
Posts: 4491
Joined: Fri Jun 10, 2011 8:15 am
Location: St. Neots

Re: Using ps4000GetValuesTriggerTimeOffsetBulk64 with 4227 S

Post by Martyn »

Yes you are correct the function "ps5000GetValuesTriggerTimeOffsetBulk64" will only provide values if the trigger source is one of the channels and not the external trigger. Sorry.
Martyn
Technical Support Manager

msagues
Newbie
Posts: 0
Joined: Fri Feb 24, 2012 7:44 pm

Re: Using ps4000GetValuesTriggerTimeOffsetBulk64 with 4227 S

Post by msagues »

Hello Martyn,

I am afraid this is a real problem for us...

We are working on an application where the trigger jitter is a mayor problem.

We need to capture several oscilloscope traces (100 or 128, aprox) of 1000 samples at 2ns sampling rate (with a PicoScope 5203). Our aim is to create an averaged trace, but avoiding the trigger jitter. If we average the traces straight away, the effect of the jitter is hiden, but the performance of the system is seriously damaged.

Could you recommend on the best way to overcome this problem?

Thanks y advance,

Mikel

Post Reply