ADR-0001: Vehicle IoT Device Architecture

2.1 Microcontroller — ESP32-S3-DevKitC-1

Decision rationale: The ESP32-S3 includes a native TWAI (Two-Wire Automotive Interface) CAN 2.0B compatible hardware controller, eliminating the need for an external CAN controller IC. Deep sleep current (~8–20µA) enables battery-backed always-on operation.

2.2 Communications Module — Quectel BG95-S5

2.3 CAN Bus Transceiver — Adafruit CAN Pal (TJA1051T/3)

Decision rationale: The TJA1051T/3 is a pure transceiver — it works directly with the ESP32-S3's native TWAI hardware over simple TX/RX pins, requiring no SPI or external CAN controller. The Adafruit CAN Pal breakout was chosen over the Seeed Studio CAN Bus board (which includes an MCP2515 SPI controller) specifically to preserve use of the ESP32-S3's native TWAI hardware.

3.1 TN + NTN Strategy

A single Quectel BG95-S5 module handles both terrestrial (LTE) and non-terrestrial (satellite) communications. There is no separate satellite modem.

Failover logic is handled in firmware on the ESP32-S3 via AT commands to the BG95-S5.

3.2 LTE Band Coverage

Band 28 (700MHz APT) is non-negotiable for Australian/NZ rural coverage.

3.3 Satellite Coverage — Skylo NTN

SIM strategy — emnify SuperNetwork SatPlus (recommended)

MFF2 form factor rationale: Permanently soldered to the PCB — improved ingress protection, better vibration resistance, reduced failure points.

3.4 GNSS

The BG95-S5 includes integrated GNSS (GPS / GLONASS / BeiDou / Galileo / QZSS). No separate GPS module is required.

4.1 Dual-Path Transport Architecture

The device uses different transport protocols depending on which network path is active. MQTT is used exclusively on the LTE path. The NTN satellite path uses CoAP with binary-encoded minimal payloads.

4.2 Why Standard MQTT Is Not Suitable for NTN

4.3 NTN Payload Policy — Strict Scope Limit

On the NTN satellite path, only the following data categories will be transmitted. All other data is queued locally and transmitted when LTE connectivity is restored.

4.4 NTN Payload Design

Target NTN payload using CBOR binary encoding:

4.5 LTE Payload Design

On the LTE path, payloads are not MTU-constrained. Full telemetry is transmitted including all CAN bus data, OBD-II PIDs, GNSS, and device status. CBOR is recommended for production to reduce data costs.

MQTT topic structure (indicative):

4.6 Local Queuing During NTN Operation

When the device is operating on the NTN satellite path, CAN bus and vehicle telemetry data must be queued locally on the ESP32-S3 (in NVS or external flash) for transmission once LTE is restored.

Queue design considerations:

• Define maximum queue depth to prevent unbounded storage growth

• Apply a FIFO or priority eviction policy — recent data is more valuable than old data

• Timestamps must be preserved accurately — data transmitted after LTE restoration must reflect the time it was captured, not the time it was sent

• Queue must survive deep sleep cycles and power loss (stored in NVS, not RAM)

4.7 Backend Protocol Bridge

Both AWS IoT Core and HiveMQ support CoAP-to-MQTT bridging. A message metadata field (network path flag) identifies which path was used.

4.8 CoAP Protocol Rationale

5.1 Protocol Support

5.2 Initial Capability

Phase 1 (current): Read-only CAN bus listening. Target data:

• Engine on/off state

• Fuel level

• Vehicle speed

• GPS (via CAN OEM PIDs where available)

• Battery voltage

Phase 2 (future): Write capability to CAN bus. The TJA1051T/3 supports full bidirectional communication.

5.3 OBD-II Port Connection

For the consumer variant and all development work, a SparkFun OBD-II connector (DEV-09911) provides:

• CANH / CANL access (pins 6 and 14)

• 12V constant power (pin 16)

• Ground (pins 4 and 5)

6.1 Requirements

6.2 Battery Chemistry — LiFePO4

Decision: LiFePO4 (lithium iron phosphate), not LiPo.

LiFePO4 is mandatory for an unattended in-vehicle device in Australian conditions.

6.3 Power Architecture Block Diagram

6.4 Key ICs Under Consideration

6.5 Low Power Strategy

3GPP Power Saving Mode (PSM) must be configured on the BG95-S5 for extended battery operation.

6.6 Relay State on Power Loss

Decision: On complete power loss, relay must default to last known state stored in ESP32-S3 NVS (non-volatile storage), not a fixed open/closed state.

Rationale: For the fuel pump disable use case, a power interruption (including deliberate battery disconnection by a thief) must not automatically re-enable the fuel pump.

7.1 Specification

7.2 Isolation Rationale

The vehicle electrical system is a hostile environment — load dump spikes, inductive kickback from motors, and ground offsets are common. Optoisolation protects the ESP32-S3 from 12V-side events. This is mandatory.

8.1 Overview

8.2 Shared Core

Both variants share:

• Identical core PCB (ESP32-S3, BG95-S5, power management, CAN transceiver, fuel gauge)

• Identical firmware codebase

• Same OTA update infrastructure

• Variant detected at boot via hardware ID pin or carrier board register

8.3 OBD-II Passthrough (Consumer Variant)

The consumer variant should implement an OBD-II passthrough — a female OBD-II port that exposes all pins from the vehicle port, so the device can remain plugged in while a workshop tool or dealer scan tool is also connected.

9.1 Phased Approach

1. Phase 1 — Breadboard prototype: Validate all subsystems using dev boards and jumper wires before committing to PCB layout.

