# Movable Pi component layout

Open **[layout.scad](layout.scad)** in OpenSCAD. This places the current README parts in the actual enclosure STLs: Raspberry Pi 4B, TONOR G11, LIELONGREN 8 W speaker, EG STARTS 100 mm button, and HiLetgo PN532. The Pi model includes connector blocks, GPIO and a seated microSD envelope. Orange and cyan rings estimate mic and speaker cable storage; purple volumes reserve plug space. The mains power adapter stays outside the box.

![Populated enclosure CAD](overview.png)

## Move things around

1. Choose **Window → Customizer** to show the controls. Expand a component's group.
2. Change its **Position** values (X, Y, Z in mm) or **Rotation** values (degrees around X, Y, Z). The button uses `Button_XY`, a height offset and rotation; its default height follows the selected roof.
3. With Automatic Preview enabled the view updates; otherwise press **F5**.
4. Use each component's **Visible** checkbox to inspect parts behind it. `View` offers open, transparent, closed, exploded, components-only and collisions-only displays. Exploded lifts the shell only; parts stay at their actual coordinates.
5. Use the Customizer **+** and **Save preset** controls to retain an arrangement in the accompanying `layout.json`. `Ctrl/Cmd+S` alone does not write Customizer values back into SCAD source. Edit source defaults if you want to change the starting layout itself.
6. `Enclosure` switches between the original and the three earlier enclosure concepts. The electronics retain their coordinates; only the button follows the roof. Reposition the other parts before assessing a different shell.

OpenSCAD moves parts with numeric controls rather than drag handles. The [individual STL exports](exports/) are separate, positioned meshes you can import and move independently in another CAD application. They are snapshots, not linked to future Customizer changes. Do not export the entire assembled view as one STL when you want separate movable objects.

## Cable storage

Select **Cable storage study** in the preset dropdown, or set `View` to `cables`. The electronics and original top become transparent so the two movable storage rings are visible. Orange is the mic cable; cyan is the speaker cable. These rings represent space for a bundle, not solid plastic or an exact winding path. Their starting positions are for exploration and have not been fitted around the components.

Under the mic and speaker cable groups, enter **total cable length**, **diameter**, and **route allowance**, all in mm. The route allowance is the portion needed between the device and Pi; the remaining length is stored in the ring. Routes are not drawn or measured automatically, so update this allowance when moving components. Move and rotate each ring with its own controls.

Starting values are **assumptions**: mic 2,000 mm and speaker 1,200 mm; both 3 mm thick, with route allowances of 250 and 200 mm respectively. These are not verified specifications for the README parts. Each default ring has an 84 × 48 mm footprint. Estimated heights are 12 mm for the mic and 6 mm for the speaker. The model divides cable material volume by a 60% packing fraction and the racetrack ring area, then rounds height up to whole cable diameters. Zero spare length removes the ring. Bend radius, packing, straight length and winding width are adjustable; the initial 12 mm inner radius is an assumption, not a cable rating.

OpenSCAD exported watertight coil meshes at 1,200, 2,000 and 4,000 mm total length (250 mm route allowance), with heights of 6, 12 and 21 mm. The updated cable view was checked in the OpenSCAD GUI; `make check` passed all lint checks and 217 tests.

The rings **are excluded from the component fit report and red collision checks**. Inspect them against the transparent bodies and enclosure; their visibility does not establish fit. Plugs remain separate reservations, and cable exits, strain relief, ferrites and ties still need measurements. The existing PNG previews and five component STL exports do not include this cable study; open the SCAD for the updated model.

## How much of the geometry is known?

