Timing of data streams onboard the MTi and in XDA (10/100-series)

The three diagrams below shows the (simplified) system architecture of the three Output Configuration presets in MT Manager: Onboard processing, XDA Processing and XDA Processing with SCR data. 

Only when using XDA processing with SCR data, it is possible to output calibrated inertial data at 2000 Hz. However, it is not the recommended setting as onboard processing will provide the shortest latency with data availability directly from the connector.Timing_XDA_and_onboard.png

The table below shows the latency of the various output configurations. Every SampleTimeFine increment is 0.5 ms. This means that when starting up the MTi, the first available calibrated data is available after 2.5 ms and first available orientation is available after 11.19 ms and then every 2.5 ms. This excludes latency from start up and the low pass filters (1.19 ms). 

SampleTimeFine increments      
   Onboard  XDA processing  XDA processing with SCR
After Calibrated data   1..25, etc (not outputted)  1..25, etc (not outputted)  1..25, etc
After SDI  5, 10, 15, 20, 25, etc  5, 10, 15, 20, 25, etc  5, 10, 15, 20, 25, etc
After XKF  5, 25, etc (not outputted)  5, 25, etc (not outputted)  5, 25, etc (not outputted)
After Sample mixer  5, 10, 15, 20, 25, etc  5, 10, 15, 20, 25, etc  5, 10, 15, 20, 25, etc

The PacketCounters and SampleTimeFine of the XDA output correspond to the PacketCounter of the SCR data and/or SDI data coming from the MTi connector. Because of the Sample Mixer, the latency is determined by the SDI output and not by the Sensor Fusion Algorithm XKF.  

Note that the MTi 1-series has a 1000 Hz output from the digital IMU and the architecture is therefore a little bit different from the MTi 10-series and MTi 100-series. 

Communication time delay

The time delay between a physical event (e.g. an orientation change or acceleration) is dictated by two factors:

  1. Internal acquisition, calculation time and message generation (signal processing duration)
  2. Serial transmission time

Thanks to the system architecture of the Xsens sensor fusion algorithm, the signal processing duration is independent of the filter profile. Using a multi-core processing unit, it is possible to bring down the total time from physical event to data transmission on the USB or serial output to several milliseconds.

The serial transmission time can easily be calculated when the byte message and the baud rate is known. 

These factors will be discussed using the example of two common output configurations of the MTi.

The bytes in the message consist of the Preamble, BusID, MessageID, length indicator, data itself and the checksum. The Preamble, BusID, MesssageID, length indicator and checksum together is always 5 bytes. The length of the various data messages is discussed in the Low-level communication protocol documentation.   

Example 1: Euler angels orientation data at 400 Hz and SDI data (delta_q and delta_v) at 100 Hz with a baud rate of 230400 bps (RS232).

Euler angles is 12 bytes, SDI data is 24 bytes. This means that there will be one message of 41 bytes, followed by three messages of 17 bytes, and then one message of 41 bytes again.


Note that, although the average data stream is lower than the baud rate, it is not possible to choose a baud rate lower than 230400 bps in this particular case, as data comes at 400 Hz (every 2.5 ms) and the longest transmission time at a baud rate of 115200 bps would be 3.56 ms.

Example 2: Quaternion data output at 100 Hz with a baud rate of 921600 bps (RS232).

Quaternion data is 16 bytes.

USB communication timing

When the MTi is used with the USB cable, much of the timing depends on the scheduling of the host (e.g. Windows) as the host needs to poll data from the USB devices. For real time interfaces, a serial interface (RS232, RS422 or RS485) is recommended.

Was this article helpful?
0 out of 0 found this helpful
Do you have a question? Please post your question in our Community Forum