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
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.
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.
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".
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.
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?