Data Logger

flux

I’m blocked again because the account has no available ACUs, so I can’t continue executing or verifying changes right now.
Completed in this session
  • Added the main schematic parts: ESP32-S3-WROOM-2, automotive 5V buck, 3.3V LDO, CAN transceiver, DS3231 RTC, OBD2, USB-C, microSD, JST-PH expansion ports, protection parts, buttons, LED, passives, inductors, and decoupling.
  • Wired the vehicle input path through fuse → switch → P-MOS reverse protection → TVS/filter → buck regulator.
  • Wired the 5V buck output, 3.3V LDO, major decoupling, ESP32 power, CAN power, RTC power, microSD power, and grounds.
  • Corrected the buck inductor to 4.7µH / ≥2.5A Isat target based on the LMR50410 datasheet.
Still to do once ACUs are available
  • Finish wiring USB-C, CAN/OBD2 signals, microSD SPI, I2C RTC/Port A, UART Port B, ADC Port C, LED, reset/boot/user buttons, and DS3231 NC/VBAT handling.
  • Run ERC/design review and fix any connection issues.
  • Update firmware starter, bring-up, and regulatory/automotive notes.
A

apx272

finish this project

flux

I’ll finish the remaining schematic wiring, verify the design, and update the key project docs with any open risks or bring-up notes.

flux

Finished the schematic phase: USB-C, CAN/OBD2, RTC/I2C, microSD, UART, ADC, buttons, LED, power, and no-connect handling are wired, and the checked ERC categories are clean.
Created docs:
Open items before layout/manufacturing:
  • Verify OBD2 connector mechanical gender/fit.
  • Review 3.3 V LDO thermals under ESP32 + microSD + WiFi load.
  • Replace/approve the provisional P-channel MOSFET with an automotive-qualified part if robustness matters.
Suggested next steps:
  1. Set board size, stackup, and layout rules.
  2. Place components with automotive/USB/CAN/antenna constraints.
  3. Route the PCB and clear DRC/airwires.
Layout and fixes
Start PCB layout
Verify OBD2 fit
Review LDO thermals
Replace MOSFET
Sign up to send

Files

Pins

Symbol

Layout

3D View

Project Specification — ESP32-S3 OBD2 Data Logger
Project Overview
Status: Draft schematic capture.
Design an automotive OBD2 data logger using an ESP32-S3-WROOM-2 module. The board logs CAN/OBD2 data to microSD, exposes USB-C for native ESP32-S3 USB programming/data, includes a DS3231 RTC, and provides three JST-PH 2.0mm expansion ports.
Intended Use
Prototype/hobbyist automotive data logger connected to an OBD2 port in a 12V vehicle electrical environment, with provisional 24V tolerance goals. Not certified for safety-critical vehicle control.
What the Device Should Do
  • Accept nominal 12V automotive input and be designed toward 12–24V tolerance.
  • Protect against reverse polarity, load-dump/surge, and ESD on exposed ports.
  • Generate 5V by buck conversion, then 3.3V by LDO for ESP32 and peripherals per the request, with LDO thermal risk tracked.
  • Communicate on CAN via OBD2 connector pins.
  • Store logs to microSD in SPI mode.
  • Maintain timestamps using a DS3231 RTC on I2C.
  • Provide USB-C device interface using ESP32-S3 native USB D−/D+ on GPIO19/GPIO20.
  • Provide status LED and user button.
Main Features
  • ESP32-S3-WROOM-2 Wi-Fi/BLE module
  • Robust automotive input path: switch, fuse/current limiting, reverse-polarity P-channel MOSFET, TVS, damped LC input filter
  • 5V buck regulator followed by 3.3V LDO
  • CAN transceiver with CAN TVS protection
  • USB-C sink/device port with CC pull-downs and USB ESD protection
  • microSD card slot in SPI mode
  • DS3231 RTC
  • JST-PH 2.0mm expansion: I2C, UART, ADC
System Architecture
Diagram



  
    
  
  
    
  































OBD2 / Vehicle node_12V-24V
Fuse or PTC
Physical Power Switch
Reverse Polarity P-MOSFET + Gate Clamp
Automotive Input TVS
Damped Input LC Filter
5V Buck
3.3V LDO
ESP32-S3-WROOM-2
CAN Transceiver
CAN TVS
microSD SPI
DS3231 RTC
USB-C Native USB
JST Expansion Ports
Hardware Subsystems
Power
  • Input: OBD2/vehicle 12V nominal, with provisional 24V support target.
  • Protection: fuse/PTC, physical switch, P-channel MOSFET reverse protection with gate-source clamp, automotive TVS, damped LC input filter.
  • Regulation: 5V buck converter, then 3.3V LDO.
  • Open risk: 5V→3.3V LDO thermals may be excessive at sustained ESP32 + microSD current.
