BCE “FM IOTM” device protocol documentation

1. Introduction
The BCE "FM IOTM" protocol is based on well-known MQTT protocol.It is a publish/subscribe, extremely
simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-
latency or unreliable networks. The design principles are to minimise network bandwidth and device
resource requirements whilst also attempting to ensure reliability and some degree of assurance of delivery.
These principles also turn out to make the protocol ideal of the emerging “machine-to-machine” (M2M) or
“Internet of Things” world of connected devices, and for mobile applications where bandwidth and battery
power are at a premium.
MQTT was invented by Dr Andy Stanford-Clark of IBM, and Arlen Nipper of Arcom (now Eurotech), in
1999. As of 2016, MQTT is now an ISO standard (ISO/IEC 20922)
You can pass a username and password with an MQTT packet. Encryption across the network can be handled
with SSL, independently of the MQTT protocol itself.
Protocol easy to adopt for the wide variety of IoT devices, platforms, and operating systems. Many
applications of MQTT can be developed just by implementing the CONNECT, PUBLISH, SUBSCRIBE,
and DISCONNECT control packets. A variety of MQTT client libraries are made available through the
Eclipse Paho project. Eclipse Paho MQTT client libraries could be downloaded from the Eclipse Paho
website.
Quality of service (QoS) levels determine how each MQTT message is delivered and must be specified for
every message sent through MQTT. Three QoS for message delivery could be achieved using MQTT:
● QoS 0 (At most once) - where messages are delivered according to the best efforts of the
operating environment. Message loss can occur.
● QoS 1 (At least once) - where messages are assured to arrive but duplicates can occur.
● QoS 2 (Exactly once) - where message are assured to arrive exactly once.

2. MQTT Client
MQTT client includes publisher or subscribers, both of them label an MQTT client that is only doing
publishing or subscribing. A MQTT client is any device or server. MQTT client libraries are available for a
huge variety of programming languages, for example Android, Arduino, C, C++, C#, Go, iOS, Java,
JavaScript, .NET.

3. MQTT Broker

The broker is responsible for receiving all messages and sending them to all subscribed clients. It also holds
the session of all persisted clients including subscriptions and missed messages. Another responsibility of
the broker is the authentication and authorization of clients.

BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
 4. Integration using MQTT broker
Using broker to distribute traffic is easy and reliable way to create multi server structure. In order to integrate
MQTT support at server side one of multiple existing libraries for most programming languages could be
used. MQTT library could simplify connection to broker to couple lines of code while only parser of payload
would be left to implement. Payload’s structure is described in section 7. Each device or group of devices
can be configured to have different topic names. Having a group of devices with different topic names makes
it easy to distribute messages between servers. Figure 1 shows example of multi server application where
servers are limited to get only certain messages.

BCE FM SERV
MQTT
BCE FM BROKE
SERV
R
BCE FM SERV

5. Integration without MQTT broker

If your system can not work with MQTT broker, direct connection to server is possible as well. In this
case your application needs to handle low level communication (you can find an example in section 6.1).
System with direct connection is shown in Figure 2. In this case all the traffic is handled by the server
itself, modules connect directly to TCP listener. It is recommended to implement server using ISO/IEC
20922 standard. Another option is to use a part of open source broker’s code (e.g. Mosquitto).

BCE FM
SERV
BCE FM ER A

BCE FM

6. Handling MQTT communication in low level example

It is important to note that every field of the following chapter (6) except payload (detailed payload
explanation is provided in chapter 7) from data transmission section (6.2) can be handled using MQTT
libraries (e.g. Paho). Flow of communication between BCE IOTM device and server (broker) is illustrated
in figure 3.

BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
 Connection SERV
BCE Connection ER
IOTM
Publish/data (BROK
device
ER)
Publish confirm

6.1 Connection

After TCP socket between server and BCE tracking module is created device initiates communication with
connection packet which is provided below:

10 3A 00 04 4D 51 54 54 04 C2 00 F0 00 0F 38 36 35 32 30 39 30 33 39 34 35 31 32 39 30 00 07 64 65 76
69 63 65 73 00 14 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44

Packet is described in following table.

