// In progress · 2025–
FSAE data acquisition board
A 4-layer STM32H723 data acquisition board for the Formula SAE electric car — three FDCAN buses, inertial and GPS logging to SD, and an 802.11ah telemetry link. Schematic and layout in Altium; firmware not yet written.
Status
In progress, targeting next season’s car (EV5). The schematic and PCB layout are still being worked, and no firmware has been written yet. The board has not been fabricated — it is still in layout. Nothing on this page has been validated on hardware. The results section is empty because there are no measurements yet.
The requirement
Log inertial, positional and bus data on a common time base, on an FSAE chassis, and stay repairable by students during a competition weekend.
The commercial option is a MoTeC L120 or L180, which is what most teams run. The case for building instead: channel count and bus topology match this car, logging behaviour can be changed between sessions without vendor tooling, and the cost folds into a build the team is doing anyway.
Against that, a MoTeC L120 or L180 is a known quantity: a commercial logger sold with a warranty, vendor support, and field history in other cars. A self-built logger has none of that. If it fails during a dynamic event there is no fallback and no support line; the failure is the team’s to find.
Buying also moves whole problem classes off the team. Calibration, connector sealing, vibration survival, and EMC are the vendor’s responsibility on a MoTeC; on this board they become the team’s, each its own validation effort on hardware that is still unbuilt and untested. The logger also competes for the same scarce student-hours as the chassis, powertrain, and the rest of the electronics. That trade only pays off if the board is finished and works.
Design decisions
STM32H723VET6. Three independent FDCAN controllers, native SDMMC, and enough headroom to parse, timestamp and buffer at the same time.
Three FDCAN buses instead of one shared bus, so a high-traffic subsystem cannot delay safety-relevant frames.
BNO085 over SPI. The part runs its own sensor fusion, so the MCU is not spending cycles on an attitude filter. The interface is SHTP rather than a register map, so the driver had to be written from scratch.
GPS: Antenova M20050-1. NMEA parsed on the MCU. Timing comes from the PPS output, not from the message contents.
Power: TSR 1-2433E buck, diode-OR’d with a USB-C input so the board runs on the bench with the car unpowered.
Logging: SDMMC in 4-bit mode through FatFS, behind a ring buffer, so a slow card write does not stall acquisition.
Telemetry: 802.11ah HaLow — XIAO ESP32S3 with an FGH100M-H. Lower data rate than conventional Wi-Fi, longer range, which is the tradeoff a trackside link wants.
Service access. USB DFU behind a BOOT0 button, SWD test pads, and a CP2102N-class USB-UART bridge on USART1.
Firmware
Not written yet. STM32CubeMX has generated the STM32CubeIDE project — clock tree and peripheral initialisation for FDCAN, SDMMC, SPI and the timers — but no application code sits on top of it.
The planned architecture: a CanBus wrapper that dispatches from interrupt context to the
owning object, with CanLogger and GpsUart above it, and an IMU driver implementing SHTP
over SPI with multi-report parsing that latches TIM2 timestamps inside the ISR rather than in
the main loop.
What went wrong
FDCAN1 was first assigned to PA11 and PA12. On the STM32H723VET6 those two pins carry the
USB data lines, D- and D+. FDCAN1_RX/TX and USB_DM/DP are alternate functions multiplexed
onto the same physical pins, and a pin can be routed to only one alternate function at a
time — so FDCAN1 and USB could not both be brought out as the board was drawn. Both are
needed: USB for DFU service access, and FDCAN1 as one of the three CAN buses.
Caught in design review, before fabrication. FDCAN1 moved to PB8/PB9, which carry
FDCAN1_RX/TX with no USB overlap.
| Signal | Before | After | Note |
|---|---|---|---|
FDCAN1_RX |
PA11 |
PB8 |
PA11 = USB D- |
FDCAN1_TX |
PA12 |
PB9 |
PA12 = USB D+ |
Bring-up plan
No results yet — the board is not fabricated, so nothing below has been measured.
Planned bring-up, in power-on order:
- Power rails first. Verify the
TSR 1-2433Ebuck output and the USB-C diode-OR fallback before any downstream rail is energised. - FDCAN. Bring up traffic independently on each of the three buses.
- Time base. Check the PPS edge against the logged timestamp.
- SD logging. Measure sustained write rate under logging load, to check whether the ring buffer keeps up without stalling acquisition.
This section is replaced with measurements once the board is built.
Artifacts
The 3D view and the routed top and bottom copper are up top. Still to come, once the board is fabricated: photos of the bare and assembled board, the board in the car, and the power-tree and FDCAN schematic sheets.
