Confidential

Decodification Manual
for

Oigo-Connected AR-XX Series

Document reference
Revision: 1.3
Authors: Renato Motta
Release date: July 15, 2016

© Oigo Telematics, 2016 Page 1

Confidential

Table of Contents

Contents
Table of Contents .......................................................................................................................................... 2
Overview ....................................................................................................................................................... 4
Description .................................................................................................................................................... 4
Communication Interfaces............................................................................................................................ 4
Update Server ....................................................................................................................................... 5
File Updates via TFTP ............................................................................................................................ 5
UDP/IP ........................................................................................................................................................... 6
Protocol Frame.......................................................................................................................................... 7
Location and Status Report Format .......................................................................................................... 7
Events ID ............................................................................................................................................... 8
Ack’ed Mode ......................................................................................................................................... 9
Report Data Items ....................................................................................................................................... 10
Appendix A – AR Communication Protocol ................................................................................................ 10
Frame Structure ...................................................................................................................................... 10
Length ................................................................................................................................................. 11
Protocol ID .......................................................................................................................................... 11
Tag ....................................................................................................................................................... 11
Identification ....................................................................................................................................... 11
Location and Status Report (Protocol 0x00) ........................................................................................... 12
Event ................................................................................................................................................... 12
Mask .................................................................................................................................................... 12
Report Fields ....................................................................................................................................... 13
SequenceNumber ............................................................................................................................... 13
GpsTime .............................................................................................................................................. 14
RtcTime ............................................................................................................................................... 15
GpsLocation ........................................................................................................................................ 16
GpsStatus ............................................................................................................................................ 16
Speed .................................................................................................................................................. 17

© Oigo Telematics, 2016 Page 2

Confidential

Heading ............................................................................................................................................... 17
Altitude................................................................................................................................................ 17
RSSI...................................................................................................................................................... 17
MainPower .......................................................................................................................................... 18
BackupPower ...................................................................................................................................... 18
GPIO .................................................................................................................................................... 18
Odometer ............................................................................................................................................ 18
SWversion ........................................................................................................................................... 18
HWversion........................................................................................................................................... 19
DeviceConfig ....................................................................................................................................... 19
ACKed UDP (Protocol 0xE0) .................................................................................................................... 20

© Oigo Telematics, 2016 Page 3

Confidential

Overview
The objective of this document is to provide the user with detailed information regarding the
data format and protocol available for the AR-XX series, it details how the report messages are
sent to the backend server, how the server should handle those messages including how to
send the correct ACK confirmation to the device and how to send commands via UDP protocol.
The AR-2x can accept commands via serial, SMS or UDP. In this document it describes how the
device sends its event report messages over UDP and how to send commands to the device
using the UDP protocol.

Note: Only AR extension commands are recognized over the IP and SMS connection.

Description
The AR-XX Device Communication Protocol is a bidirectional protocol, which allows a device and a server
to communicate over an IP (Internet Protocol) link. Each message is “self-contained” in the sense that all
the information (such as size) necessary to parse a message is contained within the message itself.

The communication link has the following parameters:

Type: UDP or UDP with ACK

Duplex: Half duplex (Device to Server only) or Full-Duplex

Endianness: Big Endian unless specified otherwise

Communication Interfaces
In general AR-XX devices support three functional communication interfaces: SMS, UDP/IP and serial
communication over a physical UART.

The AR-XX AT commands can be transacted over any of the above three interfaces. Commands and
responses have identical syntax regardless of the interface used. A response is always transacted back
via the same interface as the command. All commands and responses are also echoed to the serial port.
Unless explicitly specified otherwise, reports are always sent via the UDP/IP connection and when sent
are also echoed to the UART.

The AR-XX captures data and then it uses this data to form a report. A report is a single data structure
intended to contain all of the useful data on the device. Reports are generated after specified events,
such as periodic timeouts, speed threshold, geofence crossing etc, or in response to a command
(AT+XRN).

