PDA terminal Wi-Fi roaming: why the fleet works in the pilot and fails in the warehouse

Time：2026-10-06 Views：0

A PDA terminal deployment rarely fails in the pilot: two units, one aisle, one access point. It fails in month three, with four hundred devices crossing a building whose radio map changes whenever a pallet is stacked, and IT hears "the scanners are down". The scanners are not down; their link is being rebuilt several times a minute, and each rebuild costs the application something.

Three disciplines meet here and none owns the result: RF design belongs to the network, supplicant behaviour to the device vendor, queueing to your application. Say the awkward part first — a hardware vendor cannot fix a bad RF design.

Who actually chooses the access point

The client does. 802.11 gives the station the right to scan, select a BSS, authenticate and associate; the access point can only reject an association or deauthenticate a client already on it. The sticky client is therefore not a terminal defect — a device holding a distant access point at −75 dBm has simply been given no good reason to leave.

Nor is a roam one event. The radio re-selects a channel and BSS, layer 2 re-authentication and the four-way handshake run, the IP address survives while the subnet does not change, and the application's TCP session waits or dies. The seconds live in the last two stages.

Why a warehouse is the worst roaming environment you will specify

Metal racking is a reflector, not an obstacle. Rays arrive by several paths and interfere, and because the wavelength in the 2.4 GHz band is roughly twelve centimetres, a walk of a few centimetres can move a device from a peak into a deep null. A long narrow aisle acts partly as a waveguide: energy runs down it well and leaks across it badly, so a survey taken in one aisle can be wrong two aisles over.

Then the geometry. Access points go on ceiling beams, nine to twelve metres up, because that is where the power, cabling and forklift clearance are. The terminal's antenna is in a hand at 1.2 to 1.5 metres, below the shelf line and shadowed by the goods the racks hold, so anything surveyed at desk height is optimistic. Add the deliberate attenuators: cold-room doors and frames, and shrink film, which reflects and carries condensation. The 2.4 GHz noise floor is not empty either — motor drives and forklift cabling radiate broadband noise, microwave ovens leak around their doors, and every terminal's own Bluetooth hops inside the same spectrum.

2.4, 5 and 6 GHz on a handheld device

Free-space loss rises with frequency, and higher bands diffract less around rack edges, so coverage at a given transmit power shrinks as the band climbs. What you get back is spectrum: more non-overlapping channels, higher throughput. For terminals the deciding factor is the client. A handheld antenna is small, detuned by the operator's hand, the metal frame and the scanner window, and its efficiency at the top of 5 GHz or in 6 GHz is a compromise no datasheet describes for your grip. 6 GHz adds clean spectrum, but the coverage penalty is real, its power rules are regional, and whether a build and radio exposes it at all is a per-SKU question, not an Android-version question.

So 5 GHz carries capacity and 2.4 GHz stays for the deep aisles. The readers sit in these bands too — the W41-10 is listed as a wireless portable 2.4G Wi-Fi/Bluetooth warehouse handheld scanner, and W43 with a 150 m transmission figure to its base: a vendor's radio-to-radio number, not a measurement of your aisles.

Channel planning: the arithmetic, and the 3 a.m. change

Twenty-megahertz channels in 2.4 GHz give three that do not overlap. Forty megahertz there is a fiction in a building full of metal, and it eats the 5 GHz plan you needed for capacity. Co-channel overlap sets the real noise floor: repeating the same channel is not extra coverage, it is contention. Handheld data coverage is planned to a signal level around −65 to −67 dBm with margin, not to "the client associates".

Automatic channel selection is a reasonable mechanism and a bad habit on a handheld site. A controller that re-channels at three in the night, seeing no clients, changes every radio beneath a fleet holding neighbour lists and roam thresholds tuned to the old plan; the crew discovers it on the first shift. Dynamic frequency selection is the same failure with a legal excuse: a radar hit moves a 5 GHz access point, and every client with it. Pin channels and widths, document the fallback set, and give operations a change window.

802.11k, 802.11v and 802.11r: what each one buys

Mechanism	What it fixes	What it costs	Verify
802.11k neighbour reports	The client stops blind-scanning every channel before deciding	Controller must supply reports; client must use them	Timed roam on the real terminal
802.11v BSS transition management	The network can suggest a better target BSS	Only a suggestion; many clients ignore it	Frame capture of request and response
802.11r fast BSS transition	Re-keying happens before the move, so a roam skips full 802.1X	Supplicant, controller, RADIUS and one mobility domain must all support it	Capture at the moment of roam

The hard word in 802.11r is "chain". Fast BSS transition pre-establishes key material between access points, so a roaming station finishes reassociation with a short handshake instead of a full EAP exchange — but only if the terminal's supplicant implements it, the controller advertises the mobility domain, RADIUS accepts the identifiers returned, and the access points share the context. Android support has never been uniform across versions, builds and chipsets; two SKUs on one release can behave differently, and some industrial vendors implement it in their own driver rather than the platform. Treat it as a claim to test on the model you buy, and require the per-SKU radio feature list in writing.

Authentication, and the re-authentication tax

