The Vehicle Compatibility Problem Nobody Talks About
Every IoT telemetry pitch deck shows a clean diagram: vehicle → OBD-II dongle → cloud. The implication is that this path works for any vehicle. It doesn't, and the gap between that diagram and reality is where battery monitoring projects in African EV markets get stuck.
OBD-II is a standard that was originally designed for passenger car emissions diagnostics. The port is mandatory in the US market since 1996 and in Europe since 2001 — for cars. Electric motorcycles and three-wheelers, which dominate Africa's EV two-and-three-wheeler market, are not covered by the OBD-II mandate. Some manufacturers include an OBD-II port as a convenience feature. Others expose the CAN bus through a proprietary connector. Others don't expose bus access at all.
When we were designing SEM-1's hardware interface, we needed to know exactly what each of the major Africa-market EV models actually exposes. So we bought one of each — a Bajaj RE Electric, a TVS iQube S, and a Zembo Pikipiki — and opened them. Here's what we found.
Bajaj RE Electric: OBD-II Present, BMS Data Absent
The Bajaj RE Electric three-wheeler has a physical OBD-II port on the dashboard, which initially seemed promising. Connecting a standard ELM327 adapter confirmed the port is wired and responds to standard OBD-II PIDs. Bajaj has implemented the SAE J1962 connector and responds to Mode 01 (real-time data) requests.
The problem: the PID data exposed through the standard OBD-II interface is limited to vehicle speed, motor RPM, and basic fault codes. Battery-specific data — cell voltages, individual cell temperatures, state-of-charge, cycle count — is NOT exposed through the standard OBD-II PIDs. It lives on a separate CAN bus segment that communicates with the BMS, and that segment is not connected to the OBD-II port.
To access battery telemetry on the RE Electric, you need to tap the CAN bus directly. The BMS CAN bus runs at 500 kbps and uses the standard 11-bit CAN identifier frame format. The battery data frames are on IDs 0x301 (cell group voltages) and 0x302 (temperatures), which we identified through CAN frame logging and correlation with simultaneously measured load test values. Bajaj hasn't published these IDs — we reverse-engineered them.
The SEM-1 hardware has a dedicated CAN bus tap interface in addition to the OBD-II connector. For RE Electric installations, the SEM-1 installation guide specifies connecting the CAN tap leads directly to the BMS harness at a specific point under the rear seat panel. This requires a screwdriver and five minutes — it's not a plug-and-play installation, but it's not a mechanic job either.
TVS iQube S: Proprietary Protocol, Partially Documented
The TVS iQube S is one of the more technically interesting vehicles in the Africa-market EV two-wheeler space. TVS has built significant proprietary software infrastructure around the iQube — their SmartXonnect app uses Bluetooth to communicate with the vehicle's telematics control unit (TCU) and exposes battery state-of-charge, navigation, and vehicle diagnostics to the owner's phone.
The TCU also has a physical diagnostics port (not OBD-II standard — a 12-pin proprietary connector in a format TVS shares with several of their ICE motorcycle models) that communicates via a protocol TVS partially documented in their service manual. The service manual, obtainable from authorized dealers in India and Kenya, describes the diagnostic commands for fault code reading and clearing but doesn't document the battery monitoring commands.
Our approach for iQube battery monitoring is a combination method: we read what the Bluetooth TCU exposes (SOC, pack voltage as aggregate), and we tap the BMS CAN bus directly for the cell-level data that the TCU doesn't forward. The CAN bus on the iQube runs at 250 kbps, slower than the RE Electric, and the battery frame IDs differ. We mapped them through the same reverse engineering process.
One complication specific to the iQube: TVS pushes firmware updates to the TCU over the air. After one update in March 2025, the Bluetooth protocol changed in a way that broke our SOC read. We had to update the SEM-1 firmware to match. This is the risk of depending on Bluetooth data from a proprietary system — it changes without notice. Our SEM-1 firmware update path is designed to push protocol updates without requiring physical access to the module.
Zembo Pikipiki: Open CAN, Clean Data
Zembo is a Uganda-based EV mobility company that builds its Pikipiki electric motorcycle around a known BMS architecture — they use a CATL-derived cell pack with a Chargery BMS that communicates over a standard CANopen profile. The CAN bus is accessible via a 4-pin Deutsch connector near the rear battery compartment, and the CANopen object dictionary is partially documented in the Chargery BMS technical manual.
Of the three vehicles we analyzed, Zembo Pikipiki integration was the most straightforward. The CANopen Object Dictionary entries for cell voltages (objects 0x6800-0x6815 for the 22-cell pack), temperatures (0x6850-0x6851 for the two thermistors), SOC (0x6060), and cycle count (0x6062) are all accessible without reverse engineering. Connection is via the Deutsch connector with the appropriate adapter cable.
Zembo's open approach to diagnostics access reflects a deliberate fleet operator orientation in their business model — they want third-party tools to be able to work with their vehicles because their primary customers are fleet operators, not individual consumers. This is in contrast to TVS and Bajaj, whose primary market is individual consumer sales where proprietary diagnostics represents a service revenue stream. The business model shapes the technical architecture in ways that matter significantly for fleet monitoring.
What This Means for SEM-1 Installation
The SEM-1 has three connection modes, configurable via the setup app: standard OBD-II (for vehicles where battery data is accessible through the OBD-II port), CAN bus tap (for vehicles where battery data requires direct CAN bus access with a custom frame decoder), and CANopen (for vehicles using standard CANopen object dictionary addressing). Each mode requires a different physical connection and a different firmware configuration profile loaded at installation time.
The Stima installation guide documents the connection procedure for 14 Africa-market and Southeast Asia EV models. New models are added as we complete integration testing. If you have a vehicle model not currently on our supported list, contact engineering@stimaboda.org — we'll work through the integration with you and add it to the compatibility matrix.
The incompatibility landscape is the reason Stima builds its own hardware rather than relying on generic OBD-II readers. A generic OBD-II dongle would work for a subset of vehicles and provide incomplete battery data for most. The SEM-1's multi-mode connection architecture, combined with per-model firmware configuration profiles, is the only approach we found that provides consistent, complete battery telemetry across the heterogeneous vehicle mix that African EV fleet operators actually run.
Filed under: Hardware, Engineering · Back to Blog