© Oigo Telematics, 2016 Page 4

Confidential

Servers
AR-XX devices can be configured to communicate over UDP/IP with a number of different servers:

 Tracking Server – The main application server where the event triggered reports are sent.
 Maintenance Server – Typically used for checking the health of the unit. There is a set of AT
commands that pertain to that server.
 Update Server – The server from where application and other file updates are loaded from OTA
using TFTP protocol.
 Serial Port Server – The server that communicates with the Application Serial Port.

Communication to all servers takes place concurrently. Each server is configured with its own IP address
and port.

Maintenance Server
The purpose of the Maintenance Server is to monitor the health of the device and manage
software/firmware updates. The maintenance server link is maintained independently of the main
application server. Its IP address is set by the AT+XMIP command. It has its own limited set of
commands that control the frequency and the format of the Maintenance Reports that are targeted for
operational “housekeeping” of the device.

Update Server
The purpose of the Update Server is to host the files that can be downloaded by the device via TFTP OTA
to update various software components of the device. The Update Server must support TFTP. The
Update Server link is maintained independently of the main application server. Its IP address is set by
the AT+XUIP command.

File Updates via TFTP

There are several system files, such as the application, configuration file, etc., that can be updated in
the field OTA. The files are loaded from the Update Server. The updates are initiated by respective AR
AT commands and employ the TFTP protocol. At the end of each successful update, the device resets
itself for the newly downloaded file to take effect. At the end of a TFTP transaction (or upon a timeout),
the device can be configured to send a report that indicates success or failure of the TFTP transfer. The
report is sent to the server that initiated the transaction. I.e. if the TFTP update was initiated by the
Maintenance Server, the report will be sent to the Maintenance Server.

In case the TFTP transfer fails the device will retry to perform the same transfer a number of times as
specified by the Update Retry Policy command (Error! Reference source not found.). If all attempts
failed, the device reports back an error code via UART that can help troubleshooting the issue. The
device also sends to the server a report with respective TFTP failure tag.

© Oigo Telematics, 2016 Page 5

Confidential

UDP/IP
UDP/IP is the main communication interface of the AR-XX devices. All status reports are sent via UDP/IP.
If IP connection is unavailable, the reports are queued until IP connection becomes available. Only AR
extension commands are recognized over the IP connection (cellular standard commands are not
supported over IP). Commands sent though the IP connection are replied to through that same
connection. All commands and reports sent or received via IP are also echoed to the UART.

AR-XX devices can be configured to maintain IP connection constantly or tear it down and re-establish
when necessary (i.e. when there is a report to be sent). If configured to maintain constant connectivity
and the IP connection is lost, the device will attempt re-establishing it as soon as possible according to
the PxP policy. By default , battery powered devices maintain IP and cellular connection closed most of
the time and only establish it for short periods of time to send report. Externally powered devices
attempt to keep the IP connection open all the time. This mode of operation is configurable and can be
changed using the respective AR AT commands.

Note that while the IP connection is closed the device is only accessible via SMS and UART.

Reports
The AR-XX devices capture data and form report records with that data. A report is a data structure
containing all of the sensory and other typically useful data on the device. Reports are generated in
response to specified events, such as periodic timeout, speed threshold, geo-fence crossing, etc., or in
response to a Report Now command (Error! Reference source not found.).

Reports can be generated in either an ASCII representation of hex or as actual binary encoded hex. The
reporting format is selected via Report Format (Error! Reference source not found.) command. Note
that while the logical content of the report is the same in both representations, the size for an ASCII
report is twice the size of actual numbers of bytes compared to binary representation.

© Oigo Telematics, 2016 Page 6

Confidential

Protocol Frame
The AR Communication Protocol supports a number of message types used by different applications.
Location and Status reports are only one type of such messages. Each message is “self-contained” in the
sense that all the information (such as size and type) necessary to parse a message is contained within
the message itself. All messages adhere to a common frame structure:

