No problem!

Let's break it all down in very simple language so you can understand
Teltonika’s data sending protocols, even if you're completely new to this field.

� What is Teltonika?
Teltonika makes GPS tracking devices. These devices are used in:

 Cars
 Trucks
 Bikes
 Delivery vans
 And other IoT (Internet of Things) systems

They collect location and other data (like speed, battery, ignition, etc.) and send it to
a server or cloud. That’s how apps like vehicle tracking work.

� How Does a Teltonika Device Send Data?

Think of it like sending a WhatsApp message:

1. The Teltonika device collects data (your GPS location, speed, battery level).
2. It packs this data into a format (called a protocol).
3. It sends the packed data to a server (like sending a message to your friend).

This message can be sent in different languages (protocols). Teltonika supports

many such data sending protocols.

� What is a Data Sending Protocol?

A protocol is like a language or format the device uses to send its data to a server.

For example:

 English is a language → You understand messages in it.

 Codec 8 is a language → A server understands GPS data in this format.
� Now Let's Understand Each Protocol

1. � Codec 8 – Most Common Protocol

 Used in most Teltonika GPS devices.

 Sends data in binary format (a compact format that computers understand).
 Very fast and small in size – saves internet data.
 Sends:
o Date and time
o GPS location (latitude and longitude)
o Speed
o Angle (direction)
o IO data (like ignition on/off, battery, temperature, etc.)

� Example (not real values):

Timestamp: 2025-07-15 12:00:00

Latitude: 28.7041
Longitude: 77.1025
Speed: 45 km/h
Ignition: ON

But this data is not sent as plain text – it's sent in binary format (like 0x08FFAB0012...)
that the server needs to decode.

2. � Codec 8E – Extended Version

 Just like Codec 8, but supports more types of data.

 For example:
o You can send temperature as a decimal (e.g., 23.75°C)
o You can send more IO values

Used in advanced devices.

3. � Codec 12 – SMS Protocol

 Used to send data via SMS when the internet is not working.
 Data is smaller and basic.
 Sometimes used in UDP (another internet protocol, like TCP but faster and
less reliable).

Used in emergency or fallback cases.

4. � Codec 16 – HTTP / JSON Protocol

 This is easier to understand for humans and servers.

 Data is sent in JSON format using HTTP POST (like a web request).

Example JSON:

{
"imei": "123456789012345",
"timestamp": 1720000000,
"gps": {
"lat": 12.9716,
"lng": 77.5946,
"speed": 45
},
"io": {
"ignition": 1,
"battery_voltage": 12.3
}
}

 This is easy to read and used in modern web applications.

5. � MQTT Protocol (for IoT)

 Used in IoT devices (Internet of Things) like smart sensors, routers, etc.
 MQTT sends real-time updates to the server.
 Used where low power and fast communication are needed.
 Mostly used in Teltonika routers and special IoT products.

6. � SMS Commands

 You can send commands via SMS to the device to:

o Change settings (e.g., set speed limit)
o Request location
o Restart the device
 You receive a reply via SMS, sometimes in hex format.

Communication Flow Example

1. Device connects to the Internet using SIM card.
2. It gathers data (location, speed, etc.).
3. It packs the data using a protocol (like Codec 8).
4. It sends the data to a server (like yourcompany.com:5001).
5. Server receives and decodes the data.
6. Data is shown on the dashboard/app.
� Summary Table
Easy to
Protocol Format Use Case Used in Devices
Read?
FMB920,
Codec 8 Binary Most GPS devices ❌ No
FMB120
Codec Binary FMC130, FMx
Advanced data needs ❌ No
8E (Extended) series
Emergency / low
Codec 12 SMS / UDP ❌ No Older devices
network
Modern cloud/web FMC130, FMM
Codec 16 JSON / HTTP ❌ Yes
integration series
JSON / Topic- Routers, IoT
MQTT IoT communication ❌ Yes
based devices
❌ Yes All Teltonika
SMS Commands Configuration & fallback
(partly) devices

Great! Let's walk through everything step by step with diagrams, sample data packets, and
explanations so you truly understand how Teltonika devices send data.

STEP 1: Understanding the Flow (with Diagram)

Teltonika Data Sending Flow (Basic Diagram)
+-------------------+ +------------+ +------------------+
| Teltonika Device | --> | Internet | --> | Your Server |
| (FMB920, FMM130) | | (GPRS/4G) | | (Port: 5001 etc) |
+-------------------+ +------------+ +------------------+
| |
| Collects data (GPS, Ignition, Speed, etc.) |
| Packs data in a protocol (e.g., Codec 8) |
| Sends data to your server |
v v
� Latitude, Speed, Battery sent → � Server decodes and shows data on
UI

