AXON Node — Floor Node on the Encrypted CAN Bus

A compact STM32F072 floor module that reads Wiegand-26 cards, drives two relays, and talks to the AXON Master over CAN bus with AES-128 CTR encrypted payloads.

01 — What AXON Node Does in the System

AXON Node is the per-floor endpoint of subsystem B in the AXON access architecture. Physically it is a small STM32F072 board mounted next to the elevator landing or building entrance on each floor. Functionally it connects the platform-side card reader to the CAN bus that runs vertically through the building riser back to the AXON Master controller.

Each Node receives a unique module address from 0 to 63 through six DIP switches, plus a 2-bit device type tag (floor / door / garage / ramp) through two additional switches. The address is set in hardware, not in software, so swapping a faulty Node is a wiring-and-DIP operation — no laptop, no commissioning tool, no firmware reflash. This is deliberate: a building-services electrician should be able to replace a board in under five minutes during a callout.

The architectural separation from the AXON Master is intentional. The Node does not, by design, decide whether a credential is authorized. Its role is to capture the credential, report it to the Master, and execute the result. All permission logic — user permissions, time windows, lockdown state, schedule overrides — lives on the Master, where it can be updated centrally without touching each floor.

A typical operational flow looks like this: a resident or staff member presents an RFID card to the platform reader on their floor; the Node captures the Wiegand-26 stream over external interrupts; the Node activates the appropriate relay (door release, call signal, or both) based on the authorization result; the resulting state is broadcast on the CAN bus as an AES-128 CTR encrypted frame; the Master receives, decrypts, and logs the event. Nothing on the bus is ever in plaintext.

02 — Required Components

Every AXON Node board carries the following:

Part	Role	Notes
STM32F072CBTx	MCU (ARM Cortex-M0)	128 KB Flash, 16 KB RAM, on-chip bxCAN (CAN 2.0B / ISO 11898-1), 48 MHz.
CAN transceiver	Physical CAN PHY	TJA1051 expected.
MAX3485 (or equivalent)	RS-485 transceiver	Used for the 9600 baud local audit/debug log line.
Wiegand-26 reader input	Card input	D0 and D1 on GPIO inputs with falling-edge interrupts.
Two relays (with drivers)	Outputs (door / call signal)	CTRL_1, CTRL_2 — timed pulses, default ~5 seconds.
8-position DIP switch	Module ID + device type	6 bits for module ID (0–63), 2 bits for device type (floor / door / garage / ramp).
Power regulator	Board power

Why these specific parts

STM32F072 was selected for three reasons: it has bxCAN on-die (removing an external CAN controller from the BOM), it is widely available through 2026 with documented errata, and AES-128 CTR runs comfortably in software at the throughput a 250 kbps bus demands. RS-485 was kept as a separate audit channel because mixing diagnostic plaintext traffic onto the CAN bus would either compromise security (sending plaintext) or complicate diagnostics (everything encrypted). MAX3485 is a reliable 3.3 V RS-485 transceiver that pairs cleanly with the STM32 supply rail.

03 — How the Node Works End-to-End

The Node's operational loop is short and deterministic, which matters in a safety-adjacent environment like a building access system.

1. Card capture. The Wiegand-26 reader emits the 26-bit credential as pulses on D0 (logic 0) and D1 (logic 1). The Node captures each falling edge through external interrupts on PB10 and PB11.
2. Frame validation. The firmware validates both parity bits: bit 0 must equal even parity over bits 1–13, bit 25 must equal odd parity over bits 13–25. If parity fails, the firmware auto-inverts D0/D1 once and retries, which absorbs the most common installation error.
3. Field extraction. Once parity passes, the Node extracts the 8-bit facility code (bits 1–8) and the 16-bit card number (bits 9–24).
4. Authorization & relay action. Based on the authorization result, the Node activates the corresponding relay as a timed pulse (~5 seconds by default).
5. Status broadcast. The Node packages its current state — module ID, device type, relay state, status code, anti-replay counter — into 8 plaintext bytes, encrypts them with AES-128 CTR, and transmits the ciphertext as a CAN frame.
6. Audit log. The Wiegand read and the CAN transmission are written to the RS-485 audit line in plaintext for local diagnostics.

Every step above is bounded by a timeout. If the Wiegand frame does not complete within 50 ms of inter-bit silence, it is dropped. If the CAN transmission fails repeatedly, the Node enters recovery (see section 12). The independent watchdog (IWDG) resets the MCU if the main loop hangs for more than approximately 4 seconds.

