This article describes how Telematics Service Providers (TSPs) should parse and interpret data frames transmitted by TraX devices.
The TraX Technical Specification (Connected Version) document is the authoritative reference for the data format, while this article provides practical guidance, examples, and implementation considerations to support correct integration.
Importance of identifying firmware version
Correct identification of the firmware version is a mandatory first step when processing device data. Because the structure of the data frame evolves with each major firmware release, TSPs must determine the firmware version before parsing any data to ensure accurate interpretation and compatibility.
Required: The TSP´s device integration implementation must support all valid advertising frame versions.
The firmware version is encoded directly within the data frame and is located in the second-to-last byte (byte position 30). This attribute has been included in all major firmware versions since BSS08.
Required: To ensure accurate data interpretation, the TSP must identify the frame version before parsing the data.
Firmware versioning schema
Firmware releases follow the naming convention:
BSS + <major version number> + <optional minor version character>.
The initial release of a major version does not include a minor suffix. For example, BSS08 corresponds to firmware version 80. Subsequent minor releases are identified by an alphabetical suffix. For example, BSS08a corresponds to firmware version 81.
Firmware version–release mapping table
| BSS08 releases | BSS10 releases | BSS11 releases |
|---|---|---|
| 80 - BSS08 | 100 - BSS10 | 110 - BSS11 |
| 81 - BSS08a | 101 - BSS10a | |
| 82 - BSS08b | ||
| 83 - BSS08c | ||
| 84 - BSS08d |
Code example: Identifying the firmware version
To ensure forward compatibility, it is recommended to assume compatibility between the latest supported firmware release and future firmware versions unless stated otherwise.
The firmware version is encoded in the data frame and can be extracted from byte position 30 (0-based index). The example below demonstrates how to extract and interpret the firmware version using Python.
frame = "0201060A0957454D46464646354410FF0E0401114A2D4A2300000000006E00"
# Convert hex string to bytes
byte_array = bytes.fromhex(frame)
# Extract firmware version from byte position 30 (0-based index)
firmware_version = byte_array[30] # Value is already in decimal
if 80 <= firmware_version <= 89:
# Parse frame as BSS08
pass
elif 100 <= firmware_version <= 109:
# Parse frame as BSS10
pass
elif firmware_version >= 110:
# Parse frame as BSS11 or later
passBLE advertisement frame
The data frame contains information relevant for the TSP, including for example the device's MAC address or wheel-end health. The data frame also includes sections labeled as debug data which must be treated as an opaque string within TSP platform—meaning they should be stored but not parsed. The debug data section is essential for SKF and are expected to be included when sharing data with SKF, as they provide valuable insights into product performance.
Although the TSP may parse and segment the data as needed, we recommend retaining the entire BLE advertisement frame exactly as sent by the device. However, at a minimum, the TSP can provide the sections referred to as MAC address and Statuses incl debug data from the data frame example below, padding all other data with zeros ("0").
MAC address Statuses incl debug data
____|_____ ___________|____________
/ \ / \
0201060A0957454D46464646354410FF0E0401114A2D4A2300000000006E00We provide data frame parsing examples (see document attached to this article) to help verify correctly interprets the data format.
Development devices
In addition to the stable firmware, SKF offers a firmware specifically designed for the development integration phase, referred to as "development devices".
Important: the TraX mobile apps may prompt you to upgrade the firmware of development devices. Do not perform firmware upgrades on these devices, as they are intended solely for development purposes and must not be used in production environments..
Development devices broadcast BLE advertising frames every 10 seconds, cycling to one of six supported data frames every five minutes.
These frames represent a subset of device statuses but do not encompass the full range of data variations required for complete device integration.
The data frames generated by a development device include:
Frame1: Battery low level + Bearing failure 0x12
Frame2: Battery extreme low level 0x01
Frame3: Vibration sensor failure (WEM FAILURE) 0xA1
Frame4: Internal WEM Failure (Piezofailure) 0x61
Frame5: Temperature Sensor Failure 0x25
Frame6: Bearing Failure + Temperature Sensor failure 0x26Contact your sales represent for more information about TraX development devices.
Introduction to Bitmasking
Bitmasking is a method used to manipulate individual bits of a binary number by applying bitwise operations with a mask. A mask is a binary number designed to target and select specific bits from another binary number.
Example that extracts four different statuses from the same byte
In all the examples, we´ll use the failure status bit 0x21. It´s position in the raw BLE Advertising Frame is marked with pink color.
0x0201060A0957454D46464646354410FF0E0421114948490000000000005400
Byte Failure Status table
| Mask | Masked Byte Value | Extracted Bit Values | Description | Comment |
|---|---|---|---|---|
0x300011 0000
|
0x00 0x10 0x20 0x30 |
0 1 2 3 |
Battery extreme low Battery Low level Battery OK No data |
Battery level |
0x030000 0011
|
0x00 0x01 0x02 |
0 1 2 |
No Data No failure Failure |
Wheel End Failure |
0xC01100 0000
|
0x00 0x40 0x80 0xC0 |
0 1 2 3 |
No failure Piezo Failure WEM Failure Reversed position |
WEM failure = accel or RAM failure |
In TraX, we have the following bitmasks: 0x30, 0x03, 0xC0, and 0x0C. These hexadecimal values represent specific bit patterns.
Masking for Different Failures
Battery Level Mask 0x30
To apply the bitmask, we perform a bitwise AND operation between the byte and the mask:
0x21 (00100001)
& 0x30 (00110000)
= 0x20 (00100000)Result: Applying the 0x30 bitmask to 0x21 is 0x20, indicating "Battery OK".
Wheel End Failure Mask 0x03
0x21 (00100001)
& 0x03 (00000011)
= 0x01 (00000001)
Result: Applying the 0x03 bitmask to 0x21 gives 0x01, indicating No Wheel End Failure.WEM Failure Mask 0xC0
0x21 (00100001)
& 0xC0 (11000000)
= 0x00 (00000000)Result: Applying the 0xC0 bitmask to 0x21 gives 0x00, indicating No WEM Failure.
Temperature Sensor Failure Mask 0x0C
0x21 (00100001)
& 0x04 (00001100)
= 0x00 (00000000)Result: Applying the 0x0C bitmask to 0x21 gives 0x00, indicating No Temperature Failure.
Javascript Code Sample
See the file "bit-masking-example.js" attached to this article.