Two printable ESP32-S3 bench parts

Downloads and method·Not a build-log

Two STL files you can download from this page. A bench plate that parks a half-size (BB400) solderless breadboard and an ESP32-S3-DevKitC-1 side by side, and a fit gauge whose six stepped channels exist to measure the one dimension this repository could not source from an authority.

Read this before you download. These files have not been printed — not by me, not by anyone I know of. They are geometry that has been checked by code and by nothing else. What was checked: nine dimensional assertions run against the finished solids by tools/print/test-fit.cjs, and an independent re-read of the written STL bytes by tools/print/verify-stl.cjs. What was not checked: a printer. There is no photo of either part, no measured tolerance, no material or print-time result, and no report from anyone who has used one. This page is a download plus the method behind it. It is not a write-up of something that got made.

Everything dimensional below is either a parameter you can read in tools/print/models.cjs or a bounding box that came back from re-reading the binary STL files that this page serves. Where a parameter is marked UNVERIFIED in the generator, this page says so instead of quietly rounding it into a fact.

The bench plate

esp32-bench-plate.stl — 120.3 × 63.1 × 5.6 mm overall, 96 triangles, 4884 bytes. Two bays side by side on one slab, so tugging a jumper wire at one end does not drag the whole arrangement across the desk.

Top-view outline of the bench plate: a wide rectangular bay on the left for a breadboard, a narrow bay on the right for a devkit, a divider between them, and two gaps in the rear wall over the left bay.

Breadboard bay — 84.1 × 55.1 mm. That is the BB400 footprint of 83.5 × 54.5 mm in models.cjs plus 0.6 mm of clearance for moulding draft. The half-size breadboard footprint follows from the 2.54 mm tie-point pitch rather than from any one vendor's tooling, which is why models.cjs is willing to state it: it is consistent across suppliers to a few tenths of a millimetre.
Devkit bay — 26.2 mm wide, and open at both ends. Only the width constrains anything. The front and rear walls stop at the divider, so a board longer than the plate simply overhangs at both ends instead of colliding with a wall.
Two cable notches, 12.0 mm wide, cut into the rear wall over the breadboard half, so wires leave the plate rather than getting pinched under it.
Walls 2.0 mm thick and 3.2 mm tall above a 2.4 mm base. That height retains parts without burying the pin rows you need to reach with a probe.

The fit gauge, and the number nobody could source

The header comment in models.cjs is blunt about the problem: the DevKitC-1's board outline could not be obtained from an authority — the vendor's board page renders its content with JavaScript, and the dimensions PDF it links to returns a 404. This site's hardest rule is that no hardware fact may be invented. So the width parameter stays marked UNVERIFIED in the generator, and the gauge exists to replace it with a reading.

Why this page will not tell you the board's width. Searching for the width of an “ESP32 DevKitC” hands you a confident number. That number belongs to a different board in the same family, and copying it across would be exactly the fabricated hardware measurement this site refuses to publish. The generator carries a placeholder so that it can emit geometry at all, and labels it UNVERIFIED; the only figure quoted below that touches it is the test suite's own line calling it a guess. Six stepped channels are cheaper than a wrong number: print the gauge and the board itself tells you.

esp32-fit-gauge.stl — 83.4 × 109.8 × 5.4 mm overall, 408 triangles, 20484 bytes.

Top-view outline of the fit gauge: six pairs of parallel walls forming channels, arranged two across and three down, each with a group of small ribs beside it.

Six U-channels: 24.6, 25.0, 25.4, 25.8, 26.2 and 26.6 mm. A 0.4 mm step between neighbours, so a reading is good to that step and no better.
How you read it. Lower the board into each channel from above. The narrowest channel it settles into without being forced is the one to report.
Rib count identifies the channel. One rib beside the narrowest, six beside the widest; ribs are 1.6 mm wide on a 3.2 mm pitch, 5.0 mm long and 1.2 mm tall. The count survives you putting the part down and picking it up again, which a printed-on label at this size would not.
Channels are 16 mm long and open at both ends, so you engage a short section of bare PCB edge instead of fighting the pin headers.
Laid out two across and three down rather than in a line. In a single row the same six channels come to a 213 mm strip, which only just clears a 220 mm bed and wastes most of the plate.