<start_of_frame><length><protocol_id><tag><identification><payload>

Where:

<start_of_frame> is the character 0x7E. Note: There is no attempt to escape or remove

the <start_of_frame> character if it appears in the rest of the
frame

<length> is a 2-byte field, coded in big endian format, that gives the length of the
frame starting with the <protocol_id> field

<protocol_id> is a 1-byte field which gives information about the type of data
contained in the <payload > field

<tag> is a 1-byte field which gives information about retransmission and the
type of identification

<identification> is a variable length field. This field allows the receiving entity to uniquely
identify the sender (usually IMEI or MEID or S/N).

<payload> is a variable length field. Its content is based on the <protocol_id>

All messages start with a fixed “Start Frame” byte to assist the server to identify them quickly as coming
from an AR tracker. The value of the “Start Frame” byte can be configured via the Report Start Frame
(Error! Reference source not found.) command.

The details of the AR-XX Communication Protocol as well as the content and format of all data records
are presented in Appendix A – AR Communication Protocol. The next section provides a high level
description of the format of the <payload> associated with the Location and Status reports used by the
main tracking application.

Location and Status Report Format

This format defines the contents and structure of location and status reports, which are the most
common messages of the tracking devices. The <payload> field of a Location and Status Report
message has the following format:

<event><mask><data>

© Oigo Telematics, 2016 Page 7

Confidential

Where:

<event> is a 1-byte field indicating the trigger for the report to be sent

<mask> is a 4-byte field that specifies which data fields are contained in the data
field of the report. The report is a list of fields. Only fields which
corresponding bits in the mask are set are included in the report.

<report> is a variable length field. Its length is the determined by the fields
included in the report based on the <mask>.

Events ID
The Event field is a 1-byte field that identifies the trigger that caused the report to be sent. Below is a list
of all possible events and the commands that enable them.

EID EID Event Comments Command

(Hex) (Dec)
00 0 Reserved
01 1 Power-Up XPUP
02 2 Heart Beat Periodic report XHB
03 3 BuB Heart Beat Periodic report when running from backup battery XHBB
04 4 BuB On Switched to backup battery (main power loss) XBUB
05 5 BuB Off Switched back from BuB to main power XBUB
06 6 Power Drop External power dropped below +XPWL threshold XPWLE
07 7 Power Restore External power raised above +XPWL threshold XPWLE
08 8 Reserved
09 9 Reserved
0A 10 Reserved
0B 11 Reserved
0C 12 Relay High RLY state changed from 0 → 1 XRLY
0D 13 Relay Low RLY state changed from 1 → 0 XRLY
0E 14 Ignition High Ignition state changed from low → high XIGN
0F 15 Ignition Low Ignition state changed from high → low XIGN
10 16 GPS Locked XGPL
11 17 GPS Unlocked XGPL
12 18 IP Changed Local IP address changed XIPC
13 19 Speeding Start Speed raised above specified threshold XSPD
14 20 Speeding Stop Speed dropped below specified threshold XSPD
15 21 Reserved
16 22 Drive Trip - Start XDTS
17 23 Drive Trip - End XDTS
18 24 Moving Recurring event while in “trip” and moving XDRI
19 25 Stopped Recurring event while stopped XDRI
1A 26 Heading Change Changed heading by a specified degree while in “trip” XDHC
1B 27 Drive Distance Recurring event passing specified distance while in “trip” XDDI
1C 28 Tow Alert XTA
1D 29 Reserved

© Oigo Telematics, 2016 Page 8

Confidential

1E 30 Idling Alert XIA