Parameter name No. of bytes Example value Comment
Packet type identifier 1 10 Connection packet always
starts with 10
Remaining length 1 3A Length of remaining packet
starting with the following
byte (00 in this example)
Protocol name length 2 00 04 -
Protocol name 4* 4D 51 54 54 -
Protocol version 1 04 This document only
describes protocol version
that is defined by 04, if
server receives packet with
different protocol version
connection should be
closed.
Connect flags 1 C2 Bit0 - Reserved
Bit1 - Clean Session
Bit2 - Will Flag**
Bit3 - Will QoS0**
Bit4 - Will QoS1**
Bit5 - Will Retain**
Bit6 - Password field is
present if bit value is set
Bit7 - Username field is
present if bit value is set
Keep alive interval 2 00 F0 Highest expected time
interval between two
packets transmitted (240
seconds in this case)
Client ID field length 2 00 0F -
Client ID 15* 38 36 35 32 30 Value used by the server to
39 30 33 39 34 recognize incoming
35 31 32 39 30 connection. In this case
BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
 client is identified by IMEI
which is provided in ASCII
format
Username field length 2 00 0A Field is only present if Bit7
from connect flags is set.
Username 10* 64 65 76 69 63 Field is only present if Bit7
65 73 from connect flags is set.
Username is binary array
which can be used for
authorisation purposes.
Password field length 2 00 14 Field is only present if Bit6
from connect flags is set.
Password 20* 31 32 33 34 35 Field is only present if Bit6
36 37 38 39 3A from connect flags is set.
3B 3C 3D 3E 3F User name value which is
40 41 42 43 44 always a string and can be
used for authorisation
purposes.
Table 1. Connection packet explanation
*value can vary according to other parameters that are specified previously
**function is currently not supported by BCE devices so bit value can be expected to be reset

For full connection flags field explanation please refer to MQTT protocol description section 3.1.2. (you
can find MQTT protocol description here). If username and password are required on server side and fields
are not present or do not match connection should be closed. If server accepts the connection it should
respond to the BCE tracking module with packet that is described in the following example. Example
packet in hexadecimal:

20 02 00 00

Packet is described in the following table

Parameter name No. of bytes Example Comment
value
Packet type identifier 1 20 Connection ACK always starts
with 20
Remaining length 1 02 Length of the remaining packet
starting with 00 in this case
Reserved 2 00 00 -
Table 2. Connection confirm packet

6.2 Data transmission

Device can send data using two different services of quality (QoS0 and QoS1). Both of them are using
TCP/IP protocol. QoS0 is used for data when no confirmation from server is needed. QoS1 ensures that
none of device’s records get lost, so each QoS1 packet has to be confirmed by the server. Example of
QoS1 packet is provided below:

33 20 00 05 42 43 45 2F 44 00 1B 01 02 91 88 75 2D E7 12 03 00 01 09 00 71 BB 19 09 05 00 30 96 35
12

BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
Structure of packet is described in the following table:
Parameter name No. of bytes Example value Comment
Packet type 1 33 Packet identifier byte can
identifier be split into following
values:
Bit7-Packet type
Bit6-Packet type
Bit5-Packet type
Bit4-Packet type
Bit3-DUP flag
Bit2-QoS level
Bit1-QoS level
Bit0-Retained
Example packet belongs
to QoS1 and has to be
confirmed by the server.
Data transmission packet
type is always 3.
DUP and Retained values
may be ignored.
Bit1 - 0, Bit2 - 0: QoS0
Bit1 - 1, Bit2 - 0: QoS1
Bit1 - 0, Bit2 - 1: QoS2
Bit1 - 1, Bit2 - 1: reserved
Remaining length 1 if value is less than 20 Length of the remaining
128, 2 bytes otherwise packet starting with next
byte (00 in this case).
Note that remaining
length can encode higher
than 127 value using the
following method. For
example if packet is 279
bytes long (excluding
remaining length itself
and packet identifier) least
significant byte comes
first and its most
significant bit encodes
that packet is longer than
127 bytes. 279 is encoded
as 97 02 where least
significant byte 97 can be
masked to know that
value is higher than 127
bytes. 279 can be
calculated using the
following equation -
0x97&0x7F+2*0x80 in
hexadecimal or 23+2*128
in decimal.
Topic name length 2 00 05 Topic name is 5 bytes
long (0x05 in hex)
Topic name 5* 42 43 45 2F 44 BCE/D stands for data
type that is being sent (D
BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
 in this case stands for
regular data packet).
Topics are used for
filtering or distribution of
incoming data. Note that
topics can be longer (e.g.
BCE/D/FB01).Modules
can send more than one
data type, for structure
version 1 payload,
however only BCE/D,
BCE/E and BCE/R should
be taken into
consideration. For
structure version 2
payload topic names may
not be taken into
consideration.
Packet identifier* 2 00 1B Value used for packet
confirmation thats
explained later on. Each
QoS1 packet should be
confirmed with ACK
packet that has the same
packet identifier value.
Further explanation of
packet confirmation is
provided in next chapter.
Field is not present with
QoS0 messages.
Payload Length = Remaining 01 02 91 88 75 2D Payload structures for
length - 5 - Topic name E7 12 03 00 01 09 events and regular data
length 00 20 00 AD 59 are explained in section 7.
05 00 30 96 35 12 Example uses payload
structure version 1
Table 3. Data publish packet
*value can vary according to other parameters that are specified previously

