A LIGHTNINGSPORE BUILD · DENVER.SPACE
25 minutes · optional deeper discussion · Draft 02 · 2026-11-04 Read below or select Present. Arrow keys navigate in presentation mode; N opens notes.
Jump to a section
- Building ShieldSigner with AI
- What does a Bitcoin signer do?
- From SeedSigner to ShieldSigner
- Where trust enters the system
- Two hardware-wallet incidents
- Multi-vendor multisig
- The SeedSigner software stack
- Bitcoin libraries and shared dependencies
- The hardware and its connections
- Replacing hardware and software
- How I worked with AI
- Designing the carrier PCB
- Porting the board to tscircuit
- Designing the enclosure in OpenSCAD
- Does the complete assembly fit?
- Controlling the camera in Rust
- Replacing ZBar with ZXing-C++
- Moving the interface to LVGL
- Try the camera and interface together
- What we have verified
- Estimated build cost: about $100
- Next: assemble and test the carrier
01 / 22The build~25s
Building ShieldSigner with AI
From schematic to printable enclosure, driven by code.
- PCB → assembly → enclosure
- Fast iteration. Explicit evidence.
Presenter notes
This is a builder story: using AI to move between schematics, source, supplier drawings and mechanical models. The project is a development prototype, not a claim that a home-built signer is safer than commercial products. The main story is the PCB and 3D iteration; the camera and LVGL work show what happened when the hardware met software. Credit SeedSigner, ShieldSigner and their contributors throughout.
12 / 22AI + hardware~75s
Designing the carrier PCB
AI helped connect datasheet research, electrical review and repeatable manufacturing outputs.
- Read the datasheets for every major IC and module
- Match KiCad symbol pins and footprint pads to the real part
- Check voltage domains, signal functions and connector order
- Generate matched BOM, placement, Gerber and drill files
Datasheets → pin and pad audit → checked design → manufacturing package. Scripted edits and exports make revisions repeatable and keep the parts list and placement files tied to the same PCB revision.
Presenter notes
Start by collecting the manufacturer datasheets and mechanical drawings for the major components: the Luckfox module, LCD, camera, smartcard controller, regulators and connectors. AI helps extract pin tables, supply limits, interface requirements and recommended support circuitry into a reviewable component guide. Check each KiCad symbol pin number, name and electrical type against the datasheet, then follow it through the footprint pad and board net to the physical part. Check connector viewing direction and pin-one orientation as well as signal names. This caught concrete issues: SEC1210 power-output pin types needed correcting, and its output decoupling changed from 100 nF to 1 µF to match the datasheet recommendation. Review voltage domains, module pinmux, bus signals and power paths together. Use scripts for repeatable native edits, then run schematic ERC, PCB DRC, connectivity and schematic-to-PCB parity checks. Generate the BOM with readable values, manufacturer part numbers and supplier references, the CPL pick-and-place file, and Gerbers and drill files from the same revision. Keep DNP choices and assembly rotations explicit. The main review kit has 35 fitted SMT parts across 17 supplier SKUs. Automated checks and a manufacturing package still require a physical first article to qualify assembly, fit and powered operation.
13 / 22AI + hardware~65s
Porting the board to tscircuit
TypeScript could make tscircuit a more AI-native PCB tool in the future. I still prefer KiCad today.
- Components and connections expressed in TypeScript
- Seven sheets, editable silk and 3D models
- Check footprints and electrical connections
We checked that the tscircuit version preserved the component footprints and electrical connections. See the comparison checks ↗
An early visual port became a source-authored circuit. Both representations remain useful; the new routing is not hardware-qualified.
Presenter notes
Show a concrete AI iteration: the first port reproduced appearance using imported native geometry and copper, which was useful for comparison but not idiomatic source authoring. The rebuilt version uses semantic tscircuit primitives, functional sheets, local footprints and assets, and fresh built-in autorouting. Compare 190 physical lands within 0.005 mm and electrical partitions in both directions, then run placement, shorts and routing-style checks. That establishes specific software evidence, not hardware qualification or equal routed copper. This example demonstrates tool translation; KiCad remains the native reference and preferred workflow. There are recorded upstream core/schema incompatibilities and unresolved generic-header part-selection warnings; do not claim a perfect exporter or production-ready new layout. The longer-term possibility is a more AI-native PCB workflow: components, connections and layout are expressed in TypeScript, giving AI familiar source code to read, edit and review with normal diffs. That is a promising direction rather than a claim that tscircuit is already a more mature PCB editor.
14 / 22AI + hardware~75s
Designing the enclosure in OpenSCAD
OpenSCAD creates 3D models from code: shapes, dimensions and operations.
- Combine shapes; subtract holes and openings
- Use parameters for walls, clearances and mounting posts
- Change the code, preview the model, export parts to print
The enclosure is a program: edit its dimensions and regenerate the geometry. Next, inspect how the PCB, modules and shell fit together.
Show the case parameters
button_switch_height = 2.7;
button_gap = 0.15;
button_stroke = 0.40;
wall = 2.4;
outer_size = [176,82];Millimetres. Actual OpenSCAD source; change parameters, regenerate parts, then check fit.
Presenter notes
OpenSCAD is a code-based 3D CAD tool. You describe solids such as boxes and cylinders, position them with transforms, and combine or subtract them. A case wall can begin as an outer box with an inner box removed; another cut creates a connector opening. Variables and reusable modules control dimensions and repeated features such as screw posts. Preview the model as you edit, then render and export a mesh for slicing and printing. This gives AI concrete source code to work with and gives us readable diffs and repeatable geometry. For this project, the PCB supplies the outline, mounting holes and component positions; module drawings supply the remaining dimensions. Adjust the case around those constraints, then inspect the complete assembly in the next section. Camera and ribbon models are adjustable envelopes and screw threads are omitted.
15 / 22AI + hardware~70s
Does the complete assembly fit?
Bring the PCB, modules and enclosure together to inspect the fit.
- Inspect header heights and mating depths
- Look for collisions and blocked connectors
- Use the model to plan a printed fit test
3D loads when this section comes into view.
Nominal stack: 35.52 mm. Purchased header tolerances and physical fit still need checking. Download the PCB assembly ↗
Presenter notes
Now inspect the result of the PCB and enclosure work together. Rotate the assembled model, open the exploded view, and use PCB assembly and transparent case-fit modes to inspect interfaces. Check that display and Luckfox headers mate at the intended depth, spacers support the stack, and connectors and buttons remain accessible. Look at camera placement and cable clearance. If a header makes the case too thick or an opening is blocked, return to the PCB or case parameters and regenerate. A digital model helps identify problems before printing; a printed fit sample and real purchased components are still needed to verify tolerances. Finish the hardware story here, then move on to the camera and UI software.
20 / 22What we learned~65s
What we have verified
Software checks, bench results and remaining carrier tests.
- Native checks + provenance
- Continuity + rails + actual pinmux
- Tested bench ≠ qualified carrier
0protected PCB objects changedInspect the artwork-only comparison ↗
Presenter notes
The biggest concrete lesson: the working base-fork firmware drives GPIO56/57 as LCD outputs, while the carrier uses those nets for Left/Up buttons to ground. Pressing a button can ground a driven output. The carrier net map agrees with its intended carrier profile; rewiring it to mimic the bench would be the wrong response. The new carrier needs the carrier image, 10 MHz LCD clock, 320×240 settings and physical bring-up. Frozen-image hashes and packed checks establish exact artifacts, while first-article electrical/mechanical tests establish different facts. AI accelerated finding this mismatch; it did not exempt us from checking it.
22 / 22Next~35s
Next: assemble and test the carrier
Check the real board, fit the case and verify the complete workflow.
- Qualify the carrier first article
- Practice recovery with disposable keys
- Contribute a reproducible improvement
shieldsigner.devGet the source ↗
PCB · mechanical models · firmware · repeatable tools
Built on SeedSigner, ShieldSigner, kdmukai’s screen work, LVGL, Linux and Luckfox.
Presenter notes
Close with the actual next step: one powered carrier first article with the correct profile, continuity/rail/button/display/camera checks, and a printed fit test. Real-wallet end-to-end acceptance remains pending. Invite review of a net, a footprint, a source guard, an enclosure clearance or a repeatable test rather than generic trust in the prototype. Thank SeedSigner, ShieldSigner, kdmukai/LVGL, Linux, Luckfox and the wider open-source contributors. Link the project and Denver.space. The useful artifact is not only a board: it is a workflow that makes the next question cheaper to answer.