Go to file
type-two 6d9a49ea42 Fix the EPC scheme; verify encode independently with the Chafon
The SKU<->EPC layout inherited from daemon.cs was WRONG. daemon.cs packs 6 bytes
of SKU + 4 bytes of release_id + an 0xEC01 marker, and flagged itself as
unverified. The shop's actual scheme -- in pliceclogs/rfid-daemon/index.js
(buildEpcPayload/parseEpcData), which is what the extension and every existing
tag use -- is a single 96-bit big-endian integer:

    value = sku(14 digits) * 10^9 + releaseId

Checked against that file's own worked example: 20260321001001 + 35332 ->
20260321001001000035332. epc_decode also reproduces its guard, returning None
when value/10^9 exceeds 14 digits, so a factory tag (E28069...) can never be
reported to the operator as a real SKU.

This matters: parseEpcData rejects the EC01 layout outright, so every tag the
Windows daemon has written is invisible to the extension. ASSESSMENT.md now
carries that as a red open item against daemon.cs.

Verified end-to-end with an INDEPENDENT reader. ASSESSMENT.md sec.4 parked the
Chafon as HID-keyboard-only, but that is Windows-specific -- on macOS it exposes
a CH340 bridge and its documented serial protocol works. New chafon.py (read-only:
inventory + read EPC, CRC-16/0x8408 framing) scans the field and sees:

    0000044A5600D4CDA1FAB932  -> sku=20260722180000 rel=424242   (Urovo-written)
    E28069950000600625F600D3  -> factory/blank  (x12, rest of roll)
    126D5125FFA000067932EC01  -> factory/blank  (earlier EC01 tag, now rejected)

That last line is the bug demonstrated: a tag written earlier today under the old
scheme is unrecognised, exactly as the extension would have treated it.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-22 16:45:07 +10:00
mac Fix the EPC scheme; verify encode independently with the Chafon 2026-07-22 16:45:07 +10:00
.gitignore macOS: raw-TSPL Urovo daemon — no vendor SDK needed 2026-07-22 16:07:12 +10:00
ASSESSMENT.md Fix the EPC scheme; verify encode independently with the Chafon 2026-07-22 16:45:07 +10:00
build.cmd Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
chafcheck.cs Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
daemon.cs Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
GTSPL_SDK_C.dll Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
GTSPL_SDK.dll Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
hidapi.dll Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
PROGRESS.md Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
README.md Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
start-daemon.cmd Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
UHFPrimeReader.dll Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00
zlib.net.dll Windows Urovo D812R+ print+encode daemon + full assessment 2026-07-22 15:18:39 +10:00

pricegod-urovo-daemon

The Windows counterpart to the Mac rfid-daemon. Instead of a Chafon gun writing a loose chip while a Dymo prints a separate sticker, this drives the Urovo D812R+ (RFID) to print the label AND encode the UHF chip in one pass on the composite (paper+chip) rolls.

It listens on http://localhost:7790/ with CORS *, so it's a drop-in for the PriceGod extension's existing daemon.js client — same port, same JSON shape.

Run it

Double-click start-daemon.cmd (leave the window open while you work). That's it — no Node, no .NET SDK, no gitea clone. It's a self-contained .exe.

To rebuild after editing daemon.cs: double-click build.cmd.

What's inside

  • daemon.cs — the service (C#, .NET Framework 4.x).
  • pricegod-urovo-daemon.exe — the compiled daemon.
  • GTSPL_SDK.dll, GTSPL_SDK_C.dll, zlib.net.dll — the Gainscha/Urovo print SDK (must sit beside the .exe). Copied from the vendor Windows SDK.

The print/encode sequence is a straight port of the proven gtcheck.cs rfidgo path: SET RIBBON OFF → continuous geometry (GAP 0, RFID rolls blind the optical gap sensor) → writeUHF → draw text + QR → printlabel → read-back verify.

Routes

method path body returns
GET /status {ok, ready, status, statusText, printer}
POST /print-encode {sku, releaseId, artist?, title?, price?, condition?, w?, h?, gap?} {ok, sku, releaseId, epc, verified, status}
POST /write-tag alias of /print-encode (the daemon.js name) same
GET /read-tag {ok, epc, sku, releaseId, recognized}
POST /calibrate RFID auto-calibration
POST /recover ribbon-off + one feed to clear a fault

Quick test (PowerShell):

Invoke-RestMethod http://localhost:7790/status

SKU ↔ EPC scheme (⚠ verify)

The 96-bit EPC (12 bytes) is packed as: 6 bytes 14-digit timestamp SKU · 4 bytes release_id · 2 bytes 0xEC01 marker. This lives in the Epc class in daemon.cs and is the only thing that needs to change if it must match a different (Mac/Chafon) layout — nothing else depends on the byte order. Confirm by reading an existing tag: put a Chafon-written record at the antenna and GET /read-tag.

Notes / open items

  • Default label geometry is 65×37 mm, continuous (GAP 0). Adjust to your actual RFID roll via the w/h/gap fields, or change the DEF_* constants.
  • The label layout (text lines + QR) is functional, not yet pixel-matched to the 51×19 Dymo design in the extension's labels.js.
  • The Chafon gun is still needed for reading a loose tag off a shelf — the Urovo can only read/write a tag physically inside the printer.