6.3 Packet confirmation

Packets that belong to QoS1 should be confirmed (QoS0 packets do not need confirmation). Confirmation
to example packet is explained below.

40 02 00 1B

Parameter name No. of bytes Example value Comment

Packet type 1 40 Publish ACK always starts with 40
Remaining length 1 02 Length of the remaining packet
starting with 00 in this case
Published packet ID 2 00 1B This is the value that server
received with data packet (Packet
identifier).
Table 4. Publish confirmation packet

BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
 6.4 Connectivity keep-alive

During periods when there are no records or real time data to be sent over present connection BCE IOTM
devices send keep-alive messages (PINGREQ according to MQTT protocol specification) to keep TCP
connection alive. PINGREQ packets have to be responded with PINGRESP in order to keep connection
alive. Maximum period between two data transfers is told by BCE IOTM device during connection phase
(6.1 section Keep alive interval). Keep alive interval can be changed in device’s configuration. Example of
PINGREQ and PINGRESP packets in low level is given below:

Parameter name No. of bytes Example value Comment

Packet type 2 C0 00 PINGREQ packet identifier
Table 5. Ping request packet example

Parameter name No. of bytes Example value Comment

Packet type 2 D0 00 PINGRESP packet identifier
Table 6. Ping response packet example

Please have in mind that this part of protocol completely compatible with MQTT and only needs to be
considered if direct connection is used.

6.5 Subscribe to output control

If the device is configured to be able to control outputs on commands, the first thing it does after connecting
to server is send a subscription packet, that has to be confirmed by the server. Example of subscription
packet is given below and explained in table 7.

82 19 00 01 00 15 38 36 35 32 30 39 30 33 39 35 35 34 37 30 35 2F 4F 55 54 43 01

Hex example value Data name Comment

82 Packet type -

19 Remaining length Length of the remaining packet

starting with 00 byte (25 bytes)

00 01 Packet identifier -

00 15 Subscribed topic name length -

38 36 35 32 30 39 30 Subscribed topic name Topic is named according to

33 39 35 35 34 37 30 device’s unique ID
35 2F 4F 55 54 43 01 (865209039554705/OUTC in this
case)

01 Requested QoS Subscriptions will be done for first

QoS
Table 7. Explanation of subscription packet

Subscription packets have to be confirmed with the acknowledge packet. Acknowledge packet’s example is
explained below.

BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
90 03 00 01 01

Hex example value Name Comment

90 Packet type Subscribe ACK always starts with

90

03 Remaining length -

00 01 Packet identifier Packet’s that is being

acknowledged identifier

01 Return code Value of successfully subscribed

QoS.

Table 8. Explanation of subscription acknowledge

If server wants to control outputs it has to send publish packets that are described in Data transmission
section, but topic name has to match output control topic that is configured in device (default is IMEI/OUTC
where IMEI is device’s unique number). Payload field of output control message is explained in 7.1.3
Output control section.

BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
7. Payload
7.1 Structure version 2

Structure version 2 allows transmission of messages that can contain different types of data (events,
telemetry, files) in same topic or even packet. Structure version 2 is explained below:

Structure Record (n) Record (n+1) Record (n+2) Record (n+3) Checksum
version=2
Table 9. Structure version 2 payload

Single record may consist of one of the following:

● Telemetry data (real time or from flash records) (1)

● IMEI (2)
● Events data (3)
● Output command (4)
● File (5)

