2026-10-08

"Building StealthDeck Pro batch 7: seven numbered units from bench to box"

This is the build log for batch 7 of StealthDeck Pro — seven numbered units, each a LILYGO T-Embed CC1101 (ESP32-S3) with an nRF24L01+PA/LNA shield on top. Build-to-order means these seven exist because seven orders exist; there is no parts bin waiting for batch 8 until someone asks for it. That changes how we work: every step below happens on a bench in Australia, in one session, against a manifest that starts empty and ends with seven serials.

For anyone comparing tiers, the StealthDeck Lite is the same philosophy at a simpler BOM — Pro is the deck with sub-GHz, NFC, and 2.4 GHz radios in one shell.

What's on the bench

The T-Embed CC1101 is an ESP32-S3 (dual-core LX7) board with a 1.9-inch ST7789V IPS panel at 320×170, a 24-step rotary encoder, a PN532 NFC front-end over I2C, a CC1101 sub-GHz transceiver, WS2812 LEDs, a TF slot, and a 1300 mAh battery managed by a BQ25896 charger and BQ27220 fuel gauge (LILYGO wiki). The community pinout reference at ESPboards confirms the same silicon and the S3's native USB, which is what lets us flash and read serial without a separate UART adapter on every unit.

The nRF24L01+PA/LNA shield is a Nordic nRF24L01+ single-chip 2.4 GHz transceiver — 2.400–2.4835 GHz, 125 channels, Enhanced ShockBurst packet engine — plus an external PA on TX and LNA on RX behind an SMA or u.FL antenna connector, per the Nordic nRF24L01+ product specification v2.0. Conceding a limitation up front: the PA/LNA modules are third-party implementations of the Nordic chip, not Nordic-built modules, so output power and spur performance vary batch to batch. That's exactly why we measure rather than assume, and why the regulatory step below exists.

Landed cost for this batch: A$180.88 per unit. Batch size: 7. Ships in 3–7 business days from QA pass — and QA pass is defined later in this log.

Step 1 — BOM check

Before anything powers up, the parts for all seven units are laid out against the manifest: 7 × T-Embed CC1101, 7 × nRF24L01+PA/LNA shields, 7 × antenna whips, 7 × NFC test cards. We log the board revision silkscreened on each T-Embed (batch 7 arrived as v1.4) and the date codes on the nRF24 shields. Any variance — a different shield vendor, a changed antenna — goes into the manifest as a note before flashing, because firmware radio settings depend on knowing what's physically attached.

Two things we check that aren't in any datasheet: the rotary encoder detent feel (a crunchy encoder on unit 3 got flagged here, swapped, and the original went in the reject bin) and the USB-C port seating. Both are the classic build-to-order risks when you buy in sevens instead of seven hundreds.

Step 2 — Signing pipeline

Firmware is built from a pinned commit of our internal build recipe, then signed. We use the ESP32-S3's hardware secure-boot-v2 with an RSA-3072 key held offline; each unit in the batch gets the same signed application image and a unit-specific entry in the manifest keyed by its eFuse-derived device identity. The build itself is byte-for-byte reproducible in the sense described at reproducible-builds.org — same toolchain version, same source revision, same output hash — and the hash is written into the manifest next to every serial.

Why this matters honestly: reproducibility doesn't stop someone physically tampering with a unit, and secure boot only protects the app partition, not the radio behaviour of third-party PA shields. What it does give you is confidence that what's on the flash is exactly what our pipeline built, and a way to detect if it isn't.

Step 3 — Incoming inspection

Each board and shield is inspected before it earns a serial. Typical defects that fail here, from our reject log across batches:

Failing parts are photographed, logged, and set aside. They never get serials, and they never ship.

Step 4 — Flash and QA

Passed units get flashed in fixture order: bootloader + signed app, then unit provisioning. After flash, each unit runs the same QA checklist on the bench, operator initials against each line in the manifest:

  1. Display — full-screen test pattern at 320×170, check for dead pixels and uniform backlight.
  2. Rotary encoder — 24 detents registered clockwise, 24 counter-clockwise, button click debounces clean.
  3. NFC — read the test card, then write-and-verify a tag; PN532 ack within expected I2C timeout.
  4. CC1101 sub-GHz — loopback with a bench unit at a fixed attenuation, packet error rate under threshold at both 433 and 868 MHz settings.
  5. nRF24L01+ — two-way throughput test at 250 kbps, 1 Mbps, and 2 Mbps; verify channel sweep across a sample of the 125 channels; confirm the LNA is receiving (sensitivity spot-check against the reference deck).
  6. Battery — charge to full on BQ25896, confirm BQ27220 reports design capacity within tolerance, then a 10-minute discharge to catch thermal anomalies.
  7. WiFi + BLE — scan, associate, and BLE advertise; S3 antenna paths verified.
  8. Serial identity — the eFuse ID is read back and must match the manifest row for the physical unit in front of the operator.

Any unit that fails any line returns to the bench with the failure noted. In batch 7, one unit initially failed the nRF24 sensitivity spot-check; reseating the shield and re-torquing the SMA brought it into spec, and it passed on a full re-run of all eight lines, not just line 5.

Step 5 — Regulatory folder, complete before shipping

Australian law lets these radios operate without a licence only under class-licence conditions. The Radiocommunications (Low Interference Potential Devices) Class Licence 2025, registered on the Federal Register of Legislation and commenced 1 October 2025, authorises low-power devices on shared bands including the 2.4 GHz ISM range the nRF24L01+ uses. Our regulatory folder per unit contains: the signed firmware hash, the nRF24 PA module's declaration of conformity from the shield vendor, the measured TX power figures from the QA bench, and a lawful-use statement naming the class licence authority under which the 2.4 GHz radio operates. The folder is assembled and checked before the unit is boxed; if a folder item is missing, the unit doesn't ship that day.

This is a deliberate honesty point: the sub-GHz CC1101 side of the deck depends heavily on how the operator configures it, and we do not certify every possible use. What we do is document what was measured, point to the licence that authorises the default configurations, and make clear the operator's obligations sit with the operator.

How unit numbering ties to the manifest

Each unit is stamped SDP-B7-01 through SDP-B7-07. That ID is the primary key for a manifest row containing: board revision, shield vendor and date code, firmware build hash, eFuse device identity, per-line QA results with operator initials, regulatory folder file list, and ship date. Batch 7's manifest closes only when all seven rows are complete and all reject-bin items from the batch have a disposition (reworked, replaced, or destroyed). Nothing else — no batch number reuse, no serials issued before QA.

The numbering matters practically, too: if a customer reports a fault on SDP-B7-04 two years from now, we can reconstruct exactly which shield lot it carries, which firmware hash it shipped with, and what its bench measurements were that day. That's the whole point of numbering seven units by hand instead of casting ten thousand into a box.

Wrap on the batch

Batch 7: 7 built, 1 reject bin entry (WS2812), 1 rework-and-repass (nRF24 sensitivity), 7 manifests closed, 7 units boxed with complete regulatory folders. Ship window: 3–7 business days from today's QA close. The next batch starts only when the next order does — which is the point.

← All posts