Sampling time

We recently noticed that with the current DLL v2.5 the sampling time vector/array is not what we expect.
For example, we want to measure in between 0s and 8e-4s. So we set
obj.AcquireDefinition.value.StartTime=0
obj.AcquireDefinition.value.StopTime=8e-4
and run update/acquire etc. All works fine but in the ReplayData the t0 is not equal to the StartTime but slightly off, e.g. t0 = double(obj.ReplayData.t0.Value); % (which is t0=-1e-8)
Since we calculate the time vector with t0:dt:t0+dt*(NumSamples-1) of course the stoptime is also wrong. Even more weird, sometimes t0 is correct. But we couldn't determine a logic behind this.

Does anyone have/had the same experience? The code worked with previous DLLs.

We recently noticed that with the current DLL v2.5 the sampling time vector/array is not what we expect. For example, we want to measure in between 0s and 8e-4s. So we set obj.AcquireDefinition.value.StartTime=0 obj.AcquireDefinition.value.StopTime=8e-4 and run update/acquire etc. All works fine but in the ReplayData the t0 is not equal to the StartTime but slightly off, e.g. t0 = double(obj.ReplayData.t0.Value); % (which is t0=-1e-8) Since we calculate the time vector with t0:dt:t0+dt*(NumSamples-1) of course the stoptime is also wrong. Even more weird, sometimes t0 is correct. But we couldn't determine a logic behind this. Does anyone have/had the same experience? The code worked with previous DLLs.

Hello Cschaal,
Small changes to t0 are made to estimate the trigger transition point, to stop jitter in the displayed waveform. This functionality was added to 2.5, as a result of user request. As an example, say the trigger threshold is 0V, and the sample before the trigger is -1V and the trigger sample is 1V, we use linear interpolation to estimate a corrected trigger time of -5ns. We subtract the correction from t0. For this example if t0 had been -10ns (so we could see the sample before the trigger) it would not become -10 - (-5) = -5ns. The trigger point (0V) would now be at 0ns (rather than at -5ns), and the next sample at 5ns and so on.

Our applications graphing software allows the t0 time to change in this way, so that the trigger point remains stable (rather than jittering over -5 to +5ns). If this is not a behaviour you want, what would you suggest?

Hello Cschaal, Small changes to t0 are made to estimate the trigger transition point, to stop jitter in the displayed waveform. This functionality was added to 2.5, as a result of user request. As an example, say the trigger threshold is 0V, and the sample before the trigger is -1V and the trigger sample is 1V, we use linear interpolation to estimate a corrected trigger time of -5ns. We subtract the correction from t0. For this example if t0 had been -10ns (so we could see the sample before the trigger) it would not become -10 - (-5) = -5ns. The trigger point (0V) would now be at 0ns (rather than at -5ns), and the next sample at 5ns and so on. Our applications graphing software allows the t0 time to change in this way, so that the trigger point remains stable (rather than jittering over -5 to +5ns). If this is not a behaviour you want, what would you suggest?

Hey,

thanks for letting me know about the new implementation. All fine with me. I was just worried if there is some error in our code or in the DLL which causes the changes to t0. Having a stable trigger point seems more important than having t0 to be equal to the desired starttime.

Hey, thanks for letting me know about the new implementation. All fine with me. I was just worried if there is some error in our code or in the DLL which causes the changes to t0. Having a stable trigger point seems more important than having t0 to be equal to the desired starttime.

Another thing we never used for a long time is a different starttime than 0s. Even though the returned t0 is correctly adjusted to given starttime and trigger point, the samples in e.g. ReplayData.ChanAData.Value(1:NumSamples) do not correspond to that starttime/t0. The first sample in the data always correspond to time = 0s and not the desired starttime.
Do we have to pick the right samples from the channel data ourselves (e.g. by taking only 2350:NumSaples data points)?

Another thing we never used for a long time is a different starttime than 0s. Even though the returned t0 is correctly adjusted to given starttime and trigger point, the samples in e.g. ReplayData.ChanAData.Value(1:NumSamples) do not correspond to that starttime/t0. The first sample in the data always correspond to time = 0s and not the desired starttime. Do we have to pick the right samples from the channel data ourselves (e.g. by taking only 2350:NumSaples data points)?