OBD-II Telematics
Device Development
An OBD-II dongle that plugs into the J1962 port and turns engine data into a clean telematics feed. From the CAN front end and PID polling to DTC fault codes, VIN read, driver scoring, and sleep on ignition-off, the device reads the vehicle and protects its battery.
THE CHALLENGEThe Port Is Powered, the Data Is Not Free
The OBD-II port gives you a physical seat on the vehicle bus, but reading it well is harder than wiring an ELM327 and dumping PIDs. Most vehicles keep the port live with the key out, so a naive device drains the battery in a parked car. The bus speaks several protocols across model years, multi-frame responses need flow control, and a driver can pull a visible dongle out of the socket. This work matters when launching an aftermarket tracker or usage-based-insurance device, when an existing dongle is killing batteries or missing fault codes, or when driver behavior data the basic AT interface will not surface is required. The connector, the transport, the power logic, and the reporting are treated as one device and validated on real vehicles.
Sits inside the GPS tracking device engineering stack and shares hardware and platform building blocks with CAN Bus and J1939 Telematics.
WHAT'S INCLUDED
The Scope of the Device
OBD-II Dongle Hardware
The board behind the 16-pin J1962 connector carries a CAN transceiver for ISO 15765-4, plus the front end for ISO 9141-2 and J1850 PWM and VPW legacy buses where older vehicles need them. The same core holds the MCU, cellular modem, GNSS, and accelerometer, with the power input protected against the spikes and reverse conditions a vehicle bus throws at it.
PID Polling and Fault Codes
Mode 01 PIDs for engine RPM, vehicle speed, coolant temperature, and fuel level are polled on a cadence the application sets, stored and pending DTC fault codes are read over mode 03 and 07, and the VIN is pulled over mode 09. Multi-frame ISO 15765 responses are reassembled with proper flow control so long replies like the VIN come back complete.
Plug-and-Play or Hardwired
The device supports either install path. The plug-and-play variant self-fits into the OBD port for aftermarket and rental fleets, the hardwired variant takes fused power on a concealed harness for owned fleets that need it tamper-resistant. The board and firmware stay common, only the connector and power front end change.
Sleep on Ignition-Off
Ignition state is detected from bus voltage and the device parks in low-power sleep when the engine is off, holding standby current low enough to never flatten the vehicle battery. A voltage rise or a motion event from the accelerometer wakes it, so the device is reporting again before the trip starts.
TECHNICAL APPROACH
How the Vehicle Is Read
Transport and Protocols
The OBD transport runs on the host MCU, keeping ownership of request timing and flow control. An ELM327-style AT command interface is retained where a customer tool expects one, dropping to raw 11-bit and 29-bit CAN over the OBD pins where the AT layer will not surface the data. Protocol auto-detect picks ISO 15765-4, ISO 9141-2, or J1850 per the vehicle.
Power and Sleep Logic
Pin 16 battery voltage tells engine-running from key-off, engine running sits near 13.5 to 14.5 volts and a rested key-off near 12.2 to 12.6 volts. On a sustained drop the firmware halts PID polling, idles the modem, and sleeps the MCU at low milliamp standby. Voltage rise or accelerometer motion wakes the device so a parked car battery is never at risk.
Driver Scoring and Tamper
The onboard accelerometer scores harsh braking, acceleration, and cornering against tuned thresholds, fused with speed from the bus, so the fleet gets driver behavior the OBD PIDs alone will not show. Unplug and tamper are detected from a power-loss or bus-silence event and flagged so a pulled dongle does not go unnoticed.
INTEGRATION AND OUTPUTS
What the Device Hands Off
The device hands your platform a structured feed of position, decoded PIDs, fault codes, trip events, and driver scores over the cellular link, with the connector and power variant matched to the install. It ties into the GNSS and cellular work on the device side and into your reporting and fleet stack on the cloud side.
Decoded Telematics Feed
Position with RPM, speed, coolant temperature, fuel level, and odometer where available, plus DTC fault codes and VIN, decoded and reported on the cadence the application sets so your backend stores values, not raw bytes.
Trip and Driver Events
Ignition-on and ignition-off trips bounded by the voltage logic, harsh-event flags from the accelerometer, and tamper or unplug alerts, ready for usage-based insurance scoring and fleet behavior dashboards.
Provisioned Hardware
The dongle in its plug-and-play or hardwired form, provisioned with the protocol map for the vehicles you target and the proven sleep thresholds, so every unit reads the bus and protects the battery the same way in the field.
FAQ
Common Questions
Should the device be plug-and-play or hardwired?
It depends on who installs it and who owns the vehicle. A plug-and-play dongle into the J1962 connector takes seconds, needs no installer, and suits self-fit aftermarket and rental fleets. The tradeoff is that it is visible, a driver can unplug it, and it draws from a port that some OEMs keep live on ignition-off. A hardwired install hides the device, takes power from a fused circuit, and is harder to tamper with, but it needs a technician and a known harness. The same core board serves both, with only the connector and power front end changing.
How is the device stopped from draining the vehicle battery?
The OBD-II port stays powered on most vehicles even with the key out, so a device that polls continuously will flatten a parked battery in days. Ignition-off is detected from voltage, the engine running raises bus voltage to roughly 13.5 to 14.5 volts and a key-off rests near 12.2 to 12.6 volts. On a sustained drop the firmware stops PID polling, drops the modem to a low-power state, and parks the MCU in sleep so the standby draw sits in the low milliamp range. A motion or voltage-rise event wakes it back up.
Why not use an off-the-shelf ELM327 clone?
An ELM327 AT command bridge is fine for reading a handful of mode 01 PIDs over a serial link, but it hides the raw bus and gives no control over timing, sleep, or the modem. For a telematics product the OBD transport runs on the host MCU, which keeps ownership of the request cadence, the flow control on multi-frame ISO 15765 responses, the wake and sleep logic, and the cellular reporting. An ELM327-style command interface is retained where a customer tool expects one, dropping to raw 11-bit and 29-bit CAN where the AT layer will not surface the data.
Which vehicles will the device read?
Every car and light truck sold for the US market since 2008 uses ISO 15765-4 CAN on the J1962 connector, so that is the primary transport. Older or imported vehicles may use ISO 9141-2, KWP2000, or J1850 PWM and VPW, supported on the same connector with the right transceiver and protocol auto-detect. Standard mode 01 PIDs, mode 03 and 07 fault codes, and the VIN over mode 09 are read, and where a make exposes manufacturer-specific PIDs they are added per the vehicles you target.
Building an OBD-II Telematics Device?
Share the vehicles you target, the install path, and the data you need to get a tailored approach for the dongle, the PID and DTC reads, and the sleep logic that protects the battery on real cars.
Schedule a Free Consultation