---
type: entity
tags: [parking, hardware, readers, qr]
sources: [gee-qr-er80]
updated: 2026-06-16
status: open
---

# GEE-QR-ER80 (QR access reader)

The project's **QR-code reader** (GEE NFC LIMITED). A static optical scanner for **QR /
DataMatrix / 1D barcode**, optional ID/IC card. This is the **[[ticket-encoding|QR ticket]]
scanner** the design called for — read at the pay station and exit lane — and a path for **QR
[[permit]]** credentials. On hand: variant **`-Q-W`** (QR scanner; Wiegand/RS-232/RS-485).
(See [[gee-qr-er80|datasheet summary]] / `raw/`.)

## What it is (and isn't)

- **Optical, not RFID-prox.** Earlier we *assumed* "ER80-EM" = a 125 kHz EM4100 card reader — the
  datasheet corrects that: it's a **QR/barcode scanner**. The `-EM` in the original label was a
  mis-id; the real model is **GEE-QR-ER80**. Optional `D`/`C` variants add ID/IC card, but the unit
  on hand is **QR-only** (`-Q`).
- **Multi-interface** (Wiegand 26/34, RS-232, RS-485, USB, TCP/IP); the `-W` variant exposes
  **Wiegand + RS-232/RS-485**.

## How it fits our architecture — host-side reader

It's a **host-side identity source** ([[entry-exit-readers]]): the host sees the scan, decides, and
commands the relay — exactly the model the read-driven flows already use. A scan becomes a
`DeviceReadEvent` on the internal `read` bus (`kind: "qr"`/`"ticket"`, value = the scanned string),
consumed by the **exit flow** and the **QR-permit** path ([[parking-session]], [[permit]]) — both
**already built**. So integration is a new **`ReaderDevice` adapter**, no business-logic change
([[device-adapter-pattern]]).

- **Interface choice:** prefer **RS-232/RS-485 (serial)** for the QR variant — Wiegand can't carry a
  variable-length QR string well (it's built for fixed-width card IDs). The host reads scans over a
  serial port (USB-serial on TX/RX, or the USB variant); no Wiegand-decode hardware needed. This
  suits [[offline-first]] (local serial, no network) and sidesteps the [[dingtian-relay|Dingtian]]'s
  lack of an onboard card list (we never wanted autonomy here anyway).
- **LED/BEEP control lines** mean the host can drive scan feedback (accepted/rejected) — nice for an
  unmanned lane.
- **Linux-supported**, 4–15 VDC — fits the [[disk-os-hardening|appliance]].

## Open questions (block the adapter)

1. **RS-232/RS-485 protocol:** baud rate + frame format, and confirm a QR scan emits as an **ASCII
   string** (expected) terminated by CR/LF vs. a framed/checksummed protocol. This is the one fact
   the adapter needs and the datasheet omits. Resolve via vendor docs or by observing the port on a
   scan.
2. **Serial vs. USB-CDC vs. TCP/IP** for *this* unit: `-W` is Wiegand/RS-232/485. Decide the host
   wiring (a USB-RS232/485 adapter on TX/RX, most likely).
3. **Does Wiegand mode even carry QR?** Likely Wiegand is for the optional *card* modes only; confirm
   so we don't design a Wiegand path for QR.

## Next

A `ReaderDevice` driver in `packages/devices` (serial transport) emitting `read` events. Add it to
the [[device-registry]] under the `reader` category so the [[first-run-setup]] wizard can assign it
per lane. Pending open-question #1 (the serial frame) before coding.