FASTRAK MANUAL
Rev. G
E-2
JUNE 2012
This period is important to helmet display or virtual reality applications since dynamic errors
between the actual and computed coordinates can be very noticeable to the eye.
To discuss effective latent period let the beginning of the magnetic field sampling be at
t=0; let the end of sampling be at t=
τ
; and let the time that the solution appears in the output
buffer be t=T. The computed solution for a receiver moving at constant velocity will correspond
to where the receiver was at t=
τ
/2, the midpoint of the sampling period; hence, the effective
latency is T -
τ
/2, or 3.75 ms.
OTHER FACTORS
Although the time to transmit data is not included in the definition of latent period, a
knowledge of how to compute these delays is needed to properly align in time the receipt of
tracker solution with the actual event. For example, the factory default ASCII output record x-y-
z-az-el-rl is composed of 47 bytes (3 status bytes, 6 data words each 7 bytes long, and a CR LF
terminator) and at 115.2K Baud requires a transmission time of 4 ms (recall that there is one start
bit and one stop bit per 8 bit data byte). The tracker’s sync-to-output latent period plus transmit
time for this example is 9.5 ms, and the effective latent period plus transmit time is 5.8 ms.
It is very important to note that if the transmit time exceeds the tracker cycle time (8.33
ms), which could happen if the baud rate is too slow or if the record length is too long, it
becomes necessary for the tracker to periodically discard solutions to prevent output buffer
overflow. This would make it appear as though the tracker was not tracking continuously or was
dropping data. This interface problem is most noticeable in multiple receiver operation as the
tracker is designed to maintain constant order of receiver processing. If the interface just missed
a given receiver in the list of multiple receivers, the tracker will output nothing until this receiver
is again processed.
Another common problem is the RS232 communications XON/XOFF protocol. If the
user’s computer cannot assimilate the tracker’s output fast enough, the computer can transmit an
XOFF signal to the tracker commanding it to stop transmitting. When the user’s computer has
finally assimilated the data it has accumulated, it transmits an XON command and the tracker
once again begins transmitting coordinate data. During the XOFF period the tracker’s output
buffer is continually discarding solutions to prevent buffer overflow, thus many data sets are
never transmitted. Toggling of XON/XOFF in the user’s computer could be happening without
the user’s knowledge and could again make it appear that tracker sync-to-output latent period
was varying from 5.5 ms to many times this, and periodically dropping data. The RS232 lines
should be monitored if this problem is suspected.
A third problem is asynchronous interfacing, and a particularly annoying example of such
an interface is MIL-STD-1553 as this bus is not only asynchronous but often very slow (e.g. 25
Hz). Asynchronous interfaces guarantee that on the average the apparent latent period will be
increased by one half the tracker cycle time. For a slow 25 Hz bus rate, the sync-to-output latent
period would vary from 5.5 ms to 13.8 ms. Another example is a unsynchronized computer
issuing single record print commands at random times in the tracker’s cycle.