How license plate recognition works: the 5 steps of ANPR
"The camera reads the plate and opens the barrier" sounds simple. What happens between the photo and the barrier is a processing chain completed in under a second — and understanding it is the difference between buying a serious system and buying a camera with promises. This article walks the process step by step, with the real timing of each stage.
Step 1 — Capture: the right photo
Everything starts with a sharp image of the plate, and that is engineering, not luck. The camera is mounted at a calculated angle for the lane (typically 15-30° from the vehicle's path), at the right height, with a fast shutter to freeze motion and infrared illumination calibrated for the reflective material of plates — which is why a serious ANPR system reads the same at 2 PM and 2 AM. Timing: capture is instantaneous; the trigger is decided by vehicle detection in frame.
Step 2 — Detection: finding the plate in the image
The image arrives with everything: the car, background, headlights, reflections. The first AI model locates the plate's rectangle and crops it from the rest. This is the stage that suffers most from poorly planned installs — a repurposed generic camera, without proper angle or resolution, delivers unreadable crops and everything downstream fails in cascade. Typical time: tens of milliseconds.
Step 3 — Reading (OCR): from pixels to characters
On the crop, the optical recognition engine identifies each character and builds the plate's text. A good engine corrects confusables — 8 that looks like B, 0 like O, 5 like S — using the Mexican plate format as context. Typical time: under 100 milliseconds on edge hardware.
Step 4 — Decision: does this vehicle enter?
The read plate is compared against three lists at once: authorized residents, active invitations (with time window) and alert lists (reported vehicles). The result is one of three outputs: open, deny, or escalate. Escalation matters more than it seems: in a well-designed system, a doubtful read doesn't block access but activates an assisted verification flow — the photo is already on screen.
Step 5 — Execution and logging
The barrier receives the order and the event is logged: plate, photo, time, lane and result. That log is the system's invisible asset — the record the committee consults when there's an incident, the evidence backing a complaint, the data feeding per-hour flow statistics.
The total: under a second, without stopping
Adding the five steps, a vehicle traveling 15-20 km/h toward the barrier gets its decision before reaching it: it doesn't brake, the barrier is already rising. That fluidity — not the pretty demo photo — is the proof of a well-built system.
Where processing happens: cloud vs edge
Some systems send every photo to a cloud server and wait for the answer; if the internet fails, access stops and the queue grows. Offline-first systems process the plate on the access unit itself (edge computing): the decision is local, the barrier opens without internet and data syncs when connectivity returns. For a real community — where the internet does fail sometimes — this difference defines whether the system is operable or a source of complaints.
Frequently asked questions
How fast does the system read a plate?
The complete processing — detection, reading and decision — takes under a second. A vehicle at 15-20 km/h gets the decision before reaching the barrier and doesn't need to brake.
What if the plate doesn't read well?
A doubtful read doesn't block access: the system activates a verification flow (partial plate with confirmation, vehicle whitelist, or assisted validation with the photo on screen). Error-handling design separates operable systems from demos.
Does it need internet to decide?
Offline-first systems like GateGuard decide on the access unit, without depending on the cloud. If the internet drops, the barrier keeps opening for authorized plates and data syncs when connectivity returns.
Conclusion
From camera trigger to open barrier there is a five-step chain completed in under a second: calibrated capture, detection, reading, decision and logging. The quality of each link — and of the whole system design — determines whether your access flows 24/7 or lives jammed. GateGuard builds the entire chain with own hardware made in Mexico and edge processing.
