What the reader module does — and does not do
A reader in an elevator cabin has one job: capture a credential and hand it to the controller layer for a policy check. Authorization logic — which card may reach which floor and whether it is still valid — stays central and auditable on the master. A reader in a public cabin is the most exposed piece of the system; if it held the card database, opening one reader would open the building. Keeping it a plain field device also means permission changes touch only the master.
The AXON reader follows this rule strictly. It authenticates the card with AES-128, sends a CARD_EVENT frame carrying the 7-byte UID and an AUTH_OK flag over RS-485, and waits up to one second for an ACCESS_RESULT. No verdict within that window is shown as a deny.
Card technology: why DESFire EV3
Older cabin readers accept 125 kHz tags or MIFARE Classic cards and grant on the UID, which a hobbyist cloner copies in seconds. The AXON reader uses NXP MIFARE DESFire EV3 and requires a mutual AES authentication before it trusts anything:
- The ST25R3916B front-end reads the card's real 7-byte UID from anticollision.
- The reader selects the AXON ACCESS application (AID F5 10 02) and derives that card's read key from its UID with AES-CMAC.
- It runs DESFire
AuthenticateAES. A copied UID on a blank tag has no key, fails here, and by default produces no LED, no beep and no frame.
The reader holds only a READ sub-master key, so a stolen reader can authenticate AXON cards but cannot format, rewrite or re-key one. Background: DESFire EV3 vs MIFARE Classic and Anti-Cloning RFID.
Where the reader sits: cabin or landing
The same URX-Secure board and firmware image serve two positions; only the RS-485 bus address, fixed at build time, differs.
| Position | Bus to master | Master | Master's output |
|---|---|---|---|
| Inside the cabin | RS-485, 115200 bps 8N1 | AXON CCU-32 cabin master | 32 relays, one per floor button |
| At each landing | RS-485 to the floor AXON Node | Node bridges over CAN to AXON ICM-GE | Node relays: door release, call signal |
This article covers the cabin case; the landing case is described in How Elevator Access Control Works.
Signal path: one tap, antenna to floor button
- Card enters the field. The NFC front-end raises an interrupt and the reader's STM32G031 reads the UID over SPI.
- Card proves its key. SelectApplication, key derivation,
AuthenticateAES. - Event to the master. The reader sends
CARD_EVENTinside an encrypted, MAC-tagged RS-485 frame, blinks white and waits. - Master decides. The CCU-32 verifies the frame's counter and CMAC first, then checks the UID against its local database and that card's floor permissions.
- Relays pulse. Granted floor relays close for 3 seconds so the passenger can press those buttons on the original panel. The reader shows green plus a beep, or red, held for 3 seconds. The event is logged and published over MQTT when an uplink is available.
Nothing in the elevator's own call-button wiring is redesigned; the elevator controller sees ordinary button presses.
The RS-485 link between reader and cabin master
The reader is a bus slave: it speaks only after a tap or when polled. The CCU-32 (address 0xFE) polls readers from address 0x01 every 700 ms and treats a 2.5 s silence as a lost reader.
- Physical layer: RS-485 half-duplex, 115200 bps, 8N1; twisted pair, daisy-chained, 120 Ω at both physical ends, no star wiring.
- Frame layer: SOF 0xA5, destination, source, command, length (0–64 bytes), payload, CRC16-CCITT.
- Secure layer: a 3-pass AES-128 mutual authentication yields a per-session key; access frames are AES-CTR encrypted, then tagged with an 8-byte CMAC over a per-direction counter. A replayed or forged frame is dropped; eight bad frames lock the link for 5 seconds.
Full details: URX-Secure engineering guide, CCU-32 engineering guide.
Cabin installation notes
Cabins are electrically noisy, cramped and hard to revisit. Settle these points before the site visit:
| Item | Recommendation |
|---|---|
| Reader supply | 9–15 V DC, under 2 W typical; a shared 12 V rail is fine if sized for the load |
| Cabin master supply | 12–24 V DC, 3–6 W; budget 10 W headroom including the reader |
| Reader cable | Shielded twisted pair, under 30 m from reader to CCU-32 |
| Termination | 120 Ω at both physical ends of the RS-485 pair |
| Reader enclosure | IP20 indoor variant for the cabin panel; IP65 variant for outdoor gates |
| Cabin master mounting | Inside the cabin enclosure, dust-protected, −20 °C to +70 °C |
| Uplink | Ethernet if a cable reaches the cabin; otherwise the CCU-32's LTE-M / NB-IoT modem with an external antenna — the steel cabin attenuates signal |
The reader's idle LED shows link health without a laptop: blue when an authenticated frame arrived within the last 3 seconds, magenta when not. Cards are not accepted while the link is down, so a magenta reader is a wiring problem, not a card problem.
Controller integration: floor permissions
Reader events are mapped to floor permissions inside the CCU-32. Each card record carries a floor mask; the master pulses only the relays that mask allows, so a visitor cannot ride to another tenant's floor because that button is never enabled for their card. If the building's internet drops, the cabin keeps deciding from its local permission state and queues events; the server only synchronises the card database, collects logs and delivers firmware. If the reader link cannot be verified, the design fails closed: no unverified grant is produced.
Retrofit sites with a legacy cabin reader
Two paths exist when a cabin already has a working Wiegand reader. The CCU-32 accepts a standard Wiegand-26 reader directly on its D0/D1 inputs — the credential travels in cleartext, so treat this as a transition. Alternatively, AXON AMS (W2R-N) sits behind the existing reader and republishes its output as an addressed AXON RS-485 message, so old and new readers arrive at the master as RS-485 endpoints.
For a MIFARE Classic card estate, the master can enable READ_ALL on the URX-Secure so those cards are reported UID-only, flagged not authenticated, for logging while DESFire EV3 cards are issued. The reader never grants a UID-only card.
Local terminology and use cases
In Kosovo and the region this use case is usually described as "akses për kabinë të liftit" or "akses për kabinë të ashensorit" — the same thing under two words for elevator. Typical scenarios: a residential tower with one reader per cabin, where each resident's card enables their home floor plus garage and roof; a multi-tenant office where isolation is enforced at the button; a hotel with staff-only floors that guest cards never see. See Elevator Access Control for the wider system view.
Deployment checklist
- Policy modeling — floor masks per credential class (resident, staff, contractor, visitor).
- Credential segmentation — DESFire EV3 cards provisioned with the AXON ACCESS application; a plan for any legacy cards.
- Communication diagnostics — reader LED blue at idle, encrypted handshake completing, uplink reachable or cellular antenna fitted.
- Bench test — a pilot reader tested against the cabin master before go-live.
Frequently asked questions
Does the reader decide whether a card has access? No. It authenticates the card and reports the UID with an AUTH_OK flag over RS-485. The CCU-32 checks its local database and floor permissions, pulses the relays and replies. The reader only shows the verdict.
Which cards work with the elevator RFID reader? NXP MIFARE DESFire EV3, authenticated with AES-128 against the AXON ACCESS application. MIFARE Classic, NTAG and foreign DESFire cards are ignored by default; with READ_ALL they are reported UID-only for logging.
Does the elevator keep working without internet? Yes. The CCU-32 decides on the board from its last synchronised database and queues events until Ethernet or cellular returns.
Is the reader shipping today? URX-Secure is in final testing with pilot units available on request; the CCU-32 is shipping with firmware in final test. Ask for a pilot reader to bench-test against your master.