Custom Low-Power Bike Computer
A routed, rechargeable custom PCB for GNSS ride logging, outdoor data display, onboard storage, BLE connectivity, and explicit low-power operation.
I designed and routed 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 project has moved from architecture and schematic capture through PCB layout and is now in hardware bring-up and subsystem testing, with battery life, RF integration, testability, and data integrity treated as first-class constraints.
PCB design and routing are complete. I am now in the testing phase: bringing up the power rails and programming interface first, then checking the GNSS, barometer, flash, display, controls, and BLE path before field validation.
I own the product requirements, system architecture, component and interface selection, schematic capture, power budgeting, PCB floorplanning and routing, design-for-test decisions, bring-up, and validation planning. Firmware integration and measured power and field performance remain in progress.
- Project stage
- Board bring-up + testing
- PCB status
- Layout and routing complete
- Current gate
- Power + interface validation
- Power-path charging
- Low-IQ regulation
- GNSS + BLE integration
- Multi-bus architecture
- RF-aware PCB layout
- 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− routed between the connector and MCU
- Test
- Power rails and key communication nodes
This simplified block diagram reflects the completed PCB architecture. It intentionally omits component-level schematic detail; subsystem operation and performance are still being validated.
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
- The module was placed at the board edge with its antenna keepout protected from copper and nearby components
- SWDIO, SWDCLK, reset, 3.3 V, and ground are 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 drove its board-edge floorplanning
- UART test access was retained in the routed design
- 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 placed at the board boundary to simplify the display connection
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
- The pressure-port area was kept clear so the enclosure can expose it 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
Routing the board around its constraints
Once the schematic was complete, I treated placement and routing as part of the electrical design rather than a mechanical cleanup step. The board was floorplanned around the two antenna modules, the charger and regulator current loops, connector access, sensor constraints, and a bring-up sequence that would still work if one subsystem failed.
RF-aware floorplanning
The BLE and GNSS modules were placed at board edges and their antenna regions were kept free of copper, routing, and tall components. Noisy power circuitry and high-activity digital nets were kept away from those regions.
Compact power paths
USB input protection, charging, battery, and regulation were grouped to keep the important current loops short. Power traces were sized for their loads, with local input and output capacitors placed close to the devices they support.
Continuous return paths
Signal routing was planned over solid ground wherever possible so return currents do not have to cross plane gaps. Vias tie the ground regions together and provide short returns near layer transitions and decoupling components.
Interface-first routing
USB D+ and D− were routed together, while SPI clocks and other timing-sensitive paths were kept direct. Lower-speed I²C, UART, button, and status nets were routed after the constrained power, RF, and clock paths.
Mechanical placement
USB-C, the memory-LCD connector, battery connection, buttons, and debug access were positioned around how the assembled device will be reached and tested. The barometer pressure port was given a clear path to ambient air.
Designed for bring-up
Programming, reset, ground, rail, charger-status, and communication access points were preserved after routing. This supports staged testing instead of requiring the full board to work before any diagnosis is possible.
Constraints first, low-speed nets last
- 01
Lock connectors, antennas, and mechanical constraints
- 02
Place regulators and local decoupling around short current loops
- 03
Protect antenna keepouts and ground continuity
- 04
Route power, USB, clocks, and critical buses first
- 05
Complete low-speed control and status routing
- 06
Add test access, ground stitching, and run final design-rule checks
The completed layout is now the hardware under test. Performance claims remain open until rail behavior, programming, peripheral communication, current consumption, and RF/GNSS operation have been measured.
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 selected regulators and their required passives were placed as compact functional groups. Input and output capacitors sit close to their pins, and the current-carrying paths were routed before lower-priority digital signals so the power layout was not forced through leftover space.
Mode-based 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
These values are design estimates and targets, not published measurements. They defined the hardware and firmware test cases now being run. The preliminary 2–3 mA idle estimate exceeds the <2 mA target, so idle-state optimization remains a specific bring-up task.
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 validation method. Testing is underway, but none is presented as achieved until the corresponding measurement is complete.
| 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
The completed PCB was designed to make revision-one failures diagnosable. Programming access, rail and communication test points, battery telemetry, and defined boot states let me bring up one domain at a time and isolate faults without depending on the entire system working.
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−
- Physical control inputs
- Accessible ground points
Board-level checks
- Local decoupling
- USB protection
- BLE antenna keepout
- GNSS ground guidance
- Short power loops
- Pressure-port clearance
From completed layout to measured behavior
No arbitrary completion percentage: the useful distinction is between design work that is complete, the board-level checks currently underway, and system validation that depends on stable hardware and firmware.
Design complete
- Overall system architecture and V1 requirements
- Preliminary mode-based power budget
- Full subsystem schematics and component selection
- PCB floorplanning and component placement
- Power, USB, communication, and control routing
- Antenna keepouts, test access, and design-rule review
Testing now
- Visual inspection and rail checks
- SWD programming and reset behavior
- Charging, power-path, and battery monitoring
- GNSS UART and barometer I²C communication
- SPI flash and memory-LCD interfaces
- Buttons, charger status, and BLE connectivity
- Mode-by-mode current measurement
Next
- Close issues found during subsystem testing
- Integrate ride logging and display firmware
- Validate storage integrity and BLE transfer
- Run GNSS and altitude comparisons on reference routes
- Measure sleep, idle, ride, and transfer current
- Complete controlled runtime and field testing
Turning targets into measurements
The PCB is in testing now. These bench and field checks are the evidence required before the current estimates and functional targets can be reported as verified results.
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
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
Resolve 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 schematic and routed PCB are complete; the evidence still being developed is measured behavior. I am now testing power, programming, peripheral interfaces, current consumption, storage integrity, BLE transfer, and field performance before presenting any target as achieved.