Wearable scanner for parcel delivery: what a delivery round actually demands

A wearable scanner earns its place on a delivery round when three things are specified for a vehicle rather than a warehouse: which device is the host, where scans wait when the signal dies, and how the unit is charged and handed between drivers. Everything else — optics, mounts, picking economics — is the same problem the distribution center already solved.

In short:

• The delivery host is either the driver's phone, which is the topology the R43 page describes when it states the ring "can be paired with any Android, iOS or Windows device", or a vehicle terminal such as the M93, published as a "4G Rugged Handheld PDA 2D Barcode Scanner Android 12 with GPS NFC WIFI".
• A buffered ring survives dead zones: the R43 is the only wearable in EDOO's range printing a store-and-forward capacity, "Max storage 130000 pieces of 13 bits commodity code".
• A replayed read is a late event, so the proof-of-delivery timestamp must come from the moment of capture rather than the moment of reconnection, and the route application must de-duplicate a scan against a manual entry made while offline.
• Multi-parcel drops are the mis-scan case: with two labels in one field of view — R43 publishes "Horizontal 28°, vertical 21.5°" — one read can attach to the wrong consignment.
• A parcel fleet is an asset-custody problem before it is a scanning problem: the unit leaves a fence, lives in a vehicle and changes hands, which moves the design from shared cradles to named devices and a replacement policy.
• The pick-cycle economics, trigger-mode trade-offs and pairing architecture of wearable scanning are covered in EDOO's wearable barcode scanner picking article; this article owns the round.

Is the van or the phone the host on a delivery round?

Two topologies, and they buy different things. With the driver's phone as host, the ring is a Bluetooth peripheral of a device the driver already owns or is issued: no extra terminal to power or mount, and the app is whatever the carrier stack runs. The cost is variance — consumer handset models, OS levels, battery saver policies that kill a background reconnect, and a bond that dies on a factory reset. On a managed estate, mobile device management for rugged Android fleets is what owns that bond, so a phone-host wearable is an IT specification line, not an accessory.

With the vehicle or hand-held terminal as host, the round's computer is one rugged Android unit in the cab — the M91's published row is 4G-LTE, GPS, NFC and Wi-Fi, and the AI1580 goes further by being the host on the body: "OS: Android 14.0", "Communication: WIFI, Bluetooth 5.0", 2300mAH and 99 g, which deletes the ring-to-phone hop and the argument about whose phone it is. The trade is mass on the hand, a second charge to plan, and a field-service-style device to commission, which is what the rugged Android PDA for field service treatment covers.

The decision is not preference. It is: whose handset survives the round, who pays for the data plan, and which device holds the session when a driver swaps vehicles.

What happens to scans when the driver loses signal?

Store-and-forward means the scanner keeps reads locally when the link cannot carry them and sends them later, so a dead spot costs delay rather than data. Delivery is where this is normal, not exceptional: underground car parks, steel-clad towers, gated logistics parks and rural lanes all produce minutes without a usable link, and the ring's Bluetooth or 2.4G path to a phone in a cab has its own dead spots inside a metal vehicle body.

Capacity is the row the datasheet prints — R43's "Max storage 130000 pieces of 13 bits commodity code" is far more than a round produces — so the failure modes are behavioral, and none of them is published: whether the buffer survives a power-off or a device that switched itself off in a lock-up, whether events replay in original order, what happens when the buffer is full, and whether a replayed code reaches the WMS twice.

Specify the replay, not the size. Give every read a unique event ID at the device and require the host or server to de-duplicate on it, so a driver who keyed a delivery manually while offline does not create two accepted lines. Then fix the clock: a scan captured at 11:40 in a basement and delivered at 11:58 is a proof-of-time record only if the payload carries the capture timestamp, and a route application that stamps events on receipt will silently mis-date every buffered read.

How does scan-and-carry work at the door?

The delivery step is carrying. A driver with three parcels in the arms has no free hand for a pistol-grip scanner, and the label of the parcel being put down faces whoever is holding it. Which object the wearable reads, and how the driver knows it read, is the whole last-mile ergonomics problem.

Whether the ring fires from a physical trigger or on presentation is argued in the picking article; what changes at the door is that several labels are simultaneously visible. A finger-worn reader presented at a stack sees whichever symbol crosses its field of view first, and R43's published field of view is "Horizontal 28°, vertical 21.5°" — wide enough that two labels on adjacent parcels can sit in one frame. The consequence is a silent wrong-scan: the driver scans parcel A, the ring reads parcel B, both are accepted, and only one leaves the van.

