Relative time between triggers Rapid Block Mode

Post general discussions on using our drivers to write your own software here
brenkens
Newbie
Posts: 0
Joined: Tue May 26, 2015 1:03 pm

Relative time between triggers Rapid Block Mode

Post by brenkens »

Hello,

I've recently acquired 4 picoscopes 6404C for automatic analysis of a high bandwidth pulse. So far I was only using 1 segment and analyzing all pulses in the large buffer that was returned. Between each pulse there is a relatively large dark period and therefore I thought the Rapid Block mode would be ideal to ignore the dark data over the USB line and would dramatically increase the number of pulses I could cover.

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. The way I read the following paragraph it should do exactly what I want: Provide me the relative time offsets between triggers.


GetValuesTriggerTimeOffsetBulk64 - This function retrieves the 64-bit time offsets for waveforms captured in rapid block mode.
...
* times, an array of integers. On exit, this will hold the time offset
for each requested segment index. times[0] will hold the time
offset for fromSegmentIndex, and the last times index will hold
the time offset for toSegmentIndex. The array must be long enough
to hold the number of times requested.


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.

Since the topic was very old, 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?

Many thanks!

Benny

Hitesh

Re: Relative time between triggers Rapid Block Mode

Post by Hitesh »

Hi Benny,

Unfortunately, the ps6000 driver does not currently provide a trigger time stamping function in rapid block mode. I will make a request for this to our Development Team for consideration.

I will also report the issue described regarding the Programmer's Guide.

Regards,

Mark_O
Advanced
Posts: 0
Joined: Fri Oct 03, 2014 5:58 am

Re: Relative time between triggers Rapid Block Mode

Post by Mark_O »

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
PICO_STATUS ps6000GetTriggerTimeOffset64
(
short handle,
__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

Arguments
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.

Benny said,
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.

and,

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.

Thanks,

- Mark

Mark_O
Advanced
Posts: 0
Joined: Fri Oct 03, 2014 5:58 am

Re: Relative time between triggers Rapid Block Mode

Post by Mark_O »

GetValuesTriggerTimeOffsetBulk64 - This function retrieves the 64-bit time offsets for waveforms captured in rapid block mode.
Assuming these functions actually work (and they must, or PS6 would have nothing to go on), the problem is simply one of ambiguity in defining what the "offsets" returned are relative TO.

a) the previous segment start (or trigger, which winds up being the same thing),

b) the start of the multi-segment acquisition, or

c) from the start of each segment to the trigger within it (completely worthless)

Since Benny discovered it wasn't (a), it must be (b). The only open question is if timeOffset[0] is 0 (beginning of the initial segment), or non-zero (where the first trigger occurred). I suppose it could also be some potentially much larger number, which would be from when the system was Readied for triggering, until the first trigger finally tripped. That could provide very useful information, since that would enable all the time-stamps to be correlated back to a real-time of day reference point. [e.g. started things at 17:30:00, first trigger 37m42sec later, with all other captures then relative to that original time.] that might run the risk of overflowing the timeClock though, sooner than it would if starting at t0=0.

For every segment after the first, deltaTrig == deltaSegStart, because the triggers are at the same relative position within every segment captured... by definition.

Hitesh

Re: Relative time between triggers Rapid Block Mode

Post by Hitesh »

Hello Benny and Mark_O,

The PicoScope 6000 Series Programmer's Guide is in the process of being updated and reviewed, with a request to make these particular function descriptions clearer.

Unfortunately, this is not a timestamping function returning times relative to the first trigger event or between triggers. This is a feature that will be considered in the future but is not available in the current PicoScope 6000 Series models.

Regards,

Mark_O
Advanced
Posts: 0
Joined: Fri Oct 03, 2014 5:58 am

Re: Relative time between triggers Rapid Block Mode

Post by Mark_O »

Hitesh, thanks very much for nailing this down conclusively. It is much appreciated.
This is a feature that will be considered in the future but is not available in the current PicoScope 6000 Series models.
Wow! That literally blows my mind. A documented capability, but not actually implemented! Can you see the potential for buyers of your quite expensive products to be very, very unhappy, once they discover this tidbit of information? Really, I find it hard to believe it's true, even now, after this grudging admission.

Here's the $64,000 question... How many other Pico series scopes also do not have this capability, but document that they do? ps5000? ps4000? ps3000? Does Pico recognize that using Rapid Block mode to capture bursts of samples separated over time, with no way to determine what those time intervals are, pretty much eliminates the value of that Mode, for many, many purposes? Why is this information just being revealed now? This has been documented for a LONG time.

I was actually planning to buy a ps3000D MSO unit, specifically for it's time-stamped segmented acquisition capability. But I've been holding off for some time now, trying to get my other questions answered by Pico staff. Which, to be perfectly honest, is like pulling teeth.

Thanks for getting one free!

Mark_O
Advanced
Posts: 0
Joined: Fri Oct 03, 2014 5:58 am

Re: Relative time between triggers Rapid Block Mode

Post by Mark_O »

I can only imagine how Benny must feel about this revelation, after having just dropped over $26,000 on a stack of PicoScopes.