STEP 2: Sample Data Sent by Device (Using Codec 8 –

Binary Format)
Teltonika doesn't send plain English — it sends data like this:

000F01000000015F375FAE0100000001D5DDB7CE42E5C000011E00000000000000000002
This looks like random characters, but it's actually a binary data packet (called AVL
packet). You need to decode it using Teltonika's protocol guide.

STEP 3: Data Inside the Packet (Human Explanation)

Let’s say the binary packet above contains:

Field Meaning
Timestamp When the data was recorded
Latitude GPS position
Longitude GPS position
Speed Current speed
Angle Direction of movement
IO Elements Status like Ignition ON/OFF, Battery voltage, etc

STEP 4: Decode Binary Packet (with Python Example)

If you're a developer, you can use Teltonika Codec 8 decoder. Here’s a basic Python idea:

def decode_packet(hex_data):
# This is just an outline – real decoding needs Teltonika specs
bytes_data = bytes.fromhex(hex_data)
timestamp = int.from_bytes(bytes_data[0:8], byteorder='big')
latitude = int.from_bytes(bytes_data[8:12], byteorder='big') / 10000000
longitude = int.from_bytes(bytes_data[12:16], byteorder='big') /
10000000
speed = int.from_bytes(bytes_data[16:18], byteorder='big')