1F 31 Now Report Response to Report Now command XRN/XRN
E
20 32 Periodic Reset Scheduled “reset” took place XRSTE
21 33 Trip Odometer Virtual Trip Odometer reached specified threshold XVTOE
22 34 Maintenance Maintenance Periodic Report XMHB
23 35 Reserved
24 36 Reserved
25 37 GP1 High GP1 state changed from 0 → 1 XIOE
26 38 GP1 Low GP1 state changed from 1 → 0 XIOE
27 39 GP2 High GP2 state changed from 0 → 1 XIOE
28 40 GP2 Low GP2 state changed from 1 → 0 XIOE
29 41 GP3 High GP3 state changed from 0 → 1 XIOE
2A 42 GP3 Low GP3 state changed from 1 → 0 XIOE
2B 43 GP4 High GP4 state changed from 0 → 1 XIOE
2C 44 GP4 Low GP4 state changed from 1 → 0 XIOE
2D 45 Reserved
2E 46 Reserved
2F 47 Reserved
30-3A 48-63 Reserved
40 64 Power Save External power dropped below +XPWS threshold XPWSE
41 65 Power Normal External power raised above +XPWS threshold XPWSE
42-5F 66-95 Reserved

60-6F 96-111 Geo-Fence Enter Second digit of event indicates geo-fence number XGFE
70-7F 112-127 Geo-Fence Exit Second digit of event indicates geo-fence number XGFE
Table 1 – Events ID

NOTE: The Event ID’s listed above are the default ID’s reported by the AR-XX devices. Any Event ID can
be changed by its respective enabling command.

Ack’ed Mode
UDP is not a 100% reliable connection and occasional reports or command/responses may be lost. Since
all commands have responses, the server can repeat any command to which there is no response. In
order to assure reliable reception of reports, AR devices can be configured either in Normal or Ack’ed
mode to send the reports. In the Normal mode the reports are simply sent “as is” with no
acknowledgment from the server. In the Ack’ed mode every report sent is expected to be acknowledged
by the server by sending back an ACK message back. If acknowledgement is not received within the
specified timeout, the report is re-sent. If the report is not acknowledged after the specified number of
attempts, it is queued. If acknowledgement is received after the report is queued (i.e. past timeout of
the last attempt), it is ignored.

Report is not considered “complete” until its acknowledgement is received. Thus, if report X is sent and
report X+1 is triggered while waiting for acknowledgement of X, report X+1 will be queued until such
acknowledgement is received and only then sent. The AR (AR-XX) will attempt to re-send queued

© Oigo Telematics, 2016 Page 9

Confidential

report(s) every time a new report is triggered. If there is more than one report queued, the reports will
attempt to be sent in the order of triggering and only once the report is acknowledged, the next report
is attempted. This assures that reports are sent and received in order.

Ack’ed mode assures that all reports are received, but adds overhead in time and data. Report that is
not acknowledged is sent again and eventually will be queued and sent again. The number and
frequency of re-tries is configurable via the Report Acknowledgement command (Error! Reference
source not found.).

Report Data Items

Appendix A – AR Communication Protocol

Frame Structure
The link uses the following frame structure:

<start_of_frame><length><protocol_id><tag><identification><payload>

Where:

<start_of_frame> is the character 0x7E. Note that there is no attempt to escape or

remove the <start_of_frame> character if it appears in the rest of
the frame (Note: This field cam be omitted and/or changed)

<length> is a 2-byte field, coded in big endian format, that gives the length of the
frame starting with the <protocol_id> field

<protocol_id> is a 1-byte field which gives information about the type of data
contained in the <payload > field

<tag> is a 1-byte field which gives information about retransmission and the
type of identification

<identification> is a variable length field. This field allows the receiving entity to uniquely
identify the sender.

<payload> is a variable length field. Its content is based on the <protocol_id>

© Oigo Telematics, 2016 Page 10

Confidential

Length
Length is two-byte field that give the byte count for the reminder of the frame. The count starts with the
<protocol_id> field

Protocol ID
Protocol ID is a one-byte field that identify the type of information carried in the frame

ID Meaning Description on page

0x00 Location and Status report TBD
0x10 Remote start messages TBD
0xE0 Acknowledgment TBD
Others Reserved

