LPMS Communication Protocol
- Klaus Petersen
- HueiY
LP-BUS Protocol
LP-BUS is a communication protocol based on the industry standard MODBUS protocol. It is the default communication format used by LPMS devices.
An LP-BUS communication packet has two basic command types, GET and SET, that are sent from a host (PC, mobile data logging unit etc.) to a client (LPMS device). Later in this manual we will show a description of all supported commands to the sensor, their type and transported data.
GET Commands
Data from the client is read using GET requests. A GET request usually contains no data. The answer from the client to a GET request contains the requested data.
SET Commands
Data registers of the client are written using SET requests. A SET command from the host contains the data to be set. The answer from the client is either ACK (acknowledged) for a successful write, or NACK (not acknowledged) for a failure to set the register occurred.
Packet Format
Each packet sent during the communication is based on the following structure:
Byte # | Name | Description |
0 | Packet start (3Ah) | Data packet start |
1 | OpenMATID byte 1 | Contains the low byte of the OpenMAT ID of the sensor to be communicated with. The default value of this ID is 1. The host sends out a GET / SET request to a specific LPMS sensor by using this ID, and the client answers to request also with the same ID. This ID can be adjusted by sending a SET command to the sensor firmware. |
2 | OpenMAT ID byte 2 | High byte of the OpenMAT ID of the sensor. |
3 | Command # byte 1 | Contains the low byte of the command to be performed by the data transmission. |
4 | Command # byte 2 | High byte of the command number. |
5 | Packet data length byte 1 | Contains the low byte of the packet data length to be transmitted in the packet data field. |
6 | Packet data length byte 2 | High byte of the data length to be transmitted. |
x
| Packet data(n bytes)
| If data length n not equal to zero, x = 6+1, 6+2…6+n. Otherwise x = none. This data field contains the packet data to be transferred with the transmission if the data length not equals to zero, otherwise the data field is empty. |
7+n | LRC byte 1 | The low byte of LRC checksum. To ensure the integrity of the transmitted data the LRC checksum is used. It is calculated in the following way: LRC = sum(OpenMAT ID, Command, Package data length, and packet data byte no. 1 to no. x) The calculated LRC is usually compared with the LRC transmitted from the remote device. If the two LRCs are not equal, and error is reported. |
8+n | LRC byte 2 | High byte of LRC check-sum. |
9+n | Termination byte 1 | 0Dh |
10+n | Termination byte 2 | 0Ah |
Data Format in a Packet Data Field
Generally, data is sent in little-endian format, low order byte first, high order byte last. Data in the data fields of a packet can be encoded in several ways, depending on the type of information to be transmitted. In the following we list the most common data types. Other command-specific data types are explained in the command reference.
Identifier | Description |
Int32 | 32-bit signed integer value |
Int16 | 16-bit signed integer value |
Float32 | 32-bit float value |
Vector3f | 3 element 32-bit float vector |
Vector3i16 | 3 element 16-bit signed integer vector |
Vector4f | 4 element 32-bit float vector |
Vector4i16 | 4 element 16-bit signed integer vector |
Matrix3x3f | 3x3 element float value matrix |
Sensor Measurement Data in Streaming Mode
In streaming mode, LP-BUS transports measurement data in the following form, wrapped into the standard LP-BUS protocol. See the following chapter for examples of transmission packets. The order of the sensor data chunks depends on which sensor data is switched on
The following is the data types in 32-bit float transmission mode.
In 32-bit float transmission mode:
Chunk # | Data type | Sensor data |
1 | Float32 | Timestamp (ms) |
2 | Vector3f | Raw (uncalibrated) gyroscope data (deg/s) |
3 | Vector3f | Raw (uncalibrated) accelerometer data (g) |
4 | Vector3f | Raw (uncalibrated) magnetometer data (T) |
5 | Vector3f | Angular velocity (rad/s) |
6 | Vector4f | Orientation quaternion (normalized) |
7 | Vector3f | Euler angle data (rad) |
8 | Vector3f | Linear acceleration data (m/s2) |
9 | Float32 | Barometric pressure (mPa) |
10 | Float32 | Altitude (m) |
11 | Float32 | Temperature (°C) |
12 | Float32 | Heave motion (m) (optional) |
In 16-bit transmission mode values are transmitted to the host with a multiplication factor applied to increase precision:
Order # | Data type | Sensor data | Factor |
1 | uint32 | Timestamp (s) | 400 |
2 | Vector3i16 | Raw (uncalibrated) gyroscope data (rad/s) | 1000 |
3 | Vector3i16 | Raw (uncalibrated) accelerometer data (g) | 1000 |
4 | Vector3i16 | Raw (uncalibrated) magnetometer data (uT) | 100 |
5 | Vector3i16 | Angular velocity (rad/s) | 1000 |
6 | Vector4i16 | Orientation quaternion (normalized) | 10000 |
7 | Vector3i16 | Euler angle data (rad) | 10000 |
8 | Vector3i16 | Linear acceleration data (g) | 1000 |
9 | Int16 | Barometric pressure (kPa) | 100 |
10 | Int16 | Altitude (m) | 10 |
11 | Int16 | Temperature (°C) | 100 |
12 | Int16 | Heave motion (m) (optional) | 1000 |
NOTE: Raw accelerometer data is transmitted with misalignment correction and scaling to g units applied. Raw gyroscope data is transmitted with misalignment correction, bias correction and scaling to rad/s applied. Raw magnetometer data is transmitted with misalignment correction and scaling to uT applied, hard and soft iron calibration is not applied to raw magnetometer data transmitted directly from sensor.
Example Communication
In this section we will show a few practical examples of communication using the LP-BUS protocol. For further practical implementation ideas check the open source code of LpmsControl and LpSensor.
RequestSensor Configuration
GET request (HOST -> SENSOR)
Packet byte no. | Content | Meaning |
0 | 3Ah | Packet start |
1 | 01h | OpenMAT ID LSB (ID = 1) |
2 | 00h | OpenMAT ID MSB |
3 | 04h | Command no. LSB (4d = GET_CONFIG) |
4 | 00h | Command no. MSB |
5 | 00h | Data length LSB (GET command = no data) |
6 | 00h | Data length MSB |
7 | 05h | Check sum LSB |
8 | 00h | Check sum MSB |
9 | 0Dh | Packet end 1 |
10 | 0Ah | Packet end 2 |
Reply data (SENSOR -> HOST)
Packet byte no. | Content | Meaning |
0 | 3Ah | Packet start |
1 | 01h | OpenMAT LSB (ID = 1) |
2 | 00h | OpenMAT MSB |
3 | 04h | Command no. LSB (4d = GET_CONFIG) |
4 | 00h | Command no. MSB |
5 | 04h | Data length LSB (32-bit integer = 4 bytes) |
6 | 00h | Data length MSB |
7 | xxh | Configuration data byte 1 (LSB) |
8 | xxh | Configuration data byte 2 |
9 | xxh | Configuration data byte 3 |
10 | xxh | Configuration data byte 4 (MSB) |
11 | xxh | Check sum LSB |
12 | xxh | Check sum MSB |
13 | 0Dh | Packet end 1 |
14 | 0Ah | Packet end 2 |
xx = Value depends on the current sensor configuration.
Request Gyroscope Range
GET request (HOST -> SENSOR)
Packet byte no. | Content | Meaning |
0 | 3Ah | Packet start |
1 | 01h | OpenMAT ID LSB (ID = 1) |
2 | 00h | OpenMAT ID MSB |
3 | 1Ah | Command no. LSB (26d = GET_GYR_RANGE) |
4 | 00h | Command no. MSB |
5 | 00h | Data length LSB (GET command = no data) |
6 | 00h | Data length MSB |
7 | 1Bh | Check sum LSB |
8 | 00h | Check sum MSB |
9 | 0Dh | Packet end 1 |
10 | 0Ah | Packet end 2 |
Reply data (SENSOR -> HOST)
Packet byte no. | Content | Meaning |
0 | 3Ah | Packet start |
1 | 01h | OpenMAT ID LSB (ID = 1) |
2 | 00h | OpenMAT ID MSB |
3 | 1Ah | Command no. LSB (26d = GET_GYR_RANGE) |
4 | 00h | Command no. MSB |
5 | 04h | Data length LSB (32-bit integer = 4 bytes) |
6 | 00h | Data length MSB |
7 | xxh | Range data byte 1 (LSB) |
8 | xxh | Range data byte 2 |
9 | xxh | Range data byte 3 |
10 | xxh | Range data byte 4 (MSB) |
11 | xxh | Check sum LSB |
12 | xxh | Check sum MSB |
13 | 0Dh | Packet end 1 |
14 | 0Ah | Packet end 2 |
xx = Value depends on the current sensor configuration.
Set Accelerometer Range
SET request (HOST -> SENSOR)
Packet byte no. | Content | Meaning |
0 | 3Ah | Packet start |
1 | 01h | OpenMAT ID LSB (ID = 1) |
2 | 00h | OpenMAT ID MSB |
3 | 1Fh | Command no. LSB (31d = SET_ACC_RANGE) |
4 | 00h | Command no. MSB |
5 | 04h | Data length LSB (32-bit integer = 4 bytes) |
6 | 00h | Data length MSB |
7 | 08h | Range data byte 1 (Range indicator 8g = 8d) |
8 | 00h | Range data byte 2 |
9 | 00h | Range data byte 3 |
10 | 00h | Range data byte 4 |
11 | 2Bh | Check sum LSB |
12 | 00h | Check sum MSB |
13 | 0Dh | Packet end 1 |
14 | 0Ah | Packet end 2 |
Reply data (SENSOR -> HOST)
Packet byte no. | Content | Meaning |
0 | 3Ah | Packet start |
1 | 01h | OpenMAT ID LSB (ID = 1) |
2 | 00h | OpenMAT ID MSB |
3 | 00h | Command no. LSB (0d = REPLY_ACK) |
4 | 00h | Command no. MSB |
5 | 00h | Data length LSB (ACK reply = no data) |
6 | 00h | Data length MSB |
11 | 01h | Check sum LSB |
12 | 00h | Check sum MSB |
13 | 0Dh | Packet end 1 |
14 | 0Ah | Packet end 2 |
Read Sensor Data
Get request (HOST -> SENSOR)
Packet byte no. | Content | Meaning |
0 | 3Ah | Packet start |
1 | 01h | OpenMAT ID LSB (ID = 1) |
2 | 00h | OpenMAT MSB |
3 | 09h | Command no. LSB (9d = GET_SENSOR_DATA) |
4 | 00h | Command no. MSB |
5 | 00h | Data length LSB (GET command = no data) |
6 | 00h | Data length MSB |
7 | 0Ah | Check sum LSB |
8 | 00h | Check sum MSB |
9 | 0Dh | Packet end 1 |
10 | 0Ah | Packet end 2 |
Reply data (SENSOR -> HOST)
Packet byte no. | Content | Meaning |
0 | 3Ah | Packet start |
1 | 01h | OpenMAT ID LSB (ID = 1) |
2 | 00h | OpenMAT ID MSB |
3 | 09h | Command no. LSB (9d = GET_SENSOR_DATA) |
4 | 00h | Command no. MSB |
5 | 34h | Data length LSB (56 bytes) |
6 | 00h | Data length MSB |
7-10 | xxxxxxxxh | Timestamp |
11-14 | xxxxxxxxh | Gyroscope data x-axis |
15-18 | xxxxxxxxh | Gyroscope data y-axis |
19-22 | xxxxxxxxh | Gyroscope data z-axis |
23-26 | xxxxxxxxh | Accelerometer x-axis |
27-30 | xxxxxxxxh | Accelerometer y-axis |
31-34 | xxxxxxxxh | Accelerometer z-axis |
35-38 | xxxxxxxxh | Magnetometer x-axis |
39-42 | xxxxxxxxh | Magnetometer y-axis |
43-46 | xxxxxxxxh | Magnetometer z-axis |
47-50 | xxxxxxxxh | Orientation quaternion q0 |
51-54 | xxxxxxxxh | Orientation quaternion q1 |
55-58 | xxxxxxxxh | Orientation quaternion q2 |
59-62 | xxxxxxxxh | Orientation quaternion q3 |
63 | xxh | Check sum LSB |
64 | xxh | Check sum MSB |
65 | 0Dh | Message end byte 1 |
66 | 0Ah | Message end byte 2 |
xx = Value depends on the current configuration and measurement value.
ASCII Format Output
In ASCII output mode sensor data is transmitted as plain ASCII numerical text. The output format for each number is generally 16-bit integer, but with a multiplication factor applied to increase precision. The following multiplication factors are used:
Chunk # | Data type | Sensor data | Factor |
1 | uint32 | Timestamp (s) | 10000 |
2 | Vector3i16 | Raw (bias calibrated) gyroscope data (dps) | 1000 |
3 | Vector3i16 | Raw (uncalibrated) accelerometer data (g) | 1000 |
4 | Vector3i16 | Raw (uncalibrated) magnetometer data (uT) | 1000 |
5 | Vector3i16 | Angular velocity (dps) | 1000 |
6 | Vector4i16 | Orientation quaternion (normalized) | 100000 |
7 | Vector3i16 | Euler angle data (deg) | 1000 |
8 | Vector3i16 | Linear acceleration data (g) | 1000 |
9 | Int16 | Barometric pressure (kPa) | 1000 |
10 | Int16 | Altitude (m) | 10 |
11 | Int16 | Temperature (°C) | 100 |
12 | Int16 | Heave motion (m) (optional) | 1000 |
LP-CAN Protocol
To exchange data with LPMS through the CAN Bus interface, the serial LP-BUS protocol is split into CAN bus messages. We call this CAN bus wrapper for the LP-BUS protocol: LP-CAN.
A regular LP-CAN message is structured as shown below:
11-bit CAN identifier | The CAN identifier of a CAN message. This identifier is set to the value 514h+OpenMAT ID of target sensor for all LP-CAN transmissions. |
8 data bytes | Contains the actual data to be transmitted in a CAN message. |
An example packet with 4 data bytes wrapping from LP-BUS to LP-CAN results in the following CAN messages:
CAN Message #1:
Byte # | Name | Description |
0 | Packet start (3Ah) | Mark of the beginning of a data packet. |
1 | OpenMATID - byte 1 | Contains the low byte of the OpenMAT ID of the sensor to be communicated with. The default value of this ID is 1. The host sends out a GET / SET request to a specific sensor by using this ID, and the client answers to request alsowith the same ID. This ID can be adjusted by sending a SET command to the sensor firmware. |
2 | OpenMAT ID - byte 2 | High byte of the OpenMAT ID of the sensor |
3 | Command no. - byte 1 | Contains the low byte of the command to be performed by the data transmission |
4 | Command no. - byte 2 | High byte of the command number |
5 | Packet data length - byte 1 | Contains the low byte of the packet data length to be transmitted in the packet data field (in this example 4) |
6 | Packet data length - byte 2 | High byte of the data length to be transmitted (in this example 0) |
7 | Packet data | Packet data byte 0 |
CAN Message #2:
Byte # | Name | Description |
0 | Packet data | Packet data byte 1 |
1 | Packet data | Packet data byte 2 |
2 | Packet data | Packet data byte 3 |
3 | LRC byte 1 | The low byte of LRC check-sum. |
4 | LRC byte 2 | High byte of LRC check-sum. |
5 | Termination byte 1 | 0Dh |
6 | Termination byte 2 | 0Ah |
7 | Not used | 0 |
The number of messages needed to contain the data depends on the length of the data to be transmitted. Each CAN message is 8 bytes long. Unused bytes of a message are filled with 0.
CANopen and Sequential CAN Protocol
In CANopen and sequential CAN transmission mode, two or more output words of measurement data can be assigned to a CAN channel. In sequential CAN mode the channel addressing can be individually controlled. In CANopen mode, 4 TPDO (Transmission Data Process Object) messages and a heartbeat message are transmitted. Sensor data is assigned to specific messages either using the LpmsControl application or direct LP-BUS communication.
Data is continuously sent from the sensor to the host with the streaming frequency selected in the LpmsControl application at the selected baudrate. The data to be transmitted can be selected to adjust the bus bandwidth used by the LPMS system.
NOTE: In CANopen mode a heartbeat message is transmitted with a frequency between 0.1 Hz and 2 Hz.
The format of CANopen and Sequential CAN bus messages is controlled by the following parameters:
Channel mode
Value mode
Start ID:
IMU ID
In CANopen mode, the message base address is calculated in the following way:
Base CAN ID = Start ID+ IMU ID
In sequential CAN mode, the message base address is calculated in the following way:
Base CAN ID = Start ID + (IMU ID - 1) * 8
Therefore, using these parameters the following message formats can be adjusted:
Parameter settings | Resulting channel message setup |
Channel mode = Sequential Value mode = 16-bit fixed point (signed) StartID = 514h IMU ID = 1 | CAN message #1: CAN ID = 514h
1st 16 bits: Channel 1 data
2nd 16 bits: Channel 2 data
3rd 16 bits: Channel 3 data
4th 16 bits: Channel 4 dataCAN message #2: CAN ID = 515h
1st 16 bits: Channel 5 data
2nd 16 bits: Channel 6 data
3rd 16 bits: Channel 7 data
4th 16 bits: Channel 8 dataCAN message #3: CAN ID = 516h
1st 16 bits: Channel 9 data
2nd 16 bits: Channel 10 data
3rd 16 bits: Channel 11 data
4th 16 bits: Channel 12 dataCAN message #4: CAN ID = 517h
1st 16 bits: Channel 13 data
2nd 16 bits: Channel 14 data
3rd 16 bits: Channel 15 data
4th 16 bits: Channel 16 data |
Channel mode = Sequential Value mode = 32-bit floating point Start ID = 514h IMU ID = 1
| CAN message #1: CAN ID = 514h
1st 32 bits: Channel 1 data
2nd 32 bits: Channel 2 dataCAN message #2: CAN ID = 515h
1st 32 bits: Channel 3 data
2nd 32 bits: Channel 4 dataCAN message #3: CAN ID = 516h
1st 32 bits: Channel 5 data
2nd 32 bits: Channel 6 dataCAN message #4: CAN ID = 517h
1st 32 bits: Channel 7 data
2nd 32 bits: Channel 8 data |
Channel mode = CANopen Value mode = 16-bit fixed point (signed) Start ID = 180h IMU ID = 1
| CAN message #1: CAN ID = 181h
1st 16 bits: Channel 1 data
2nd 16 bits: Channel 2 data
3rd 16 bits: Channel 3 data
4th 16 bits: Channel 4 dataCAN message #2: CAN ID = 281h
1st 16 bits: Channel 5 data
2nd 16 bits: Channel 6 data
3rd 16 bits: Channel 7 data
4th 16 bits: Channel 8 dataCAN message #3 CAN ID = 381h
1st 16 bits: Channel 9 data
2nd 16 bits: Channel 10 data
3rd 16 bits: Channel 11 data
4th 16 bits: Channel 12 dataCAN message #4: CAN ID = 481h
1st 16 bits: Channel 13 data
2nd 16 bits: Channel 14 data
3rd 16 bits: Channel 15 data
4th 16 bits: Channel 16 data |
Channel mode = CANopen Value mode = 32-bit floating point Start ID = 180h IMU ID = 1
| CAN message #1: CAN ID = 181h
1st 32 bits: Channel 1 data
2nd 32 bits: Channel 2 dataCAN message #2: CAN ID = 281h
1st 32 bits: Channel 3 data
2nd 32 bits: Channel 4 dataCAN message #3: CAN ID = 381h
1st 32 bits: Channel 5 data
2nd 32 bits: Channel 6 dataCAN message #4: CAN ID = 481h
1st 32 bits: Channel 7 data
2nd 32 bits: Channel 8 data |
Transmitted units in 32-bit float mode:
Data type | Unit |
Raw (uncalibrated) angular speed (gyroscope) | radians / s |
Raw (uncalibrated) acceleration (accelerometer) | g |
Raw (uncalibrated) magnetic field strength (magnetometer) | uT |
Euler angle | radians |
Linear acceleration | g |
Quaternion | normalized units |
In 16-bit integer modes values are multiplied with a constant factor after transmission to increase precision:
Data type | Unit | Factor |
Raw (uncalibrated) angular speed (gyroscope) | radians / s | 1000 |
Raw (uncalibrated) acceleration (accelerometer) | g | 1000 |
Raw (uncalibrated) magnetic field strength (magnetometer) | uT | 100 |
Angular Velocity | radians / s | 1000 |
Quaternion | normalized units | 10000 |
Euler angle | radians | 10000 |
Linear acceleration | g | 1000 |
Barometric pressure | kPa | 100 |
Altitude | m | 10 |
Temperature | °C | 100 |
Heave motion (optional) | m | 1000 |