A credential that works perfectly in testing can fail at a gate on a Saturday. The cause is usually not the credential — it is spacing, presentation and what the guest has been led to expect.
- Two credentials in the field at once
- Reader spacing at gates and lockers
- Presentation is learned, and can be designed
- Queues turn small delays into visible ones
- What to record from a reader test
Two credentials in the field at once
When a guest presents a wristband while holding a wallet containing a card, a reader may see both. Systems handle that in different ways — some pick one, some report a conflict, some appear simply not to respond — and to the guest it looks like the band failed.
It is worth knowing which behaviour your system has, because the mitigation is different for each: a spacing change, a placement change, or simply telling guests to present the band away from their wallet.
Reader spacing at gates and lockers
Closely spaced readers — a bank of lockers, adjacent turnstiles — can produce reads at the wrong unit if the credential is presented between them. This is the one situation where more read range is actively unhelpful.
Testing a locker bank means presenting at the units at each end and in the middle, quickly, as a guest would. Testing one locker in isolation tells you nothing about the bank.
Presentation is learned, and can be designed
Guests present the top of the wrist without being told. They do not naturally turn a wrist over, hold a credential still, or present twice. A specification that requires any of those is a specification that will generate complaints.
The design responses are to keep the module on the top of the wrist, to make its position findable by touch, and to place readers where a natural gesture reaches them rather than where the wiring was convenient.
Outdoor readers in bright sun often have indicator lights that are invisible. Where that is the case, guests cannot tell a successful read from a failed one — which produces repeated presentations and a queue. It is a placement problem worth raising with the installer.
Queues turn small delays into visible ones
A read that takes two attempts is invisible at a quiet door and obvious at a gate with forty people behind it. That is why throughput testing has to be done at the peak condition rather than at an average one.
It is also why the compact constructions need more care in high-volume settings: the same marginal read that is a curiosity at a hotel door is a queue at an embarkation gate.
What to record from a reader test
Per reader type: whether the first presentation succeeded, at what distance, wet and dry, and with the credential in the position a guest naturally uses. Not an overall impression.
A recorded result per reader type turns a later problem into a known exception rather than a surprise, and it gives the property something concrete to take back to an installer where reader placement is the actual issue.
Compatibility is confirmed against the property’s lock system, credential technology and encoding requirements before production. We do not claim universal compatibility.
Questions this raises
01Why does the band fail when the guest is holding their wallet?+
Because the reader may be seeing two credentials at once. Systems handle that differently — picking one, reporting a conflict, or appearing not to respond — and to the guest it looks like the band failed. Knowing your system’s behaviour determines the fix.
02Can a guest open the wrong locker?+
At closely spaced readers it is possible if the credential is presented between units, which is the one case where more read range is unhelpful. Test a locker bank at both ends and the middle rather than testing one locker in isolation.
03Guests present twice at our outdoor gate. Why?+
Often because the reader’s indicator is invisible in bright sun, so nobody can tell a successful read from a failed one. That is a placement and installation issue rather than a credential one, and it is worth raising with your installer.