The second door-step variable is confirmation. A beeper is competing with traffic, a gate and an intercom, and a status LED is competing with daylight and a hood. EDOO's pages differ here, and the difference is a specification: R42 prints "Prompt method Sound, LED, and vibration", R43 prints "Notification Beeper, LED", and AI1520 is the model whose page puts a built-in display on the ring itself, so the driver reads the confirmation without finding a phone. A delivery read the operator cannot feel is a re-scan, and a re-scan is a parcel left unscanned.

What belongs in a proof-of-delivery sequence?

A defensible proof-of-delivery transaction binds three things: which consignment, which evidence, and at what time from which position. The order matters, because each step constrains the next.

Read the item first, so the event is attached to a consignment rather than to whatever the manifest line happens to be open. Capture evidence second — a recipient identifier, a signature, or a placement photograph where the recipient is absent. Close the manifest line last, and only if the read reached the application, since an accepted line with no read behind it is precisely what an audit later cannot distinguish from a delivery that never happened.

Position is the weak link. GNSS works at the kerb and fails in a lobby, a basement or an underground concourse, so an application that requires a fix before it will accept a proof fails exactly the deliveries that most need evidence. Decide what the fallback is — a scan timestamp, a photographed label, a network cell — and write it into the app rather than discovering it in a dispute.

Two rules keep the wearable invisible, and both come from the picking article's WMS treatment: a scan must never require a screen tap to be accepted, and a read arriving while an unexpected dialogue is open must queue rather than vanish. Exceptions are scans too: refused, damaged, neighbour-drop and wrong-address each need their own code, because an exception typed as free text is an exception nobody can report on.

How do a van, a charger and a second driver work together?

Charging on a round is a vehicle problem. A cab's 12-volt socket is often ignition-switched, so a device plugged in overnight never charges; a permanent live drains the vehicle battery; and a shared USB hub in a van with three phones and a terminal is a load and a heat question. Ask, in writing, which circuit the charger sits on before you plan a night of charging in a depot yard. Where the device is docked at the depot rather than in the cab, the AI1510 page is the architecture built for it: a "180mAh pure cobalt high-density battery, detachable" that "can be charged on a base", plus a gateway its page states serves 300 devices at 100 meters, and a scenario list that names "Express logistics" first.

Handover is a pairing and custody problem. If the ring bonds to a handset, a second driver on the same route is a new host: re-pairing at a door step is not a five-minute job, and a bond held by a managed profile can drop when a policy re-pushes. The cleaner shapes are a device that travels with the route and pairs to a route terminal, or a self-hosting unit such as AI1580, where the wearable and the computer are the same object and the handover is a login. Either way, record the device ID against the driver and the vehicle at shift start, because a scan you cannot attribute is not evidence.

Weather adds the one cold-chain mechanism worth repeating here: a wet, cold device carried into a warm cab has surfaces below the dew point of that air, so it fogs — on the window and across the charging contacts. That is a dock-and-dry habit, not an enclosure feature.

Why does a parcel fleet need different hardware terms from a warehouse fleet?

FAQ

What is the best way to scan parcels on a delivery round? Read each consignment separately, at the point of handling, with a confirmation the driver can feel. Hands-free reading exists for exactly this step, but a wide field of view over a stack of parcels will accept the wrong label, so the rule is one parcel presented at a time and one event per parcel, never one scan for a stack.

Can a ring scanner work with a driver's phone? Yes, on the phone-as-host topology: EDOO's R43 page states pairing with "any Android, iOS or Windows device" and prints "SDK Provided : Yes", while R43 names Bluetooth HID, SPP and BLE modes. What you must specify is which mode your app consumes and whether the bond survives an OS update on a managed handset.

What is store-and-forward in delivery scanning? The device holding reads until a link returns, then sending them. R43publishes "Max storage 130000 pieces of 13 bits commodity code", which is capacity, not behavior: still require capture timestamps, event order, and server-side de-duplication so a replayed scan cannot double-count a delivery.

How should a fleet hand wearable scanners between drivers? Treat the unit as a named asset with a record against driver and vehicle, and decide whether it travels with the route or the person. A ring bonded to a handset follows the handset; a self-hosting unit such as AI1580 or a cell-swappable AI1510 follows the route.

Related EDOO resources

EDOO product datasheet · EDOO product datasheet · R43 product page · EDOO product datasheet · EDOO product datasheet · EDOO product datasheet · Solution/309.html · Solution/305.html · Solution/316.html