04 — CAN Bus Configuration and Encryption

Why 250 kbps

The Node uses bxCAN (CAN 2.0B per ISO 11898-1) on the STM32F072 configured at 250 kbps. The choice of 250 kbps is a deliberate trade-off: higher rates (500 kbps, 1 Mbps) cut the maximum reliable bus length roughly in half each step, which becomes a real constraint in a multi-floor riser. At 250 kbps the bus comfortably handles 250 meters end-to-end on appropriately specified cable with 120 Ω termination at both ends per the ISO 11898-2 high-speed CAN physical-layer specification — enough for almost any residential or mid-rise commercial building without active repeaters.

Bit timing math

The actual register configuration:

• APB1 clock: 48 MHz
• Prescaler: 12
• Time Segment 1 (BS1): 13 TQ
• Time Segment 2 (BS2): 2 TQ
• Synchronization Jump Width (SJW): 2 TQ

Verification: 48 MHz / (12 × (1 + 13 + 2)) = 250 kbps. The sample point is at (1 + 13) / 16 = 87.5%, which is the recommended value in CiA standards for robust sampling under cable propagation delay.

The CAN filter accepts every message (mask 0x0000) into FIFO0. Filtering happens above the CAN layer because messages are encrypted and a hardware ID filter would not see the meaningful payload anyway.

Arbitration ID layout

The Node uses the 11-bit standard CAN ID as follows:

arbitration_id = (module_id << 5) | (counter_low_5_bits)
                  (6 bits)         (5 bits)

This serves two purposes. First, traffic from low-ID modules has natural priority in CAN arbitration, which matters when many Nodes attempt to transmit during a busy event (for example, a fire-alarm-triggered unlock cascade). Second, the counter bits embedded in the ID let receivers do fast coarse deduplication without decrypting every frame.

AES-128 CTR — why and how

CTR (Counter) mode as specified in NIST SP 800-38A was chosen over CBC, GCM (NIST SP 800-38D), and others for three reasons specific to CAN-bus constraints:

• Block size fits exactly. AES has a 128-bit (16-byte) block. CTR encrypts a counter to produce a keystream and XORs it with the plaintext. With an 8-byte CAN payload, the implementation only uses 8 bytes of the keystream — no padding, no padding-oracle vulnerability surface.
• No IV transmission overhead. The nonce is derived from the module ID; the counter is part of the message ID and the encrypted payload. Nothing extra needs to travel on the bus.
• Fast on Cortex-M0. The STM32F072 has no AES accelerator. A software AES-128 implementation in CTR mode comfortably exceeds the throughput required for a 250 kbps bus with status messages every five seconds.

Anti-replay

Each Node maintains a 16-bit counter that increments on every status transmission. The full 16-bit counter is encoded inside the encrypted 8-byte payload. The low 5 bits also appear in the CAN arbitration ID. A receiver can therefore:

1. See the low 5 bits of the counter immediately, without decryption, and reject a frame that obviously rewinds.
2. After decryption, verify the full 16-bit counter against the last known value for that module ID and reject frames that go backwards or jump implausibly far forward.

This makes a recorded-and-replayed attack on the bus extremely impractical, even though the bus itself has no native authentication.

Key management — current state and risk

05 — Pinout and Wiring

Function	Pin	Notes
CAN RX / TX	PA11 / PA12	bxCAN peripheral.
Wiegand D0 / D1	PB10 / PB11	External interrupt, falling edge.
Relay CTRL_1 / CTRL_2	PB0 / PB1	GPIO output, timed pulse ~5 s.
RS-485 DE / RE	PA8	HIGH = transmit, LOW = receive.
RS-485 TX (DI) / RX (RO)	PA9 / PA10	USART1, audit log @ 9600 baud.
DIP module ID S1–S6	PA0–PA5	Inputs with internal pull-up, module ID 0–63.
DIP device type S'1 / S'2	PA6 / PA7	Device type: floor / door / garage / ramp.

For RS-485 cabling, run a single twisted pair with the transceiver tied to local ground; do not loop ground through the building chassis. For CAN, run a dedicated shielded twisted pair (preferably CAT-grade or a CAN-specified cable) and terminate with 120 Ω at both physical ends of the bus — not at every Node.

06 — Communication Architecture: CAN + RS-485

CAN bus is the primary link to the Master: 250 kbps, AES-128 CTR encrypted payload, arbitration ID encoding module address and partial counter. The bus topology is a linear backbone with short stubs (≤30 cm) to each Node. Use 120 Ω termination resistors at both physical ends of the backbone — adding termination at branches will degrade the differential signal.

