Hitesh wrote:Unfortunately, the ps6000 driver does not currently provide a trigger time stamping function in rapid block mode.
I am finding this very confusing, and would appreciate a bit more explanation. Page 34 of ps6000pg-en-9.pdf says,3.9.13 ps6000GetTriggerTimeOffset64
__int64 * time,
PS6000_TIME_UNITS * timeUnits,
unsigned long segmentIndex
This function gets the time, as a single 64-bit value, at which the trigger occurred.
Call it after block-mode data has been captured or when data has been retrieved from
a previous block-mode capture.
Applicability Block mode, rapid block mode
handle, the handle of the required device
time, on exit, the time at which the trigger point occurred
timeUnits, on exit, the time units in which time is measured.
segmentIndex, the number of the memory segment for which the
information is required.
This lets you request them one at a time. And Section 3.9.22, ps6000GetValuesTriggerTimeOffsetBulk64 on Page 45, lets you retrieve as many of them as you like in one shot. "Applicability: Rapid block mode
Are you saying this doesn't work, and the documentation is poor? I don't see how this could be true, since PicoScope6 must have some way to obtain the time-stamps it provides for Rapid Block mode.
All is working fine until I found out that the time offset between triggers, is not what the function GetValuesTriggerTimeOffsetBulk64() is meant for. Actually I had to refer to this forum, in order to find that out, because from the API documentation it not unambiguously clear what this function does.
I just read a 4 year old post in which it became clear to me that the function gives an array with the time offsets from start of segment to the trigger of that segment. ...I'm hoping some progress is made in the firmware to also retrieve the relative time between triggers in the rapid block mode? Is there currently a way to get this info?
If that is the case, then I don't understand what the big deal is?
If the API really does provide a time-stamping function (contrary to what Hitesh said), then it doesn't matter if the time-value is (a) relative to the last trigger (what Benny needs), or (b) the start of acquisition (what I understand it to be). For it to be (c) "time offsets from start of segment to the trigger of that segment"
would make NO sense at all, because that's a constant, regardless of how many segments are acquired. And already specified when the trigger position is configured (pre/post settings).
So I'm wondering why the answer to Benny wasn't simply,
>>> deltaTimeBetweenTwoTriggers = timeOffset[n+1] - timeOffset[n].
which is everything he needs, for what he wants to do with it. The API is returning "absolute" times, relative to an initial Tstart. And he's looking for times relative to the previous trigger point, which are easily obtained, and always have been. No need to, "make a request for this to our Development Team for consideration"
This mechanism is far superior to the other option, of returning deltaTs directly in the array, because in that mode, finding the offset from Tstart for a particular segment would then require traversing the entire list and adding up all the deltas. Much easier to just calculate the difference between two neighboring timestamps.