Teltonika Codec 8: how sensor and CAN data reaches the platform

Why Teltonika, specifically?

Teltonika is a Lithuanian manufacturer and one of the most widely deployed names in fleet telematics worldwide; its FMB series and siblings are close to a default choice for many fleet operators and resellers. A large part of that reach traces back to an early engineering decision: documenting the protocol publicly and precisely, so any platform can implement it without special agreements. The protocol these devices speak when transmitting tracking data is Codec 8 — and its newer sibling, Codec 8 Extended.

Everything starts with a simple handshake: the device opens a TCP connection and sends its IMEI; the platform accepts or rejects it. After acceptance, AVL packets flow — the acronym stands for Automatic Vehicle Location — carrying everything the device has collected: positions, speeds, events, and sensor readings. Understanding what is inside those packets is not just a developer concern. A fleet manager who knows that the "fuel reading" arrives as a raw number rather than liters, and that "temperature" may come from a wired probe, from CAN, or from a wireless BLE sensor, makes better purchasing and installation decisions — and knows where to look when a reading seems wrong.

The protocol runs over both TCP and UDP: TCP is the common choice because its transport guarantees complement the acknowledgement contract we will meet shortly, while UDP appears in data-frugal configurations that accept lighter guarantees. Either way, the essence of the packet stays the same — what changes is the carrying envelope, not the content.

Anatomy of a Codec 8 packet

A Codec 8 packet is a disciplined structure you can read byte by byte:

• Preamble: four zero bytes announcing the start of a packet.
• Data field length: four bytes stating how much follows, so the platform knows where the packet ends before reading it.
• Codec ID: a single byte, 0x08, declaring the Codec 8 format.
• Record count: how many AVL records this packet carries — devices batch several records per transmission to save airtime.
• The records themselves, then the record count repeated at the tail as a cross-check, and finally a CRC-16 that exposes corruption.

Each AVL record, in turn, carries three layers:

• Time: eight bytes of milliseconds since 1970 GMT — enough precision to order rapid-fire events unambiguously.
• GPS element: longitude and latitude at seven decimal places, altitude, heading, satellite count, and speed — plus a record priority indicating urgency.
• IO elements: the heart of the matter — the event IO ID that generated the record (if any), a total element count, then groups ordered by value size: 1-byte elements, then 2-byte, 4-byte, and 8-byte. Each element is a simple pair: an ID, then a value.

Once the platform receives the packet and verifies its integrity, it replies with a 4-byte acknowledgement carrying the number of accepted records. If that number matches what the device sent, the device deletes the records from its memory and moves on; if not, it retransmits. This simple contract is what makes Teltonika data nearly impossible to lose even on intermittent networks: the device stores and retries until the platform confirms.

Note, too, that the device does not transmit on a blind fixed rhythm; its configuration decides when a record is generated: every so many metres, every turn beyond an angle threshold, every time interval, or on an event such as ignition on or off. A packet may therefore carry one urgent record — or dozens accumulated from an entire trip through a dead zone. A sound platform treats both cases with the same logic: decode, verify, acknowledge, then order by record time rather than arrival time.

Codec 8 Extended: when IDs ran out and values grew

The original Codec 8 was designed with a 1-byte IO ID — at most 255 addressable parameters — and values capped at 8 bytes. That was enough for the era of voltages, temperatures, and digital inputs, but it grew tight as data sources multiplied: CAN bus readings whose parameters proliferate by the dozen, wireless BLE sensors sending composite payloads, and diagnostic data that will not compress into 8 bytes.

Codec 8 Extended (codec ID 0x8E) answered with two decisive expansions: a 2-byte IO ID opening the door to thousands of parameters, and a new group of variable-length elements carrying values of whatever size is needed. Modern devices support both formats, and the choice is a configuration decision on the device itself.

The practical rule: if your fleet relies on the basics — position, speed, ignition — either format serves. If you read CAN or plan wireless sensors, Codec 8 Extended is the road, and what matters most is that your platform decodes both with equal fluency. One practical tip before rolling any configuration out fleet-wide: pilot it on a single vehicle and watch the monthly data volume — the difference between a frugal configuration and a chatty one can mean multiples in SIM consumption with no operational value in return.

From an IO ID to a meaningful reading

Here lies the gap where many projects stumble: an IO ID is just a number. The packet does not say "this is the reefer-box temperature"; it says "element number so-and-so has value so-and-so". Two devices of the same model with different configurations may send different element sets, and the same value may be millivolts needing division, a percentage, or a CAN value needing descaling. Without a deliberate translation layer, you end up with many numbers and little knowledge.

That is the job of Pixa's sensor abstraction layer: any raw parameter — from any of the 18 supported protocol families — can be declared as a sensor with a clear name, a conversion formula, and a calibration table where needed: weight, multi-zone temperature, doors, PTO, passengers, RPM, and more. Fuel is the complete example of the chain: the raw value passes through a multi-point calibration table that converts it to actual liters according to tank geometry, then through smoothing that absorbs slosh while the vehicle moves — becoming a sound basis for detecting fills and drains (theft) by volume, time, and place with an instant alert, and for comparing actual against standard consumption. The full path is described on the fuel management page.

Driver identity travels the same route: an iButton, RFID, or BLE card reader sends a raw identifier among the IO elements, and the platform resolves it into a known driver to whom the trip, behavior, and penalty points are attributed. Likewise wired and wireless temperature probes: multiple raw values become multi-zone temperature, each zone with its own name and its own independent rule.

A packet's journey through Pixa

When a Teltonika device reaches Pixa, its data follows a clear route: IMEI handshake and acceptance, then packet reception and CRC verification, then the acknowledgement with the accepted-record count — the contract that guarantees the device never deletes what the platform has not received. Each record is then pushed in real time over SignalR to the live tracking screen, calibrated sensor readings appear on the vehicle card, the alert rules feed on them with compound conditions and time windows, and they accumulate into 29 ready-made reports in Arabic and English. During installation and commissioning, the raw-data viewer shows IO elements exactly as they arrived — before any conversion — turning the diagnosis of an odd reading into minutes of inspection rather than guesswork. Device support tiers and lists live in the device guide.

That same contract is what protects your data in the worst conditions: a vehicle that spent hours inside a coverage-blocked warehouse comes back and uploads its accumulated records in one batch, and the trip completes in the log as if the outage never happened — without historical points ever mixing into the live position on screen, because ordering rests on the millisecond-stamped record time.

Running Teltonika hardware, or planning to read CAN and new sensors? Contact the Pixa team via the contact page to review your device configuration and bring calibrated readings onto the platform.