AXON Node
Per-floor bridge between the landing reader and the AXON Master: it takes the reader's authenticated card event over RS-485, forwards it on the encrypted CAN backbone, and pulses two relays only when the master says so.
The floor node that never decides alone
AXON Node is the per-floor endpoint of subsystem B in the AXON architecture. It sits at each elevator landing or building entrance, next to the reader, and does three things: it polls the landing reader over RS-485, it forwards each authenticated card event to the AXON Master over the CAN backbone, and it drives two relays — typically a door release and a call signal — when the master answers with a grant. The board is built around an STM32F072 (Cortex-M0, 48 MHz) with on-chip bxCAN, a TJA1051 CAN transceiver and an RS-485 transceiver, and takes its bus address from an 8-position DIP switch.
The design rule is simple: the node never decides. The card database, floor permissions and time windows live on the master. The node terminates the reader's RS-485 secure session, re-wraps the event for the CAN bus, and waits. If the master's verdict does not arrive within 800 ms the pending tap expires as a deny — fail-closed, not fail-open. Relay pulses are commanded by the master (one message carries decision, relay mask and pulse length), so a node cannot be talked into opening a door by anything other than a verified master command.
Because sixty-plus nodes sit in publicly accessible corridors, every node holds its own diversified AES-128 key, derived from a CAN root key and the node id. A cracked-open board exposes that node alone; a failed MAC or replayed counter drops that node's session and forces re-authentication, and nothing else changes. Traffic is encrypted, then MACed, with a 4-byte counter per direction, and the 11-bit arbitration ID is bound into the MAC so a frame cannot be replayed to another node. Hardware acceptance filters mean a node's CPU never even sees the other nodes' frames.
What the board does for the site
RS-485 to CAN bridge
The node is the landing reader's controller on RS-485 and a session peer of the AXON Master on CAN. It reuses the cabin master's reader protocol implementation verbatim, so a reader neither knows nor cares whether a cabin master or a floor node is on the other end of the cable.
Per-node diversified key
Each node holds only its own AES-128 key, derived by AES-CMAC from the CAN root key and the DIP-set node id. The master derives the same key per session; nodes never share a bus key. Changing the DIP address re-derives the key, drops the session and re-applies the hardware filters.
Encrypt-then-MAC on both buses
Reader-side RS-485 and master-side CAN both run a 3-pass mutual authentication, then AES-CTR encryption followed by an 8-byte CMAC with 4-byte monotonic counters. The card UID never crosses either bus in the clear, so a passive tap cannot track residents floor by floor.
Two master-commanded relays
CTRL_1 and CTRL_2 (door release, call signal) pulse only on a verified master command: the access verdict carries a relay mask and pulse length in 100 ms steps, and a separate relay command supports off, on and pulse for door release from the server or app. Denies pulse nothing.
DIP-switch addressing
Six switches set the node id (0–62; 63 is reserved for broadcast) and two set the device type: floor, door, garage or ramp. Address goes into the bxCAN hardware filters, so only frames for this node and broadcasts reach the CPU. Replacing a board is a wiring-and-DIP job — no laptop.
Self-recovering bus and MCU
An independent watchdog resets a hung main loop after about 4 s. Five consecutive CAN errors trigger a 30 s pause and a full re-initialisation with filters re-applied. A plain status frame every 5 s tells the master whether the session is up and the reader online, so a rebooted node is re-authenticated at once.
One landing tap, reader to master and back
Reader authenticates card
The landing reader runs mutual authentication with the DESFire EV3 card and sends the card event (flags, UID) to the node over the secured RS-485 link at 115200 baud.
Node re-wraps for CAN
The node verifies and unwraps the RS-485 frame, then sends the event on its own CAN session: AES-CTR encrypted, CMAC-tagged, fragmented into three 8-byte frames.
Master decides
The AXON Master checks UID and floor permission in its local database and answers with decision, relay mask and pulse length — budget under 100 ms, measured under 10 ms.
Node executes the verdict
The node forwards the decision to the reader for its LED and beeper and, on grant only, pulses the relays in the mask for the commanded length. Denies pulse nothing.
Two buses, two secure sessions, one verdict path
CAN 2.0B, 250 kbps
Classic CAN with 11-bit IDs and an 87.5 % sample point. The arbitration ID is direction, node id and message type, so every ID has exactly one legal transmitter and arbitration stays non-destructive however many nodes tap at once. Up to 63 nodes on one backbone, 120 Ω termination at the two physical ends only, short stubs, TJA1051 transceiver.
ID = DIR ‖ NODE ‖ TYPE · 120 Ω at endsRS-485, 115200 8N1
The node is the reader's controller, running the same RS-485 protocol implementation as the cabin master. Half-duplex with DE/RE turnaround, DMA receive, secure layer v2: 3-pass mutual authentication, AES-CTR payload encryption, CMAC and 4-byte counters. A secured ping with a 2.5 s window drops and re-authenticates a rebooted reader in about 3 s.
Secure v2 · encrypt-then-MAC · CRC16Per-node AES-128, mutual auth
K_node is AES-CMAC of the CAN root key over a fixed label and the node id. The master derives it per session; the node holds only its own key. The handshake is DESFire-style 3-pass; sessions have a 15-minute maximum age and a counter ceiling; the master staggers boot handshakes 20 ms apart, so 63 nodes authenticate in about 1.3 s.
AES-CMAC diversification · 15-min re-keyThe numbers, from the datasheet
Values are taken from the node firmware and the AXON system specification (June 2026). Bench-measured figures are marked as such; unconfirmed hardware limits are left out.
| Role | RS-485 ↔ CAN bridge; per-floor endpoint, does not decide |
|---|---|
| MCU | STM32F072CBTx, Cortex-M0, 48 MHz, 128 KB Flash, 16 KB RAM |
| Addressing | 8-way DIP: 6-bit node id (0–62) + 2-bit device type |
| Device types | Floor / door / garage / ramp |
| Firmware | Axon_node-v1 — CAN contract v1, RS-485 secure v2 |
| Decision latency | Budget < 100 ms; measured < 10 ms; deny at 800 ms |
| CAN bus | Classic CAN 2.0B, 11-bit ID, 250 kbps, SP 87.5 % |
|---|---|
| CAN transceiver | TJA1051 |
| Nodes per backbone | Up to 63 (id 63 = broadcast) |
| Termination | 120 Ω at both physical ends only |
| RS-485 (reader) | USART1, 115200 8N1, half-duplex, DE/RE on PA8 |
| Wiegand-26 input | D0/D1 on PB10/PB11 (legacy path, retained) |
| Fragmentation | 1-byte header, ≤ 7 B per frame, 100 ms reassembly |
| Relays | 2 × (CTRL_1 on PB0, CTRL_2 on PB1) |
|---|---|
| Relay control | Master command: mask, off/on/pulse, pulse × 100 ms |
| Master offline | Production build: deny (dev build: local fallback) |
| Status frame | Every 5 s: fw, type, relays, session, reader, uptime |
| Key model | Per-node AES-128, AES-CMAC diversified from CAN root |
|---|---|
| Handshake | 3-pass mutual auth (DESFire-style), master initiates |
| Payload | AES-CTR encrypt-then-CMAC (8-byte tag), 4-byte counters |
| Anti-replay | Monotonic counter per direction; CAN ID bound in MAC |
| Filtering | Hardware acceptance: own id + broadcast only |
| Session limits | 15-min max age, counter ceiling, 10-min re-auth sweep |
| Key storage | Dev key in flash; no secure element on node BOM yet |
| Watchdog | IWDG, ~4 s, prescaler 256 |
|---|---|
| Bus-off recovery | 5 consecutive errors → 30 s pause → re-init |
| Reader liveness | Secured ping, 2.5 s window; re-auth in ~3 s |
| Fail-closed | Pending tap expires as deny after 800 ms |
| Supply input | 12–24 V DC |
|---|---|
| Mounting | Indoor IP30 enclosure, DIN-rail; IP65 in damp spaces |
| CAN cabling | Shielded twisted pair, stubs ≤ 30 cm, no star wiring |
Terminals & connectors
bxCAN peripheral to the TJA1051 transceiver; CAN_H / CAN_L to the building backbone, 120 Ω only at the two ends of the bus.
USART1 to the landing reader at 115200 8N1, half-duplex. PA8 HIGH transmits, LOW receives. Single twisted pair, local ground reference.
GPIO outputs to the two relay drivers. Pulsed on the master's command (mask + length); door release and call signal are the usual assignment.
Falling-edge interrupt inputs for a Wiegand-26 reader. Retained from the earlier firmware; the production credential path is the RS-485 reader.
Node id 0–62 with internal pull-ups. Setting 63 is reserved for broadcast and invalid for a node. A change re-derives the key and re-filters.
Device type: floor, door, garage or ramp. Reported in the 5-second status frame so the master applies the matching policy.
How it compares to off-the-shelf floor controllers
| Aspect | AXON Node | Off-the-shelf floor controllers |
|---|---|---|
| Reader-to-controller link | RS-485 with mutual auth, AES-CTR encryption and CMAC; the UID never appears in the clear | Wiegand-26 clock/data in cleartext on the reader cable, trivially sniffed and cloned |
| Backbone to the decision-maker | One shielded pair, CAN 250 kbps, up to 63 nodes, encrypted with per-node keys | An Ethernet/PoE drop and controller per floor, or OSDP that ties you to OSDP-only readers |
| Compromise blast radius | One node — its session is dropped and re-authenticated; other nodes keep their own keys | A single shared bus key, or no bus encryption at all |
AXON Node, up close
Where AXON Node fits
Typical configurations we size for integrators. Every scenario below is a planning example, not a customer reference.
One node per landing on a single riser
A 20-floor residential tower with one elevator puts a node beside each landing reader. All nodes share one CAN backbone through the riser, terminated at the basement master end and at the machine room. The master holds the floor-to-credential table; nodes capture taps, forward them and pulse the call relay on grant. Roughly 80 m of bus, well inside margin.
Landing nodes and door nodes on the same bus
A 12-floor office with several tenants per floor uses nodes at each landing and further nodes on internal doors. The device-type DIP bits mark landing nodes and door nodes so the master applies the right policy to each. One backbone carries both; per-node keys and hardware filtering keep them logically separate without a second cable run.
Stricter policy without different hardware
A hotel reserves two floors for staff areas and places nodes at those landings. Guest credentials are simply absent from the authorised list for those floors, and stricter time windows apply. Node behaviour is identical everywhere; the difference lives entirely in the master's centrally managed permissions, changed without a visit to the floor.
Visiting hours as a single configuration push
A hospital guards wards with different visiting policies. Time-windowed access is applied per credential class — medical staff, administration, cleaning, contractors, family. Because the master is authoritative and the node fails closed, changing visiting hours is one configuration change at the master; nothing changes on the per-floor hardware and no door opens on a silent master.
AXON Node FAQ
How is each AXON Node addressed on the CAN bus?
Are the messages on the CAN bus encrypted?
Does the node make access decisions on its own?
Why 250 kbps and classic CAN?
What is the RS-485 port used for?
Is the same AES key used on all nodes?
The rest of the AXON system
Ready to specify AXON Node?
Tell us the floor count, where the master will sit and which landings need a door relay as well as a call relay. We size the CAN backbone, termination and node addressing for your building. Availability on request.