# Provisional carrier module footprints

These project-local footprints are in `Carrier.pretty`. They are mechanical
starting points, **not fabrication-ready connector selections**. Both are now
assigned to their matching symbols in the native schematic through the project
library tables and used in the routed PCB draft. The assembled module 3D models
are not provided. See `pcb-draft-notes.md` for placement/routing and
`rs232-footprint-notes.md` for the additional provisional RS-232 reference footprint.

## Shared pad/drill provenance and limits

Reference inspected locally: installed KiCad library footprint
`Connector_PinHeader_2.54mm:PinHeader_1x04_P2.54mm_Vertical`, file
`/usr/share/kicad/footprints/Connector_PinHeader_2.54mm.pretty/PinHeader_1x04_P2.54mm_Vertical.kicad_mod`
(format version `20260206`; local KiCad `10.0.6-1.fc44`).

Both footprints use that reference's **1.70 × 1.70 mm plated through-hole pads,
1.00 mm drills, rectangular pad 1, and circular remaining pads**, on
`*.Cu` and `*.Mask`, with unused copper layers retained. Nominal pitch is 2.54 mm.
Only the reference's pad/drill convention is reused, not its connector body,
courtyard, or 3D model. HW678 pad 23 is circular: only overall pad 1 is rectangular.

**PROVISIONAL connector fit — awaiting the selected actual pin/socket datasheet.**
Breadboard fit supports centre spacing, not drill size, finished-hole tolerance,
annular-ring suitability, socket body clearance, mating height, or solderability.
Validate those against the actual final headers and beta-test sockets and the PCB
fabricator's process before release. No electrical nets or ESP32 GPIO assignments
are inferred. No courtyards are supplied: module/connector assembly clearances
remain incomplete, so automated courtyard checks cannot establish fit.

Coordinates below are millimetres, unrotated on the carrier front side, X right
and Y down. Views are not mirrored. Placement on the back side or viewing the
module from its solder side requires the appropriate KiCad transform; do not
silently reverse the numbering.

## `Carrier:OLED_26mm_I2C_Provisional`

Origin: top-left corner of the module PCB, viewed from the front/display side,
header at the top. User-verified geometry from the current request and the later
mechanical-evidence section of `README.md`:

| Pad | Signal | X | Y |
|---|---|---:|---:|
| 1 | GND | 9.19 | 1.50 |
| 2 | VCC | 11.73 | 1.50 |
| 3 | SCL | 14.27 | 1.50 |
| 4 | SDA | 16.81 | 1.50 |

- PCB boundary: (0, 0) to (26, 26), solid rectangle on `F.Fab`.
  This depicts the module, not the carrier's routed edge; no `Edge.Cuts` is used.
- Four unnumbered, non-plated through holes, diameter 2.00 mm, at
  (1.75, 1.75), (24.25, 1.75), (1.75, 24.25), (24.25, 24.25).
  Hole centres are 1.75 mm from adjacent edges, with 22.50 mm spacing in both axes.
  These transfer the verified module hole geometry to the carrier; they do not
  select screws, inserts, bosses, or hardware clearance envelopes.
- Display boundary: (1, 4.5) to (25.5, 21), 24.5 × 16.5 mm, dashed on `F.Fab`.
  This is the supplied display boundary, not a verified active-pixel area or case cutout.
- Pad-to-signal mapping is documented here and in the footprint description;
  footprint pads themselves have numbers, not assigned nets.

The approved geometry supersedes the earlier 22.16 mm hole-spacing measurement:
22.50 mm hole spacing, Y=1.50 mm header centres, and the centred header coordinates
above apply. See README for the user-reported successful template fit check.

## `Carrier:HW678_2x22_Provisional`

Component/top view: antenna up, USB connectors down. Origin is the top-left header
centre (pad 1), **not a PCB corner**.

- Left row: pads 1 through 22, top to bottom, X=0.
- Right row: pads 23 through 44, top to bottom, X=25.40.
- Y=0 through 53.34 in 2.54 mm increments for each row (21 intervals).
- User breadboard fit verifies nominal 2.54 mm pitch and 25.40 mm row spacing;
  these supersede the earlier raw caliper dimensions in README.
- Numbering follows the project's explicit convention, not a generic dual-row
  connector's alternating or counterclockwise numbering. Physical numbers do
  **not** establish GPIO, supply, or ground assignments.
- Only pads and annotation text are present. **No PCB outline, antenna keepout,
  courtyard, USB envelope, mounting holes, or 3D model is guessed.** Text positions
  are annotations, not dimensional evidence. Outline registration, antenna extent,
  connector offsets/overhang, and assembly height remain unknown.

## Validation and release gates

Validation performed with KiCad 10.0.6 `pcbnew.FootprintLoad`: both footprints
parsed successfully. Assertions passed for pad counts, all numbered pad positions,
pad shapes/types/sizes/drills, OLED NPTH positions and diameters, both OLED `F.Fab`
rectangle bounds, and absence of courtyards, `Edge.Cuts`, and keepout zones.
HW678 was also checked to contain no graphical shapes. The local Python binding
emitted three startup `PROPERTY_ENUM` assertions (also seen on a version-only
import); these did not prevent loading or the checks from passing.

Repeat the retained footprint regression checks from the repository root with:

```sh
/usr/bin/python3 -B hardware/PCB/validate_footprints.py
```

This requires the system Python with KiCad's `pcbnew` binding. It checks the
native-loaded pad counts, coordinates, pad types, sizes, drills and geometry. Parsing is
not DRC, electrical verification, connector fit verification, or fabrication approval.
Print both footprints at 1:1 and check the real assemblies, especially HW678 row
numbering/orientation. Before layout release, select and verify connectors, map
HW678 pins from reliable board evidence, and establish module envelopes,
antenna restrictions, USB access, mounting hardware, and courtyards.