Wi‑Fi Requirements & Best Practices for NX Handhelds

Who this is for: dealers, installers, and whoever looks after the restaurant's network. Section 8 is written for managers and does not assume any networking knowledge.

What it covers: what the network has to do for NX handhelds to work reliably, how to build it, and how to recognize the one failure that looks like nothing is wrong.

The short version

If you only change one thing: get the handhelds off 2.4 GHz.

1. Why handhelds are different from registers

A wall‑mounted register has a wired connection or sits three metres from an access point and never moves. It is the easiest client on the network.

A handheld is carried through a building, into corners the survey never covered, behind stainless steel, past microwaves, and in and out of the walk‑in. It roams between access points mid‑order. It goes in an apron pocket where a human body absorbs a chunk of the signal.

A network that has run registers flawlessly for years can be genuinely inadequate for handhelds, and this surprises people. Adding handhelds to an existing site is a network project, not just a hardware order.

2. Bands and channels

Use 5 GHz

2.4 GHz has three non‑overlapping channels (1, 6 and 11). It is shared with microwaves, cordless phones, Bluetooth, wireless cameras, and every neighboring business. A commercial kitchen is close to the worst 2.4 GHz environment there is.

5 GHz has far more channels, much less interference, and shorter range — which in a restaurant is an advantage, because it means less noise between cells.

• Set handhelds to prefer 5 GHz, or enable band steering.
• Consider disabling 2.4 GHz entirely on APs in the main service areas once 5 GHz coverage is proven.
• Keep 2.4 GHz only where you have equipment that genuinely needs it (some older printers and KDS bump bars).

Channel width

• 2.4 GHz: 20 MHz only. Never 40 MHz.
• 5 GHz: 20 or 40 MHz. Avoid 80 MHz in multi‑AP sites — it eats the channel plan and buys you throughput that a POS does not need.

Channel plan

Set channels manually, or verify whatever auto‑assignment chose. Adjacent APs must not share a channel. Re‑check after any AP is added or moved.

3. Coverage and placement

Design target

−65 dBm or better, with SNR ≥ 25 dB, everywhere an order can be taken. Survey with a handheld at waist height, not a laptop at head height, and walk the actual service path.

Do not forget: patios, private dining rooms, the bar well, the walk‑in door, the office, and the route between the kitchen and the floor.

Overlap

Cells should overlap by roughly 15–20% at the −65 dBm boundary. Too little and handhelds drop between cells. Too much and they cling to a distant AP instead of roaming.

Placement

• Mount APs in the open ceiling of the service area, not in a void, not above ductwork, not inside a metal enclosure.
• Stainless steel, walk‑in coolers, water heaters, and full water containers all block 5 GHz hard. An AP on the far side of a walk‑in effectively does not exist.
• Kitchens usually need their own AP. Do not expect the dining‑room AP to cover the line.
• Keep APs away from microwaves and cordless phone bases.

Not supported

Range extenders, powerline adapters, and consumer mesh kits. They halve throughput, add latency, handle roaming badly, and are the most common cause of the "connected but not working" failure in §6. Use cabled APs. If you cannot run a cable, use a proper wireless‑uplink AP from the same vendor with a dedicated backhaul radio.

4. Roaming

A handheld crosses cells constantly. Roaming has to be fast and it has to be the client's decision, supported by the network.

• Enable 802.11r (fast transition), 802.11k (neighbor reports), 802.11v (BSS transition management). Most handhelds support all three.
• Same SSID, same security type, same password on every AP. A different SSID per AP means the handheld will not roam, it will disconnect and reconnect — which drops orders.
• Consider a minimum RSSI / client kick threshold (around −75 dBm) so a handheld that has wandered too far is pushed to reassociate rather than clinging to a dying signal. Set this carefully; too aggressive and you cause the disconnections you are trying to prevent.
• Disable any "band steering" that is fighting your minimum‑RSSI setting. Pick one strategy.

5. Network configuration

5.1 Client isolation must be OFF — hard requirement

Many APs ship with client/AP isolation on by default, or it gets enabled when the POS is put on a network originally built for guests.

NX devices talk to each other directly over the local network. They also talk directly to the kitchen display server and to printers. With client isolation on, devices can each reach the internet and still be unable to see one another — so orders sync through the cloud slowly or not at all, kitchen tickets do not arrive, and printers appear offline. Everything looks connected.

Turn client isolation off on the POS SSID.

5.2 A separate SSID and VLAN for the POS

