Functional description

• Pin description
• Pin Map
• Peripheral interfaces
• Peripheral interface selection
  • Peripheral interface architecture
  • Xbus Protocol
  • MTSSP Synchronous Serial Protocol
  • I2C
  • SPI
  • UART half-duplex
  • UART full duplex with RTS/CTS flow control
  • CAN (Controller Area Network)

This chapter describes the Xsens Avior OEM series pinout and gives details about the supported communication interfaces.

Pin description

Below figure shows the pin configuration of the Xsens Avior OEM series.

Pin configuration of the Xsens Avior OEM series

Below table shows the pin descriptions of the Xsens Avior OEM series.

Overall Pin functions

Peripheral function selection

Function descriptions

* Supported from FW 1.3.0 and later

UART with flow control option

Pin descriptions Avior OEM Host Interface through UART with flow control

* Supported from FW 1.3.0 and later

UART with half duplex control option

Pin descriptions Avior OEM Host Interface through UART with half duplex control

* Supported from FW 1.3.0 and later

SPI option
Pin descriptions Avior OEM Host Interface through SPI

I2C option
Pin descriptions Avior OEM Host Interface through I2C

Pin Map

The pin mapping depends on the status of the selection pins (pin 8 = SEL0 and pin 10 = SEL1), which will be sampled during the boot sequence of the module. When both of these pins are pulled high (with external pull-ups) these pins are used as I2C pins after boot-up (the user must ensure that no I2C communication is happening during the boot-up sequence). The DRDY signal (pin 6) can then be used to indicate to the host/master that new data is available (for SPI and I2C communication).

Peripheral interfaces

The Avior OEM series supports different peripheral interfaces depending on the peripheral selection inputs. These are all low-level interfaces that need proper transceivers (e.g. RS232 or CAN transceiver) added externally when communicating over a cable. Some peripherals (e.g. SPI or I2C) can also be directly connected to a host MCU.

Peripheral interface selection

The Xsens Avior-series module supports UART, I²C, and SPI interfaces for host communication. The host can select the active interface through the peripheral selection pins PSEL0 and PSEL1. The module reads the state of these pins at start-up, and configures its peripheral interface according to the Table below. To change the selected interfaces, the host must first set the desired state of the PSEL0 and PSEL1 pins, and then reset the module. The module has internal pull-ups on the PSEL0 and PSEL1 pins. If these pins are left unconnected, the peripheral interface selection defaults to I²C (PSEL0 = 1, and PSEL1 = 1).

Peripheral interface selection

Peripheral interface architecture

At its core, the module uses the Xsens-proprietary Xbus protocol which is compatible with all Xsens Motion Tracker products. This protocol is available on all interfaces; UART (asynchronous serial port interfaces), I²C and SPI interfaces. The I²C and SPI interfaces differ from UART in that they are synchronous, and have a master-slave relationship in which the slave cannot send data by itself. This makes the Xbus protocol not directly transferable to these interfaces. For this purpose, the module introduces the MTi Synchronous Serial Protocol (MTSSP) protocol, a protocol for exchanging standard Xbus protocol messages over the I²C and SPI interfaces. The below figure shows how MTSSP fits in the module's (simplified) communication architecture. The module has generic Input- and Output-Queues for Xbus protocol messages. For I²C and SPI, the MTSSP layer translates these messages, while for the UART connection, the module transports the messages as-is.

Communication architecture of Xsens Avior-series module (simplified)

Xbus Protocol

The Xbus protocol is Xsens’ proprietary protocol for interfacing with the MTi 1-series. The MT Low Level Communication Protocol Documentation is a complete reference for the protocol. For a better understanding of the MTSSP explanation, the advice is to read the protocol reference first.

MTSSP Synchronous Serial Protocol

This Section specifies the MTi Synchronous Serial Protocol (MTSSP). The Xsens Avior-series module uses MTSSP as the communication protocol for both the I²C and SPI interfaces. The embedded example codes, which can be found in the MT SDK folder of the MT Software Suite, provide a reference implementation for the host side of the protocol.

Data flow

MTSSP communication happens according to the master-slave model. The Xsens Avior-series module will always fulfill the slave-role while the user/integrator/host of the module is always the Master. The Master always initiates and drives communication. The Master either writes a message to the module, or reads a message from the module.

The figure below shows the data flow between the host (Master Device), and the Xsens Avior-s (Slave). The Master can control the Module by sending Xbus messages to the Control Pipe. The Module considers the bytes received in a single bus transfer to be exactly one Xbus message. The Xsens Avior-s places the received message in the Input Queue for further handling. The Xbus Interpreter handles the messages in the Input Queue, and places the response messages in the Output Queue. The Master Device can read these response messages from the Notification Pipe.

