Files
parking_solution/wiki/sources/qrcode-sdk.md
T
julian f67c1ead87 wiki: ER80 protocol = HTTP GET poll + JSON verdict (from QRCode SDK)
The QRCode SDK v1.6.5 settles the reader protocol (supersedes the earlier
serial guess). On each scan the reader HTTP-GETs the host
(/qa/mcardsea.php?cardid&mjihao&cjihao&status&time); the host replies JSON
{data:[{...,status,output}],code:0}. Reply status 1=valid(beep 2x)/0=invalid
(beep 1x); output 0=Access/1=WG26/2=WG34; time syncs the clock. The GET's status
low digit is the direction (1=in/0=out).

Key: the beep/accept is decided by the SERVER REPLY, not locally -- the 'no
beep' during bring-up was a plain-text reply, not a scan failure. Host-in-the-
loop and synchronous. 'Server language' only selects the URL path; transport is
plain HTTP.

New source page qrcode-sdk; updated gee-qr-er80 (protocol resolved), index.
2026-06-16 12:05:05 +02:00

63 lines
2.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
type: source
tags: [parking, hardware, readers, qr, protocol, sdk]
sources: [qrcode-sdk]
updated: 2026-06-16
---
# Source: QRCode SDK v1.6.5 (GEE/Dingtian QR reader)
Vendor SDK for the QR access reader ([[gee-qr-er80]]; also branded Dingtian). Defines the
reader↔server **HTTP protocol** — the missing piece the datasheet omitted. Files at
`QRCode_sdk - QRCode_v1_6_5/sdk/` (config tool `QRCode_v1_6_5.exe`, demos in C#/PHP/VC++, protocol
docs `readme.txt`, `qrcode_HTTP_GET.txt`, `VC++/how to.txt`). **Not copied into `raw/`** — bulky +
binaries; this summary is the faithful capture. Entity: [[gee-qr-er80]].
## The protocol — HTTP GET poll, server replies the verdict
The reader is configured (via the Windows tool) with a **server IP/port + "server language"**
(JSP/PHP/C#/ASP/CGI — this only selects the URL path, e.g. `/qa/mcardsea.php`; transport is plain
HTTP either way). **On each scan** the reader sends:
```
GET /qa/mcardsea.php?cardid=445D2C&mjihao=1&cjihao=HW256097&status=11&time=1540402036 HTTP/1.0
```
| Param | Meaning |
| --- | --- |
| `cardid` | **the scanned QR/barcode data** (or card id) |
| `mjihao` | device id (machine number) |
| `cjihao` | device serial number |
| `status` | **2 chars**: high = valid `1`/invalid `0` (reader's own pre-check), low = direction **`1`=in / `0`=out**. A 1-char status = fail. |
| `time` | UTC time |
**Server → reader reply (JSON) — this is the access DECISION and drives the beep + output:**
```json
{"data":[{"cardid":"<echo>","cjihao":0,"mjihao":1,"status":1,"time":"<utc>","output":2}],"code":0,"message":""}
```
| Reply field | Meaning (from the C# demo comments) |
| --- | --- |
| `status` | **`1` = valid → buzzer 2×; `0` = invalid → buzzer 1×** |
| `output` | **`0` = Access, `1` = WG26, `2` = WG34** — output line/format driven on a valid read |
| `time` | UTC — **can sync the device clock** |
| `code` | `0` = success |
> **Implication (explains the "no beep"):** the reader's beep/accept is decided by the **server's
> reply**, not locally. A non-JSON / missing reply ⇒ no valid feedback ⇒ no beep, even though the
> scan succeeded. So "no beep" ≠ "didn't scan" — it means the server didn't answer with the verdict.
## Integration consequence
This is **host-in-the-loop, synchronous**: the GET *is* the access query; our JSON reply *is* the
decision. So the backend endpoint must **decide (valid/invalid + direction) and reply** — richer
than a fire-and-forget read. Direction comes from the `status` low digit. See [[gee-qr-er80]] +
[[device-input-flow]].
## Defaults / misc
- Default device IP `192.168.1.99` (`readme.txt`).
- Demos: PHP `qa/mcardsea.php` (minimal echo, status 0), C# raw-socket server on :80 (full parse),
VC++ raw HTTP example. All show the same GET-in / JSON-out contract.