Each record starts with a record type and two bytes that describe remaining length of record.
Devices that use BCE IOTM protocol can publish files, telemetry data or events that can be used for
debugging purposes. BCE IOTM devices can also subscribe to output control. Each of those cases may
share the same topic, or topic names can be configured to be different. Files by default are sent over BCE/F
topic, telemetry data by default is sent over BCE/D, events by default are sent over BCE/E topic, real time
telemetry data is sent over BCE/R topic. To receive output commands module with default configuration
subscribes to IMEI/OUTC where IMEI is device’s unique id.

7.1.1 Telemetry data (regular data) and IMEI

Telemetry data and IMEI records are structured using the same rules as provided in structure version 1
(refer to section 7.1.1).

Example records are explained below:

Element name No. of bytes Comment Example value

Record type 1 Type of record (01 in this 01
case)
Record length 2 Remaining length of record 09 00
Record timestamp 4 Unix timestamp (UTC) 20 00 AD 59
(little endian)
Sensors array Record length - 4 Sensor encoding is 05 00 30 96 35
described in the following
table(each member is
provided in little endian
format)
Table 10. Explanation of telemetry data record structure

Element name No. of bytes Comment Example value

Record type 1 Type of record (02 in this 02
case)
Record length 2 Remaining length of record 08 00
BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
 IMEI 8 Unsigned int of 8 bytes that 91 88 75 2D E7 12
corresponds to device’s IMEI 03 00
Table 11. Explanation of IMEI record structure

Example payload that contains telemetry data and IMEI is given below
02 02 08 00 91 88 75 2D E7 12 03 00 01 09 00 20 00 AD 59 05 00 30 96 35 F3

Example value Description