The Master can switch the Module between configuration and measurement mode by sending the usual GotoConfig and GotoMeasurement (reduced Xbus) messages to the Control Pipe. When placed in Measurement mode, the module will place the generated measurement data (MTData2) in the Measurement Pipe. The Master Device has to read the Measurement Pipe to receive measurement data.

For the Master to know the size of the messages in the Notification and Measurement pipes, it can read the Pipe Status. The Pipe Status contains the size in bytes of the (single) next message in both the Notification and Measurement pipes. The Master can tweak the behavior of the protocol by writing the Protocol Configuration. The Master can also read the Protocol Configuration to check current behavior, and get protocol information.

For best practices for I²C and SPI communication, please see BASE: Best practices I²C and SPI

Data flows within MTSSP

Data ready signal

The Data Ready Signal (DRDY) is a notification line driven by the module. Its default behavior is to indicate the availability of new data in either the Notification or the Measurement pipe. By default, the line is low when both pipes are empty, and will go high when either pipe contains an item. As soon as the Master has read all pending messages, the DRDY line will go low again.

Opcodes

The Master starts each transfer with an opcode. The opcode determines the type of the transfer. The defined opcodes are as listed in the table below. Following the opcode, and depending on whether it is a read or write transfer, the Master either reads or writes one or more data bytes. The specific transfer format depends on the underlying bus protocol (I²C or SPI).

For some opcodes, the MTSSP uses reduced Xbus messages. A reduced Xbus message is a regular Xbus message with the preamble and busID fields removed to save bandwidth. These fields correspond to the first two bytes of a regular Xbus message. The calculation of the checksum for a reduced Xbus message still includes the busID and assumes its value to be 0xFF. For an overview of available Xbus messages, refer to the MT Low Level Communication Protocol Documentation.

List of defined opcodes

ControlPipe (0x03)

The ControlPipe opcode allows the Master to write messages to the Control Pipe. The bytes following the opcode represent a single (reduced) Xbus message.

PipeStatus (0x04)

The PipeStatus opcode allows the Master to retrieve the status of the module's Notification- and Measurement pipes. The format of the message is as follows (All data is little endian, byte aligned):

NotificationPipe (0x05)

The Master uses the NotificationPipe opcode to read from the Notification Pipe. The read data is a single reduced Xbus message.

MeasurementPipe (0x06)

The Master uses the MeasurementPipe opcode to read from the Measurement Pipe. The read data is a single reduced Xbus message (MTData2).

I²C

The Xsens Avior-series module acts as an I²C Slave. The User of the Xsens Avior-series module is the I²C Master.

The user can configure the I²C slave address through the ADD0, ADD1 and ADD2 pins. The module reads the state of these pins at start-up, and configures the slave address according to the table below. The ADD0, ADD1 and ADD2 pins are floating by default, and need to be pulled up (VDDIO) or down (GND) by the user.

List of I²C addresses

[1] The Xsens Avior module relies on the I²C clock stretching feature to overcome fluctuations in processing time. The Master is required to support this feature.

Writing to the Xsens Avior-s

Write operations consists of a single I²C write transfer. The Master addresses the module and the first byte it sends is the opcode. The bytes that follow are the data bytes. The interpretation of these data bytes depends on the opcode, as described in #MTSSP.

The maximum message size a module can receive is 512 bytes. If the Master sends more than 512 bytes, the module will reset its receive-buffer, which reduces the received message to consist only of the excess bytes.

The below figure shows the I²C transfer of a write message operation:

I²C write message operation

Reading from the module

To read from the module, the Master first does an I²C write transfer to transmit the opcode. The opcode tells the module what data the Master wants to read. The module then prepares the requested data for transmission. The Master then does an I²C read transfer to retrieve the data. The figure below shows the I²C transfers for the described read method.

Read message operation with full write transfer and full read transfer (I²C)

Alternatively, the user can perform the read operation using an I²C transfer with a repeated start condition. The below figure depicts this read method.

Read message transfer using a repeated start condition (I²C)

The Master controls how many data bytes it reads. For reading the Notification- and Measurement Pipes, the number of bytes the Master must read depends on the size of the pending message. In order to determine the correct number of bytes, the Master should first read the Pipe Status to obtain the sizes of the pending messages.

If the Master reads more bytes than necessary, the module will restart sending the requested data from the beginning.

SPI

The Xsens Avior-series module acts as an SPI Slave. The User of the Xsens Avior-series module is the SPI Master.

SPI Configuration

The Xsens Avior-series supports 4-wire mode SPI. The four lines used are:

• Chip Select (SPI_nCS)
• Serial Clock (SPI_SCK)
• Master data in, slave data out (SPI_MISO)
• Master data out, slave data in (SPI_MOSI)

