A10 vision experiment · retained physical evidence
From dataset to board proof.
A model can run on real hardware and still fail the product's quality gate. Follow the evidence behind our Nordic nRF54LM20B object-detector experiment.
This is a review of retained results. It does not train a model, accept uploads, or launch a new board run. The keyword models are a separate experiment.
- Proved
- A named model was compiled, linked, and run on a physical nRF54LM20B.
- Still unproved
- Product accuracy, representative application performance, power, and energy.
- Decision
- Reject this candidate for product use. Improve the data and model before advancing.
- 01
Freeze a small, explicit dataset
The bundled release contains 124 images and 915 annotations across 80 original COCO categories. This demo collapses accepted labels to one generic-object class. Train, validation, and test splits contain 100, 12, and 12 images. This is a hardware-integration fixture, not evidence for 80-class or product-generalized detection.
Implementation and data-handling notes
Local intake verifies the release, seals a data capsule, and deletes temporary staging. Sealed capsules require manual purge; the declared 24-hour expiry is not automatically enforced. This public walkthrough accepts no uploads.
- 02
Select a model that can fit
The 12,714,380-byte A8 baseline is rejected as oversized. The same-release A10 full-integer candidate is 946,888 bytes, providing a smaller starting point for the Axon retargeting step. Fit is a reason to continue evaluation, not proof of useful accuracy.
- 03
Compile for an exact target
Retargeting produces a 925,608-byte full-integer ReLU model for quality evaluation and a separate 925,856-byte native-head model for the Axon compiler and firmware. Its six output heads match the full-integer graph's intermediate tensors byte-for-byte on 20 deterministic test vectors; this is not a separate dataset evaluation.
The pinned path uses Nordic nRF Connect SDK v3.4.0, Edge AI v2.2.0, and Axon compiler 1.3.0 for the nRF54LM20 DK / nRF54LM20B.
Inspect model identities
- Initial full-integer candidate · 946,888 bytes · SHA-256
- b0bbf6a05e04b8491884833a087e6168caf41a0cde438e6e43be4dcbb68bb4a5
- Evaluated full-integer ReLU model · 925,608 bytes · SHA-256
- 0ce303f59801647465d95454bd7a98f8068de7fb9ca34255d7fa8f01d1761c0d
- Compiled and board-linked native-head model · 925,856 bytes · SHA-256
- 0d4984410644b0c32a823d5ac318e999c41e0ef7e4985b2f0f8ac967b5788d50
- 04
Link the firmware
The retained SDK build links the exact model into a firmware harness. Reported usage is 1,248,044 bytes of flash and 190,927 bytes of RAM. This establishes the build path; it does not validate a complete customer application.
- 05
Compare host and physical board
Signed results show deterministic outputs across 10 runs on one known image, with controlled inference p95 of 158.592 ms. The host and board top boxes agree at IoU 0.9884. That measures host-to-board agreement, not detection accuracy.
Against the image's two labels at an IoU threshold of 0.5, the board produced 1 true positive, 0 false positives, and 1 false negative (recall 0.5).
This is a one-input functional check. Dataset accuracy on the board, end-to-end application performance, power, and energy remain unmeasured.
- 06
Reject the model when quality fails
Product-quality gate: failed.
On the frozen 12-image validation split, the 925,608-byte full-integer ReLU model scored mAP@0.50 of 0.055858 and recall of 0.088. The separate 925,856-byte native-head artifact is the compiler and board-linked model described in step 3. Neither the quality result nor the limited equivalence check makes this candidate acceptable for product use. Improving the data and model quality is the next useful step.
Bring one dataset and one target.
We will define the quality, build, and board-evidence gates for a bounded project. Contact us for a guided intake walkthrough.