• POS gets its own SSID, hidden or not, with WPA2‑PSK or WPA3.
• Never put the POS on guest Wi‑Fi. Guest networks are rate‑limited, isolated, and often behind a portal.
• If you use VLANs, the POS VLAN must contain the handhelds, registers, KDS/kitchen server, and printers — they all need to reach each other.

5.3 No captive portal

A captive portal, a terms‑of‑service splash page, or any periodic re‑authentication will break the POS silently. The device will associate, fail every request, and report itself online.

5.4 DHCP

• Lease pool at least three times the device count. Handhelds re‑associate often; an exhausted pool is a classic mid‑shift failure.
• Lease time 8–24 hours.
• Reserve addresses for the kitchen/KDS server and every printer. The POS is configured with those addresses; if DHCP moves them, the integration stops.

5.5 Firewall and outbound access

Allow outbound from the POS VLAN:

Allow within the POS VLAN (device‑to‑device, do not block):

Do not use deep packet inspection, TLS interception, or "smart" security appliances on the POS VLAN. They break certificate pinning and long‑lived connections.

5.6 Internet circuit

• Business‑grade connection. 25 Mbps down / 5 Mbps up is comfortable for a typical site.
• The POS keeps working through a short internet outage, but card authorization and online orders do not.
• An LTE failover router covers the internet circuit dying. It does not help if the problem is the Wi‑Fi inside the building — which is the more common failure.

6. The failure you cannot see: "connected but not working"

This is the most important section in this document.

The usual assumption is that a Wi‑Fi problem means bars disappearing. The failure that actually costs restaurants orders looks like this:

The handheld shows full signal. It says it is connected. It has an IP address. And it cannot reach anything at all — not the internet, not the kitchen, not the other terminals.

It happens when a handheld stays associated to an access point whose own connection has failed, or when a roam half‑completes and the handheld ends up attached to nothing useful. The Wi‑Fi icon is reporting "I am associated to a radio," which is true, and says nothing about whether traffic is getting anywhere.

In one investigated case a handheld sat at −60 dBm — a good signal — with a valid IP address and no working path to anything, for four minutes. Staff kept taking orders on it the whole time because there was no reason on screen to think otherwise. The kitchen server was fine; eleven other terminals were working normally throughout.

What to take from this:

• Good signal strength does not mean a working connection.
• A handheld that is behaving oddly should be checked with Device Info → Sync Status, not by looking at the signal bars.
• If it recurs on the same handheld in the same part of the building, it is an AP or roaming problem at that location — not a broken handheld, and not a POS bug.
• Turning Wi‑Fi off and on again on the handheld genuinely does fix this one, because it forces a fresh association. It is worth doing before escalating.

7. Pre‑install checklist

Before handhelds go live:

• [ ] Site survey walked with a handheld, at waist height, along real service paths
• [ ] −65 dBm or better confirmed in every order‑taking area, patio and private room included
• [ ] 5 GHz coverage proven; handhelds preferring 5 GHz
• [ ] Same SSID/security on all APs; 802.11r/k/v enabled
• [ ] Channel plan set and verified; 20 MHz on 2.4 GHz
• [ ] Client isolation OFF on the POS SSID
• [ ] POS on its own SSID/VLAN, no captive portal
• [ ] DHCP pool ≥ 3× device count; reservations for kitchen server and printers
• [ ] Outbound 443 and DNS confirmed working from the POS VLAN
• [ ] Device‑to‑device ports open within the VLAN (7771, 8080, printer and KDS ports)
• [ ] No extenders, powerline adapters or consumer mesh anywhere in the path
• [ ] Walk test: carry a handheld through the whole building while ringing a test order, and confirm the kitchen receives every item

That last one is the only test that proves the deployment.

8. For managers: recognizing the symptoms

You do not need to fix these — but knowing which is which saves a lot of time on a support call.

Please do not move, unplug or re‑point access points to try to fix coverage. It usually makes the channel plan worse and the symptoms harder to diagnose.

9. Before you contact support

Have this ready — it turns a multi‑day back‑and‑forth into one call:

1. Which devices are affected (serial or station name), and whether registers are affected too
2. Where in the building, as precisely as possible
3. When it started, and whether it is constant or intermittent
4. What changed recently — new equipment, a new neighbour, a router swap, a firmware update
5. A photo of Device Info → Sync Status from an affected handheld while the problem is happening
6. Your AP make and model, and how many there are
7. If you have a kitchen display server: whether the other terminals could still reach it

Point 7 is the fastest way to separate "the kitchen server is down" from "this one handheld is off the network," and those two have completely different fixes.

Appendix: quick reference