Compute / Wireless
  • ESP32-S3-WROOM-2 module. Must preserve antenna keepout during layout.
  • Boot/reset support required: EN pull-up/RC, BOOT GPIO0 access, strapping pin care.
USB-C
  • Device/sink USB-C port.
  • CC1/CC2 each require independent 5.1kΩ pull-down.
  • D− connects to GPIO19; D+ connects to GPIO20.
  • Add ESD protection on D+/D− and series placeholders.
CAN / OBD2
  • CAN transceiver connected to ESP32 TWAI TX/RX pins.
  • CANH/CANL routed to OBD2 pins 6 and 14.
  • Dedicated CAN TVS on CANH/CANL.
  • Termination is optional/DNI only because OBD2 loggers are normally not bus endpoints.
Storage
  • microSD card slot in SPI mode with 3.3V supply, local bulk/decoupling, and signal integrity placeholders.
RTC
  • DS3231 RTC on I2C bus, shared with Port A.
Expansion Ports
  • Port A I2C: 3.3V, GND, GPIO21 SDA, GPIO22 SCL.
  • Port B UART: 3.3V, GND, GPIO16 RX, GPIO17 TX.
  • Port C ADC: 3.3V, GND, GPIO1 ADC1, GPIO2 ADC2. This corrects the pasted GPIO34/GPIO35 request because those are not ESP32-S3 ADC pins.
Interfaces and Connections

Table

InterfaceNets / PinsNotes
Vehicle powerOBD2 pin 16 and GND pins 4/5Protected input path
CANOBD2 pin 6 CANH, pin 14 CANLTVS-protected
USB-CVBUS, GND, CC1/CC2, D+/D−Sink/device only; no USB backfeed unless intentionally added
I2CGPIO21 SDA, GPIO22 SCLDS3231 + Port A, one pull-up pair
UARTGPIO16 RX, GPIO17 TXPort B
ADCGPIO1, GPIO2Port C; protect and define max voltage
LED/ButtonGPIO12 LED, GPIO13 buttonUser interface
Power and Runtime Expectations
Powered from vehicle/OBD2 supply. No battery operation specified. Design target is continuous operation while vehicle power is present.
Power Tree and Power Budget
See power-budget project file. Initial design target: 3.3V rail ≥600mA peak, 5V rail ≥1A capability, input path ≥1.5A design margin.
Manufacturing and Assembly Expectations
  • Automotive-grade/AEC-qualified parts preferred for protection and CAN/power path where available.
  • SMD assembly assumed.
  • Use automotive-temperature components where possible.
Firmware-Relevant Hardware Requirements
  • ESP32-S3 native USB for programming/log download.
  • I2C DS3231 initialization.
  • SPI microSD initialization.
  • CAN/TWAI driver configuration.
  • GPIO status LED and user button.
Physical Design Expectations
  • Place power/protection components near vehicle input.
  • Keep CANH/CANL grouped and away from noisy switching nodes.
  • ESP32 antenna at board edge with copper keepout.
  • Use adequate width for 12V input path and high-current 5V path.
Important Design Decisions
  • P-channel MOSFET selected over a series diode for reverse protection to reduce heat and voltage drop; AEC-qualified P-FET availability remains open.
  • USB-C is configured as sink/device only, not USB-PD.
  • 3.3V is generated by an LDO after 5V buck per request, despite thermal concerns.
  • CAN termination is not permanently populated for OBD2 usage.
  • PORT C ADC pins changed from GPIO34/GPIO35 to GPIO1/GPIO2 because ESP32-S3 GPIO34/GPIO35 are not valid ADC pins.
Assumptions
  • SMD prototype/assembly is acceptable.
  • OBD2 connector may be represented by the available library OBD2 connector pending mechanical gender verification.
  • USB is used for data/programming, not primary power.
  • The board is a logger/diagnostic tool only and does not control vehicle safety functions.
Change Notes
  • Initial requirements captured from pasted text on 2026-07-04.
  • ADC port mapping corrected for ESP32-S3 after independent review.

  • Project Overview

  • Intended Use

  • What the Device Should Do

  • Main Features

  • System Architecture

  • Hardware Subsystems

  • Power

  • Compute / Wireless

  • USB-C

  • CAN / OBD2

  • Storage

  • RTC

  • Expansion Ports

  • Interfaces and Connections

  • Power and Runtime Expectations

  • Power Tree and Power Budget

  • Manufacturing and Assembly Expectations

  • Firmware-Relevant Hardware Requirements

  • Physical Design Expectations

  • Important Design Decisions

  • Assumptions

  • Change Notes