Tag
Tag is one byte field that gives information about the frame:

Bit 7 When set, it indicates that the device is expecting an acknowledgement

frame from the server
Bit 6 Odd/Even frame indication
Bit 5-4 Reserved
Bit 0-3 Cellular mode / identification:
0000: Device is GSM/EDGE. Identification is the IMEI
0001: Device is CDMA 1X. Identification is the MEID
1111: No Identification field
Other values: Reserved

Identification
The Identification is a variable length field which is a unique identifier for the hardware. The
identification can be omitted in the following situation:

1. For all messages originating from the server

2. For messages originating from the device when the server can uniquely identify the hardware.
For example, if the device is assigned a unique IP address, the server might be able to identify
the device without any additional data.
For GSM devices, the identification is the IMEI of the device:

Identification (IMEI)
0000 IMEI
4 bits 15 nibbles
The valid IMEI nibbles are 0-9.

For CDMA devices this is the MEID of the device left padded with an extra 0x00 byte:

Identification (MEID)

© Oigo Telematics, 2016 Page 11

Confidential

0x00 MEID
1 byte 14 nibbles
The valid MEID nibbles are 0-F.

Location and Status Report (Protocol 0x00)

This protocol defines the contents and structure of location and status reports, which are the most
common messages of the tracking devices.

The <payload> field of a Location and Status Report message has the following format:

<event><mask><report>

Where:

<event> is a 1-byte field indicating the trigger for the report to be sent

<mask> is a 4-byte field that specifies which data fields are contained in the data
field of the report. The report is a list of fields. Only fields which
corresponding bits in the mask are set are included in the report.

<report> is a variable length field. Its length is the determined by the fields
included in the report based on the <mask>.

Event
The Event field is a 1-byte field that identifies the trigger that caused the report to be sent.

Mask
The Mask field is a 32-bit (4-byte) field that specifies the type of data contained in the data field of the
report. Different reports may be programmed to output different data fields. A properly designed
listener should never assume that the reports always have a fixed length. I shall check the length of the
frame and the mask and parse the data fields that it is aware of. New fields will always be added at the
end of the data field so the properly designed listener should just ignore the extra fields.

Mask Bit Mask Content Length

© Oigo Telematics, 2016 Page 12

Confidential

Bit 0 0x00000001 SequenceNumber 2 bytes

Bit 1 0x00000002 GpsTime 5 bytes
Bit 2 0x00000004 RtcTime 5 bytes
Bit 3 0x00000008 GpsLocation 8 bytes
Bit 4 0x00000010 GpsStatus 2 bytes
Bit 5 0x00000020 Speed 1 byte
Bit 6 0x00000040 Heading 2 bytes
Bit 7 0x00000080 Altitude 2 bytes
Bit 8 0x00000100 RSSI 1 byte
Bit 9 0x00000200 MainPower 2 bytes
Bit 10 0x00000400 BackupPower 2 bytes
Bit 11 0x00000800 GPIO 2 bytes
Bit 12 0x00001000 Odometer 4 bytes
Bit 13 0x00002000 SWversion 6 bytes
Bit 14 0x00004000 HWversion 5 bytes
Bit 15 0x00008000 DeviceConfig 2 bytes
Bit 16 0x0001000
Bit 17 0x0002000
Bit 18 0x0004000
Bit 19 0x0008000
Bit 20 0x0010000
Bit 21 0x0020000
Bit 22 0x0040000
Bit 23 0x0080000
Bit 24 0x0100000
Bit 25 0x0200000
Bit 26 0x0400000
Bit 27 0x0800000
Bit 28 0x1000000
Bit 29 0x2000000
Bit 30 0x4000000
Bit 31 0x8000000 Reserved
Table 2 - Report Fields

Report Fields
The report is treated as a list of fields in a fixed order, as specified in Table . Only fields that are enabled
by the <mask> are included in any given report. The length of the report is determined accordingly and
can vary based on the fields included.

