Custom Low-Power Bike Computer
Designing a rechargeable custom PCB for GNSS ride logging, outdoor data display, low-power operation, onboard storage, and BLE connectivity.
I am designing a custom bike computer around a single-cell Li-ion battery, an nRF52840-based MCU/BLE module, GNSS, barometric altitude sensing, SPI flash, and a reflective memory LCD. The goal is to take the embedded system from schematic through PCB bring-up and firmware while treating battery life, RF integration, testability, and data integrity as first-class design constraints.
Schematic finalization. Major subsystems are designed, and I am completing MCU integration, physical controls, battery monitoring, debug access, and bring-up test points before beginning PCB layout.
Current work covers product-level requirements, system architecture, component and interface selection, schematic capture, power budgeting, and validation planning. PCB fabrication, firmware completion, and measured performance are future stages.
Bike computer block diagram / schematic overview / future PCB render
Replace with the project-level architecture graphic or an honest PCB render after layout is complete.
/images/projects/bike-computer/system-overview.webp - Project stage
- Schematic finalization
- Hardware scope
- Custom battery-powered PCB
- Next gate
- Schematic review + ERC
- Power-path charging
- Low-IQ regulation
- GNSS + BLE integration
- Multi-bus architecture
- RF-aware placement
- Designed-for-debug bring-up
A focused embedded V1
I scoped V1 around the parts of a commercial cycling computer that are most useful for embedded hardware and firmware learning: sensing, energy management, storage, outdoor display behavior, radio connectivity, and robust data capture.
- GNSS ride logging at 1 Hz
- Live speed, distance, and elapsed time
- Barometric altitude and cumulative elevation gain
- Physical-button user interface
- Reflective memory LCD
- Local nonvolatile ride storage
- BLE ride transfer through a custom GATT service
- USB-C charging for a single-cell Li-ion / LiPo battery
- Breadcrumb-style course following and off-course indication
- Battery monitoring
Scope principleThose features are intentionally outside V1. Keeping the application surface narrow protects the core goal: reaching real custom hardware with a credible power, sensing, storage, and bring-up story.
Power, compute, sensing & storage
The design separates energy management from the 3.3 V embedded domain and the boosted display rail, then gives each peripheral an interface chosen for its actual bandwidth and debug needs.
- GPIO
- Physical controls + LCD EXTCOMIN
- ADC
- Switched battery-voltage divider
- SWD
- Programming, reset, and debug
- Status
- Charger CHG / PGOOD inputs
- USB
- D+ / D− retained pending final scope decision
- Test
- Power rails and useful communication nodes
This is the intended architecture at schematic finalization. It documents design direction, not implemented firmware or a validated PCB.
Selection rationale, not just a BOM
Each part and interface was selected to reduce a specific system risk: RF implementation, outdoor readability, power, pin count, routing, bring-up, or data integrity.
u-blox NINA-B306-00B
Integrated radio keeps revision one achievable
The NINA-B306 combines an nRF52840 Cortex-M4F platform, BLE radio, and antenna in one module. That reduces first-revision RF risk compared with implementing a discrete 2.4 GHz antenna and matching network.
- MCU and BLE share one qualified module
- Antenna keepout and edge placement still constrain PCB floorplanning
- SWDIO, SWDCLK, reset, 3.3 V, and ground are being exposed for bring-up
- Focused RF projects can cover antenna design without making this board depend on a first discrete 2.4 GHz implementation
u-blox SAM-M10Q
Integrated antenna, with placement still treated as RF design
UART was selected for a direct bring-up and debug path. V1 does not need every optional interface, and backup-supply support remains an evaluated option rather than an automatic addition.
- Integrated GNSS antenna reduces external RF circuitry
- Module antenna and ground-plane guidance will drive early floorplanning
- UART test access is planned before layout
- Optional features are included only when they justify their power and routing cost
LS027B7DH01 memory LCD
Sunlight readability without e-ink update behavior
A reflective memory LCD provides very low static/display power while remaining responsive enough for changing ride metrics. That combination is a better fit than e-ink for this UI.
- SPI-style serial interface
- MCU GPIO provides EXTCOMIN polarity switching
- Dedicated display power rail
- FPC connector integrated at the board boundary
ST LPS22DF
Interface bandwidth matched to the sensor
The barometer provides altitude and elevation data without relying exclusively on noisier GNSS altitude. I²C is sufficient for its low data rate, saves MCU pins, and simplifies routing.
- I²C selected instead of unnecessary SPI bandwidth
- Local decoupling and bus pull-ups included in the schematic
- Preserves pins for display, storage, controls, and debug
- Enclosure and layout must expose the pressure port to ambient air
Winbond W25Q128JVSIQ
Local ride data before transfer
SPI NOR flash provides nonvolatile storage for ride logs before BLE transfer or later export. The hardware selection is complete; storage management and robust ride-file handling remain firmware work.
- Dedicated chip select on the SPI bus
- Data integrity is a system requirement, not an assumed property
- Shutdown behavior must not corrupt an active ride file
- No claim of completed GPX logging or BLE file transfer
NINA-B306 schematic
Add the completed MCU, SWD, status, control, and optional USB connections.
/images/projects/bike-computer/nina-b306-schematic.webp SAM-M10Q schematic and eventual PCB placement
Replace with the reviewed GNSS sheet, then add the antenna-aware layout view.
/images/projects/bike-computer/gnss-schematic-placement.webp Memory LCD schematic
Add the display connector, serial interface, EXTCOMIN, and power-rail schematic view.
/images/projects/bike-computer/memory-lcd-schematic.webp Designing around a real battery discharge curve
Power architecture is a primary design constraint, not a support circuit added after the digital design. USB-C feeds protected 5 V input power into a BQ24074 charger with power-path management, allowing the system load and battery charge path to be treated explicitly.
- 01Single-cell Li-ion / LiPo energy storage
- 02USB-C 5 V input with ESD / transient protection
- 03BQ24074RGTR charger with programmable current and power-path management
- 04Low-quiescent-current 3.3 V system regulation
- 05Dedicated boosted rail for the memory LCD
- 06Battery-voltage measurement into the MCU
- 07Charger CHG / PGOOD status monitoring where applicable
- 08Intentional physical power and off-state behavior
A Li-ion cell moves above and below the 3.3 V system rail as it discharges, so a buck-boost topology is attractive. The selection priority is low quiescent current across real operating modes—not output-current capability the board does not need.
The final 3.3 V regulator and 5 V boost device are not named here because schematic finalization has not yet established both choices. The architecture and selection criteria are defined; final part commitment is still open.
USB-C + charger + regulator schematic
Export the reviewed USB-C, BQ24074, 3.3 V, and display-rail schematic here.
/images/projects/bike-computer/power-architecture.webp Pre-hardware power budget
| Mode | Estimated current |
|---|---|
| Deep sleep | 20–100 µA |
| Idle UI | 2–3 mA |
| Ride | 12–15 mA |
| Ride + BLE advertising | 14–18 mA |
| BLE transfer burst | 12–20 mA |
- Ride mode
- <25 mA
- Idle
- <2 mA
- Sleep
- <100 µA
- Measured ride battery life
- ≥12 hours
All values above are pre-hardware estimates, not measurements. The budget is a design tool rather than a post-build calculation. The preliminary 2–3 mA idle estimate currently exceeds the <2 mA target, creating a concrete optimization problem for hardware and firmware bring-up.
Interfaces with a reason
The design uses multiple buses because the peripherals have different bandwidth, pin-count, power, boot-state, and debugging needs—not because one interface is universally best.
SAM-M10Q GNSS
Simple bring-up and readable debug path
LPS22DF barometer
Adequate bandwidth with fewer pins
W25Q128JV flash
Local high-capacity ride-log storage
Memory LCD
Serial pixels, chip select, and EXTCOMIN control
Physical buttons
Defined boot states and responsive input
Battery divider
Battery telemetry without continuous divider loss
NINA / nRF52840
Programming, breakpoints, and fault isolation
Phone / sensors
Ride transfer and future heart-rate input
Future host connection
Optional debug, firmware, serial, or file transfer
Testable system requirements
Every number below is a target with a planned validation method. None is presented as achieved, measured, or verified.
| Area | Current target | Planned validation |
|---|---|---|
| GNSS logging | 1 Hz with no dropped samples | Timestamp and sequence audit over a reference route |
| Position accuracy | ±5 m versus reference device | Repeated known-route comparison |
| Elevation gain | <10% error versus reference | Barometer log comparison over repeated route |
| UI response | <100 ms | Button event to display-update timing |
| Boot | <3 s to usable state | Power-on timing across repeated starts |
| BLE transfer | ≥100 kB, CRC-valid, no corruption | Known payload transfer and hash / CRC comparison |
| Off-course | ~20 m for 5 consecutive seconds | Injected and field route-deviation cases |
| Ride current | <25 mA | Bench current profile in defined ride mode |
| Idle current | <2 mA | Bench current profile in defined idle mode |
| Sleep current | <100 µA | Low-current measurement after confirmed sleep entry |
| Ride battery life | ≥12 h | Controlled full-charge runtime test |
| Shutdown integrity | No ride-file corruption | Repeated power interruption during file activity |
Designing revision one to be diagnosable
A major focus before layout is making the first PCB revision diagnosable. Beyond connecting the functional blocks, I am adding programming access, rail test points, communication test points, battery telemetry, and defined boot states so failures can be isolated during bring-up.
Program + control
- SWDIO
- SWDCLK
- Reset
- 3.3 V reference
- Ground reference
- Intentional boot-state pulls
Power visibility
- USB input
- Battery node
- 3.3 V rail
- Display rail
- Battery ADC
- CHG / PGOOD status
Interface access
- GNSS UART
- Useful SPI nodes
- Useful I²C nodes
- USB D+ / D− decision
- Physical control inputs
- Accessible ground points
Layout constraints
- Local decoupling
- USB protection
- BLE antenna keepout
- GNSS ground guidance
- Short power loops
- Pressure-port exposure
What is designed, open, and next
No arbitrary completion percentage: the useful distinction is between architecture already defined, schematic details currently being closed, and work that depends on a fabricated board.
Completed / largely designed
- Overall system architecture and V1 requirements
- Preliminary mode-based power budget
- USB-C charging and power-path architecture
- 3.3 V and display power architecture
- Memory LCD, barometer, SPI flash, and GNSS schematics
- Major component selection
Currently finalizing
- NINA-B306 MCU integration and physical buttons
- Power-button and off-state behavior
- Battery-voltage ADC measurement
- Charger status connections
- SWD interface and test points
- Final USB functionality
- Schematic review and ERC
Next
- PCB floorplanning and RF module placement
- Power layout, routing, and DRC review
- Fabrication and assembly
- Staged power and interface bring-up
- Peripheral firmware, logging, and BLE transfer
- Field testing and measured current characterization
PCB layout — add after layout is complete
Reserved for the real top and bottom layout once placement and routing are complete.
/images/projects/bike-computer/pcb-layout.webp Assembled PCB / bench bring-up photo
Reserved for a real assembly and staged power-up photo after fabrication.
/images/projects/bike-computer/bench-bringup.webp Measurements to make after fabrication
There are no physical results yet. This plan turns the requirements into bench and field checks to run only after assembly and staged bring-up.
Power
- Deep-sleep current
- Idle current
- GNSS tracking current
- BLE advertising current
- BLE file-transfer current
- Real battery runtime
GNSS
- Time to first fix
- Track deviation versus reference
- Dropout rate
- Repeated known-route comparison
Altitude
- Stationary pressure / altitude noise
- Drift
- Elevation gain versus reference
BLE
- Transfer throughput
- 100 kB+ file integrity
- CRC verification
- Reconnect behavior
System
- Boot time
- Button latency
- Dropped logging samples
- Safe-shutdown corruption testing
Power measurements / ride comparison plots
Reserved for measured current profiles, GNSS comparisons, and runtime results.
/images/projects/bike-computer/validation-plots.webp Interview-sized design conversations
The most valuable learning is in the tradeoffs: what to specify, what to simplify, what to expose for debug, and what evidence will be needed before calling the design successful.
- 01
Requirements before routing
Translate product ideas into electrical and system targets that can be checked after assembly.
- 02
Mode-based power design
Use a power budget before fabrication to identify which rails, peripherals, and firmware states deserve optimization.
- 03
Topology follows the battery
Select regulation around Li-ion discharge range and quiescent current instead of headline output current.
- 04
Power path is system behavior
Treat charging, system load sharing, and the off state as operating modes rather than a charger-IC black box.
- 05
Interfaces have tradeoffs
Choose SPI, I²C, UART, GPIO, and ADC from bandwidth, pin-count, power, routing, and debug needs.
- 06
Integrated RF still shapes layout
Plan module edge placement, antenna keepouts, ground guidance, and nearby circuitry before dense routing begins.
- 07
First revisions need observability
Add programming access, test points, telemetry, and known boot states while the schematic is still flexible.
- 08
Failure modes cross domains
Power loss, flash writes, BLE transfer, and ride-file structure must be designed together to prevent data corruption.
- 09
Scope protects completion
Defer maps and analytics so the project can reach PCB fabrication, bring-up, and measured field behavior.
The next meaningful proof points are a reviewed schematic, a layout that respects the power and antenna constraints, and a staged bring-up plan. Results will be added only after the board exists and the measurements have been performed.