There is a computer standing next to most fixed-mount reading stations. It is the weakest part of the station.

It has a fan that pulls in dust, an OS that updates itself at the worst possible moment, a remote-desktop session nobody can reach, and a disk that fails without warning. All so the line can do three things: take a picture, read a few characters, save a row.

That computer needs a cabinet, a power run, a monitor, a keyboard and a mouse — plus somebody on site who knows how to fix Windows.

We put the whole thing inside a single Android tablet.

• The reader stays where it is: a fixed-mount barcode reader that pushes images over FTP
• Image intake, alignment, OCR, field extraction, database and dashboard all run on the tablet
• No industrial PC, no Windows, no second screen, no keyboard

Subtraction, not addition

The real cost of a fixed-mount OCR station is rarely the recognition algorithm. It is the computer that hosts it.

What the line sees: the station goes from a device, a computer, and a person who maintains the computer to a device and a screen.

The chain

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

        Photoelectric trigger
                │
                ▼
┌────────────────────────┐
│  Fixed-mount reader    │
│  ① capture             │
│  ② FTP push (BMP)      │
│  ③ TCP push barcode    │
└───────────┬────────────┘
            │  LAN (wired preferred)
            ▼
┌──────────────────────────────────────────────┐
│  Android tablet (1920×1200 landscape)        │
│                                              │
│  In-house FTP server (port 10070)            │
│        │                                     │
│        ▼                                     │
│  Image hub: only the newest frame is kept    │
│        │                                     │
│        ▼                                     │
│  ORB template alignment → ROI crop →         │
│  PP-OCRv6 → regex                            │
│        │                                     │
│        ▼                                     │
│  AnalysisResult (the single contract)        │
│        ├──▶ SQLite record (+ source image)   │
│        ├──▶ Live dashboard (light / boxes)   │
│        └──▶ Outputs (broadcast/TCP/serial)   │
└──────────────────────────────────────────────┘

Five steps, one pipeline:

1. Intake — the reader pushes an image; the tablet is the FTP server, so nothing is staged and nothing is relayed
2. Locate — ORB feature templates recover each region of interest even when the part sits off-position
3. Read — PP-OCRv6 runs on-device, on the cropped regions only
4. Extract — regex pulls the serial number, lot code and date out of the recognized text
5. Record — result, source image and timing go into a searchable, exportable log

The entire chain is local. No cloud, no second computer, and no dependency on the plant’s IT department.

What is actually inside the tablet

A minimal FTP server, written on purpose

A general-purpose FTP library is heavy, and the reader only ever uses two commands:

1

USER / PASS → PASV → STOR → 226

It does not even send TYPE. It never calls LIST, SIZE, or walks a directory tree.

So the server is ours, and that is not about elegance. It is about controlling every byte of the sequence — so that when a station misbehaves on site, the problem can be located frame by frame instead of guessed at behind a black-box library.

An image hub that only ever holds the newest frame

A production line is not a file backup service. A backlog has no meaning.

• A new image replaces the previous one; nothing queues
• The process holds exactly one full-size bitmap in memory
• If analysis falls behind, frames are dropped and counted — the displayed result never gets stale

ORB templates: teach it once, it finds the regions afterwards

Parts never stop in exactly the same place, so fixed-coordinate cropping always drifts.

• Capture a sample, draw the regions on a full-screen preview (two-finger zoom, finger-accurate)
• Extract ORB features over each region and save them as a binary .feat file
• At run time, match and use the homography to map all four corners of each region onto the current frame

Measured: 48 ms to learn, 143 ms to match, three regions included.

There are exactly two fallback behaviours, and no third:

With several templates, a single “do not fall back” setting makes the whole line behave that way — the strictest rule wins.

Recognition: PP-OCRv6, on-device

The model is a resident singleton, warmed at startup, and swapped by releasing before loading — never two models resident at once.

Regex: only the fields you asked for

• Applied to the full OCR text, not per region — the most commonly misunderstood part
• All rules are evaluated, no short-circuit; priority only sets the output order
• Capture groups win: use the group if defined, otherwise the whole match
• 200 ms timeout per rule, and an invalid pattern only flags itself — it cannot take the other rules down

Changing to a new label layout means redrawing the regions and swapping the rule set. No code changes.

Records you can filter, read and export

One row per result in SQLite, carrying:

• Status (OK / NA) and the failure reason (template not matched / timeout / recognition error)
• Matched fields, full OCR text, timing, model build
• The barcode the reader pushed
• The source image as JPEG quality 85, for human review

The log page filters by date, template and keyword, with paging, detail view, delete, clear and CSV export.

What only shows up on a real line

Two systems can look identical in a demo and separate immediately in a workshop. Everything below came from running this build on a line.

1. No “computer corner” beside the station

A fixed-mount reader is usually mounted on the side or above the line, so the viewing angle is constrained. A PC needs space beside it for a chassis and a monitor, plus a mains run, a video cable and room for an operator.

The tablet compresses all of that into one mount, one network cable, one power feed:

• Wall mount, articulated arm or magnetic base — it goes wherever the reader had to go
• The screen sits within arm’s reach, so the operator sees OK/NG and the annotated image at a glance
• Nobody has to redesign the line layout around “where does the computer go”

2. Power cuts, restarts and shift changes

The real rhythm of a line is: start the shift, power down at lunch, trip a breaker, change over, stop for a while. An industrial PC handles all of this badly — an update stuck at boot, a service that never started, a session nobody logged into, a remote desktop that will not connect.

The tablet’s answer is plain but effective:

• App auto-start plus a resident foreground service — no login, no button to press
• A crash restarts the service; all configuration lives in local storage
• A shift change means looking at the screen to check whether it is green

One less operating system is half the failure surface gone. On a line, that sentence is worth a lot.

3. Fanless, low power, dust-tolerant

The fan in an industrial PC is a vacuum cleaner for the workshop. After a year the heatsink is felted with dust, and by summer the CPU is thermally throttled. The tablet is passively cooled, with no moving parts and no mechanical disk:

• No moving parts means no dust trap
• An order of magnitude less power, so no extra load on the panel
• A toughened glass front wipes clean and tolerates oil mist and coolant splash

4. Changeovers measured in hours, not weeks

Changing product on a PC-based station usually means: edit config → remote in → restart the service → debug on site → drive back when it fails again.

Here, configuration (a template ZIP and a regex JSON) takes effect on import:

5. Roving inspection and temporary stations

Not every position on a line justifies a permanently installed system:

• Incoming inspection — tablet and reader wheeled to goods-in, then wheeled back
• Pilot production — run a new line for two weeks to prove OCR works before committing
• Rotating positions — one tablet serves several stations, with separate configurations

With a PC, monitor and cabinet these cases never pay off. With a tablet, you pick it up and go.

6. Data stays on the device, and the network can fail

• Images, characters and records stay local — nothing goes to a cloud and nothing leaves the building
• FTP, inference and the database all complete on the LAN or on the device
• Lose the internet or the MES and recognition plus the dashboard keep working; output resumes when the link returns

For medical UDI, automotive components and any supplier working on an air-gapped network, this item is often the condition for getting through the door at all.

7. Maintenance: from “owning a computer” to “updating an app”

The compute budget: 6 TOPS the firmware will not hand over

The honest starting point

The tablet we validate on is built on a Qualcomm QCM6690, and the paper specification is not weak:

On the real device, this generation of industrial firmware does not expose the NPU to applications — the neural-network HAL is missing and there is no vendor inference library. That is not unusual. Industrial terminal firmware consistently lags phone firmware by a release or two.

So the route is: do not bet on the hardware; make the CPU fast enough first.

Here is where a frame actually goes (real device, three regions):

Where the NPU will take this in the next year

The on-device software stack changed generation in 2026, which suits a product built once and shipped across hardware generations.

1. LiteRT becomes the single entry point. NNAPI is deprecated; the replacement is LiteRT (formerly TFLite), one API across Qualcomm, MediaTek, Samsung and Google Tensor NPUs, with ahead-of-time compilation and per-device AI packs. It requires API 31+, which the tablet already exceeds.

2. On Qualcomm, ONNX plus QNN. Our models are standard ONNX exported straight from PyTorch, so on Snapdragon they can go through the QNN execution provider to Hexagon directly. No retraining, no framework migration. The same model file runs on the CPU today and the NPU tomorrow.

3. The right split for OCR: detection on CPU, recognition on NPU.

So the realistic speed-up is not “put the whole model on the NPU”. It is hybrid inference: detection stays on the CPU, the recognition batch goes to the NPU. For this workload that cut lands exactly where the payoff is.

