julian
bf37106c5c
The reader on hand is a GEE-QR-ER80 QR/DataMatrix/1D barcode access reader (not an EM4100 prox-card reader as first guessed). Interfaces: Wiegand 26/34, RS-232, RS-485, USB, TCP/IP; 4-15 VDC; Linux-supported. Variant on hand: -Q-W (QR scanner, Wiegand/RS-232/485). This is the QR-ticket scanner the design already needed: a host-side reader whose scans become read-bus events consumed by the (already-built) exit flow and QR-permit path. Prefer RS-232/485 over Wiegand (Wiegand can't carry a variable-length QR string; autonomy is moot with the no-ACL Dingtian). New source + entity pages; updated ticket-encoding, entry-exit-readers, index. Open (blocks the adapter): the RS-232/485 frame + baud (ASCII CR/LF expected).
60 lines
3.2 KiB
Markdown
60 lines
3.2 KiB
Markdown
---
|
||
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.
|