Omega Vehicle Security 1400 User Manual
Registers, Data Formats, & Queries
Appendix C
C-18
ChartScan User’s Manual
Trigger Latency
Each trigger source has an associated latency. This is the time between the actual trigger and its recognition by
the acquisition device.
The following latency times are only representative of the time between when the trigger is detected and when
the trigger has been processed. Hardware latency times and ISR servicing of other tasks at the time of the
trigger event but before the trigger is detected are not accounted for. In other words, these times may be offset
as much as the hardware latency times, in addition to the amount of time that the longest uninterrupted ISR takes
to process.
the acquisition device.
The following latency times are only representative of the time between when the trigger is detected and when
the trigger has been processed. Hardware latency times and ISR servicing of other tasks at the time of the
trigger event but before the trigger is detected are not accounted for. In other words, these times may be offset
as much as the hardware latency times, in addition to the amount of time that the longest uninterrupted ISR takes
to process.
TRIGGER SOURCE
LATENCY
(avg)
(avg)
OBSERVED
VARIATION
VARIATION
External Triggers ( TTL Rising, TTL Falling)
610.95 µs
2.10 µs
Selected Temperature Range
N/A
(1)
N/A
(1)
GET (IEEE only)
645.6 µs
3.10 µs
TALK (IEEE only)
780.53 µs
12.00 µs
“@" character
2.255 µs
620.00 µs
Alarm
N/A
(1)
N/A
(1)
Absolute Time
44.5 µs
27.0 µs
Count (post-trigger)
45.9 µs
28.5 µs
(1) When using a channel level or alarm as the trigger source, the trigger latency is
dependent on the number of channels being scanned and the programmed timebase.
If the scan time is less than or equal to the programmed scan rate, then the maximum
trigger latency is equal to the programmed scan rate. If the scan time is greater than the
programmed scan rate, the maximum trigger latency is equal to the scan time.
dependent on the number of channels being scanned and the programmed timebase.
If the scan time is less than or equal to the programmed scan rate, then the maximum
trigger latency is equal to the programmed scan rate. If the scan time is greater than the
programmed scan rate, the maximum trigger latency is equal to the scan time.
Trigger Overrun
A trigger overrun condition exists if more than one trigger start event or more than one trigger stop event occurs
during one trigger acquisition. This is flagged and notification is given, but no other action is taken. The trigger
overrun bit in the Error Source Register (ESE) is set. The user may query (with the E? command) the Error
Source Register to determine if a trigger overrun has occurred.
during one trigger acquisition. This is flagged and notification is given, but no other action is taken. The trigger
overrun bit in the Error Source Register (ESE) is set. The user may query (with the E? command) the Error
Source Register to determine if a trigger overrun has occurred.
Buffer Overrun
ChartScan’s internal buffer will wrap-around if the controlling computer cannot read the data out of the buffer
before it is completely full. This situation is called “buffer overrun.” It prevents new data from being lost and
keeps the scan rate consistent, but it also overwrites the oldest data.
Although registered as an error, depending on the application, a buffer overrun may be a part of normal
operation.
For example, if a ChartScan unit with 256 Kbytes of memory was configured to scan 16 channels at a
one-minute interval, the buffer would fill and an overrun would occur in about 5.6 days. Regardless of how long
ChartScan is left unattended after that point, it will always maintain the newest 5.6 days of scans.
There are two cases of buffer overrun. One when only one trigger block is in the buffer, and secondly, when
multiple trigger blocks are in the buffer.
If a buffer-overrun occurs, it may be detected by querying the Status Byte (STB) by either a SPOLL (IEEE 488
only) or a U1X command (IEEE 488 or RS-232).
before it is completely full. This situation is called “buffer overrun.” It prevents new data from being lost and
keeps the scan rate consistent, but it also overwrites the oldest data.
Although registered as an error, depending on the application, a buffer overrun may be a part of normal
operation.
For example, if a ChartScan unit with 256 Kbytes of memory was configured to scan 16 channels at a
one-minute interval, the buffer would fill and an overrun would occur in about 5.6 days. Regardless of how long
ChartScan is left unattended after that point, it will always maintain the newest 5.6 days of scans.
There are two cases of buffer overrun. One when only one trigger block is in the buffer, and secondly, when
multiple trigger blocks are in the buffer.
If a buffer-overrun occurs, it may be detected by querying the Status Byte (STB) by either a SPOLL (IEEE 488
only) or a U1X command (IEEE 488 or RS-232).