Control de Acceso Físico

01 What it is

Access control for a school, end to end: a custom PCB with an Arduino Nano driving two Wiegand readers and two locks, a ZKTeco PROID10BM MIFARE card reader on each door, a Spring Boot backend that decides who gets in and a web panel to add, remove and block students, hosted on the school own server.

• pcb_control board Rev A: 170 × 115 mm, 61 through-hole components, 42 nets, ERC and DRC at zero.
• Two independent Wiegand 26/34 readers, two door relays as dry contacts and two exit buttons.
• The board decides nothing: it reads the card, sends the ID over serial and opens only when the backend gives the signal.
• Spring Boot backend that checks whether the student is active or blocked, and a web panel with students, cards, access history and status.

02 The board · Rev A

Designed in KiCad. Everything is through-hole on purpose: no SMD, so the whole board solders with one technique and one iron. Four M3 screws in 3.2 mm holes.

03 How it works

04 Terminal blocks

MX126 / DG126 family, 5.00 mm pitch, 1.3 mm drill and Ø2.8 mm pad. J2 and J3 are rotated 180° so the cable mouth faces the edge, which puts pin 1 on the right: the silkscreen is labelled pad by pad and reads SHIELD · BUZZ · LED · D1 · D0 · GND · 12V left to right. Trust the silkscreen, not the pin number.

05 Nano pinout

The Nano has only two hardware interrupts and four Wiegand lines are needed here. Reader 1 takes INT0/INT1; reader 2 goes through a pin-change interrupt. That is why the firmware cannot be the basic two-line example.

D10–D13 and A4–A7 remain free: room for door sensors, an RTC or storing cards over I²C.

06 Firmware

control_acceso.ino compiles for arduino:avr:nano with no warnings: 6.5 KB of flash (21 %) and 324 B of RAM. It reads both readers on interrupt and assembles the frame bit by bit; closes the read after 25 ms of silence; accepts 26 and 34 bits and validates both parity bits before sending anything. It stores no cards: the ID goes out over the Nano USB, as a 115200 serial port, to the school server, and the backend decides.

• Sends CARD with the reader number and the ID; if the backend answers OPEN, it opens the relay for 3 s without blocking the loop, with a long beep and green LED; on DENY or a bad frame, three short beeps.
• Exit buttons with 30 ms debounce.
• The ID is (facility << 16) | number, the same for Wiegand 26 and 34: both formats collapse to the same 32-bit ID, which is what the server stores when the student is registered.
• The backend records every read, authorized or not, in the access history.
• The PCINT2 vector covers the whole port D, so the routine compares against the previous state to keep only the falling edges of PD4 and PD5.

> CARD 1 00A1B2C3    # Nano → backend: lector 1 leyó este ID
> OPEN 1             # backend → Nano: alumno activo, abre el relé 1 tres segundos
> DENY 1             # backend → Nano: bloqueado o desconocido, tres pitidos
> BTN 2              # Nano → backend: botón de salida 2, solo para el historial

07 Resilience

An access controller lives inside a box, with nobody watching it, and has to keep working. These are the decisions made with that in mind, not for elegance.

08 Verification and risks

What was checked and what was not, kept apart on purpose. A passing ERC does not mean the circuit works: during the design, a serious mistake (BC337 base and collector swapped) survived a perfectly clean ERC. It only showed up when reading the netlist net by net and asking KiCad for the real pin order of the transistor.