RS-485 (USART1, 9600 baud, half-duplex) is a local audit and debug line. The Node writes Wiegand reads and CAN events to it in plaintext for diagnostics during commissioning. Direction is controlled by the DE/RE line on PA8 (HIGH = transmitting). Transmission is DMA-driven so the main loop is not blocked. This is intentionally not the binary reader protocol with CRC16 used by the separate AXON Reader device — keeping the diagnostic log on its own line means a noisy reader cable cannot pollute the CAN bus.

Why two buses instead of one

A common engineering question is why not run everything over CAN, or everything over RS-485. The answer is that the two buses serve different masters:

• CAN is the operational data path: encrypted, prioritized, deterministic latency, fault tolerant. It carries production traffic.
• RS-485 is the diagnostic data path: plaintext, human-readable, slow. It exists so a technician with a laptop and a USB-RS-485 adapter can sit in the building lobby and read what every Node is doing, without ever needing the AES key.

07 — Data Model and Frame Format

Wiegand-26 layout

• Bit 0: even parity over bits 1–13
• Bits 1–8: facility code (8 bits)
• Bits 9–24: card number (16 bits)
• Bit 25: odd parity over bits 13–25

Inter-bit timeout (no pulse for 50 ms) ends the frame. Pulse width and pulse spacing on D0/D1 follow the standard Wiegand timing (50 µs pulse, 1 ms inter-pulse, give or take) but the firmware is tolerant of moderate deviation because field readers often vary slightly.

CAN payload — before encryption

The 8-byte plaintext layout sent to AES-CTR:

plain[0] = module_id;
plain[1] = device_type;
plain[2] = relay1_active;
plain[3] = 'O';
plain[4] = 'K';
plain[5] = counter & 0xFF;
plain[6] = (counter >> 8) & 0xFF;
plain[7] = 0;

AES_CTR_Crypt(&ctx, nonce, counter, plain, cipher, 8);
can_id = (module_id << 5) | (counter & 0x1F);
CAN_SendMessage(can_id, cipher, 8);

The bytes 'O' and 'K' are an in-band liveness signature: after decryption, a receiver can confirm the frame originated from valid firmware (not a random ciphertext that happened to decrypt to plausible bytes) by checking those magic bytes. It is not a cryptographic MAC — that would require GCM or a separate HMAC — but it filters out 99.6% of garbage decryptions before further parsing.

08 — Built-in Protections (verified in firmware)

• AES-128 CTR payload encryption on every CAN transmission.
• 16-bit anti-replay counter with low bits also in the CAN ID for fast filtering.
• Independent Watchdog (IWDG), ~4 second timeout, prescaler 256. If the main loop hangs, the MCU resets.
• Wiegand parity validation with auto D0/D1 inversion retry to absorb cable swaps.
• CAN error recovery: 5 consecutive transmit/receive errors trigger a 30 second pause followed by re-initialization of the CAN peripheral.
• RS-485 audit log at 9600 baud capturing every Wiegand event and every CAN transmission attempt, in plaintext, for offline diagnosis.
• Status heartbeat every 5 seconds, so a missing Node is detectable in well under 30 seconds at the Master.

09 — Real-World Deployment Scenarios

Multi-floor residential tower

In a 20-floor residential building in Prishtinë with a single elevator and two staircases, one AXON Node is installed on each floor next to the elevator landing reader. All Nodes connect to a single CAN backbone running up the riser, terminated at the basement (Master end) and the rooftop machine room. The Master holds floor-to-credential mappings; the Nodes capture cards and report state. Total bus length: approximately 80 meters, well within 250 kbps margin.

Mid-rise office with mixed access policies

A 12-floor office building with multi-tenant floors uses AXON Nodes at each landing plus additional Nodes on internal doors. The device-type DIP bits distinguish landing-floor Nodes from door Nodes so the Master applies the appropriate permission policy. The same physical bus carries both — encryption and addressing keep them logically separated.

Hotel with staff-only floors

A hotel with two floors reserved for staff areas places Nodes at the elevator landings of those floors with stricter time-window policies enforced at the Master. Guest credentials simply do not appear in the authorized list for staff floors; the Node behavior is identical, the difference is entirely in centrally-managed permissions.

Hospital with controlled wings