Following is a detailed explanation of the report fields.

SequenceNumber
The SequenceNumber is a 2-byte field which carries a sequential frame count. This number can be used
by the server to detect missing frames.

© Oigo Telematics, 2016 Page 13

Confidential

GpsTime
GpsTime is the Coordinated Universal Time (UTC) reported by the GPS system. The format is as follows:

GpsTime
Y M DD HH MM SS
4 bits 4 bits 1 byte 1 byte 1 byte 1 byte

Where:

Y is 4-bit nibble representing the year

Y Year
0 2010
1 2011
..
9 2019
..
F 2025

M is 4-bit nibble representing the month

M Month
1 January
2 February
..
12 December

DD is an 8-bit representation of the day of the month

DD Day
01 1st
02 2nd
..
10 16th
..
1F 31st

HH, MM and SS are 8-bit representations of the hours, minutes and seconds at the time the report was
generated.

Exceptions:

1) If the GPS time is not available at the time the report is generated, the Device will report all
zero’s (see GpsStatus)

© Oigo Telematics, 2016 Page 14

Confidential

RtcTime
RtcTime is the Real Time Clock (RTC) reported by the device. The format is as follows:

RtcTime
Y M DD HH MM SS
4 bits 4 bits 1 byte 1 byte 1 byte 1 byte

Where:

Y is 4-bit nibble representing the year

Y Year
0 2010
1 2011
..
9 2019
..
F 2025

M is 4-bit nibble representing the month

M Month
1 January
2 February
..
12 December

DD is an 8-bit representation of the day of the month

DD Day
01 1st
02 2nd
..
10 16th
..
1F 31st

HH, MM and SS are 8-bit representations of the hours, minutes and seconds at the time the report was
generated.

Exceptions:

1) If the GPS time is not available at the time the report is generated, the Device will report all
zero’s (see GpsStatus)

© Oigo Telematics, 2016 Page 15

Confidential

GpsLocation
GpsLocation is the position reported by the Device GPS subsystem. The format is as follows:

GpsLocation
LAT LON
4 bytes 4 bytes

Where:

LAT is a 4-byte representation of the Latitude sent as encodedLat, a big endian unsigned number.

Decoding:

double latitude = ((double)encodedLat / 1000000.0) – 90.0

LON is a 4-byte representation of the Latitude sent as encodedLon, a big endian unsigned number.

Decoding:

double longitude = ((double)encodedLon / 1000000.0) – 180.0

For information the encoding is performed as follows:

encodedLat = (uint32)((latitude + 90.0) * 1000000.0)

encodedLon = (uint32)((longitude + 180.0) * 1000000.0)

Exceptions:

1) If the GPS location is not available at the time the report is generated, the Device will report all
zero’s (see GpsStatus)

GpsStatus
GpsStatus is a 2-byte field which gives information about the status of the GPS signal, the format is as
follows:

GpsStatus
Status Satellites HDOP
4 bits 4 bits 1 byte
Where:

Status is a 4-bit field:

Bit 7 Reserved
Bit 6-4 000: GPS is not locked
001: GPS is locked
100: Last known GPS position
Other value reserved

© Oigo Telematics, 2016 Page 16

Confidential

Satellites indicates the number of satellites used in the position reports

Bit 3-0 Satellite count

Exceptions:

1) If the Status indicates that the GPS is not locked, the GPS data (including number of satellites)
was generated during the last valid fix.
2) If the device has never acquired a valid GPS fix, the reported number of satellites (as well as
position data) will be zero.

HDOP is an indication of the quality of the received signal. The reported value must be divided by 10 to
obtain the actual HDOP.

Speed
Speed is a 1-byte field which indicates the speed of the device in kilometer/hours. The value can be
converted into MPH by dividing the reported value by 1.609

Speed
1 byte

