Prototype to outlet: a scoop weighing station

A weighing station checks that every scoop of ice cream in an order matches its target weight before the order leaves the counter. Ours scans the order QR, tares the cup, guides staff scoop by scoop, checks pack barcodes and uploads the result. One unit runs in an outlet today.

What problem does a weighing station solve?

A weighing station solves portion drift. When staff fill hundreds of cups a day by eye, some scoops run heavy and some run light. Heavy scoops give away margin. Light scoops disappoint customers. Neither shows up in the sales report, because the POS only knows that “one single scoop” was sold.

ScoopScale is the station we built for Natural Ice Cream outlets to close that gap. It sits on the counter beside the POS. The POS prints or shows a QR code for each order. Staff scan it, and the station walks them through the order one item at a time.

Three design rules came from the start, and they shaped everything later:

• The users have limited time and often limited literacy in English. The screen uses very large text, few words, strong colours, sounds and an LED on the scale.
• Staff must never need to press tare. The station handles the cup weight itself.
• The outlet’s Wi-Fi is not reliable. A result must survive a dropped connection.

We describe it here as a case of hardware work in general. The same path, from a prototype on a desk to a unit in daily use, is where most hardware projects meet their real problems.

How does the station guide an order?

The station guides an order as a sequence of small steps, each with one clear instruction and one clear result.

1. Scan the order QR. The code carries the order token and a list of items. Each scoop item has a target weight in grams and a tolerance. Each pack item has an expected barcode. The whole code is rejected if it is malformed, so a half-valid order never starts.
2. Show the item. The screen shows the item’s full name, the step count (for example 1 of 4) and the target weight.
3. Weigh scoop items. Staff put the cup on the scale. The station subtracts the cup weight, then shows add more, take some out, or OK. When the weight sits inside the tolerance and holds still for about a second, it beeps and moves on.
4. Scan pack items. Packs such as family tubs are never weighed. Staff scan the barcode on the pack, and the station checks it matches the expected code. A wrong pack shows a clear warning and what was needed.
5. Finish and upload. When every step is done, the result goes to the server: order token, device, status, start and finish times, and each item’s target and actual weight.

A cancelled order is also sent, with only the completed steps and a status that says so. That matters for audit: a half-finished order is information, not noise.

The “hold still” rule deserves a note. A scale reading jitters when a cup is placed or lifted. Accepting the first in-range number would give false passes. Requiring a stable reading for a short time removes most of those, and lifting the cup mid-weigh returns the screen to “put cup on”, so staff cannot game it by hovering.

What hardware is inside the prototype?

The prototype is three off-the-shelf modules wired together: a small display controller with a speaker, a scale unit with a load cell amplifier, and a 2D code scanner.

• Display and controller module. Runs the firmware, shows the screen and plays sounds. It has no extra memory chip, so screen buffers live in internal RAM.
• Mini scale unit. Measures weight and shows status on its own RGB LED. It talks over I2C.
• 2D code scanner module. Reads order QR codes and pack barcodes over a serial link, set to auto-sense mode with a carriage-return suffix.

Using ready-made modules was the right call for the first unit. It let us test the workflow in an outlet within weeks, before spending anything on custom boards. The cost of that choice shows up later: loose cables, a case that is not built for spills, and a firmware update that needs a USB cable.

Setup is also done by QR code. A standard Wi-Fi QR, the kind a phone generates from its share screen, joins the station to the outlet network. A separate set of admin QR codes, protected by a key compiled into the firmware, sets the server address and device name, starts cup setup, or runs a scale check against a reference weight. No laptop is needed at the outlet.

What do you learn when a prototype meets a real counter?

You learn that the failure cases matter more than the happy path. A counter is wet, busy and loud, and staff are trained to serve customers, not to debug devices.

Four lessons came out of the first outlet:

Queue everything. Wi-Fi drops. The station stores finished results and retries sending them, so the count of pending results is visible on the ready screen. Nothing is lost, and the outlet manager can see if something is stuck.

Make errors say what to do. A message such as “BAD CODE” is too vague alone. “SHOW MANAGER” tells the person at the counter what the next action is. Each error screen has a colour, a sound, and a single next step.

