Teltonika Bridge

You might also like

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 6

Teltonika Bridge

We would like to create a solution written in c# that will import data from Teltonika devices into the
Bluesky trail platform these devices include the GH5200, the TMT250 and the TAT100.

Teltonika devices
The Teltonika devices mentioned above and further on in the document are GPS trackers that will
send periodic GPS updates (based on a time period elapsing or the devices moving a certain distance
etc This is all configured within the devices.) Some of the devices also come equipped with Buttons
allowing users to generate other events such as SOS or MANDOWN for example. The signals sent
from these devices will contain information about actions taken by a user in terms of movement or
button presses as well as information about the current status of the device i.e battery level, signal
strength etc.

Blue Sky Trail


Blue Sky Trail is our platform designed to record information for the purposes of Proof of presence
(i.e patrols and GPS tracking) Daily occurrence Records (i.e recording the tasks completed in a day)
and lone worker. The integration of the Teltonika devices will allow us to use them to provide
functionality to the proof of presence and lone worker facets of the system. The

The Solution
The solution will need to take signals from the Teltonika devices and format them into events that can
be sent to various endpoints on the Bluesky trail platform. In aid of this the details for:
- The Teltonika codec
- The Blue Sky Trail endpoints
- The events and properties of the events sent from the Teltonika devices
Will be detailed below.
We can also provide source code in c# for receiving and decoding the data from the devices, this will
be provided along side this document as well as the links to the Teltonika wiki detailing the protocol
and the list of events that can be expected from the devices.

Codec format
We want to use the Codec8 Extended over TCP for this project. This is detailed here:
https://wiki.teltonika-gps.com/view/Teltonika_Data_Sending_Protocols#Codec_8_Extended

To summarise a device will send its IMEI to the server, once it receives and ack it will send its data to
be processed. This is sent as a hex string that can be decoded as follows:
This packet will be formatted as follows:
It is worth noting that multiple events/updates can be sent at once, these should be processed
separately.
The following data is how this string would be decoded:
000000000000004A8E010000016B412CEE0001000000000000000000000000000000000
10005000100010100010011001D00010010015E2C880002000B000000003544C87
A000E000000001DD7E06A00000100002994

AVL Data Packet HEX From example


Zero Bytes 00 00 00 00
Data Field Length 00 00 00 4A
Codec ID 8E
Number of Data 1 (Records) 1
Timestamp 00 00 01 6B 41 2C EE 00 (GMT: Monday, June
10, 2019, 11:36:32 AM)

Priority 1
Longitude 00 00 00 00
Latitude 00 00 00 00
Altitude 00 00
Angle 00 00
Satellites 0
Speed 00 00
Event IO ID 00 01
N of Total ID 00 05
N1 of One Byte IO 00 01
1’st IO ID 00 01 (AVL ID: 1, Name: DIN1)

1’st IO Value 1
N2 of Two Bytes IO 00 01
1’st IO ID 00 11 (AVL ID: 17, Name: Axis X)

1’st IO Value 00 1D
N4 of Four Bytes IO 00 01
1’st IO ID 00 10 (AVL ID: 16, Name: Total Odometer)

1’st IO Value 01 5E 2C 88
N8 of Eight Bytes IO 00 02
1’st IO ID 00 0B (AVL ID: 11, Name: ICCID1)

1’st IO Value 00 00 00 00 35 44 C8 7A
2’nd IO ID 00 0E (AVL ID: 14, Name: ICCID2)

2’nd IO Value 00 00 00 00 1D D7 E0 6A
NX of X Byte IO 00 00
Number of Data 2 (Number of Total 1
Records)
CRC-16 00 00 29 94

The data we will need from this specifically is


- the IMEI of the device (this is used as a device ID in BST)
- the time stamp
- Positional data: * this could potentially be taken from the IO values as it is there in ISO6709
format but which ever option works best
o Longitude
o Latitude
o Altitude
o Angle
o Speed
- IO Values
o Permanent
o Eventual

IO values
The IO values (listed in their entirety here:
https://wiki.teltonika-gps.com/view/GH5200_AVL_ID_List ) can be split into two groups:
Permanent, these are values that indicate the status of the device, for example battery level, signal
strength GPS, every event submitted will need some of this information to be sent along with it as will
be listed below.
Eventual IO values these are only present when an event has triggered them such as pressing of a
button or the device being powered on.
Below are a list of the signals that should be sent to each endpoint and how the data should be
acquired, The events should be sent to the endpoints via POST and the data should be formatted in
JSON in the request body:

Alarms (/api/alarm)
Movement event
ID 310
Name Movement Event
Name to send to BST Man Down
Min value 0
Max value 1
Description 0 – Movement Event Occurred
1 – No Movement Event Occurred
This should only be sent if no movement event
occurs
Devices GH5200, TMT250

Button Click
ID 389
Name Button Click
Name to send to BST Amber Alert
Min value 0x11
Max value 0x53
Description Button ID (X) and Action (Y) Value 0xXY
X - button ID:
1 - alarm button
2 - power button
3 - button 1
4 - button 2
5 - button 3
Y - action:
1 - 1 click
2 - 2 clicks
3 - long click

For our purposes any instance of this event


should send an Amber alert, unless this is
caused by the sending of an Alarm/SOS
Devices GH5200, TMT250

Alarm
ID 236
Name Alarm
Name to send to BST SOS
Min value 0
Max value 1
Description 0 – Reserved
1 – Alarm event occurred
If an Alarm event occurs send the event to BST
Devices GH5200, TMT250

Request details
Event - POST - /api/Alarm
"deviceid": <IMEI from ack>,
"eventtime":<TimeStamp>,
"alamType": <name to send as above>,
"longitude":<long>,
"latitude":<lat>,
"altitude":<altitude>,
"speed":<speed>,
"course":<angle>,
"percentage":<AVLID 113>,
"signalstrength":<AVLID 21>

Events (/api/event)
Power Event
ID 390
Name Power Event
Name to send to BST Power On/ Power Off
Min value 0
Max value 1
Description 1 – device turned off
0 – device turned on
Devices GH5200, TMT250

Request
Event - POST - /api/Event
"deviceid": <IMEI from ack>,
"eventtime":<TimeStamp>,
"eventType":<name to send as above>,
"eventInfo":<event value>,
"longitude":<long>,
"latitude":<lat>,
"altitude":<altitude>,
"speed":<speed>,
"course":<angle>,
"percentage":<AVLID 113>,
"signalstrength":<AVLID 21>

Updates (/api/update)
If data is received that does not contain one of the listed Eventual IO ID and values then it should be
submitted to the update endpoint as follows

Event - POST - /api/update


"deviceid": <IMEI from ack>,
"eventtime":<TimeStamp>,
"longitude":<long>,
"latitude":<lat>,
"altitude":<altitude>,
"speed":<speed>,
"course":<angle>,
"percentage":<AVLID 113>,
"signalstrength":<AVLID 21>

Other details/ requirements:


We will require the solution to provide logging for the following details:
- Signals received by the solution (i.e information received from the Teltonika devices)
- POST requests sent by the solution including:
o The endpoint the event was sent to
o The request body sent
o The response received from the server (e.g 200, 405 etc as well as any error message)

We will require a configuration file to allow us to control the following:


- Where the log is saved
- If the log is enabled
- The server details for the destination server of the POST events (i.e everything before /api/event)
The solution should be built as a windows service.

You might also like