Built the first-pass RoadLog ELD Vehicle Module schematic and renamed/documented the project. It now contains 84 components and 50 nets, including protected 12/24 V truck power, BLE compute, J1939 CAN, legacy J1708 hardware, FRAM event storage, debug/service connections, indicators, and test provisions.
The Project Specification records the phone-first architecture, initial power budget, offline resilience, fleet-plugin direction, and the boundary between this board and full FMCSA compliance.
Open items
Independently inspect the executor’s completed wiring and resolve any ERC/connectivity findings.
Confirm every automotive protection and power-stage rating against its selected-part datasheet.
Validate J1708 behavior and the ignition/tamper-event sensing path.
Create firmware pin mapping, secure event-storage behavior, and the mobile/cloud compliance specification.
Complete schematic review before moving to PCB placement and routing.
FMCSA compliance still requires the complete app/cloud system, data-transfer workflows, malfunction handling, documentation, testing, self-certification, and registration.
RoadLog is a low-cost vehicle interface for an owner-operator electronic logging device (ELD). It reads truck engine data, transfers records to the driver's phone or tablet over Bluetooth, and buffers events locally during temporary phone disconnects. The hardware is one part of an FMCSA-compliant system; compliance also depends on app behavior, records, transfer methods, security, testing, documentation, and self-certification.
Intended Use
Retrofit module installed in a commercial truck and paired with the driver's phone/tablet.
Initial market: owner-operators; optional software plugins later support fleet dispatch, maintenance, documents, and remote administration.
First revision is a proof-of-concept/engineering validation board, not a finished certified ELD.
What the Device Should Do
Detect vehicle motion and engine operating state from the vehicle data bus.
Capture required engine-derived information with timestamps.
Maintain a local append-only event buffer when the phone is disconnected.
Synchronize securely to an Android/iOS application over Bluetooth Low Energy (BLE).
Recover cleanly from vehicle cranking, load dump, brownouts, and abrupt power loss.
Support firmware update, diagnostics, and manufacturing test.
Main Features
Phone/tablet is the sole user interface, network connection, and location source in this cost-optimized revision.
BLE microcontroller/module.
J1939 CAN interface; legacy J1708/RS-485-style interface included where practical for older trucks.
Nonvolatile storage for disconnected event buffering.
Status indicators and service/programming access.
Expansion/service header for future fleet accessories, not an unprotected external plugin bus.
System Architecture
Diagram
Hardware Subsystems
Vehicle power: protected nominal 12 V/24 V truck input, reverse-polarity and transient protection, wide-input conversion to logic power.
Compute/BLE: qualified BLE-capable MCU or module with secure boot/update support and sufficient memory.
J1939: protected CAN transceiver connected to vehicle CAN-H/CAN-L; no fixed 120 ohm termination because the module attaches as a stub to an already terminated vehicle bus.
J1708: protected legacy differential interface for older vehicles, implemented only with a verified compatible physical layer.
Storage: high-endurance nonvolatile memory sized for event buffering and audit metadata.
Service: debug/programming connection, reset/boot controls, and restrained status indication.
Interfaces and Connections
Truck connector inputs: battery, ground, J1939 CAN-H/CAN-L, optional J1708 A/B, and ignition sense if available.
BLE link to phone/tablet.
Internal service/debug connector.
Reserved low-voltage expansion signals for future accessories.
Power and Runtime Expectations
Powered from the vehicle; no user-serviceable battery in the first revision.
Must tolerate 12 V and 24 V systems and automotive transients through appropriately rated protection.
Low parked-current target to avoid draining the vehicle battery.
Select the 3.3 V converter for at least 500 mA continuous output with transient margin. At 9 V minimum operating input and 85% conversion efficiency, a 400 mA peak at 3.3 V reflects to about 173 mA at the protected vehicle input, excluding protection leakage. Final values must be replaced with datasheet maxima before production release.
Manufacturing and Assembly Expectations
Standard SMT assembly with automotive-temperature-rated active parts where available.
Prefer readily sourced components and a two- or four-layer PCB suitable for low-volume prototypes.
Include test access for input power, regulated rail, reset, debug, and both vehicle buses.
Firmware-Relevant Hardware Requirements
BLE pairing/bonding, encrypted characteristics, monotonic record sequencing, checksums, and authenticated firmware update.
Brownout-safe writes and recovery after abrupt power loss.
Store enough metadata to distinguish engine state, motion state, odometer/engine-hours inputs, diagnostic faults, connection changes, and synchronization status.
Phone app provides location, driver interaction, records display, certification prompts, roadside display/transfer workflows, and cloud connectivity.
Physical Design Expectations
Compact enclosed dongle or short-cable module near the truck diagnostic connector.
Locking/strain-relieved vehicle harness preferred over placing a large enclosure directly on the diagnostic socket.
Automotive temperature, vibration, ESD, and transient environment must guide enclosure and PCB release testing.
Important Design Decisions
Phone/tablet connectivity and GPS only; no modem or standalone GNSS in revision one.
Owner-operator workflow first; fleet capabilities are software plugins rather than mandatory hardware cost.
Local buffering remains in hardware to prevent data loss during phone disconnects.
The prototype will prioritize J1939 and preserve a path for legacy vehicle support.
Compliance Boundary
The PCB alone cannot be called FMCSA compliant. A deployable ELD must implement and validate the applicable 49 CFR Part 395 Appendix A functional requirements, records, malfunction/diagnostic behavior, data transfer, driver accounts, edits/annotations, security, user documentation, and FMCSA self-certification/registration. Location sourced only from the phone creates an availability and tamper-resistance risk that must be addressed in the complete system design and test evidence.
Assumptions
Initial hardware connects to common heavy-truck diagnostic wiring through a replaceable harness.
The phone normally remains with the driver and grants Bluetooth/location permissions.
Cloud and mobile software are separate workstreams.
Exact connector pinout and mechanical form will be selected after target truck generations are prioritized.