Enterprise Wi-Fi means 802.1X: the authenticator forwards an EAP exchange to a RADIUS server and the terminal receives a session key. WPA2-Enterprise is the long-standing profile; WPA3-Enterprise tightens cipher suites and requires protected management frames, which blocks the deauthentication attacks that reach your crew as random drops. Mixed sites add boundaries — an open or PSK yard network, a guest SSID, a corporate 802.1X SSID — and every boundary crossed is a full re-authentication, so yard to dock door costs more than an aisle roam.

The tax differs by method. EAP-TLS is quick per attempt but depends on device certificates and their expiry, and without FT caching a roam re-runs it. PEAP/MSCHAPv2 can require a round trip to a domain controller for its inner authentication; re-attempts stack with supplicant retransmission timers into the stall people time at about eight seconds. A DHCP lease change aggravates it: some supplicants treat a new IP as a materially different network and restart the exchange while the application's sockets break. Capture one roam to get your real number.

The application layer, where a 400 ms gap becomes a lost scan

A link gone for 400 milliseconds is survivable at the transport layer, because retransmission timers absorb short gaps. Survivable at the wrong layer is a lost record. If the application does a blocking write on the scan thread with a timeout shorter than the gap, the operator hears a beep that means nothing and moves on. Store-and-forward is the fix and it is cheap: accept the scan locally, persist it so a crash or a battery swap cannot lose it, then send from a queue with backoff. Make the queue idempotent, because it will retry — every submission needs a client-generated identity so the server recognises a duplicate instead of creating a second pick. That is the difference between a network problem and an inventory discrepancy.

Do not count a 200 response as delivered without reading the payload, because a captive portal answers in HTML with a success code; and show queue depth while it drains, so a silent backlog becomes a report rather than a month of missing data.

Symptom, mechanism, owner

Symptom on the floor	What is usually happening	Who owns the fix
Scans work in aisle 3, not at the dock door	Coverage edge, or an open door and yard-SSID boundary forcing re-auth	Network design, not the terminal
Device holds a distant access point that looks strong	Sticky client with no neighbour report or transition hint	Supplicant plus controller configuration
Works on the charger, dies ten minutes off it	Power-save polling; the access point buffers and ages frames	Controller DTIM and client sleep policy
Drops and re-joins every twenty metres	Aggressive roam thresholds, or overlapping cells on one channel	Controller roam parameters
Fine at night, failing mid-shift	Client count and channel contention per access point	Radio resource management, or more radios
Slow only after the freezer run	Cold-soaked device, window condensation, door-crossing re-auth	Terminal specification plus RF design

A survey checklist that predicts the fleet, not the laptop

Survey at hand height with a device in the class you intend to buy, never a laptop at desk height, and record the rate the client actually negotiates.
Measure per-access-point client counts at peak shift; capacity failures present as coverage failures.
Walk-test with a ping at 100 ms intervals down each aisle and count the gaps, then repeat at the dock and freezer doors.
Capture two or three roams and time each stage, so you know whether the problem is scanning, re-keying or EAP.
Audit the 2.4 GHz noise floor for microwave, motor-drive and Bluetooth contribution before blaming the terminal.
Record the PoE budget, cable runs and mount heights you have, because they decide where access points can go.
Re-survey after racking changes — a planogram move is an RF event.

The uncomfortable conclusion

Most of those fixes live in controller configuration, access point placement, channel and power plans and PoE capacity, none of which the terminal vendor controls. What a vendor can answer is the per-SKU radio feature list, the 6 GHz treatment for your region, roaming behaviour measured on your sample, and the certification trail behind the radio — see technical recognition and product documentation. Hardware can be specified to the job: the warehousing and logistics scope covers the handheld readers and PDA and POS terminals, including M91, listed as a rugged Android 12 handheld with GPS, NFC and Wi-Fi, and M73, listed with Wi-Fi and a hot-swappable battery. Where the radio itself must change, that is an OEM/ODM conversation scoped through Solutions For Your Projects — talk to us with your band plan in hand. Configuration can be pushed across a fleet by your management tooling; none of it buys a decibel of coverage.

FAQ

Why does my PDA terminal lose connection when the operator walks between aisles? Because the client, not the network, decides roaming: the terminal holds its association until its own thresholds force a scan, reassociation and re-authentication. Racking produces peaks and nulls centimetres apart, so the strongest signal is a poor proxy for the best access point. Fix it with 802.11k neighbour reports, 802.11v transition hints, tuned thresholds, and coverage measured at hand height.

Does 802.11r fix Wi-Fi roaming on Android handhelds? It removes the re-authentication tax by pre-establishing key material, but only where the terminal's supplicant, the controller and RADIUS all implement fast BSS transition in one mobility domain. Android support varies by build, chipset and vendor driver, so verify on the exact model with a capture taken during a real roam.

Why do scans fail on battery but work on the charger? That pattern is power-save polling: a sleeping client wakes on a beacon interval to collect buffered traffic, and an access point discarding frames for a client whose buffers overflowed presents as random drop-outs. Fix the controller's DTIM and buffering settings and the terminal's sleep policy, not the transmitter.

Should the application assume the network is available? No. Treat the link as intermittent: queue each scan and persist it before responding, retry with backoff, identify every submission so a retry cannot create a duplicate transaction, and report queue depth so a building-wide RF problem arrives as an alert instead of as missing inventory.