Protect the settings. Wi-Fi can be re-joined by anyone, because a locked-out outlet cannot work. The server address and device ID need the admin key, because changing those silently would break reporting.

Plan for the scale drifting. Load cells change with temperature and wear. A scale check mode, driven by an admin QR and a reference weight, lets a manager confirm the station still reads correctly without any tools.

None of these appeared in the first design review. They appeared in the first week of use.

What changes in the next hardware generation?

The next generation replaces the stacked modules with a custom carrier board and a proper enclosure, and adds remote management so a unit can be updated without anyone visiting the outlet. It is designed and ready, but not yet manufactured.

• Custom board. An ESP32 carrier board designed in KiCad. The design-rule checks pass and the factory files are ready for a PCB assembly service. Moving from loose modules to one board removes the cable faults and makes each unit identical.
• Enclosure. Parametric 3D-printed enclosures, with checks for spill-proofing. Parametric means the dimensions come from a few numbers, so a change of display or scale size is an edit and a reprint.
• Remote updates. Signed over-the-air firmware updates, with automatic rollback if a new version fails to start, delivered over encrypted MQTT.

The over-the-air part is the highest priority, so it is worth explaining. A device keeps a connection to a broker. The server publishes a “desired” state for each device: settings, and a signed firmware manifest. The device publishes a “reported” state: what it is running now. When desired and reported differ, the device acts. For firmware, it downloads the image, verifies the signature itself, writes it to the inactive partition, restarts into it, and confirms it is healthy. If it does not confirm in time, the bootloader goes back to the old version.

Two details make this safe. The device checks the broker’s certificate against a root certificate built into the firmware, so it cannot be redirected to an impostor. And updates are signed, so a compromised download server cannot push firmware the device will accept. Each device has its own credentials and can see only its own topics.

How do the prototype and the next generation compare?

The table below sets the two side by side. The first column is in daily use. The second is designed and waiting for manufacture.

Aspect	Prototype in the outlet	Next generation
Electronics	Off-the-shelf modules, wired	Custom ESP32 carrier board
Enclosure	Basic case	Parametric 3D-printed, spill-proofed
Firmware updates	By USB cable	Signed over-the-air, with rollback
Result upload	HTTP to an endpoint	Encrypted MQTT, queued when offline
Device identity	Settings entered by QR	Hardware ID with per-device credentials
Status	One unit in daily use	Designed, factory files ready, not yet made

We are careful about the last row. The honest description is a unit in daily use at an outlet, with a pilot rollout planned. It is not a fleet, and we do not claim one.

Should you build or buy a station like this?

Buy a standard commercial scale if the only need is to read weight. Build a station when the weight must be checked against the order, because that means joining the scale to your POS data and your workflow.

A general-purpose retail scale tells you a number. It does not know that this cup should hold 80 grams of mango with a tolerance of 8, or that the next item is a sealed pack to be scanned. That logic lives in the order. So the value of a custom station is the link between the physical world and the order record, plus the checks staff cannot skip.

Questions to ask before starting:

1. How big is the loss? If portion drift costs little, a poster of scoop sizes may be enough.
2. Who uses it? Design for the least experienced person on the busiest shift.
3. What happens offline? Decide it on day one.
4. How will you update it? If the answer is “someone with a cable”, plan for that cost across every unit.
5. Who owns the order format? Agree the QR payload with the POS team early, since both sides must change together.

Where does this fit in the wider platform?

The station is one part of the Restrologic work for Natural Ice Cream, where the same company runs its outlets on our POS suite. The order QR comes from the POS, so the station and the till agree on what was ordered. Read the full Natural Ice Cream case study for the platform side, and the ScoopScale product page for what the station does and its current status.

If you run a food business and portion control, packing checks or counter automation are costing you money, our hardware and IoT service covers prototypes through to production boards and firmware. The restaurant industry page shows how this fits with POS and reporting. Our article on the read-only analytics agent shows how station data could feed an owner’s questions later. To talk about your counter, use the contact page. We will ask about your volumes and your staff before we suggest any hardware.