It looks like the time stamp for a measurement point is defined by the time at which the measure function is called. We’ve got a testcase now were we are triggering on rare events between which we have to wait for seconds, sometimes several minutes. Especially when there is a wait for several minutes and the next events happens seconds after the first, the first measurements gets timeshifted backwards to when the measurement routine was called while the second gets a timestamp that is just off by a few seconds, essentially pulling both measurements appart on the timeline.
Is there any way to update the timestamp within a driver so that we can just update it after a successfull trigger?
the invisible root module “Time” of the sequencer gives a basic access to the the time spent since the start of the run and a timestamp.
If you like to have a more individual time logging, you could have a look at the driver Logger-PC_Time:
There you can see how to log your own time values, e.g. in different units, or starting at different phases.
Furthermore, it would be possible to also change the semantic phase function at which the new time value is taken.
It is correct that the Time module takes a new time during “measure” as this is the phase where a measurement instrument is forced to start acquiring data.
In your case where you have a random trigger event, it would make more sense to take the time when the instrument responds with the data.
I have following options in mind:
You might be able to retrieve a timestamp from the instrument that the instrument driver could return as well by converting it to a timestamp of the Python datetime module.
You create a new driver just for taking the time for this instrument.
One could improve the Logger-PC_Time driver with new options to change for example the phase at which time is taken. Thus, you would be able to configure it to your needs and it would be a general solution for all users that we can maintain via GitHub and our server.