2. Phase 2 — First PCB (single board): Design a single 4-layer PCB containing all subsystems.

3. Phase 3 — Modular split: Once Phase 2 is proven, split into core module + variant-specific carrier boards.

9.2 Layer Stack-up (Minimum)

4-layer board is the minimum for this design:

9.3 Subsystem Separation Guidelines

9.4 Tooling

9.5 Hardware Versioning

From the first prototype, implement:

• A visible PCB version silkscreen (e.g. HW_REV: 1.0)

• A hardware version register readable by firmware at boot (GPIO strap pins or I2C EEPROM)

• A changelog tracking hardware revisions and firmware compatibility

10.1 Customer Tiers

10.2 Firmware Release Pipeline

10.3 OTA Update Requirements

OTA firmware updates are mandatory from day one, not a future feature.

• ESP32-S3 OTA via ESP-IDF dual partition (A/B) with automatic rollback on failure

• Update delivery via BG95-S5 LTE/satellite data channel

• Tier-based update scheduling

• Failed update must roll back to previous known-good firmware automatically

• OTA must function on both LTE and satellite (satellite bandwidth constraints mean update packages should be delta/incremental where possible)

11.1 Target Markets

11.2 Hardware SKU Strategy

Goal: One hardware SKU for all markets.

The BG95-S5 LATEA variant covers all target LTE bands globally. No regional hardware variants are required for the communications stack. Variant differentiation is Consumer vs Prosumer only, not regional.

12.1 Modular Core + Carrier Concept

The device is physically split into two parts:

• Core module — a self-contained enclosure housing all active electronics (ESP32-S3, BG95-S5, power management, CAN transceiver, fuel gauge). This is the certified radio device.

• Carrier enclosure — a variant-specific outer enclosure. Contains only passive connectors, wiring, antenna elements, and mechanical housing.

12.2 Certification Advantage

Separating the radio (BG95-S5) into the core module means:

• Only the core module requires radio certification (RCM / ACMA in AU/NZ, FCC in US, CE in EU)

• The BG95-S5 itself carries Quectel's own modular certifications

• Carrier enclosures contain no active radio components and do not independently require radio certification

• Hardware revisions to the carrier do not trigger re-certification of the radio

12.3 Enclosure Manufacturing Path

13.1 Overview

Antenna type is determined by the carrier enclosure variant, not the core module. The core module exposes U.FL / MHF4 coaxial ports for LTE and GNSS.

13.2 Consumer Variant — Internal Antenna

Recommended: Combined LTE + GNSS FPC (Flexible Printed Circuit) antenna, mounted adhesively on inside of enclosure lid.

13.3 Prosumer / Commercial Variant — External Antenna

Connector standard: FAKRA for production, SMA for development/early prosumer

FAKRA colour coding:

14.1 Immediate (Prototyping Phase)

• [ ] Procure OBD-II connector (SparkFun DEV-09911 from Core Electronics AU)

• [ ] Procure Adafruit CAN Pal transceiver (ADA5708 from Core Electronics AU)

• [ ] Wire ESP32-S3 DevKitC-1 ↔ BG95-S5 EVB via UART and test AT commands

• [ ] Wire ESP32-S3 ↔ CAN Pal ↔ OBD-II connector and validate TWAI receive

14.2 Near Term (Firmware)

• [ ] Implement basic TWAI receive and log raw CAN frames

• [ ] Identify target vehicle PIDs (fuel level, ignition state, speed)

• [ ] Implement BG95-S5 AT command driver in Rust (esp-idf-hal / esp-rs)

• [ ] Implement LTE → satellite failover logic with path detection

• [ ] Implement MQTT client for LTE path (esp-mqtt)

• [ ] Implement CoAP client for NTN satellite path (libcoap via esp-idf)

• [ ] Implement CBOR binary encoding for NTN payloads

• [ ] Implement local telemetry queue (NVS-backed) for CAN data during NTN operation

• [ ] Implement 3GPP PSM configuration on BG95-S5

• [ ] Implement ESP32-S3 deep sleep with timed wake

• [ ] Implement OTA update partition scheme

• [ ] Design and implement backend CoAP→MQTT bridge (evaluate AWS IoT Core or HiveMQ)

14.3 Commercial / Procurement

• [ ] Confirm BG95-S5 compatibility with emnify SatPlus — hard dependency before finalising PCB design

• [ ] Evaluate emnify SatPlus plan tiers against expected per-device data consumption

• [ ] Design emnify REST API integration for per-SIM chargeback

• [ ] Confirm BG95-S5 production availability and pricing at target volumes

• [ ] Investigate Australian RCM requirements for a vehicle-connected radio device

14.4 Hardware Design (PCB Phase)

• [ ] Complete breadboard prototype validation before starting PCB design

• [ ] Select and evaluate BQ25895 or BQ25798 charger IC

• [ ] Select and evaluate automotive buck converter (LM5165 / LM53635)

• [ ] Select LiFePO4 cell size for each variant

• [ ] Design 4-layer PCB in KiCad (single board first)

• [ ] Finalise core PCB dimensions before enclosure design begins

14.5 Enclosure & Antenna

• [ ] Engage RCM / EMC consultant to confirm certification strategy for core module

• [ ] Select combined LTE+GNSS FPC antenna for consumer carrier (evaluate Taoglas FXP73 or equivalent)

• [ ] Define core-to-carrier interface connector (evaluate Molex Micro-Fit 3.0)

• [ ] Define IP rating target for prosumer/commercial carrier enclosure (IP65 minimum)