The module uses SPI mode 3: It captures data on the rising clock edge, and it latches/propagates data on the falling clock edge. (CPOL=1 and CPHA=1). Data is clocked-out MSB first. The module uses an 8-bit data format.

Data transfer

The module uses  a single type of SPI transfer for all communications. The below figure depicts this basic transfer.

SPI basic transfer

The Master starts a transfer by pulling the SPI_nCS low, in order to select the Slave. The Master must keep the SPI_nCS line low for the duration of the transfer. The Slave will interpret the rising edge of the SPI_nCS line as the end of the transfer. The Master places the data it needs to transmit on the SPI_MOSI line. The Slave will place its data on the SPI_MISO line.

The Master first transmits the opcode. The opcode determines what kind of data the Master transmits, and what kind of data the Master wants to read from the Slave (see #MTSSP). The second-to-fourth byte the Master transmits are the fill words. These fill words are needed to give the Slave time to select the data it must send for the remainder of the transfer. Both Master and Slave are free to choose the value of the fill words, and the receiving end should ignore their value. However, the first 4 bytes transmitted by the MTi 1-series module (Slave) are always 0xFA, 0xFF, 0xFF, 0xFF.

Following the first four words are the actual data of the transfer. It is the responsibility of the Master to determine how many bytes it must transfer. For reading the Notification- and Measurement Pipes, the number of bytes the Master must read depends on the size of the pending message. In order to determine the correct number of bytes, the Master should first read the Pipe Status to obtain the sizes of the pending messages.

Timing

The table below and figure specify the timing constraints that apply to the SPI transport layer. The Master must adhere to these constraints.

SPI timing

SPI timing

UART half-duplex

The user can configure the Xsens Avior-series module to communicate over UART in half-duplex mode. The UART frame configuration is 8 data bits, no parity and 1 stop bit (8N1). In addition to the RX and TX pins, the modules use control line DE. There is no nRE line available on the Xsens Avior-series. However, as you can see from the image “Behaviour of the nRE and DE lines” below, the user can simply use the DE line also as the nRE line. We intend to raise/lower those two lines at the same time anyway. The modules use these control outputs to drive the TX signal on a shared medium and to drive the signal of the shared medium on the RX signal.

A typical use case for this mode is to control an RS485 transceiver where the shared medium is the RS485 signal, and the DE line controls the buffers inside the transceiver.

When the module is transmitting data on its TX pin, it will raise the DE line, else it will pull it low. The figure below depicts the behaviour of the involved signals.

Behaviour of the nRE and DE lines

Note that in this mode the UART of the Xsens Avior-s itself is still operating full duplex.

UART full duplex with RTS/CTS flow control

The user can configure the Xsens Avior-s module to communicate over UART in full duplex mode with RTS/CTS flow control. The UART frame configuration is 8 data bits, no parity and 1 stop bit (8N1). In addition to the RX and TX signals for data communication, the module uses the RTS and CTS signals for hardware flow control.

The CTS signal is an input for the module. The module checks the state of the CTS line at the start of every byte it transmits. If CTS is low, the module transmits the byte. Otherwise, it postpones transmission until CTS is lowered. When, during the transmission of a byte, the user raises the CTS signal, then the module completes transmission of that byte before postponing further output. The module will not retransmit this byte. The figure below shows the behaviour of the TX and CTS lines.

Data transmit behaviour under CTS

The RTS signal is an output for the module. If the RTS line is high, the module is busy and unable to receive new data. Otherwise, the module’s UART is idle and ready to receive. After receiving a byte, the direct memory access (DMA) controller of the module will transfer the byte to its receive first in first out (FIFO) buffer. The module will not pull up the RTS signal during this transfer. 

Only in the following cases the RTS is pulled up:

• If the Rx buffer is completely filled. This could happen if a lot of data is sent continuously on the Rx line.
• During device initialization or after a reset.

The user can use this communication mode without hardware flow control. In this case, the user must tie the CTS line low (GND) to make the module transmit.

CAN (Controller Area Network)

A Controller Area Network (CAN bus) is a robust standard designed to allow communication between devices in applications without a host computer. The Xsens Avior module provides raw CAN_Rx and CAN_Tx lines which can be combined with a CAN transceiver and termination resistance (if needed). The CAN interface of the Avior series does not have a termination resistor. It can be used in a CAN bus that already incorporates the required termination. If used in a single device connection or when placed at the end of a CAN bus, a 120 Ω termination resistor needs to be added between CAN_H and CAN_L pins. The user can choose between regular CAN 2.0 A/B or CAN-FD, as long as the connected CAN transceiver chip supports this. For more information, refer to the Hardware Integration Manual and MT CAN Protocol Documentation.