Complete project source footprint including SDK, generated build files, third-party code, and app source.
Technical archive
The record behind the result.
Velo has a polished final surface, but the archive proves the engineering behind it: self-authored code scale, module boundaries, release automation, backup discipline, and the reconstructed 0.01 to V1.0.0 development journey.
Core application firmware excluding SDK, third-party libraries, generated build files, and config.
Self-authored firmware, OTA release automation, and the Velo desktop release tool together.
A visible trail of iterative engineering from early bring-up to the frozen final baseline.
Physical development evidence
The build journey is visible on the bench.
These photos turn the archive into more than documents: first power, measurements, display bring-up, and final internals show how the project was physically debugged.
First power
Power-on and testpoint work
The board was checked through physical testpoints and jumpers before the higher-level product flow was trusted.
Thermal check
Early hardware safety check
Thermal inspection and power validation helped make the bring-up process disciplined instead of purely trial-and-error.
LCD bring-up
Display path under measurement
The first LCD bring-up was paired with signal capture, turning visual progress into measurable engineering evidence.
Internals
Final unit with the back opened
The finished device can be inspected as hardware, not just as a polished front face.
Code quality evidence
The project grew into a layered codebase.
The line counts are not shown as vanity numbers. They show that Velo moved beyond a single demo loop into separable firmware, services, hardware managers, security checks, and release tooling.
AreaScaleWhat it coversQuality signal
Core firmware26,818 linesSelf-authored application firmware excluding SDK, third-party libraries, generated build files, and config.Split into runtime, UI, services, drivers, managers, storage, and fallback boundaries.
Product UI and screens10,321 linesTouch UI, home surface, settings, Wi-Fi, update flow, distance page, and supporting UI helpers.The UI is organized around screens and shared UI infrastructure rather than one monolithic loop.
Services layer7,364 linesWeather, time, Node-RED integration, OTA, reminder logic, storage-facing behavior, and validation paths.Network and OTA behavior live behind service boundaries so UI code does not own release policy.
Drivers and managers5,575 linesLCD, touch, ToF, hook LED, power-facing behavior, and product hardware managers.Board control is kept below product logic, making hardware problems easier to isolate.
Release tooling2,448 linesCommand-line release automation plus the Windows Velo OTA Release Tool.A/B packaging, signing, upload, cloud check, and acceptance are repeatable.
Project configuration36,259 lines with configWhen project configuration is included, the self-authored delivery footprint grows beyond firmware code alone.The buildable project preserves the configuration needed to reproduce the embedded result.
Version journey
From first signal to final signed release.
The early 0.xx labels are a presentation timeline reconstructed from engineering checkpoints, backups, board evidence, and release milestones. The final engineering baseline is V1.0.26.
First hardware contact
ToF bring-up, UART recovery, and the first real sensor logs.
Board logs proved the sensor and UART path were alive.RTOS foundation
FreeRTOS, CPU/GDB debugging, and boot-path observability.
Debugger sessions exposed runtime state instead of guessing from LEDs.Display and touch recovered
HX8357D display, touch ADC bench, X/Y ring mapping, and drawing interaction.
ADC bench tests converted raw touch behavior into calibrated interaction.Product definition
The project became a door-side weather reminder terminal with hook LEDs.
The feature set moved from demo drawing to a real reminder workflow.Connected behavior
Wi-Fi, Node-RED, NVM3, sleep/wake, brightness, and distance UI matured.
Networking, local storage, and low-power behavior became product features.OTA became real
Release paths, 0x1BBE2, V1.0.12 stabilization, and reboot-only bugs.
Install errors and first-reboot failures forced release-path debugging.A/B fallback proof
Slot-aware OTA, fallback, bad package rejection, and reset persistence.
Board tests proved reset persistence, rollback, and bad package rejection.Final showcase release
LED_ON product experience, signed manifest, payload hash, release tooling, and reset-persistent OTA.
Final proof shows V1.0.26 OTA success, fallback demo, bad package rejection, and tooling.Primary records
What proves this was self-developed.
Firmware Core
26.8k self-authored lines across product firmware modules.
Product UI
10.3k lines across touch UI, screens, and update surfaces.
Signed OTA
Manifest signature and payload hash validation are integrated.
Release Tool
A/B package generation, signing, upload, and acceptance checks.
Recovery Logic
Trial boot, confirm, fallback, and reset persistence.
Validation Practice
Success cases, bad package, bad signature, bad payload, and fallback.
Engineering ledger
Proof of quality, not just quantity.
This ledger focuses on reviewable engineering assets: code structure, reliability, security, release tooling, and traceable validation practice.
Layered firmware architecture
Hardware drivers, product UI, screens, services, managers, storage, and fallback code are separated by responsibility.
Clear module boundaries make the system reviewable instead of being one large demo file.OTA and recovery state machine
The firmware tracks active slot, inactive target, trial boot, confirmation, rollback, and reset persistence.
The final validation matrix covers success, fallback, bad package, bad signature, and bad payload.Security boundary
Signed manifest verification and payload hash binding protect release policy and firmware bytes separately.
Bad manifest fails during check; bad payload fails during install.Release automation
The desktop release tool builds slot A/B packages, signs manifests, uploads files, verifies endpoints, and creates acceptance evidence.
The release flow can be reproduced through a GUI instead of hand-edited JSON.Engineering traceability
The project uses frozen baselines, clean backups, one-click acceptance, and board-level negative tests.
Failures became recorded validation cases rather than hidden debugging debris.