02 Structure version
02 Record type (IMEI in this case)
08 00 Remaining length of IMEI record
91 88 75 2D E7 12 03 00 IMEI value (865209039554705)
01 Record type (Telemetry data)
09 00 Remaining length (this record is made of 9 more bytes)
20 00 AD 59 Unix timestamp (09/04/2017 @ 7:26AM (UTC)
05 Sensor type (Sensor is unsigned 16 bit value)
00 30 Sensor identifier (12288 which stands for VCC in sensor name list)
96 35 Sensor value (13718 mV in this case)
F3 Checksum (sum of all bytes starting with structure version)
Table 12. Structure version 2 payload example

Each payload ends with a checksum of it’s own (In example case checksum is started counting from first
payload byte 02). Sensors array consists of multiple sensors. Each sensor is described with a type, sensor
ID and value fields.

Element name Length of bytes Comment

Value type 1 Specifies type of sensors value (bool, int,
floats, etc.). List of values is provided below.
Sensor identifier 2 ID that specifies sensor
Length * Field is only present when string type values
are provided and specifies their length.

Value ** Possible values are described together with

types
Table 13. Sensor field structure
*- field is only present with array and string type values.
**- length can vary according value type.

Type name Value Comment

Type_false 0 Used for binary sensor values. Note that value
field is not present with this field since type
already specifies value.
Type_true 1 Used for binary sensor values. Note that value
field is not present with this field since type
already specifies value.
Type_null 2 Used to define sensors whose values are not
present. Note that value field is not present with
this field since type already specifies value.

BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
Type_zero 3 Used to define sensors whose values are zero.
Note that value field is not present with this
field since type already specifies value.
Type_U8 4 Used to define sensors whose values are 255
and below. Value field is present with this
sensor and is 8 bits long.
Type_U16 5 Used to define sensors whose values are
between 65535 and 256. Value field is present
with this sensor and is 16 bits long.
Type_U32 6 Used to define sensors whose values are
between 4294967295 and 65535. Value field is
present with this sensor and is 32 bits long.
Type_U64 7 Used to define sensors whose values are above
4294967295. Value field is present with this
sensor and is 64 bits long.
Type_S8 8 Used to define sensors values that are signed
and are 8 bits long. Value field is present with
this sensor type.
Type_S16 9 Used to define sensors values that are signed
and 16 bits long. Value field is present with this
sensor type.
Type_S32 10 Used to define sensors values that are signed
and are 32 bits long. Value field is present with
this sensor type.
Type_S64 11 Used to define sensors values that are signed
and are 64 bits long. Value field is present with
this sensor type.
Type_Float 12 Used to define sensors values that expressed
with a floating point number. Value field is
present with this sensor type and is 32 bits long.
Type_Double 13 Used to define sensors values that are expressed
with a double precision number. Value field is
present with this field and is 64 bits long.
Type_GPS 14 Used to define value that comes as GPS data
structure.
GPS structure (16 bytes long) consists of the
following fields:
Latitude (32 bits float)
Longitude (32 bits float)
Speed (16 bits unsigned int)
HDOP (8 bits unsigned int)
Satellites (8 bits unsigned int)
Course (16 bits unsigned int)
Altitude (16 bits signed int)
Type_StringL1 32 Used to define sensors that are represented as
string and are less than 256 bytes long. After
sensor ID field 1 byte length field is present.
After length comes string (length is presented
previously).``
Type_BinaryL1 33 Used to define sensors that are represented as
binary array and are less than 256 bytes long.
After sensor ID field 1 byte length field is
present. After length comes binary array (length
is presented previously).
BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
Type_StringL2 64 Used to define sensors that are represented as
string and are less than 65536 bytes long. After
sensor ID field 2 bytes length field is present.
After length comes string (length is presented
previously).
Type_BinaryL2 65 Used to define sensors that are represented as
binary array and are less than 65536 bytes long.
After sensor ID field 2 byte length field is
present. After length comes binary array (length
is presented previously).
Table 14. Sensor value types

Another payload example with a detailed description of data values is provided below (note that payload is
formed in little endian format).

02 02 08 00 91 88 75 2D E7 12 03 00 01 3A 00 20 00 AD 59 05 00 30 B1 35 03 03 40 03 0C 30 03 01 A0
03 02 A0 0E 00 D0 B9 AB 5B 42 03 34 C0 41 00 00 1F 06 00 00 32 00 04 07 20 64 00 8C 00 01 62 00 20
00 C0 04 47 6F 6F 44 01 09 00 21 00 AD 59 05 00 30 BA 35 9B 66 00 00 6D 00 00 67 00 44

Hex example value Data name Value

02 Structure version 2
02 Record type 2 (IMEI record)
08 00 Record length 8 bytes
91 88 75 2D E7 12 03 00 IMEI 865209039554705
01 Record type 1 (Sensors array record)
3A 00 Length 58 bytes
20 00 AD 59 Unix timestamp Monday, September 4, 2017 7:26:24 AM
(UTC)
05 Sensor value type Unsigned 16 bit integer
00 30 Sensor identifier VCC (sensor names will be provided
together with this document)
B1 35 Sensor value 13745
03 Sensor value type Zero value type (value encoded in type so
there will be no value field)
03 40 Sensor identifier Mileage sensor (sensor names will be
provided)
03 Sensor value type Zero value (value encoded in type so no
value field present)
0C 30 Sensor identifier RPM sensor
03 Sensor value type Zero value
01 A0 Sensor identifier Acceleration sensor identifier
03 Sensor value type Zero value
02 A0 Sensor identifier Cornering sensor identifier
0E Sensor value type GPS structure type
00 D0 Sensor identifier GPS structure sensor identifier
B9 AB 5B 42 03 34 C0 41 Sensor value 54.9177 - Latitude
00 00 1F 06 00 00 32 00 24.0254 - Longitude
0 - Speed
3.1 - HDOP
6 - satellites
0 - degrees course
50 - meters above sea level
04 Sensor value type Unsigned 8 bit integer

BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
 07 20 Sensor identifier Fuel level sensor
64 Sensor value 100 is fuel level value
00 Sensor value type Boolean false signal
8C 00 Sensor identifier Foot brake signal
01 Sensor value type Boolean true signal
62 00 Sensor identifier Front left door open signal
20 Sensor value type String sensor
00 C0 Sensor identifier String 1 sensor whose length is less than
256
04 Length String 1 is 4 bytes long
47 6F 6F 44 Sensor value String 1 is 4 byte ASCII string “GooD”
01 Record type 1 (Sensors array record)
09 00 Length 9 bytes
21 00 AD 59 Unix timestamp Monday, September 4, 2017 7:26:25 AM
(UTC)
05 Sensor type value Unsigned 16 bit integer
00 30 Sensor identifier VCC
BA 35 Sensor value 13754
9B Checksum Sum of all bytes starting with structure
version 02
Table 15. Explained example packet
*For list of sensor names please contact BCE tech. support team

7.1.2 Events data

Events from structure version 2 are explained below:

Element name No. of bytes Comment Example value

Record type 1 Type of record 03
Record length 2 Remaining length of record 0A 00
Timestamp 4 Unix timestamp 20 00 AD 59
Function ID 1 Function identifier 00
Warning ID 1 Warning identifier 01
Firmware name * ASCII string of firmware 46 54 32 50
name. Length is equal to
Record length - 6
Table 16. Event record structure explanation

Payload example that contains events data and IMEI is given below.
02 02 08 00 91 88 75 2D E7 12 03 00 03 0A 00 20 00 AD 59 00 01 46 54 32 50 03 0A 00 22 00 AD 59 64
33 46 54 32 50 FB

Example value Description

02 Structure version
02 Record type (IMEI)
08 00 Remaining length of IMEI record (8 bytes)
91 88 75 2D E7 12 03 00 IMEI value (865209039554705)
03 Record type (Events data)
0A 00 Remaining length of Events data record (11 bytes)
20 00 AD 59 Unix timestamp (09/04/2017 @ 7:26AM (UTC)
BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
 00 Function ID
01 Warning ID
46 54 32 50 Firmware name (FT2P)
03 Record type (Events data)
0A 00 Remaining length of Events data record (11 bytes)
22 00 AD 59 Unix timestamp (09/04/2017 @ 7:26AM (UTC)
64 Function ID
33 Warning ID
46 54 32 50 Firmware name (FT2P)
FB Checksum (sum of all bytes starting with structure version)
Table 17. Structure version 2 example payload with events

7.1.3 Output control

Output control structure from version 2 is explained below

Element name No. of bytes Comment Example value

Record type 1 Type of record 04
Record length 2 Remaining length of record 0A 00
Expiration 4 Field describes period of output 50 00 AD 59
command validity (UTC time)
Output ID 1 Output identifier 00
Unique ID 1 Field is used to prevent CC
repeated output command run.
Each output command must
have different Unique ID field
in order to run commands.
Command length 1 Length is used to describe 3
Output data field size
Output data * For structure of this field please 00 00 05
refer to section 8.
Table 18. Structure version 2 output control record explanation

Example of output payload that can be used to turn on OUT1 for 1 second is given below:
02 02 08 00 91 88 75 2D E7 12 03 00 04 0A 00 50 00 AD 59 00 11 03 00 64 00 9F

Example value Description

02 Structure version
02 Record type (IMEI)
08 00 Remaining length of IMEI record (8 bytes)
91 88 75 2D E7 12 03 00 IMEI value (865209039554705), IMEI record in this case is not mandatory
to send output commands that only contain output control record.
04 Record type (Output control)
0A 00 Remaining length of Output control record (10 bytes)
50 00 AD 59 Expiration. Command is valid until provided time in unix format.
00 Output identifier (According to section 8. 00 Output stands for OUT1)
11 Unique identifier which is used to prevent duplicate output command run

BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
 03 Output command length in bytes
00 64 00 Output data. For structure please refer to section 8.
9F Sum of all bytes starting with structure version
Table 19. Structure version 2 output control example

7.1.4 File transmission

Announce file packets from structure version 2 are explained below:

Element name No. of bytes Comment Example value

Record type 1 Type of record 05
Record length 2 Remaining length of record 4E 00
Packet type 1 Field is used to tell subscriber 01
that record is announce of file
File name 64 File name is ASCII string. String 38 36 35 32 30 39
is NULL terminated. If string is 30 33 39 35 35 34
shorter than 64 bytes, remaining 37 30 35 2D 31 35
bytes are padded with zeros. 32 34 32 33
33 36 33 33 2E 63
61 6E 00 00 00 00
00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00
00 00 00 00 00 00
00 00 00
Timestamp 1 Unix timestamp of file creation. 20 00 AD 59
File length 1 Number of bytes that make 0B 00 00 00
whole file
Checksum 4 32 bit value that is sum of all 31 04 00 00
file’s bytes.
Number of packets 2 Total number of file part 01 00
messages
Table 20. Explanation of record that announces transmission of file

Part of file packets from structure version 2 are explained below:

Element name No. of bytes Comment Example value

Record type 1 Type of record 05
Record length 2 Remaining length of record 10 00
Packet type 1 Field is used to tell subscriber 02
that record is part of file
Packet number 2 Field is used to tell order 01 00
number of file parts
Number of packets 2 Field is used to tell total 01 00
number of file parts. When
received message’s packet
number and number of packets
fields are equal it can be
considered that file
transmission is done

BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
 File part * Part of file. Length of File part 48 65 6C 6C 6F 20
is described in Length of file 77 6F 72 6C 64
part field
Table 21. Explanation of record that’s a file of a part

Every file transmission starts with announce packet. Example payload with file record that has file announce
is given below:

02 02 08 00 91 88 75 2D E7 12 03 00 05 4E 00 01 38 36 35 32 30 39 30 33 39 35 35 34 37 30 35 2D 31 35
32 34 32 33 33 36 33 33 2E 63 61 6E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 20 00 AD 59 0B 00 00 00 3C 04 00 00 01 00 14

Example value Description

02 Structure version
02 Record type (IMEI) (this record is optional and may not be present during f
08 00 Remaining length of IMEI record (8 bytes)
91 88 75 2D E7 12 03 00 IMEI value (865209039554705)
05 Record type (File)
4E 00 Remaining length of file record (78 bytes)
01 Packet type (Announce file)
38 36 35 32 30 39 30 33 39 35 35 34 File name in ASCII string format. Always 64 bytes value.
37 30 35 2D 31 35 32 34 32 33 33 36
33 33 2E 63 61 6E 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
20 00 AD 59 Unix timestamp of file creation
0B 00 00 00 File size in bytes
3C 04 00 00 Checksum of whole file
01 00 Number of packets that will make whole file
14 Checksum. Sum of all bytes starting with structure version
Table 22. Example of payload that has file announce record

Example of payload that has part of file is given below:

02 02 08 00 91 88 75 2D E7 12 03 00 05 10 00 02 01 00 01 00 48 65 6C 6C 6F 20 77 6F 72 6C 64 18

Example value Description

02 Structure version
02 Record type (IMEI) (this record is optional and may not be present during file
transmission)
08 00 Remaining length of IMEI record (8 bytes)
91 88 75 2D E7 12 03 00 IMEI value (865209039554705)
05 Record type (File)
10 00 Remaining length of File record (16 bytes in this case)
02 Packet type (Part of file)
01 00 Packet number
01 00 Total number of packets
48 65 6C 6C 6F 20 77 6F 72 6C 64 File content
18 Checksum. Sum of all bytes starting with structure version
Table 23. Example of payload that has part of file

BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
8. Output data structures

This section explains Output data field that is mentioned in section 7.1.3.

Output ID Output name Length Data

00 OUT1 3
Function Data Description
ID

00 B0 B1 Turn output on for a

period that is specified
in data field (10ms
resolution)

01 B0 B1 Turn output off for a

period that is specified
in data field (10ms
resolution)
Output data field is combination of Function ID and
Data fields

01 OUT2 3
Function Data Description
ID

00 B0 B1 Turn output on for a

period that is specified
in data field (10ms
resolution)

01 B0 B1 Turn output off for a

period that is specified
in data field (10ms
resolution)
Output data field is combination of Function ID and
Data fields

02 OUT3 3
Function Data Description
ID

00 B0 B1 Turn output on for a

period that is specified
in data field (10ms
resolution)

01 B0 B1 Turn output off for a

period that is specified
in data field (10ms

BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
 resolution)
Output data field is combination of Function ID and
Data fields

03 OUT4 3
Function Data Description
ID

00 B0 B1 Turn output on for a

period that is
specified in data field
(10ms resolution)

01 B0 B1 Turn output off for a

period that is
specified in data field
(10ms resolution)
Output data field is combination of Function ID and
Data fields

04 OUT5 3
Function Data Description
ID

00 B0 B1 Turn output on for a

period that is
specified in data field
(10ms resolution)

01 B0 B1 Turn output off for a

period that is
specified in data field
(10ms resolution)
Output data field is combination of Function ID and
Data fields

05 UNLOCK 2
OVER CAN Data Description

B0 B1 Data field contains 16bit CAN output

command ID

06 LOCK OVER 2
CAN Data Description

B0 B1 Data field contains 16bit CAN output

command ID

07 REMOTE 1
DUMP Data Description
COMMAND

BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
 01 Forces device to log data from CAN1
for up to 20 seconds.

02 Forces device to log data from CAN2

bus for up to 20 seconds.

08 STATIC 1
SIGNAL1 Data Description
CONTROL
01 01 is used to set static signal to 1.
Any other data will change static
signal state to 0.

09 STATIC 1
SIGNAL2 Data Description
CONTROL
01 01 is used to set static signal to 1.
Any other data will change static
signal state to 0.

0A STATIC 1
SIGNAL3 Data Description
CONTROL
01 01 is used to set static signal to 1.
Any other data will change static
signal state to 0.

0B STATIC 1
SIGNAL4 Data Description
CONTROL
01 01 is used to set static signal to 1.
Any other data will change static
signal state to 0.

0C STATIC 1
SIGNAL5 Data Description
CONTROL
01 01 is used to set static signal to 1.
Any other data will change static
signal state to 0.

0D SCRIPT n
REMOTE
COMMAND
Table 24. Output data field structure

To form output command Output data field from section 7.1.3 should be formed in following order:
Function ID, Data bytes.

Example of Output data that should be used in order to turn on OUT1 of BCE IOTM device for 500ms is
given below:
BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
 00 80 00
Please take into consideration that Output control record is a part of payload that has to be wrapped with
MQTT header. During cases where no MQTT broker is used server has to make sure that payload is being
published to BCE IOTM device with preconfigured topic name (IMEI/OUTC by default, where IMEI is
replaced with device’s unique ID) and QoS1. Explanation of data publishing is given in section 6.2.

BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
 Annex A.
Specific structure parsing for ISOBUS messages
Some binary array sensors can be parsed to structures.

Sensor with identifier 0xEFFE can be parsed according to structure provided below.

Value name Length Example value hex Example value

dec
DDI 2 E4 01 484
Element number 2 01 00 1
Value 4 20 D6 13 00 1300000
Table 25. Structure of DDI element and value that can make up whole 0xEFFE sensor value

Note that length of binary array should be n*8, otherwise structure should be considered invalid.
Payload’s (in hexadecimal) that contains sensor 0xEFFE example (example is provided with payload of
structure version 1, however same rules can be applied to structure 2 telemetry data record):

01 02 91 88 75 2D E7 12 03 00 01 34 00 20 00 AD 59 0E 00 D0 B9 AB 5B 42 03 34 C0 41 00 00 1F 06 00
00 32 00 41 FE EF 18 00 E4 01 01 00 20 D6 13 00 C0 00 05 00 40 AC 27 00 02 00 06 00 20 D6 13 00 01
09 00 21 00 AD 59 05 00 30 BA 35 64

Example packet is explained below.

Hex example value Data name Value

01 Structure version 1
02 Record type 2 (IMEI record)
91 88 75 2D E7 12 03 00 IMEI 865209039554705
01 Record type 1 (Sensors array record)
34 00 Length 52 bytes
20 00 AD 59 Unix timestamp (UTC) Monday, September 4, 2017 7:26:24
AM
0E Sensor value type GPS structure type
00 D0 Sensor identifier GPS structure sensor identifier
B9 AB 5B 42 03 34 C0 41 Sensor value 54.9177 - Latitude
00 00 1F 06 00 00 32 00 24.0254 - Longitude
0 - Speed
3.1 - HDOP
6 - satellites
0 - degrees course
50 - meters above sea level
41 Sensor value type Binary array, length provided in two
bytes
FE EF Sensor identifier ISOBUS parameters table
18 00 Length 24 bytes
E4 01 DDI(1) 484
01 00 Element number(1) 1
20 D6 13 00 Value(1) 1300000
C0 00 DDI(2) 192
05 00 Element number(2) 5
40 AC 27 00 Value(2) 2600000
02 00 DDI(3) 2
06 00 Element number(3) 6
BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS
20 D6 13 00 Value(3) 1300000
01 Record type 1 (Sensors array record)
09 00 Length 9 bytes
21 00 AD 59 Unix timestamp (UTC) Monday, September 4, 2017 7:26:25
AM
05 Sensor type value Unsigned 16 bit integer
00 30 Sensor identifier VCC
BA 35 Sensor value 13754
64 Checksum Sum of all bytes starting with
structure version 01
Table 26. Example of payload that contains ISOBUS data

ddi484e1=1300000; ddi192e5=2600000; ddi2e6=1300000

BALTIC CAR EQUIPMENT Chemijos st. 15 LT-51332, Kaunas, Lithuania www.bce.lt TELEMATICS & IOT SOLUTIONS