In a hospital, Nodes guard wards with different visiting policies. Time-windowed access is applied per credential class (medical staff, administrative staff, cleaning, contractors, family). Because the Master is authoritative, changes to visiting hours are a single configuration push without touching any per-floor hardware.

10 — Installation Requirements

• Power: 12–24 V DC at the location of each Node, with at least 10 W of reserved capacity per board for safe margin.
• Cable: dedicated shielded twisted pair for CAN backbone. Do not share the cable with mains, fluorescent lighting feeds, or elevator motor cables — induced noise from those sources is a well-known source of bus-off events.
• Termination: 120 Ω at both physical ends of the CAN backbone. Test with a multimeter across the bus pair with all Nodes powered off: you should read approximately 60 Ω (two 120 Ω terminators in parallel).
• RS-485 audit run: keep within 50 meters per Node for reliable 9600 baud operation. This line is optional — the Node functions on the CAN bus alone — but installing it during build saves time during future troubleshooting.
• Wiegand reader cabling: shielded multicore, maximum 100 meters per Wiegand specification, but in practice keep under 30 meters for reliable parity at 5 V signaling.
• Enclosure: any standard IP30 indoor enclosure with DIN-rail compatibility. If the Node is installed outdoors or in damp utility spaces, use an IP65 enclosure with a sealed cable entry.

11 — Recommended Bus Topology

CAN expects a linear bus, not a star or tree. The two correct topologies are:

1. Straight backbone with short stubs: a single twisted pair running through the building riser, with each Node connecting via a stub of 30 cm or less. Terminate 120 Ω at both physical ends of the backbone only.
2. Daisy chain: each Node has IN and OUT terminals; the bus enters one and leaves the other. Terminate only the first and last Node.

Common installation mistakes that cause hard-to-diagnose intermittent faults:

• Star topology: branching off a single central point to every Node. The reflections at the branch points cause sporadic frame loss that gets blamed on firmware.
• Termination at every Node: this drops bus impedance below specification and increases transceiver current. Two terminators total, no more.
• Single twisted pair shared with mains: ground loops and 50 Hz pickup will eat into the CAN error budget.

12 — Troubleshooting Guide

The Node drops off the CAN bus after a few minutes (bus-off)

Almost always a bit-timing or termination issue. Confirm every Node is configured for 250 kbps and that bus termination measures ~60 Ω end-to-end. The firmware does include automatic recovery (5 consecutive errors → 30 s pause → re-init), so persistent bus-off after recovery indicates a physical layer problem, not a software bug.

Card reads are intermittent

Usually a Wiegand parity failure caused by D0/D1 cable swap or noise. The firmware auto-inverts and retries once per read, but cable runs above 30 meters without proper pull-up termination tend to glitch the falling edge. Verify the 50 ms inter-bit timeout in firmware matches what your specific reader emits and confirm PB10/PB11 are correctly wired.

CAN frames arrive but decrypt to garbage

Three possibilities, in order of likelihood: (1) a Node has a different pre-shared key from the rest (check the firmware build it is running); (2) the nonce derivation differs between Node and receiver — confirm both use module ID + counter the same way; (3) the counter on one side has wrapped or fallen out of sync, which breaks CTR mode entirely until both sides reset.

The relay never activates even on valid cards

The current firmware drives the relay from the local card-authorization path, so check that the Node's local authorization logic recognizes the card. Once the Master-driven relay path is implemented, this troubleshooting step will become "verify the Master sent the activation command and the Node received it" — but for now it is local.

Status frames stop appearing on the bus from one Node

Either the Node is in its 30-second recovery pause after accumulated errors (wait one minute and look again), or its power is intermittent. Check the RS-485 audit line first — if it is silent too, the Node is not running. If audit traffic continues but CAN does not, the issue is in the CAN PHY or its wiring.

The watchdog keeps resetting the Node

The IWDG fires if the main loop fails to kick it within ~4 seconds. This points to a firmware bug or a hardware interrupt storm (for example, a flapping Wiegand line generating tens of thousands of interrupts per second). Inspect the RS-485 audit log just before the reset to see what the Node was doing.

13 — How the AXON Node Compares to Alternatives

For builders considering off-the-shelf access components:

• Generic Wiegand controllers (most market entries): cheap, but transmit credentials in cleartext over short cables. Cloning is trivial with a sub-€50 device. AXON Node uses Wiegand-26 only between the reader and the Node — the moment a credential is captured, it leaves the Wiegand domain and enters AES-128 CTR encryption on CAN.
• OSDP-based readers (more secure than Wiegand): OSDP Secure Channel does provide encryption, but ties you to OSDP-compatible readers, which are more expensive and less available in this region. AXON Node lets you use any Wiegand-26 reader on the market while keeping the network-side encrypted.
• IP-per-floor (PoE controllers): gives every floor an Ethernet drop and a controller. Maximally flexible, maximally expensive, and requires the building to have structured cabling to every floor — which most retrofit projects do not. CAN bus on a single shielded pair is far cheaper to pull through an existing riser.

14 — Current Implementation vs Roadmap

To set integrator expectations honestly:

What ships today (Axon_node-v1)

• STM32F072 firmware with full Wiegand-26 capture and parity auto-correction.
• AES-128 CTR encrypted status broadcasts on the CAN bus every 5 seconds.
• Local relay activation from the card-authorization path.
• Watchdog and CAN error recovery as described.
• RS-485 audit log at 9600 baud.
• DIP-switch addressing for module ID and device type.

On the roadmap (not in v1)

• Master-authoritative relay control. Today the Node decides locally. The target architecture has the Master parse incoming card events and issue an encrypted CAN command back to the originating Node that drives the relay. This is the most important behavioral gap.
• Per-device keys. Move from a single shared pre-shared key to keys derived from an ATECC608 secure element using the module ID.
• Authenticated encryption. Replace AES-CTR with AES-GCM where the bus and codebase can afford the larger overhead, or add a separate HMAC.
• Field firmware updates over CAN. Signed bootloader-managed updates that propagate through the bus from the Master.

15 — Key Takeaways

16 — Frequently Asked Questions

How is each AXON Node addressed on the CAN bus?

Via 6 DIP switches for the module ID (0–63) and 2 DIP switches for the device type (floor / door / garage / ramp). All in hardware, no software step required.

Are the messages on the CAN bus encrypted?

Yes. Every CAN frame carries 8 bytes of AES-128 CTR ciphertext with a 16-bit anti-replay counter. No module transmits plaintext on the bus.

Does the Node make access decisions on its own?

By design, no — the Master decides. In the current firmware, the relay is driven from the local card-authorization path; the Master-authoritative path is the next milestone.

Why 250 kbps on the CAN bus?

To preserve bus length across a multi-floor riser without active repeaters. 250 kbps is the highest standard CAN rate that still allows reliable operation across the lengths typical buildings need.

Why AES-128 CTR rather than CBC or GCM?

CTR matches the 8-byte CAN payload without padding, runs efficiently on Cortex-M0 without an AES accelerator, and needs no IV transmission overhead. GCM would add a 16-byte authentication tag that does not fit a single CAN frame.

What is the RS-485 line used for?

A local plaintext audit and debug channel at 9600 baud, half-duplex. It is not the binary CRC-protected reader protocol used by AXON Reader.

What happens when CAN errors accumulate?

The firmware tolerates transient errors automatically. After 5 consecutive errors, the Node pauses CAN for 30 seconds, then re-initializes the peripheral. Repeated entry into recovery indicates a physical bus problem.

Is the same AES key used on all Nodes?

In Axon_node-v1, yes — a pre-shared key. Per-device keys via a secure element are planned for the next hardware revision.

How does the Node validate a Wiegand-26 frame?

By checking even parity over bits 1–13 and odd parity over bits 13–25. If parity fails, it auto-inverts D0/D1 once and retries to absorb installation cable swaps.

Which microcontroller does the Node use?

STM32F072CBTx — ARM Cortex-M0 at 48 MHz, 128 KB Flash, 16 KB RAM, with on-die bxCAN (CAN 2.0B).

17 — Related Guides and Products

18 — Get an AXON Node Quote for Your Building

Need encrypted CAN-bus floor access for an elevator retrofit or new installation in Kosovo or the wider region? We can size the bus topology for your specific riser, supply the modules from local stock, and support commissioning. Typical lead time for stocked configurations is one to two weeks.

References and Standards

External standards and technical specifications referenced in this guide:

• ISO 11898-1 — Controller Area Network (CAN) data link layer and physical signalling
• ISO 11898-2 — High-speed CAN transceiver physical layer
• NIST SP 800-38A — Recommendation for Block Cipher Modes of Operation (CTR mode)
• NIST SP 800-38D — Galois/Counter Mode (GCM) and GMAC
• Wiegand-26 interface — protocol reference
• STMicroelectronics STM32F072CB — MCU datasheet
• NXP TJA1051 — High-speed CAN transceiver datasheet