This repository is the complete production test system for the Lord of Robots LoR Core V3 robotics controller. It contains two production station applications, the dedicated ESP32 test firmware, a shared serial protocol, local CSV traceability, packaging tools, and release/update infrastructure.
The same board receives the same verified firmware and follows the same pass/fail rules whether it is tested from a Windows PC or an Android USB-host device.
| Windows station | Android station | |
|---|---|---|
| Best for | Fixed production benches | Portable or compact fixtures |
| Connection | CH340/CH341 virtual COM port | USB-C Host/OTG to CH340 |
| Installation | Self-contained NSIS installer | Manually side-loaded APK |
| Firmware upload | Bundled standalone esptool | Native Espressif serial flasher |
| Test records | ProgramData CSV | Private app CSV with manual export |
| Application updates | Automatic from public GitHub Releases | Manual APK replacement |
| Firmware updates | Verified at runtime from GitHub Releases | Verified and embedded when the APK is built |
| Reference platform | Windows 10/11 x64 | Pixel 6, Android USB Host |
Start with the platform-specific guide:
- Windows: installation, configuration, and operator guide
- Android: installation, USB setup, operation, and APK build guide
Different Android phones, tablets, hubs, and USB-C cables must be qualified before production use because USB Host power and CH340 control-line behavior vary by device.
- Detects and opens the LoR Core USB interface.
- Places the ESP32 into its ROM bootloader and programs the approved four-image firmware package.
- Reads the canonical factory eFuse MAC address as the permanent board ID.
- Begins a fail-safe test transaction by provisionally storing failed in ESP32 NVS.
- Measures battery input from a calibrated 20-sample ADC average when that check is enabled.
- Scans Wi-Fi and records network/RSSI information.
- Performs an active Bluetooth Low Energy scan.
- Shows the LED animation and asks the operator to approve it.
- Guides the operator through buttons A-D and the user switch while detecting each transition automatically.
- Sends
TEST_PASSonly after every required check passes; otherwise it sendsTEST_FAIL. - Appends one local CSV audit record and displays it in Test History.
- Startup: a dark-to-dark spatial rainbow presentation always runs first.
- Normal idle: the LEDs fade seamlessly into the icy-blue spatial orb.
- Buttons: A is yellow, B green, C red, and D blue while held.
- Pass: all LEDs show green for two seconds, then return to the icy-blue animation.
- Fail or interrupted test: solid red is stored in NVS and returns after every power cycle.
- Recovery: a complete passing production test clears the red latch.
The provisional failure state is written at TEST_START. A cable disconnect, station crash, reset, or power loss after that point therefore cannot leave an incomplete board looking passed.
| Check | Evidence captured | Default criterion |
|---|---|---|
| Identity | eFuse MAC, chip, revision, flash size, firmware | Valid LoR Core V3 protocol handshake |
| Battery input | Calibrated voltage, averaged raw ADC, 20 samples | 6.0-12.0 V |
| Wi-Fi | Visible count, target/best SSID, RSSI | Target or strongest AP at/above configured floor |
| Bluetooth LE | Advertisement count and strongest RSSI | At least one received advertisement |
| RGB LEDs | Rainbow startup and icy-blue animation | Operator approval |
| Buttons A-D | Expected GPIO transition only | Correct individual transition |
| User switch | Expected GPIO transition only | Correct transition |
Android can deliberately skip the battery check through its default-on Check Battery Voltage setting. A skipped check is shown as SKIP, leaves VIN CSV fields blank, and is excluded from the overall result. Windows always includes the configured VIN check.
| Function | GPIO |
|---|---|
| Button A | 35 |
| Button B | 39 |
| Button C | 38 |
| Button D | 37 |
| User switch | 36 |
| Battery sense | 34 |
| RGB LED data | 33 |
This April 2026 production mapping supersedes the older datasheet mapping for buttons B-D and the user switch.
The approved firmware package contains exactly four images at 0x1000, 0x8000, 0xe000, and 0x10000. Manifests identify the product and protocol and carry a SHA-256 for every image. Both clients reject an incomplete, modified, misaddressed, or wrong-product package.
- Windows ships with a verified fallback package and can activate a newer verified package from a normal public GitHub Release.
- Android's build synchronizer downloads or reuses the same Release package, verifies it, and embeds it in the APK.
- Production stations do not need Arduino IDE or FastLED. Those are release-builder dependencies only.
- Testing continues with the installed/bundled firmware when GitHub or the network is unavailable.
See System Architecture and Serial Protocol for the complete design.
Every completed or failed production attempt is appended locally. No cloud database or multi-PC synchronization is implemented.
- Windows:
C:\ProgramData\Lord of Robots\LoR Core V3 Test Station\results\lor_core_v3_results.csv - Android: private application storage; use Test History -> Export CSV to create a portable copy
Windows upgrades and uninstalls preserve ProgramData. Android upgrades preserve app data, but uninstalling the APK removes its private CSV. Manufacturing is responsible for scheduled exports/backups and retention.
See Data and Traceability for the schema, skip semantics, privacy guidance, and backup procedure.
Download the latest Windows installer
The installer includes the UI, Python runtime, pyserial, standalone uploader, branding, and production firmware. It creates desktop and Start Menu shortcuts. The current installer is not Authenticode-signed, so Windows may show an unknown-publisher warning.
Android is distributed manually and is not published through Google Play. Build or obtain the approved APK, enable installation from the chosen file source, install it, connect the LoR Core through a USB-C data/OTG path, and grant USB access. Keep the same signing key for every APK update or Android will require uninstalling the old app, which would erase its private history.
See the Android guide before deploying an APK to production.
production_test/ Windows UI, launcher, firmware, and branding
android/ Native Android USB-host application
installer/ Windows packaging and GitHub Release builder
docs/ARCHITECTURE.md Components, trust boundaries, and state flow
docs/SERIAL_PROTOCOL.md Host-to-firmware commands and responses
docs/DATA_AND_TRACEABILITY.md CSV schema, storage, export, and retention
docs/TROUBLESHOOTING.md Symptom-based recovery procedures
docs/RELEASE_PROCESS.md Version, build, validation, and release process
.github/workflows/quality.yml Windows source and Android build validation
VERSION Authoritative Windows application version
- System architecture
- Serial protocol
- Release process
- Windows installer details
- Android third-party notices
- Security policy
- Release history
Use GitHub Issues for reproducible bugs and documentation problems. Remove board IDs, printed serials, operator names, SSIDs, and CSV production records before attaching logs or screenshots. Report vulnerabilities privately through GitHub Security Advisories.
Copyright © 2026 Lord of Robots. All rights reserved. See LICENSE. Third-party components retain their own licenses.