Correct calculation of trigger delay in niScope_ConfigureTriggerDigital

[blakney]

In the case where one uses the trigger delay option form niScope_ConfigureTriggerDigital, the input is a double precision real in units of seconds. This value is presumably converted to integer sample dwell periods "behind the wizards curtain". Would this conversion be best approximated by a ceiling, floor and rounding function. Also is this conversion consistent for all NI Scope versions (and hopefully future versions.)

Finally, the accuracy in the measurement of this value on a  Tclocked locked PXI 5421/PXI 5122 is a function of the digitizer's clock accuracy, the PXI clock accuracy, and the AWG clock accuracy. Since the accuracy of the trigger basically boils down the the Tclock accuracy,  only the digitizer's clock (since it is free running during the pretrigger scans) and the number of pretrigger scans really add to that Tclock error?

FYI - the value is needed to deconvolve the original phase (and in our case there are unfortunately zero, first and second order phase shifts) of a signal from our ICR mass spectrometer. 

Thanks, Greg

[Stephenah · Accepted solution]

Greg,
  Using TClk to lock  two boards together will configure them for start triggers and ensure that they both start together.  When the they are Tclked together they will recognize triggers on the same edge of TClk.  The TClks on both boards will have a small amount of skew that is constant for a system and can be measured.  Measurements taken with the system can then be adjusted to account for the skew.  The only jitter in TClk comes from the jitter of the individual boards' clock.  If you configure the digitizer for a reference trigger the trigger time will be as accurate as it would be in a normal case and it is possible to figure out when the reference trigger occurred relative to the 5421's time.

The trigger delay will get rounded.

Stephen