If you've ever had to maintain firmware for more than 5 GPS tracker SKUs simultaneously, you know the pain. Different pin assignments, different peripherals, different wiring harnesses, different protocol parsers on the platform side.
I've been designing IoT tracking hardware for over 20 years, shipping to 100+ countries. The pattern that finally broke the cycle for us was modular I/O: one base PCB, one connector, swappable wiring harnesses that determine the device's function.
This post walks through how we allocate a 9-pin connector across 6 hardware modules.
The Problem: SKU Sprawl
A typical telematics provider needs hardware for:
- Basic fleet tracking (GNSS + ACC + relay)
- Cold chain (temperature/humidity probes)
- Vehicle security (iButton driver auth + immobilizer)
- Driver safety (SOS panic button)
- E-vehicle tracking (48V input)
- Cargo monitoring (BLE beacon scanning)
In a fixed-function world, that's 6 separate products. Each with its own PCB revision, firmware branch, wiring diagram, and platform integration.
The fleet management market hit $27 billion in 2025 growing at ~17% CAGR. More deployments = more use cases = more SKUs = more pain.
The Solution: 9-Pin Modular Architecture
Reserve fixed pins for universal functions. Dedicate a modular zone for swappable modules.
Pin Function Type Notes
─── ───────────────── ──────── ──────────────────────────────
1 Power In (9-48V) Fixed Wide voltage, no converter
2 GND Fixed Common ground
3 ACC Detection Fixed Ignition state
4 Module Pin A MODULAR Signal / Data+ / GPIO-1
5 Module Pin B MODULAR GND / Data- / GPIO-2
6 Module Pin C MODULAR Extended I/O (3-wire modules)
7 Module Pin D MODULAR Extended I/O (4-wire modules)
8 Relay NO Fixed Engine cut - normally open
9 Relay COM Fixed Engine cut - common
Pins 1-3 and 8-9 never change. Pins 4-7 are the modular zone — a 4-wire bus that accepts 6 different pre-terminated harnesses.
The Six Modules
Module 1: SOS Button
Pin 4: Button signal (pulled high, active low)
Pin 5: Button GND
Pin 6: NC
Pin 7: NC
Simple momentary switch. Firmware debounces, generates priority alarm with coordinates. Used in taxi and ride-hailing fleets.
Module 2: Backup Battery
Pin 4: Battery V+ (3.7V LiPo)
Pin 5: Battery GND
Pin 6: Charge enable (from base PCB)
Pin 7: NC
2-4 hour backup after main power cut. Critical for anti-theft — if someone disconnects the vehicle battery, the tracker keeps reporting.
Module 3: GPIO Expansion
Pin 4: Digital Input 1 (door sensor, PTO, fuel switch)
Pin 5: Digital Input 1 GND
Pin 6: Digital Input 2
Pin 7: Digital Input 2 GND
Two opto-isolated digital inputs. Turns the tracker into a light telematics controller.
Module 4: iButton / Electronic Key
Pin 4: 1-Wire Data (Dallas protocol)
Pin 5: 1-Wire GND
Pin 6: LED indicator (registered key = green)
Pin 7: LED GND
Driver touches registered iButton to reader. Unregistered key → relay fires → engine immobilized. Used in rental fleets and construction equipment.
Module 5: BLE Gateway
Pin 4: UART TX (from BLE module)
Pin 5: UART RX (to BLE module)
Pin 6: BLE VCC (3.3V regulated from base)
Pin 7: BLE GND
Bluetooth 2.4 GHz scanner. Detects BLE beacons for driver proximity, cargo tags, or environmental sensor beacons inside a reefer.
Module 6: Temperature & Humidity Probe
Pin 4: 1-Wire Data (DS18B20 or similar)
Pin 5: Probe GND
Pin 6: Probe VCC (3.3V)
Pin 7: NC (or second probe data for dual-zone)
Wired external probe. Threshold alarms configured via platform commands. Reports in telemetry stream alongside GPS data.
Power Budget
Here's where it gets real. The base unit + cellular modem + GNSS typically draws 50-80mA active, <5mA sleep. Each module adds:
| Module | Active (mA) | Sleep (mA) | Notes |
|---|---|---|---|
| SOS | ~0 | ~0 | Passive switch, no quiescent draw |
| Battery | 0 (net saver) | 0 | Provides power, doesn't consume |
| GPIO | <1 | <0.1 | Opto-isolator bias current |
| iButton | <1 | <0.5 | 1-Wire pull-up only |
| BLE | 8-15 | <1 | Scanning interval dependent |
| T&H Probe | 1-3 | <0.5 | Sampling interval dependent |
BLE is the most power-hungry module. If you're designing for long-interval reporting (e.g., once per hour), the BLE scan window becomes your main power lever. We typically scan for 2 seconds every 30 seconds in normal mode, and extend to 10-second scans only when the accelerometer detects motion.
Firmware Auto-Detection
The firmware needs to know which module is connected without user configuration. Two approaches:
Resistor ID (simple): Each harness includes a resistor divider between Pin 6 and Pin 7 that produces a unique voltage. The MCU reads this ADC value at boot → module type determined.
// Simplified module detection
uint16_t adc_val = read_adc(MODULE_ID_PIN);
if (adc_val < 200) module = MODULE_SOS;
else if (adc_val < 600) module = MODULE_BATTERY;
else if (adc_val < 1000) module = MODULE_GPIO;
else if (adc_val < 1400) module = MODULE_IBUTTON;
else if (adc_val < 1800) module = MODULE_BLE;
else module = MODULE_TEMP_HUMIDITY;
Protocol probe (robust): At boot, firmware sends a query on Pin 4 and checks for expected responses — UART ACK for BLE, 1-Wire presence pulse for iButton/T&H, high impedance for SOS. More robust but takes 200-500ms longer at boot.
We use resistor ID for production and protocol probe as a fallback validation.
Protocol Layer: Module-Aware Packets
Every data packet includes a module_id field so the platform knows which data fields to expect:
{
"device_id": "TK-0044712",
"timestamp": "2026-04-16T12:00:00Z",
"lat": 22.5431,
"lng": 114.0579,
"speed_kmh": 45,
"acc": true,
"module_id": 6,
"module_data": {
"temp_c": 3.2,
"rh_pct": 68,
"alarm": null
}
}
One protocol parser on the platform side. The module_id field tells it which module_data schema to expect. No more maintaining 6 separate device integrations.
Lessons Learned
1. Don't skimp on the modular pin count. We started with 2 modular pins and hit limits immediately with BLE (needs UART TX/RX + power + GND = 4 wires). Four modular pins is the minimum for a useful modular zone.
2. Wide voltage (9-48V) is non-negotiable. The moment you limit to 12-24V, you lose e-scooter, golf cart, and forklift markets. Those are growing fast.
3. Relay with safety interlock. A remote engine cut that activates at highway speed is a liability nightmare. Implement a speed gate (e.g., >20 km/h = queue the cut, execute only when speed drops below threshold).
What's Your Approach?
I'm curious how others are handling multi-function tracker design. Are you using modular connectors, or still maintaining separate SKUs? Have you tried hot-swappable modules (detect changes without reboot)?
If you're working on similar hardware architecture problems, I'd be happy to compare notes.
This article was written with AI assistance for research and drafting. The architecture recommendations are based on 20+ years of IoT vehicle tracker design experience.