Hitesh,
the ps6000 driver does not currently provide a trigger time stamping function in rapid block mode.
This statement is neither accurate, nor true. The driver contains TWO such functions. The correct statement would be that neither of them works. ;)

I'm wondering if this is a capability that isn't yet implemented in the FPGA of the ps6000 scopes? Or if it's just the driver that hasn't implemented the interface layer to it yet?

- Mark

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

Re: Relative time between triggers Rapid Block Mode

Post by Martyn »

Just to clarify, we do not provide trigger time stamping functions for inter block timing, although this may come in future product releases, or updates to existing drivers/fpga code if space permits.

To clear things up:-

The GetTriggerTimeOffset functions do exactly what they say, they return the offset of the trigger from the sampling interval,for the given memory segment. The purpose of these functions is to reference the sampling points to the trigger so that applications that display the waveforms, such as PicoScope, can plot the trace based on the trigger point, and thus avoid the trace jumping around from waveform to waveform.

The actual trigger point of the signal will always occur after the last pre trigger sample, and before or exactly at the first post trigger sample. The time offset gives a calculated time from the trigger point to the post trigger sample point, it can be zero if the trigger and post trigger sample are coincident. With this information you can then draw the trigger at time point 0 on the x-axis, and all the samples at the appropriate sample time plus the offset.
Martyn
Technical Support Manager

brenkens
Newbie
Posts: 0
Joined: Tue May 26, 2015 1:03 pm

Re: Relative time between triggers Rapid Block Mode

Post by brenkens »

Nice to read all these responses. Thanks all. Somehow I was not triggered about this forum activity. And I lost interest after reading my requirements where not possible in the current baseline.

Although I really would like this option, the application I built with an integrated picoscope is still a success. The result is that my automatic analysis only covers a lower amount of pulses because of all the noise I transfer in between the pulses (because I cannot use Rapid Block Mode). I just need 1 continuous buffer now to determine relative timing between pulses.

Anyway, if this option would be made I'd still like to incorporate it into our application. We would like to role out this application as standard part of our machine. It would be nice to know whether PicoTech offers some dedicated support when larger quantities are ordered? In case so I will try to let our procurement contact PicoTech about it.

Regards,

Benny

DavidH
Newbie
Posts: 0
Joined: Thu Feb 18, 2016 2:19 pm

Re: Relative time between triggers Rapid Block Mode

Post by DavidH »

Hitesh wrote: Unfortunately, the ps6000 driver does not currently provide a trigger time stamping function in rapid block mode. I will make a request for this to our Development Team for consideration.

I will also report the issue described regarding the Programmer's Guide.

Regards,
Greetings,

We also bought a 6404C unit and were planning to get a few dozens more for our systems based partly on the "Time between triggers" feature we thought was implemented by the "Get Trigger Time Offset" family commands.
Any development on this yet? That would be very nice, cause its lack hampers our current work.

Thanks!

David

Hitesh

Re: Relative time between triggers Rapid Block Mode

Post by Hitesh »

Hi David,

The feature is not currently supported on the PicoScope 6000 Series devices but I have passed on your comments for our Development Team.

Edit: I have picked up your e-mail support ticket and will respond via that method.

Regards,

brenkens
Newbie
Posts: 0
Joined: Tue May 26, 2015 1:03 pm

Re: Relative time between triggers Rapid Block Mode

Post by brenkens »

Can I follow the development ticket online? Or is it possible to have an estimation whether we can expect this in a Linux driver the this 2016Q2? (I need to release the final version of my tool in this quarter) After this we start production of the tool and the software will be frozen.

Thanks!

Hitesh

Re: Relative time between triggers Rapid Block Mode

Post by Hitesh »

Hi brenkens,

Please e-mail support@picotech.com and we will look to assist you further.

Thanks,

bouttier
Newbie
Posts: 1
Joined: Thu Jun 23, 2016 1:19 pm

Re: Relative time between triggers Rapid Block Mode

Post by bouttier »

Hi,

I'm new to the world of Picoscope but I'm just trying to retrieve the relative time between triggers, either in rapid block mode or simple block mode (i'm working at 200Hz max so it's not a problem) with a picoscope 4227.

Does anyone know if that is possible ? If it is not in the simple way of calling a function, do you know if i'll be able to do it with a 10microseconds accuracy by myself ?

You can take a look at my previous posts if you want to know more about my project :
topic25071.html
topic25081.html

Thanks,
Martin

Hitesh

Re: Relative time between triggers Rapid Block Mode

Post by Hitesh »

Hi Martin,

The trigger timestamping feature is not available for the PicoScope 4227 and is unlikely to be added as it is an obsolete product.

The current PicoScope 3000D and D MSO models support trigger timestamping but are only 8-bit resolution devices compared to the 12-bit resolution of the PicoScope 4000 Series devices. There has been some work on this for the PicoScope 6000 Series as well but I believe it still requires some verification and is not available via the current SDK download (10.6.10.22).

One work around might be to trigger the signal generator output every time the input channel is triggered and measure the time between the signals output. There might be a few milliseconds delay though.

The article on Triggering a PicoScope signal generator using the PicoScope API functions might be useful.

Regards,

Post Reply