4. Order matters: quantize first, accelerate second.

1

FP32 baseline → INT8 quantization → NPU acceleration → vendor tuning

INT8 alone is a 2–4× speed-up that every device benefits from; the NPU is the bonus. Each step is measured on its own — never three changes at once.

Further out: compute moves from the cabinet to the pocket

The roadmap for industrial silicon is already visible. Take a current-generation part such as Qualcomm’s Dragonwing Q-6690:

• 6 TOPS NPU with Wi-Fi 7, 5G and integrated UHF RFID
• Eight years of Android upgrades
• Software feature tiers that unlock compute, multimedia and camera capability over the air

Three consequences, and they are structural for line-side systems.

a) One board, capability that grows in software. Ship it today as a barcode terminal; unlock an NPU tier next year and the same unit runs OCR, defect detection and voice commands. Design the hardware once, differentiate in software. Standard ONNX plus a standard runtime is how we stay eligible for that.

b) Portable compute: from fixed station to mobile station.

c) The metric shifts from peak TOPS to sustained milliwatts. A line does not need a benchmark score. It needs eight continuous hours without throttling, without a hot back panel, without dropped frames. Low-power NPUs and compute-in-memory matter precisely because industrial systems are never switched off.

For the next two years, “portable, offline, and enough compute” will be worth more than “the most compute”. What is genuinely scarce on a line is not TOPS — it is a box that mounts beside the station, needs no operator, and comes back up after a power cut.

Engineering, not a demo

A few rules that keep it from becoming a demo:

• core-* never depends on UI and never returns Chinese — it returns stable codes, and the UI maps them into three languages
• One result contract: AnalysisResult, used by the database, the UI and every output channel
• Consumer faults are isolated: a failed database write cannot break the UI, and a broken UI cannot stop the pipeline
• Verification runs with --rerun-tasks — incremental builds produce false successes
• Device testing goes through one smoke script: at most five adb calls per round, and anything provable by unit test never reaches hardware

Scope: what it does, and what it refuses to do

It does:

• The full chain locally: intake → recognition → field extraction → record → dashboard
• Template and regex import/export (a template is a single ZIP: sample image, features, parameters)
• Three-language UI, multiple license keys, capability unlocking per feature
• Record filtering, detail view and CSV export

It refuses to:

• Reader: a fixed-mount reader that can push images over FTP (BMP) and optionally push the barcode over TCP. Other models are supported case by case.
• Tablet: Android 10 or newer, landscape, 1920×1200 or better. Our validation device runs Android 16.
• Network: same LAN as the reader, wired strongly recommended (a USB-C or dock Ethernet adapter is the simplest route).
• Configuration: one template per label layout — regions drawn once, plus one regex set. A new layout is a new template, not a code change.
• Speed: ~240 ms end to end per frame at three regions on this hardware. If your cycle time is shorter than that, we need to talk about the layout — usually fewer regions or a smaller crop solves it.
• Interface language: Chinese today, English build in progress.
• Output channels: broadcast and TCP are available; serial and Modbus are being completed in the current phase.
• Grading: reference-grade, not a certified verifier.

What is next

• Serial and Modbus transports, so results reach a PLC directly
• Barcode grading in the same capture — content and quality from one image
• NPU enablement along both routes (LiteRT and QNN), quantizing before accelerating
• Multi-station expansion, automatic record retention, export progress feedback

We do not build universal recognition. We build the version that keeps running on a line.

Try it with your own parts

Three steps to a working station: install the APK → enter the reader’s IP and the FTP target → draw the regions and set the rules. From unboxing to the first record takes hours, not weeks.

The Android tablet edition is available as a build option — pricing and the custom-option list are on the Fixed-Mount OCR pricing page, and a free 30-day trial runs on your own reader and your own parts.

Related reading: Fixed-Mount OCR V2 covers the PC-based line edition and barcode grading, On-Device AI on Android explains what an NPU can and cannot run today, and Barcode Quality Grading covers the grading engine this build reuses.

💬 Questions or a custom requirement?

Tell us what your station looks like — the reader, the part, the fields and the cycle time — and we will set up a fast, tailored build, including a trial on your own samples.

📧 sales@happylab.me · 🌐 global.happylab.me

HappyLab builds practical AI and browser-based tools for industrial device workflows.