ASQUARETE

Case study

Field tag audits without a laptop — Chainway C5, Belgian minerals inspection company

A Belgian minerals inspection company needed to audit RFID-tagged sample containers at remote sites with no network and no laptop. A Chainway C5 offline app captures filtered reads and exports CSV over email at the end of a visit.

Device · Chainway C5Role · Offline-first Android field appStack · Android, Kotlin, SQLite, Chainway UHF SDK

A Belgian minerals inspection company audits RFID-tagged sample containers at quarry and processing sites, many of which have no reliable network connectivity and no realistic way to bring a laptop into the field — inspectors work outdoors, in dust and weather, with one rugged handheld and nothing else. Their existing process involved manually logging container IDs on paper at each site, then transcribing them into a spreadsheet back at the office, which introduced transcription errors and meant a full day's lag between a field audit and having usable data.

The requirement was an Android app on a rugged handheld that worked completely offline for the duration of a site visit, captured only the tags relevant to that day's audit (not every tag within radio range, since sites often have adjacent unrelated stock), and produced a clean export at the end without requiring any other computer.

The problem

Two separable problems, both real. First: sites frequently have RFID-tagged material from unrelated shipments sitting nearby, and a naive bulk read at a site picks up tags that have nothing to do with the audit in progress — the app needed a way for the inspector to scope a read to "this audit" without pre-loading an exact tag list, since the whole point of an audit is discovering what's actually present.

Second: the entire workflow had to survive with zero connectivity from the moment the inspector left the office to the moment they were back at a desk with wifi. That ruled out any design that assumed a background sync call, a cloud lookup for tag metadata, or a server-side session ID.

Hardware used

ItemRole
Chainway C5Rugged Android handheld, integrated UHF RFID module
Chainway UHF SDKBulk tag read, RSSI reporting
SQLite (on-device)Local session store — audit sessions, captured EPCs, timestamps
Android email intentCSV handoff at end of visit, no server round-trip

Architecture

Everything runs on-device. An inspector starts a new "audit session" (a site name and date, entered locally, no network call), then does one or more scan passes. Each pass is scoped by an RSSI floor set at the start of the session — tags below the floor are treated as "not physically at this station" and excluded, which handles the adjacent-stock problem well enough in practice without needing a predefined tag list.

[Start audit session] --local record, SQLite--
        |
        v
   [Scan pass 1] --RSSI floor filter--> [session EPC set]
   [Scan pass 2] --dedup against set -->      |
        |                                     |
        v                                     v
   [Inspector reviews captured list on-device]
        |
        v
   [Export CSV] --Android share/email intent--> office inbox

At the end of a visit, the inspector reviews the captured EPC list on-screen (count, timestamp, RSSI per tag) before exporting. Export writes a CSV to local storage and hands it to Android's native share intent, which the inspector routes to an email app already configured with offline send-on-reconnect — the phone doesn't need connectivity at the moment of export, only at some point before the message actually needs to leave the device.

What was tricky

The RSSI-floor-as-scope-boundary approach is a compromise, and it was worth stating that plainly to the client rather than pretending it's precise. It works well when the audit target is physically separated from adjacent stock by a few meters, which is true at most of their sites, but it degrades at sites where unrelated tagged material sits close to the audit target. The honest fix — requiring line-of-sight antenna orientation and a lower fixed power setting during capture — was a training change for inspectors, not a code change, and took longer to land than the software did. No amount of filtering logic replaces an inspector holding the reader the right way.

The other real difficulty was testing an offline app being actually offline. It's easy to build something that works with airplane mode on in an office and still have it silently depend on a cached DNS result or a background service that assumes it'll get a connection eventually. Testing meant putting the device in a Faraday-adjacent state for hours at a time and confirming the SQLite-backed session survived an app kill and device reboot mid-audit, not just an airplane-mode toggle.

Result

Field audits that previously required paper transcription and a next-day office pass now produce a CSV within minutes of leaving a site, with zero transcription step. Across the first quarter of use, the client reported catching two sites with adjacent-stock RSSI overlap in the field rather than discovering the data was contaminated back at the office — a problem that, under the old paper process, would only have surfaced as an unexplained inventory mismatch weeks later.


Role · Offline-first Android field app

Stack · Android, Kotlin, SQLite, Chainway UHF SDK

Updated Jan 8, 2026

Similar hardware on your desk?

Send the device model, the SDK, and what's failing. You get a written feasibility read within 24 hours.

Get a feasibility read

Another case study