| Part | Basis | Model limitations |
|---|---|---|
| Enclosure | Original STL pair, 192 × 120 × 82 mm assembled | STL units interpreted as mm; print accuracy and tolerances not measured |
| Pi 4B | [Official mechanical drawing](https://datasheets.raspberrypi.com/rpi4/raspberry-pi-4-mechanical-drawing.pdf): 85 × 56 mm board, 58 × 49 mm mounting pattern, component-height callouts | PCB thickness 1.6 mm, hole diameter 2.7 mm, connector outlines and microSD envelope are simplified assumptions; no heatsink/fan included |
| Speaker | [Exact README ASIN listing](https://www.amazon.com/dp/B08QRYTPGH): 7.17 in wide × 2.2 in deep × 1.81 in high | Model uses the complete retail housing, about 182 × 56 × 46 mm. Corner radius, feet, cable exit and underside relief are not controlled drawings. Converted decimal dimensions do not imply fine tolerances |
| Button | [Exact README ASIN listing](https://www.amazon.com/dp/B072JLSH34): 100 mm overall diameter, 95 mm top-to-microswitch depth, 24 or 88 mm mounting hole | Above-panel height of 22 mm, 86 mm upper body, 23 mm upper-body depth, stem and microswitch shapes are assumptions. All key envelope dimensions are editable |
| TONOR G11 | [Manufacturer photos and product identity](https://www.tonormic.com/products/tonor-g11-conference-usb-microphone) | **75 × 100 × 18 mm is an assumed body**, not measured or verified supplier dimensions. The current Amazon listing's roughly 200 × 300 × 50 mm dimensions are inconsistent with the manufacturer's compact product photos and were not accepted as body dimensions. Measure the actual unit |
| HiLetgo PN532 | README V3 product identity; [ELECHOUSE V3 manual](https://www.elechouse.com/elechouse/images/product/PN532_module_V3/PN532_%20Manual_V3.pdf) for related-module context | **43 × 41 × 4 mm body and header are proxies**, not verified HiLetgo dimensions or mounting holes. No substitute part is being selected |
| Cables/plugs | Explicit adjustable reservations | Plug lengths, bend allowance and cable bundle are assumptions. Spare cable storage is estimated from editable lengths and diameters; actual routes, wire terminals, mounting fasteners and strain relief are not modeled |

The Pi's hole-pattern centre is placed at (37.5, 26.7, 12.5), with 180° Z rotation. Its four hole axes align with the original base posts at X=8.5/66.5 and Y=2.2/51.2; Z=12.5 is the measured post-top plane. The button opening centre measured from the STL is approximately (-43, 0); its mesh diameter is about **86.99 mm**, versus the supplier's nominal **88 mm** mounting-hole option. Check the physical button and printed opening before changing that hole.

## What currently clashes?

The default arrangement is a starting point, **not a claim that everything fits**. Solid intersection checks of these models find:

- **Speaker / button proxy:** approximately 7.55 cm³ overlap.
- **Speaker / original base:** approximately 0.143 cm³ overlap near mounting geometry. A more accurate speaker underside/feet model may change this.
- No positive-volume intersections for the other modeled component pairs or their original-shell checks at the saved default positions. That does not establish clearances for unmodeled screws, cables, ventilation or acoustic paths.

[fit-check.json](fit-check.json) contains the measurements for the exported default arrangement. Red `clash-*.stl` files isolate the interference regions. The shorter shell also places the button proxy bottom below the enclosure floor with the assumed 22 mm above-panel height; it is not a drop-in solution for this populated layout.

`Show_overlap_warnings` uses fast bounding boxes to select component pairs, then shows their actual modeled overlap in red. Console **bounding-box candidates are not confirmed clashes**: Pi/button and mic/NFC are examples of false positives at the defaults. `Exact_enclosure_collisions` adds magenta intersections against the actual shell meshes and can be slower. Cable reservations are visual only and are excluded from these checks. Moving a part fully outside an opening can avoid surface intersection while still being outside the intended product envelope; inspect both the closed view and coordinates.

Five component exports passed watertightness and winding checks. The GUI position control was exercised and restored. OpenSCAD and independent Manifold intersections agreed within 0.001 mm³ for the speaker/button clash. Moving the mic +10 mm in X was verified to change both X bounds by exactly 10 mm without changing Y/Z bounds. `make check` passed syntax/lint and 217 tests. No physical Pi, audio, GPIO, NFC, Wi-Fi or WhatsApp verification was performed. Physical body measurements, mounting, cable storage, button travel, acoustic alignment and thermal/RF checks remain.

## Refresh exports and fit checks

From the repository root, run the developer helper:

```sh
uv run --with trimesh --with manifold3d python scripts/dev/check-enclosure-layout.py
```

It exports the current **SCAD source defaults**, refreshes component/interference meshes and `fit-check.json`, and checks the original enclosure. It does not apply a saved Customizer preset. Transfer a chosen arrangement into source defaults before using it. It exits successfully when the check ran correctly even if the report contains clashes. The five exports have assembly coordinates; reposition each to the print bed only if printing dummy fit gauges.

Sources checked 2026-09-05. No controlled assembly CAD exists for the retail mic, speaker, button or NFC module in this package; replacing these proxy bodies with measured models is the next step toward proving fit.