PCB
The custom board made the project physical.
A clean board photo anchors the firmware story in real hardware rather than a simulator.
Engineering
A system you can trace.
Follow the work from the screen to RTOS tasks, hardware drivers, Wi-Fi services, Node-RED cloud flows, signed OTA policy, release tooling, and validation evidence.
Guided architecture map
Choose a path through the system.
Each route lights up the layers that made Velo more than a single-screen prototype.
01live
Product UIExperience02
RTOS TasksRuntime03
DriversHardwareServicesDomain
Node-RED CloudCloud
A/B OTARecovery
Signed ManifestSecurity
Release ToolTooling
Validation EvidenceProof
From board to product
The system has hardware evidence.
PCB, signal capture, and assembly photos make the engineering path tangible before the page moves into the deeper failure stories.
Bring-up
Signals were measured, not guessed.
Logic-analyzer and wiring evidence shows the debugging path behind display, touch, and sensor behavior.
Assembly
Electronics, LCD, and hook base converged into one unit.
The final assembly photos show the transition from bench wiring to an integrated product surface.
The hard parts we solved
Failures became evidence.
These are the engineering stories that make Velo feel complete: not only successful demos, but real failure modes that were isolated, fixed, and validated.
A/B OTA that survives real resets
- Challenge
- The project had to update across two firmware slots without overwriting the running image, even during jump updates such as 1016 to 1018.
- Resolution
- The release path now targets the inactive slot, trial boots, confirms only after runtime health, and preserves the confirmed image for fallback.
- Proof
- Successful 1018, 1020, 1021, 1022, 1025, and final 1026 resets stayed on the expected confirmed firmware.
Signed manifest trust boundary
- Challenge
- A cloud manifest can describe which firmware to install, so the device needed to distinguish authentic release policy from edited JSON.
- Resolution
- Ed25519 signature verification was added over canonical manifest fields, with the public key embedded in firmware and release-tool signing built into the desktop workflow.
- Proof
- Bad-signature manifests produced check failed before download or install began.
Payload identity, not just manifest identity
- Challenge
- A valid manifest is not enough if the referenced RPS file is replaced or corrupted after signing.
- Resolution
- The signed manifest now binds to the payload SHA256, and install rejects modified bytes before accepting the image.
- Proof
- The bad-payload test passed check, then failed install with the observed 0x46 rejection code.
LED behavior without OTA instability
- Challenge
- Hook LED I2S refresh collided with the OTA install path and created a real board-level failure during update testing.
- Resolution
- OTA install now pauses the hook LED backend, aborts pending I2S transfer cleanly, and resumes product behavior after the critical flash path.
- Proof
- Final releases kept LED_ON behavior while OTA install and reset persistence remained stable.