Heading
Heading is a 2-byte field which indicates the heading of the device in degrees. Valid values are between
0 and 359.

Heading
2 bytes

Altitude
Altitude is a 2-byte signed field which indicates the altitude of the device in meters. The value can be
converted into feet by multiplying it by 3.28084. Valid values are between -1000 and +10000.

Altitude
2 bytes

RSSI
RSSI is a 1-byte field which gives a relative indication of the RF signal strength seen by the device. Valid
values are 0-31 and 99 where 0 indicates a very weak signal, 31 a very strong signal and 99 no signal at
the time the report was generated.

RSSI

© Oigo Telematics, 2016 Page 17

Confidential

1 byte

MainPower
MainPower is a 2-byte field which indicates the voltage of the power source (in units of 10 mV) that is in
use at the time the report was generated. This source will generally be the main power source (car
power) or a backup battery if the main source has been disconnected and the device is still running.

MainPower
2 bytes

BackupPower
BackupPower is a 2-byte field which indicates the voltage of a secondary power source (in units of 10
mV)

BackupPower
2 bytes

GPIO
GPIO is a 2-byte field with the following format:

GPIO
GPIO Status GPIO Direction
1 byte 1 byte

Odometer
Odometer is a 4-byte field with the following format:

Odometer
4 bytes

The odometer reports in km.

SWversion
SWversion is a 6-byte field which indicates the current release of all software components of a given
device. The format is as follows:

SWversion
Baseband Application
3 bytes 3 bytes

© Oigo Telematics, 2016 Page 18

Confidential

Baseband is a 3-byte field which indicates the software release version of the baseband subsystem. The
field can be expanded to X.Y.Z where X, Y and Z are the individual bytes in the field. If the device does
not include a baseband subsystem, the field is all zeros.

Application is a 3-byte field which indicates the current release of the application running on a given
device. The field can be expanded to X.Y.Z where X, Y and Z are the individual bytes in the field.

Example:

SWversion = 0x01080A030B10 is decoded as:

Baseband version is V1.8.10 and Application version is V3.11.16

HWversion
HWversion is a 5-byte field which indicates the current release of all the hardware components of a
given product. The format is as follows:

HWversion
Assembly Revision I/O
2 bytes 1 byte 2 bytes

Assembly is a 2-byte field which specifies the board assembly.

Revision is a 1-byte field which indicates the revision of the assembly.

I/O is a 2-byte field which indicates the software release version of the I/O processor. The release
version can be expanded to X.Y where X and Y are the individual bytes in the field. If the device does not
include a dedicated I/O subsystem, the field is all zeros.

DeviceConfig
DeviceConfig is a 2-byte field which indicates the version of the product configuration file.

DeviceConfig
Change bit Config Number
1 bit 15 bits

The Config Number is a number` (from 0 to 32767) that indicates the version of the configuration
installed on the device.

The Change Bit is set if the original configuration has been altered with one or more user commands.

© Oigo Telematics, 2016 Page 19

Confidential

ACKed UDP (Protocol 0xE0)

The device can be set to request that the server acknowledges the UDP packets. When operating in this
mode, a status report will be re-sent over and over until a matching acknowledgement is received from
the server.

The server acknowledges the data with the following frame:

<start_of_frame><length><protocol_id><tag>[<identification>]

Note: This protocol has no <payload> field.

Example 1: No identification required:

<start_of_frame>  As specified (default 0x7e)

<length>  0x0002

<protocol_id>  0xE0

<tag>  0x0F or 0x4F (bit 6 shall match the same bit in the frame that is being
acknowledged)

Note: generally, no identification is needed from server to device

Example 2: Identification required:

<start_of_frame>  As specified (default 0x7e)

<length>  0x000A

<protocol_id>  0xE0

<tag>  0x00 or 0x40 (IMEI used for identification)

<identification>  0x0122334455667788

© Oigo Telematics, 2016 Page 20