Functional Description

• Pin configuration
• Pin map
• Pin descriptions
• 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

This chapter describes the MTi 1-s pinout and gives details about the supported communication interfaces.

Pin configuration

Pin configuration of the MTi 1-series module (top view)

Pin map

The pin map depends on the peripheral selection, as can be seen in the table below. Configuring the peripheral is explained in #Peripheral interface selection.

Pin mapping for peripheral selection

[1] AUX and SYNC_PPS pins are only available on MTi-7/8.

[2] I²C addresses, see #List of I2C addresses.

[3] CTS cannot be left unconnected if the interface is set to UART full duplex. If HW flow control is not used, connect to GND.

Pin descriptions

Peripheral interface selection

The MTi 1-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 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 MTi 1-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 MTi 1-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 MTi 1-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 MTi 1-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 MTi 1-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.

Note: Both the Measurement Pipe and the Notification Pipe have limited sizes and can therefore only contain a limited number of (reduced) Xbus messages. The amount of messages that can be contained in the pipes depends on the size of the individual messages. Both pipes act as a First-In-First-Out (FIFO) buffer: When reading from either pipe, the oldest message in the pipe will be read first. Once the pipe is full, a newly produced message will be discarded by the MTi 1-s and a (reduced Xbus) error message (data overflow, 0x42 0x01 0x29 0x95) will be added to the Notification Pipe. It is therefore important for the host to read out new messages in time, such that the pipe will not fill up, resulting in lost measurement data or notifications.

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

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.

The Master can change the behaviour of the DRDY signal using the Procotol Configuration. Please refer to the description of the ConfigureProtocol opcode (#List of defined opcodes) for more information.

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

ProtocolInfo (0x01)

The ProtocolInfo opcode allows the Master to read the active protocol configuration. The format of the message is as follows (All data is little endian, byte aligned):

m_version:

m_drdyConfig:

ConfigureProtocol (0x02)

The ProtocolInfo opcode allows the Master to change the active protocol configuration. The format of the message is as follows (All data is little endian, byte aligned):

m_drdyConfig:

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 MTi 1-series module acts as an I²C Slave. The User of the MTi 1-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 pulled-up internally, so when left unconnected, the address selection defaults to 0x6B (ADD = 111).

List of I²C addresses

[4] The MTi-1 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 MTi 1-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 MTi 1-series module acts as an SPI Slave. The User of the MTi 1-series module is the SPI Master.

SPI Configuration

The MTi 1-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 MTi 1-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 lines nRE and DE. 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 nRE and DE lines control the buffers inside the transceiver.

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

Behaviour of the nRE and DE lines

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

UART full duplex with RTS/CTS flow control

The user can configure the MTi 1-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 raise the RTS signal during this transfer. Therefore, with every byte received, the module raises the RTS line quickly. The figure below shows this behaviour.

RTS behaviour under data reception

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.