From Conveyor Prototype to an Auditable SIM-Card OCR Pipeline

Returned-device operations can leave teams with batches of physical SIM cards to identify, record and reconcile. Reading tiny printed numbers by hand is repetitive. A single wrong digit can associate a card with the wrong record.

I started by connecting physical handling with image capture and structured extraction. The most demanding work came after detecting the cards: a detector can find a SIM reliably while OCR produces a valid-looking, high-scoring number that is wrong.

Finding the card was the beginning. Reading every digit needed its own evidence.

That shaped the system around exact identifier matching, visible source evidence, recoverable processing and explicit acceptance decisions.

The original prototype explored a custom dispenser and nine-card capture. The current pilot uses hand-loaded conveyor batches. The ESP32 controls belt movement; the Raspberry Pi handles the camera and card detection.

The dashboard coordinates loading, positioning, capture and submission. It shows a live preview with detection overlays, saves the original frame and individual native-resolution crops, and preserves run and batch state across interruptions.

Historical prototype: dispenser demonstration and original interface

These earlier development materials show the mechanical and interface work that preceded the hand-loaded Paddle/Kimi pilot. They document the project's history; the deployed architecture is described below.

Play Prototype Demo

Generic OCR and larger vision models did not consistently separate identifiers from manufacturing codes or read stacked digits in the right order. Prompt and image-preparation experiments helped unevenly. A separate reader-and-selector experiment also failed to improve the debugging batch.

I moved to a controlled training workflow: 40 labelled photographs, evenly split between MTN and Vodacom, representing 39 physical cards. I grouped duplicate photographs by physical card, linked reviewed line crops to source coordinates, and separated training, validation and test cards. This made model adaptation measurable without counting related images as independent examples.

Fine-tuning gave me a domain-adapted recognizer. The remaining errors showed where to work next: orientation, merged rows, text selection and identifier assembly.

The larger gains came from preparing text for the trained model. I isolated the card from the green conveyor, used the clipped corner as an orientation hint when its outline was trustworthy, corrected residual skew, and separated rows the text detector had merged.

When primary extraction remained unresolved, whole-card alignment and an additional reading path recovered supported text. Identifier selection excluded logos, manufacturing codes and neighbouring cards. Inference still begins with a full SIM crop; the operator does not have to crop the identifier.

Model adaptation and image geometry solved different parts of the problem. Training alone could not recover text the pipeline never presented correctly.

A format expectation is a warning signal, not permission to manufacture a correction. Unfamiliar layouts and unclear digits still require supporting image evidence.

Capture and detection run on the Pi. Live recognition runs in the demand-only cloud worker, with selective visual verification and results returned to the dashboard.

The Pi records images and pending delivery before sending them. Stable identifiers and hashes bind retries to the same work. Backend acknowledgement confirms durable receipt; OCR completion is a later event. Each stage exposes its own status and failures.

Complete Paddle readings can be accepted when source, provider format and selected text-region checks pass. Weak, missing or conflicting readings go to Kimi K3 with the original image, selected deskewed views, relevant text rows and Paddle's output.

Kimi may confirm a weak reading or make an image-supported correction. Acceptance also checks response structure, legibility, printed groups and provider format. Unresolved digits, source or provider conflicts, and a contradiction of an otherwise strong, unflagged Paddle reading remain review cases.

The Pi replay corresponds to approximately five cards per minute, excluding startup. This is sequential OCR throughput on that benchmark, not end-to-end conveyor throughput or a cloud-worker rate. The live Pi service continues to run capture and detection, with OCR in the cloud.

The next accuracy milestone is a larger, independently labelled set of previously unseen physical cards, with varied print formats, orientations and capture conditions. Exact identifier errors, unresolved outcomes, unnecessary review and latency need separate reporting.

Each card links its original frame, native crop, raw OCR, selected text-region scores, judge reading and explanation, and final acceptance or review status. A review pop-out brings the evidence together so an operator can identify which stage made a mistake.

Corrections preserve the original extraction and record the operator's decision. A late cloud result cannot overwrite an existing operator review. Recovery, evidence and the review interface are part of OCR quality: an unexplained result is difficult to trust or improve.

The work spans mechanical design, embedded control, computer vision, model training, cloud delivery and application development. The useful evidence of that breadth is in the decisions and their measured consequences.

The pilot connects capture, durable delivery, on-demand recognition, selective verification, result storage and review in one working system. Continued validation determines how far it can be trusted on a customer's cards and process.

The commercial objective is to reduce repeated transcription while keeping exceptions visible and records traceable. A customer evaluation should establish actual error rate, review workload, throughput and cost against that customer's baseline.