Which numbers are asserted, and which are not

Provenance of every parameter in `tools/print/models.cjs`
Parameter	Status
Breadboard footprint, 83.5 × 54.5 mm	Standard BB400 half-size footprint, fixed by 2.54 mm pitch. Bay span asserted by `test-fit.cjs`.
Breadboard clearance, 0.6 mm	Design choice. Asserted only in the sense that the bay is neither undersized nor sloppy.
Devkit board width	UNVERIFIED in `models.cjs` — a placeholder, never sourced, never measured. This page does not restate it as a fact about the board. It is the number the gauge exists to measure.
Devkit board length	UNVERIFIED in `models.cjs`. Made harmless by leaving the bay open at both ends — `test-fit.cjs` asserts that openness directly.
Devkit clearance, 0.8 mm	Design choice. The intent is that a full millimetre of error in the unverified width would still leave the bay usable; nothing has tested that, because nothing has been printed.
Devkit bay, 26.2 mm	Follows arithmetically from an UNVERIFIED input, so treat it as a guess with a margin. The finished span is asserted by `test-fit.cjs`; what it is a good span for is not.
Six channel widths, 24.6–26.6 mm	Asserted: `test-fit.cjs` measures each finished channel against its stated width.
Base 2.4 mm, walls 2.0 mm × 3.2 mm, notches 12.0 mm	Design choices, read straight from the parameter block.

What the checks actually check

node tools/print/test-fit.cjs takes a scan line across the finished solids at wall height and reports the clear span, the way a caliper would, rather than trusting the arithmetic that produced them. Nine assertions pass:

bench plate
  ok   the breadboard bay is wide enough for a BB400, and not sloppy
  ok   the breadboard bay is DEEP enough, and not sloppy
  ok   the devkit bay holds the board width with the intended clearance
  ok   the devkit bay is OPEN end to end, so an unverified board LENGTH cannot bind
  ok   the rear wall really is notched for cables
  ok   nothing overhangs: every solid sits on the base or on another solid

fit gauge
  ok   every channel measures its stated width
  ok   the ribs never intrude into a channel
  ok   channel widths bracket the nominal 25.4 mm guess in both directions

9 assertion(s) passed

That third assertion is worth reading carefully. It checks the bay against the parameter, not against a real board — it confirms the generator did what the parameter block asked for, which is a different and much weaker claim than "your board will fit". The same measurement pass earned its keep during design: a stray 4 mm term had inflated the devkit bay to 30.2 mm, four millimetres of slop that the arithmetic hid and the scan line caught.

node tools/print/verify-stl.cjs then re-reads the bytes that actually landed on disk with a separate parser, on the principle that a generator validating its own memory says nothing about the file. Run against the two STLs this page serves, it reports 408 triangles for the gauge and 96 for the plate, both sitting exactly on Z=0, with every facet normal agreeing with its winding order. The two preview images above are that tool's own output, not drawings made by hand.

Downloads

esp32-bench-plate.stl (4884 bytes) · top-view preview (SVG)
esp32-fit-gauge.stl (20484 bytes) · top-view preview (SVG)

Both are binary STL in millimetres, sitting on Z=0, so they import at the right scale and orientation without anything to correct in the slicer. They are served from this site — the same bytes the repository holds, not a re-export from somewhere else.

Printing them

Both parts have a flat bottom, nothing overhangs, and the tallest feature on either is 5.6 mm, so as guidance: lay them on the bed as they arrive, and you should not need supports, a raft or a brim. PLA is fine — neither part carries load or heat. 0.2 mm layers, three perimeters and light infill are plenty; these are bench furniture, not machine parts, and there is nothing to gain from a slow profile.

The repository README puts the gauge at roughly fifteen minutes. Treat that as a rough estimate with no slicer behind it and no printer behind it either — slice the file and believe your own number.

Print the gauge first. It is the smaller part and it is the one that turns the unverified width parameter into a measured one, after which the generator emits a plate sized to the board rather than to a guess.

What this page does not claim

That either part fits anything. Nobody has put a board in one.
Any tolerance, surface finish, stiffness or material result. None was measured.
Any print time observed on a printer. None was observed.
That anyone has downloaded, printed or used these files.

← All electronics build-logs