Personal / protocol engineering
Teltonika Telemetry Receiver
A standard-library Go receiver for FMC650-oriented AVL telemetry over TCP or server-authenticated TLS.
- Period
- Jun 2026
- Role
- Personal-project developer
- Delivery
- Lab deployment
Overview
Context before technology.
Codec 8 Extended decoding, CRC validation, durable raw journaling before acknowledgement, a fixed-capacity normalized-output queue, and lab routing shaped the receiver design.
Lab ingress and protocol
Durability before acknowledgement.
- 01
FMC650 tracker
Outbound plain TCP connection
-> - 02
Public Internet
Bidirectional packet path
-> - 03
Lab router
Public IP and inbound TCP forwarding
-> - 04
Nginx VM
TCP stream proxy in separate Proxmox guest
-> - 05
Receiver LXC
Go process in separate Proxmox guest
Addresses, ports, guest identifiers, device identifiers, and capture data are omitted. Optional server-authenticated TLS exists in source but was not deployed on this path.
- 01
Open TCP
Tracker opens a plain TCP connection through the lab ingress path.
- 02
Identifier admission
Length-prefixed numeric identifier is checked against optional allowlist.
- 03
Admission result
Receiver returns one-byte accept or reject result.
- 04
Read AVL packet
Receiver reads header, declared data field, and CRC field.
- 05
Validate and decode
Checks Codec 8 Extended, envelope counts, CRC, and exact record-byte consumption.
- 06
Append and sync
Complete packet receipt reaches authoritative raw JSONL before positive acknowledgement.
- 07
Acknowledge
Receiver writes four-byte accepted-record count; derived publication follows only after success.
Persistence failure prevents positive acknowledgement. ACK failure after raw commit can create duplicate receipts on tracker retry; exactly-once delivery is not claimed.
- Raw IO
Preserve received value
Keep AVL ID, width, and raw bytes.
-> - Profile
Match local contract
Configured AVL ID and expected transport fields
-> - Recover
Recover full CAN byte order
Only from received tracker value
-> - Verify
Fail-closed checks
ISO-TP, Mode 01 service, PID, width, formula, and range
-> - Derived
Expose or retain raw
Failure keeps diagnostics and leaves ACK unchanged
Receiver boundary
The receiver accepts FMC650-oriented AVL traffic over TCP, with optional server-authenticated TLS. It handles the device handshake and Codec 8 Extended packet framing without external protocol libraries.
It is a protocol-focused lab system, not a fleet platform or production device-management service.
Integrity before acknowledgement
Packet handling validates zero preamble, bounded declared length, Codec 8 Extended, equal envelope record counts, CRC-16/IBM, decoder success, and exact record-byte consumption before positive acknowledgement. Raw events are appended and synchronized before acknowledgement so derived-output failures do not erase the authoritative input record.
Manual CAN and OBD-II fields follow fail-closed handling. Derived records enter a fixed-capacity, non-blocking queue only after successful ACK; this bounds dispatch pressure, not output-file growth.
Deployment and limits
For lab testing, a physical tracker reached a public-facing lab endpoint over plain TCP through router forwarding and an Nginx stream proxy in a separate Proxmox VM, then the Go receiver in a separate Proxmox LXC. Addresses, ports, guest identifiers, device data, and captures are intentionally omitted.
Tests exist but the full suite was not run and one fixture is absent. Codec support is limited to Codec 8 Extended; optional TLS is server-authenticated rather than mutual TLS and was not the deployed tracker path.
Working set