Four Enclosure Revisions and What We Still Don't Know

We’ve been prototyping PayTable Cube v2 since February. The hardware brief was clear enough: a 58mm table station for restaurants, running on battery, displaying a QR code for menu access and payment, durable enough for a commercial hospitality environment.

Four enclosure revisions later, we’re still prototyping. Here’s what we’ve learned and what’s still open.

The hardware stack

The current iteration runs on the Waveshare ESP32-S3-Touch-LCD-1.85 — an all-in-one module that combines the ESP32-S3 SoC, a 1.85" round 360x360 capacitive touchscreen, and the CST816T touch controller on a single board. We moved through an Arduino Giga R1 WiFi and an ESP32-S3 DevKit before landing here.

The consolidation onto one module matters in a way that isn’t obvious from the spec sheet. Fewer discrete components means fewer soldered joints, fewer connectors, fewer things to reseat when a device gets bumped. In a restaurant environment, that’s not a marginal gain.

The PN532 NFC reader is gone. The physical button is gone. The interaction model is now three touch gestures: single tap to wake, double tap to call the waiter, long-hold five seconds to open the WiFi provisioning portal. That simplification is a direct result of watching what guests actually do — or don’t do — with hardware at a table.

The enclosure problem

The enclosure is 3D-printed PLA/PETG, parametric OpenSCAD. Every revision has been driven by something we didn’t know we didn’t know.

Revision 1 established the outer form. Revision 2 addressed the lens fitment — getting a PMMA cover lens to seat flush and stay there without adhesive that would complicate serviceability. Revision 3 was the sealing geometry: we’re targeting IP54, which means meaningful dust and splash resistance. That requires a PORON foam gasket compressed consistently across the lens interface and a silicone dust plug on the USB-C port. Getting both without the gasket extruding or the plug seat cracking under compression took iteration.

Revision 4 addressed cable routing and the assembly sequence — the order in which you install components matters when the tolerances are tight and you can’t reach a fastener once another component is in place.

We don’t know yet what revision 5 reveals.

The known unknown

The Waveshare display module uses mineral glass, not chemically strengthened glass. This is documented in the module specs and we’re not ignoring it.

In a restaurant environment, the cover glass gets wiped down multiple times a day with whatever the staff has on hand — cloth, paper towel, occasionally something abrasive. Scratch accumulation over six to twelve months of that is an unknown. Mineral glass is more susceptible than chemically strengthened glass (Gorilla Glass and equivalents). Whether the scratch rate in practice is acceptable, imperceptible, or a problem — we don’t have that data yet.

That’s one of the things a prototype phase is for.

The firmware

The device polls table status via GET /api/v1/Nfc/TableStatus every 30 seconds and renders a QR code with the embedded PayTable logo for menu and payment links. The QR is dynamic — it updates on state change.

The provisioning flow uses a captive portal triggered by the five-second long-hold. This is the primary method for getting a new device onto a restaurant’s WiFi without physical access to the device internals.

Build environment

One operational note: if you’re building for the ESP32-S3 on a Mac with Apple Silicon, plan for friction. The bootloader entry sequence requires a specific chord that reliably requires a powered USB hub in our setup. The PC is the primary dev machine for a reason.

What we’re not claiming

We’re not shipping v2. We don’t have a launch date. What we have is a prototype that has taught us things the spec couldn’t, an enclosure that’s on its fourth revision for good reasons, and a hardware platform we’re more confident in than we were in February.

The next revision will reveal something. That’s the point of doing them.