print(f"Time: {timestamp}, Lat: {latitude}, Lng: {longitude}, Speed:

{speed}")

To properly decode, you’ll need Teltonika's AVL Protocol PDF → Download Here

Alternative: JSON Format (Much Simpler – Codec 16)

Some newer Teltonika devices can send data in JSON over HTTP — much easier to
understand:

{
"imei": "352094089475122",
"timestamp": 1721040000,
"gps": {
"lat": 28.7041,
"lng": 77.1025,
"speed": 55
 },
"io": {
"ignition": 1,
"battery_voltage": 12.5
}
}

You can directly see and work with this on your server or cloud platform (like AWS, Azure,
etc).

STEP 5: What You Need on Your Server

1. Public IP or Domain → So your Teltonika device can send data to it.
2. Open Port (usually 5001) → Listening for incoming data.
3. Decoder Software → That reads Codec 8 / JSON packets and stores the data.
4. Dashboard or App (optional) → To display the GPS location, speed, etc.

Summary for Beginners

Topic Explanation
What is Sent? GPS data, speed, battery, ignition, etc.
How is it Sent? Using Protocols like Codec 8 (binary) or Codec 16 (JSON)
Via What? Internet (GPRS, 4G) or SMS (fallback)
To Where? Your server's IP & port
Do You Need to Decode? Yes, if using Codec 8. No, if using Codec 16 (JSON)
Can You See Live Data? Yes, with server + decoder + dashboard

Sure! Here's a very simple explanation of the entire paragraph, step by step, so even a
beginner can understand how a Teltonika GPS device communicates with a server.

STEP-BY-STEP: How a Teltonika Device Talks to a

Server

1. Device Connects to Server

When the GPS device connects to the server for the first time:
  It sends its IMEI number (a unique 15-digit ID, like a mobile phone number for the
device).

� Example IMEI: 356307042441013

➡� Sent as HEX: 000F333536333037303432343431303133

What does this mean?

 000F = length of IMEI = 15 bytes

 The rest = IMEI written in text format (ASCII bytes)

2. Server Responds

After the server receives the IMEI, it decides:

 � Accept the device → send back 01

 � Reject the device → send back 00

This response is 1 byte (just one small piece of data).

3. Device Starts Sending Location Data (AVL Data Packet)

If the server replies with 01 (accepted), the device will start sending AVL data packets,
which include:

 GPS location (Latitude, Longitude)

 Speed
 Time (timestamp)
 Ignition status
 GSM signal
 Battery voltage
 Many other small data points

4. Server Confirms It Got the Data

After receiving the data:

 The server must reply with a 4-byte number (like 00000002) to say how many data
records it received.

If the server doesn’t reply correctly or the numbers don’t match:

 The device resends the data again.

 Now Let’s See Real Examples (Made Easy)

Example 1: One Data Record

The device sends a packet:

0000000000000036...(lots of data)...0000C7CF

This means:

 Data size: 36 bytes

 Codec ID: 08 → it's using Codec 8 (binary format)
 Number of records: 01 (just one)
 Data: timestamp, location, speed, etc.
 CRC: Error-checking code (like a signature)

Data inside:

 � Date: June 10, 2019

 � Location: All 0s (means no GPS fix at that moment)
 � GSM Signal: 3
 � Ignition: ON
 ⚡ Voltage: 0x5E0F = 24175 (converted to volts)

� Server replies: 00000001

(Means: I got 1 record)

Example 2: Another Single Record

Another example where the device sends:

0000000000000028...(data)...F22A

 Same structure but fewer IO elements.

 This one still includes:
o Date/time
o Ignition status
o GSM signal
o External voltage

� Server replies: 00000001

 Example 3: Two Data Records in One Packet

Now the device sends two location records together:

0000000000000043...(data for 2 records)...252C

The two records contain:

 Record 1 → Date/time: June 10, 2019, 10:01:01 AM

 Record 2 → Date/time: June 10, 2019, 10:01:19 AM

� Server replies: 00000002 (Means: I got 2 records)

Structure of One AVL Data Packet (Simplified)

Part What It Means
00 00 00 00 Zero bytes (header)
00 00 00 36 Length of data
08 Codec ID (Codec 8)
01 Number of records
Data GPS, timestamp, IO values
CRC For data check (like a signature)

Summary in Simple Terms

Step What Happens
1�⃣ Device connects to server
2�⃣ Sends IMEI number
3�⃣ Server accepts or rejects device
4�⃣ If accepted, device sends GPS and other info
5�⃣ Server confirms how many records it got
6�⃣ If confirmation fails, device resends the data

Great question! Let's break it down in simple terms.

What does the server do after receiving IMEI?

When a Teltonika device connects to your server, it first sends its IMEI number (a unique
device ID, like a mobile phone number).
Now the server has to decide:
� Do I want to allow this device to send me data?
� Or should I reject it?

When to send 0x01 (accept):

The server sends 0x01 (just 1 byte) if the IMEI is valid and allowed.

This usually means:

 The IMEI is registered in a database or list.

 The device is authorized to send data.
 You want to start receiving AVL packets from this device.

Example code logic:

authorized_imeis = ["356307042441013", "352094089475122"] # list of

allowed devices

if received_imei in authorized_imeis:
response = b'\x01' # accept
else:
response = b'\x00' # reject

When to send 0x00 (reject):

The server sends 0x00 if:

 The IMEI is not in the list

 The device is not registered
 It’s an unknown or fake device

That tells the device: “You’re not allowed to send data here.”

Server Response Format

 Accept: b'\x01' (binary format, 1 byte)

 Reject: b'\x00'

⚠ Note: You must send this in raw binary, not as a string "01" or "00".

Simple Flow:
Device → IMEI → Server
Server checks IMEI in database
↳ Found? → Send 0x01
↳ Not Found? → Send 0x00

Great follow-up! Let's look at what to do when a new device connects and its IMEI is not
in your database.

Situation:
 A new Teltonika GPS device tries to connect to your server.
 It sends its IMEI number.
 Your server checks its database and does not find this IMEI.

You Have 2 Options (Based on Your Business Rule):

Option 1: Allow New Devices Automatically

If you want to allow all new devices:

1. Accept the IMEI (send 0x01)

2. Add the new IMEI to your database for future checks

Example (Python-style):

if received_imei not in imei_database:

# Accept the device
send(b'\x01')

# Store the new IMEI

imei_database.append(received_imei)
save_to_file_or_db(received_imei)

� Use this when you're okay with allowing any new device (e.g., during testing or initial
setup).

Option 2: Reject Unknown Devices

If you're strict and only allow registered devices:

1. Reject the IMEI (send 0x00)

2. Log the unknown IMEI for admin review

Example:
if received_imei not in imei_database:
send(b'\x00') # Reject

log("Unknown IMEI tried to connect: " + received_imei)

� Use this in production when security is important and you only want known devices.

Option 3: Ask Admin to Approve

You can also create a middle path:

 Log unknown IMEIs

 Alert the admin (e.g., send an email or store in “pending approvals” table)
 Let the admin decide whether to approve it later

Recommended Practice
Environment Best Action
Development/Test Allow and auto-add unknown IMEIs
Production Reject and notify/log for approval

Tip: How to Store IMEIs

You can store authorized IMEIs in:

 A simple text/CSV file

 A SQLite or MySQL database
 An online dashboard where you can approve/reject IMEIs

Summary
Situation What Server Should Do
IMEI is found Accept → send 0x01
IMEI not found, but you allow new devices Accept, add to DB
IMEI not found, and you are strict Reject → send 0x00, log it
Want admin control Log & wait for manual approval

Would you like a working Python code example for this full flow, including storing IMEIs
in a file or DB?
Just say the word!