---
title: "ArduinoTITO-PlayerTracking"
url: "https://maker.wiznet.io/Lihan__/projects/arduinotito-playertracking/"
markdown_url: "https://maker.wiznet.io/Lihan__/projects/arduinotito-playertracking/md"
type: "UCC: User Created Content"
author: "marcrdavis"
author_url: "https://github.com/marcrdavis/ArduinoTITO-PlayerTracking"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "marcrdavis"
original_url: "https://github.com/marcrdavis/ArduinoTITO-PlayerTracking"
published: "2026-07-06"
language: "en"
likes: 0
views: 176
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# ArduinoTITO-PlayerTracking

> A homebrew slot machine TITO, player tracking and display project

Original author: marcrdavis (source: https://github.com/marcrdavis/ArduinoTITO-PlayerTracking)

## Article

## Arduino TITO & Player Tracking — Casino-Grade Ticketing and Loyalty for Your Home Slot Machine

`#TITO` `#SASProtocol` `#PlayerTracking` `#W5100` `#TOE` `#EthernetServer` `#ArduinoMega` `#RFID` `#RemoteManagement` `#RetroGaming`

> 📚 Context: Long-running open-source hobby/enthusiast project (v1 → v4, actively maintained; v4.0 build 20260623) Implementation verified: full 3,200-line Mega sketch, W5100 Ethernet Shield, `EthernetServer` on port 80 + `EthernetClient` reporting, SAS protocol over Serial1, KiCad-free but PDF-documented hardware wiring.

---

### 01 — What is this project?

Casinos use a deceptively sophisticated stack behind every slot machine. **TITO** (Ticket In / Ticket Out) is the industry mechanism that replaced coin hoppers: instead of dropping coins, a machine prints a barcoded voucher when you cash out, and accepts one when you sit down. Behind that sits **SAS** (Slot Accounting System) — the Gaming-standard serial protocol, spoken by virtually every modern slot machine, that lets a host system read meters (credits, coin-in, games played, jackpots), issue commands (lock/unlock, enable/disable bill validator, mute), and validate tickets. On top of both runs **player tracking**: the loyalty layer that identifies a player by card, follows their play, and drives the little display on the machine that says "Welcome back."

For a home slot-machine owner — a surprisingly active collector community — all of that is normally locked inside proprietary casino management systems that cost more than the machine itself. There is no consumer product that gives a hobbyist TITO, remote control, and player tracking for a game sitting in their basement.

This project closes that gap. Using an **Arduino Mega 2560** and a **WIZnet W5100 Ethernet Shield**, it implements a working slice of the real casino stack: it speaks SAS to any SAS-compatible game, prints and redeems TITO tickets, exposes a **web management console** for remote control, and pushes live play data to a central **player-tracking server** — while reusing the machine's existing display, keypad, and card-reader hardware. Version 4.0 adds a rewritten web console for every network-enabled sketch and remote SD-card file updates.

The result: a homebrew board that turns a standalone slot machine into a networked, remotely-managed, loyalty-aware device — the kind of thing that normally requires a casino IT department.

### 02 — Why networked TITO & player tracking?

#### 🔷 The serial protocol is only half the problem

Talking SAS over a serial line to one machine is a solved problem. The hard part is everything *around* it: getting meter data off the machine, letting an operator manage the game without standing in front of it, and correlating a physical RFID card with a player record. Every one of those is a **network** problem, not a serial one. The moment you want remote control and centralized player tracking, you need a reliable TCP/IP endpoint bolted onto a microcontroller.

#### 🔷 Two network roles at once

What makes this project architecturally interesting is that the same board plays **both sides** of the network conversation:

- As an **HTTP server** (`EthernetServer server(80)`), it serves a web management console so an operator can lock/unlock the game, toggle the bill validator, reset jackpots, and view configuration from a browser.

- As an **HTTP client** (`EthernetClient` → `client.connect(serverIP, 80)`), it reports each card-in event and the player's session meters (credits, coin-in, games won/lost, total won) to a separate player-tracking server via a `GET /?pu&cardID=…&data=…` request.

Doing both, reliably, on an Arduino Mega's limited RAM — alongside the SD and SAS libraries — is exactly why the hardware TCP/IP offload of the WIZnet chip matters.

#### 🔷 Reusing existing hardware

The project deliberately drives the machine's *existing* player-tracking display, keypad, and card reader. That constraint — retrofit, don't replace — is what makes it genuinely useful to the collector community rather than a lab demo.

### 03 — System architecture

![](https://maker.wiznet.io/upload/ckeditor5/201041839%5F1783327994%2Epng)

### 04 — Why WIZnet W5100? ⭐

#### 🔷 The technical core

The Arduino Mega 2560 has just 8 KB of SRAM. Running a full software TCP/IP stack (like the classic ENC28J60 + UIPEthernet path) on top of the SAS protocol handler, an IniFile config parser, the SD library, RFID, keypad, and display drivers would exhaust RAM and destabilize the whole system — the README's changelog explicitly documents earlier stability problems caused by "the memory requirements of the Ethernet and SD libraries." The W5100 solves this at the hardware level.

#### 🔷 Socket mode used — TOE / TCP (`Sn_MR_TCP`)

This project uses the W5100's **hardwired TCP mode (TOE — TCP/IP Offload Engine)** on both of its sockets:

- **Listening socket** — `EthernetServer server(80)` → `server.begin()` puts a socket into TCP listen for the web management console (equivalent to `Sn_MR_TCP` + `listen()`).

- **Client socket** — `client.connect(serverIP, 80)` opens an outbound TCP connection to the player-tracking server to report card and meter data.

The entire TCP handshake, retransmission, windowing, and checksum work happens **inside the W5100 silicon**. The Mega only reads and writes socket buffers over SPI — no lwIP, no software stack, no per-packet CPU cost. That is precisely what lets a memory-constrained 8-bit MCU serve HTTP *and* act as an HTTP client while simultaneously running a real-time casino serial protocol.

#### 🔷 Advantage over alternatives

- **vs ENC28J60 (software stack):** ENC28J60 is a MAC+PHY only — the MCU must run the full TCP/IP stack in SRAM. On a Mega already loaded with SD + SAS + RFID, that path was the documented source of instability. The W5100's onboard stack removes that burden entirely.

- **vs Wi-Fi shields:** the README states plainly that "Wifi shields are NOT recommended" — a slot machine on a casino/home floor needs a deterministic, low-latency wired link for meter accuracy and remote-command reliability, not a congested 2.4 GHz radio.

- **Drop-in ecosystem:** the standard Arduino `Ethernet.h` library targets the W5100/W5200/W5500 family directly, so the shield is a true plug-and-play addition to the Mega stack.

#### 🔷 Verified evidence ✅

- `#include <Ethernet.h>` + `EthernetServer server(80)` + `EthernetClient` confirmed in the 3,209-line V4 Mega sketch.

- Header comment specifies the exact hardware: *"Arduino Mega 2560 R3; Compatible RFID or magnetic reader; **W5100 Ethernet Shield**; Serial Port."*

- Configurable MAC (`byte mac[]`) and static-IP fallback (`IPAddress ip(192,168,1,254)`) with DHCP as primary — production-grade network setup.

- Full SAS command table present in code (`LOCK`, `ULOCK`, `MUTE`, `EBILL`/`DBILL` bill-validator enable/disable, `transComplete`, meter reads for credits/coin-in/games/jackpots).

- Three PDF documentation manuals + a companion Game Manager app + a player-tracking server component — a complete, reproducible system, not a snippet.

### 05 — Key components

#### 🌐 WIZnet W5100 — TOE / TCP mode (dual socket: HTTP server + HTTP client)

Provides the hardware TCP/IP offload that makes networked TITO possible on an 8-bit Mega. One socket listens on port 80 for the web management console; another connects outbound to the player-tracking server. All TCP mechanics run in-chip over SPI.

#### 🎰 Arduino Mega 2560 R3

The host controller. Chosen over the Uno specifically for its larger SRAM and multiple hardware serial ports — `Serial1 @ 19200` is dedicated to the SAS/TITO link with the game, leaving USB serial free for debugging.

#### 💳 MFRC522 RFID reader

Identifies the player by card and triggers the "card-in" event that starts a tracked session and reports to the central server. (Magnetic-stripe readers are also supported via commented `MagStripe` includes.)

#### ⌨️ Keypad + LCD/VFD display

The on-machine operator/player interface. The keypad issues live SAS commands (mute, lock, enable bill validator); the display reuses the slot machine's existing player-tracking panel.

#### 💾 SD card

Stores the config file (`IniFile`), the web-console HTML, and player/bonus/admin card definitions — and in v4 can be updated remotely over the network.

#### 📡 SAS protocol layer (Serial1)

A partial Arduino implementation of the Gaming-standard Slot Accounting System, reading meters and issuing machine commands — the bridge between the physical game and the networked world.

### 06 — Application scenarios

#### 01. Home slot-machine collector

Retrofit a garage or game-room slot machine with real TITO ticketing and remote management — cash out to a printed voucher, lock the game from a phone browser, all over the home LAN.

#### 02. Small-venue / arcade loyalty

Run a lightweight player-tracking loyalty layer across several machines, each board reporting card sessions and meters to one central server — without a commercial casino-management contract.

#### 03. Remote game administration

Manage a machine you can't physically reach: unlock/lock play, enable or disable the bill validator, reset jackpots, and inspect configuration from the web console — the wired W5100 link keeps commands deterministic.

#### 04. Retro-gaming & protocol education

A rare, fully-documented open-source reference for the SAS protocol and TITO mechanics — valuable to anyone learning how real gaming hardware talks, with the network layer cleanly separated onto the WIZnet chip.

### Conclusion

> **This project rebuilds a slice of a casino's machine-management stack — TITO ticketing, SAS control, and player tracking — on an 8-bit Arduino, and it is the hardware TCP/IP offload of the WIZnet W5100 that makes serving a web console and reporting to a loyalty server possible without collapsing the Mega's memory.**

- ✅ Implements real Gaming-industry mechanisms (TITO + SAS) on hobbyist hardware

- ✅ W5100 runs in **TOE/TCP mode** as *both* HTTP server and HTTP client simultaneously

- ✅ Offloads the entire TCP/IP stack from an 8-bit MCU already saturated with SD + SAS + RFID

- ✅ Wired Ethernet chosen deliberately over Wi-Fi for command/meter reliability

- ✅ Actively maintained across four major versions (latest build 20260623)

- ✅ Complete, reproducible system: firmware + Game Manager app + tracking server + three PDF manuals

- ✅ Retrofits existing machine hardware rather than replacing it

- ✅ Demonstrates that casino-grade ticketing and loyalty gear is another place a WIZnet chip quietly lives

**And the reach point:** even the ticketing and player-tracking electronics behind a slot machine — a domain almost nobody associates with hobbyist Ethernet — run on a WIZnet chip.

### 07 — Similar Projects on WIZnet Makers

This project sits at the intersection of two families already present on WIZnet Makers: **networked cashless-payment / vending controllers** and **Ethernet game peripherals**. All of them lean on a WIZnet chip's TCP link to move money, credits, or input data off a machine — the same architectural need TITO has.

- [**mdb-arduino-cashless**](https://maker.wiznet.io/Hannah/projects/mdb-arduino-cashless/) — An Arduino Uno bridges the **MDB (Multi-Drop Bus)** vending protocol to a networked cashless payment flow, with an MFRC522 RFID reader for tap-to-pay. The closest cousin to TITO: MDB is to vending machines what SAS is to slot machines — the standard serial protocol this board lifts onto the network.

- [**Vending Machine / Cashless Device Implementation**](https://maker.wiznet.io/rena/projects/Vending-MachineCashless-Device-Implementation/) — A vending cashless device (Nottingham Hackspace's Vend2 lineage) that also pairs RFID with a networked payment backend over TCP. Same "authenticate a card → authorize a transaction on a machine" loop as TITO's card-in event.

- [**Ethernet gaming controller with W5500**](https://maker.wiznet.io/ronpang/projects/ethernet-gaming-controller-with-w5500-1/) — A W5500-based Ethernet game controller. Shares TITO's *gaming-peripheral-over-wired-Ethernet* angle, but points the other direction: sending player **input** into a game rather than metering a game's **output**.

#### Comparison

| Project | Core MCU | WIZnet role | Machine protocol | Card / auth | Direction of data | Server/Client |
| --- | --- | --- | --- | --- | --- | --- |
| **Arduino TITO & Player Tracking** (this) | Arduino Mega 2560 | W5100 · TCP (TOE) | **SAS** (slot machine) | MFRC522 RFID | Meters **out** + remote cmds **in** | **Both** (HTTP server + client) |
| mdb-arduino-cashless | Arduino Uno | W5x00 · TCP | **MDB** (vending) | MFRC522 RFID | Payment auth | Client-side payment flow |
| Vending / Cashless (Vend2) | Arduino | W5x00 · TCP | Vending (Vend2) | RFID | Payment auth | Networked backend |
| Ethernet gaming controller | (controller board) | W5500 · TCP | — (HID-style input) | — | Input **in** to game | TCP link |

### Q&A

**Q. Which WIZnet socket mode does this use, and why not UDP?** A. It uses **TOE / TCP mode (**`**Sn_MR_TCP**`**)**. Both the web management console (inbound) and the player-tracking reports (outbound) are HTTP, which is TCP-based — reliable, ordered delivery matters for meter data and remote commands, so TCP is the correct choice over UDP.

**Q. Why a W5100 and not just an ENC28J60 to save cost?** A. The ENC28J60 is MAC+PHY only and forces the MCU to run the TCP/IP stack in software/SRAM. The README's changelog documents that the combined memory footprint of the Ethernet-plus-SD software path was a real source of instability on the Uno-class hardware. The W5100's in-silicon stack removes that RAM pressure — essential when the Mega is already running SAS, SD, RFID, keypad, and display code.

**Q. Could this move to a W5500 or W55RP20?** A. Yes, cleanly. The standard `Ethernet.h` library covers the whole W5100/W5200/W5500 family, so a W5500 shield would be close to a drop-in upgrade with more sockets and higher SPI throughput. A W55RP20 (RP2040 + W5500-in-package) would be an interesting single-chip modernization, though it would mean porting the Mega-specific SAS timing to the RP2040.

**Q. Is this legal / is it a cheating device?** A. No. It reads standard SAS meters and manages a machine the *owner* controls — the same read/command operations a legitimate casino host system performs. It targets home collectors and small venues managing their own hardware, not tampering with third-party machines.

---

## [한글 버전]

## Arduino TITO & Player Tracking — 우리 집 슬롯머신에 카지노급 티켓팅과 멤버십을 얹다

`#TITO` `#SAS프로토콜` `#PlayerTracking` `#W5100` `#TOE` `#EthernetServer` `#ArduinoMega` `#RFID` `#원격관리` `#레트로게이밍`

> 📚 컨텍스트: 오래 유지된 오픈소스 취미/애호가 프로젝트 (v1 → v4, 활발히 유지보수 중; v4.0 빌드 20260623) 구현 검증: 3,200줄짜리 Mega 스케치 전체 확인, W5100 이더넷 실드, 80포트 `EthernetServer` + `EthernetClient` 리포팅, Serial1을 통한 SAS 프로토콜, PDF로 문서화된 하드웨어 배선.

---

### 01 — 이 프로젝트는 무엇인가?

카지노의 모든 슬롯머신 뒤에는 의외로 정교한 시스템이 돌아간다. **TITO**(Ticket In / Ticket Out)는 동전 호퍼를 대체한 업계 표준 방식이다. 동전을 쏟아내는 대신, 정산할 때 바코드가 찍힌 바우처를 출력하고, 게임을 시작할 때 그 바우처를 받아들인다. 그 아래에는 **SAS**(Slot Accounting System)가 있다. 거의 모든 현대 슬롯머신이 사용하는 게이밍 업계 표준 시리얼 프로토콜로, 호스트 시스템이 미터값(크레딧, 코인인, 게임 수, 잭팟)을 읽고, 명령(잠금/해제, 지폐인식기 활성화/비활성화, 음소거)을 내리고, 티켓을 검증할 수 있게 해준다. 그리고 이 둘 위에 **플레이어 트래킹**이 얹힌다. 카드로 플레이어를 식별하고, 플레이를 추적하고, 머신에 붙은 작은 디스플레이에 "다시 오신 걸 환영합니다"를 띄우는 멤버십 계층이다.

집에 슬롯머신을 두는 소유자 — 의외로 활발한 수집가 커뮤니티가 존재한다 — 에게 이 모든 건 보통 머신 값보다 비싼 상용 카지노 관리 시스템 안에 잠겨 있다. 지하실에 놓인 게임기 하나에 TITO, 원격 제어, 플레이어 트래킹을 붙여주는 소비자용 제품은 없다.

이 프로젝트가 바로 그 간극을 메운다. **Arduino Mega 2560**과 **WIZnet W5100 이더넷 실드**로, 진짜 카지노 스택의 동작하는 일부를 구현한다. SAS 호환 게임기와 SAS로 통신하고, TITO 티켓을 출력·상환하고, 원격 제어용 **웹 관리 콘솔**을 열고, 실시간 플레이 데이터를 중앙 **플레이어 트래킹 서버**로 밀어올린다. 그것도 머신의 기존 디스플레이·키패드·카드리더를 그대로 재활용하면서. v4.0은 모든 네트워크 지원 스케치에 새로 작성된 웹 콘솔과 원격 SD카드 파일 업데이트를 추가했다.

결과물은, 독립형 슬롯머신을 네트워크에 연결된, 원격 관리 가능한, 멤버십을 인식하는 장치로 바꿔주는 자작 보드다. 보통은 카지노 IT 부서가 있어야 가능한 그런 것 말이다.

### 02 — 왜 네트워크 기반 TITO와 플레이어 트래킹인가?

#### 🔷 시리얼 프로토콜은 문제의 절반일 뿐

머신 한 대와 시리얼로 SAS를 주고받는 건 이미 풀린 문제다. 어려운 건 그 *주변* 전부다. 머신에서 미터 데이터를 빼내고, 운영자가 머신 앞에 서지 않고도 게임을 관리하고, 물리적 RFID 카드를 플레이어 레코드와 연결하는 것. 이 하나하나가 시리얼이 아니라 **네트워크** 문제다. 원격 제어와 중앙 집중식 플레이어 트래킹을 원하는 순간, 마이크로컨트롤러에 신뢰할 수 있는 TCP/IP 엔드포인트를 붙여야 한다.

#### 🔷 한 보드가 네트워크의 양쪽 역할을 동시에

이 프로젝트가 아키텍처적으로 흥미로운 지점은, 같은 보드가 네트워크 대화의 **양쪽**을 모두 수행한다는 것이다.

- **HTTP 서버**로서(`EthernetServer server(80)`), 웹 관리 콘솔을 제공해 운영자가 브라우저에서 게임 잠금/해제, 지폐인식기 토글, 잭팟 리셋, 설정 조회를 할 수 있게 한다.

- **HTTP 클라이언트**로서(`EthernetClient` → `client.connect(serverIP, 80)`), 카드 인식 이벤트와 플레이어의 세션 미터(크레딧, 코인인, 승/패 게임 수, 총 획득액)를 별도의 플레이어 트래킹 서버로 `GET /?pu&cardID=…&data=…` 요청으로 보고한다.

이 두 가지를 Arduino Mega의 제한된 RAM에서 — SD와 SAS 라이브러리까지 함께 돌리면서 — 안정적으로 해내는 것, 바로 그것이 WIZnet 칩의 하드웨어 TCP/IP 오프로드가 중요한 이유다.

#### 🔷 기존 하드웨어 재활용

이 프로젝트는 의도적으로 머신의 *기존* 플레이어 트래킹 디스플레이, 키패드, 카드리더를 그대로 구동한다. "교체하지 말고 개조하라"는 이 제약이야말로, 이것을 실험실 데모가 아니라 수집가 커뮤니티에 진짜로 쓸모 있는 물건으로 만든다.

### 03 — 시스템 아키텍처

![](https://maker.wiznet.io/upload/ckeditor5/201041839%5F1783328340%2Epng)

### 04 — 왜 WIZnet W5100인가? ⭐

#### 🔷 기술적 핵심

Arduino Mega 2560의 SRAM은 고작 8 KB다. SAS 프로토콜 핸들러, IniFile 설정 파서, SD 라이브러리, RFID, 키패드, 디스플레이 드라이버 위에 소프트웨어 TCP/IP 스택(고전적인 ENC28J60 + UIPEthernet 방식)까지 얹으면 RAM이 고갈되고 시스템 전체가 불안정해진다. README의 변경 이력은 "이더넷과 SD 라이브러리의 메모리 요구량" 때문에 과거에 겪은 안정성 문제를 명시적으로 기록하고 있다. W5100은 이 문제를 하드웨어 레벨에서 해결한다.

#### 🔷 사용 소켓 모드 — TOE / TCP (`Sn_MR_TCP`)

이 프로젝트는 W5100의 **하드와이어드 TCP 모드(TOE — TCP/IP Offload Engine)**를 두 소켓 모두에서 사용한다.

- **리스닝 소켓** — `EthernetServer server(80)` → `server.begin()`이 웹 관리 콘솔을 위해 소켓을 TCP 리슨 상태로 둔다 (`Sn_MR_TCP` + `listen()`에 해당).

- **클라이언트 소켓** — `client.connect(serverIP, 80)`이 플레이어 트래킹 서버로 카드·미터 데이터를 보고하기 위해 아웃바운드 TCP 연결을 연다.

TCP 핸드셰이크, 재전송, 윈도잉, 체크섬 전부가 **W5100 실리콘 내부에서** 처리된다. Mega는 그저 SPI로 소켓 버퍼를 읽고 쓸 뿐이다 — lwIP도, 소프트웨어 스택도, 패킷당 CPU 비용도 없다. 바로 이것이, 메모리가 빠듯한 8비트 MCU가 실시간 카지노 시리얼 프로토콜을 돌리면서 동시에 HTTP 서버 노릇도 하고 HTTP 클라이언트 노릇도 할 수 있게 만드는 요인이다.

#### 🔷 대체 솔루션 대비 우위

- **vs ENC28J60(소프트웨어 스택):** ENC28J60은 MAC+PHY일 뿐이라 MCU가 SRAM에서 전체 TCP/IP 스택을 돌려야 한다. SD + SAS + RFID로 이미 가득 찬 Mega에서 이 방식은 문서에 기록된 불안정성의 원인이었다. W5100의 온보드 스택은 이 부담을 통째로 없앤다.

- **vs Wi-Fi 실드:** README는 "Wi-Fi 실드는 권장하지 않는다"고 못 박는다. 카지노/가정 플로어의 슬롯머신은 미터 정확도와 원격 명령 신뢰성을 위해 혼잡한 2.4 GHz 무선이 아니라 결정론적이고 지연이 낮은 유선 링크가 필요하다.

- **드롭인 생태계:** 표준 Arduino `Ethernet.h` 라이브러리가 W5100/W5200/W5500 계열을 직접 지원하므로, 이 실드는 Mega 스택에 그대로 꽂아 쓰는 플러그앤플레이 추가물이다.

#### 🔷 검증된 증거 ✅

- 3,209줄짜리 V4 Mega 스케치에서 `#include <Ethernet.h>` + `EthernetServer server(80)` + `EthernetClient` 확인.

- 헤더 주석이 하드웨어를 정확히 명시: *"Arduino Mega 2560 R3; 호환 RFID 또는 마그네틱 리더; **W5100 이더넷 실드**; 시리얼 포트."*

- 설정 가능한 MAC(`byte mac[]`)과 정적 IP 폴백(`IPAddress ip(192,168,1,254)`), DHCP를 기본으로 하는 프로덕션급 네트워크 설정.

- 코드에 SAS 명령 테이블 전체 존재(`LOCK`, `ULOCK`, `MUTE`, 지폐인식기 활성/비활성 `EBILL`/`DBILL`, `transComplete`, 크레딧/코인인/게임/잭팟 미터 읽기).

- PDF 매뉴얼 3종 + 동반 Game Manager 앱 + 플레이어 트래킹 서버 컴포넌트 — 코드 조각이 아니라 완전하고 재현 가능한 시스템.

### 05 — 핵심 구성요소

#### 🌐 WIZnet W5100 — TOE / TCP 모드 (듀얼 소켓: HTTP 서버 + HTTP 클라이언트)

8비트 Mega에서 네트워크 기반 TITO를 가능케 하는 하드웨어 TCP/IP 오프로드를 제공한다. 한 소켓은 웹 관리 콘솔을 위해 80포트를 리슨하고, 다른 소켓은 플레이어 트래킹 서버로 아웃바운드 연결한다. 모든 TCP 메커니즘이 SPI를 통해 칩 내부에서 돈다.

#### 🎰 Arduino Mega 2560 R3

호스트 컨트롤러. Uno가 아니라 Mega를 고른 건 더 큰 SRAM과 다수의 하드웨어 시리얼 포트 때문이다 — `Serial1 @ 19200`을 게임기와의 SAS/TITO 링크 전용으로 쓰고, USB 시리얼은 디버깅용으로 남겨둔다.

#### 💳 MFRC522 RFID 리더

카드로 플레이어를 식별하고, 추적 세션을 시작해 중앙 서버로 보고하는 "카드 인식" 이벤트를 발생시킨다. (주석 처리된 `MagStripe` 인클루드를 통해 마그네틱 스트라이프 리더도 지원한다.)

#### ⌨️ 키패드 + LCD/VFD 디스플레이

머신 상의 운영자/플레이어 인터페이스. 키패드는 실시간 SAS 명령(음소거, 잠금, 지폐인식기 활성화)을 내리고, 디스플레이는 슬롯머신의 기존 플레이어 트래킹 패널을 재활용한다.

#### 💾 SD 카드

설정 파일(`IniFile`), 웹 콘솔 HTML, 플레이어/보너스/관리자 카드 정의를 저장한다 — v4에서는 네트워크를 통해 원격으로 업데이트할 수 있다.

#### 📡 SAS 프로토콜 계층 (Serial1)

게이밍 업계 표준 Slot Accounting System의 부분 구현으로, 미터를 읽고 머신 명령을 내린다 — 물리적 게임기와 네트워크 세계를 잇는 다리다.

### 06 — 활용 시나리오

#### 01. 가정용 슬롯머신 수집가

차고나 게임룸의 슬롯머신에 진짜 TITO 티켓팅과 원격 관리를 개조로 얹는다 — 정산은 출력된 바우처로, 게임 잠금은 폰 브라우저로, 전부 가정 LAN을 통해.

#### 02. 소규모 업장 / 아케이드 멤버십

여러 머신에 걸쳐 가벼운 플레이어 트래킹 멤버십 계층을 운영한다. 각 보드가 카드 세션과 미터를 하나의 중앙 서버로 보고 — 상용 카지노 관리 계약 없이.

#### 03. 원격 게임 관리

물리적으로 닿을 수 없는 머신을 관리한다. 웹 콘솔에서 플레이 잠금/해제, 지폐인식기 활성/비활성, 잭팟 리셋, 설정 점검 — 유선 W5100 링크가 명령을 결정론적으로 유지한다.

#### 04. 레트로 게이밍 & 프로토콜 교육

SAS 프로토콜과 TITO 메커니즘에 대한 드물게 완전히 문서화된 오픈소스 레퍼런스 — 실제 게이밍 하드웨어가 어떻게 통신하는지 배우려는 이에게 가치 있고, 네트워크 계층이 WIZnet 칩으로 깔끔하게 분리되어 있다.

### 결론

> **이 프로젝트는 카지노의 머신 관리 스택 일부 — TITO 티켓팅, SAS 제어, 플레이어 트래킹 — 를 8비트 Arduino 위에 재구축한다. 그리고 웹 콘솔을 서비스하면서 동시에 멤버십 서버로 보고하는 것을 Mega의 메모리를 무너뜨리지 않고 가능케 하는 것이 바로 WIZnet W5100의 하드웨어 TCP/IP 오프로드다.**

- ✅ 실제 게이밍 업계 메커니즘(TITO + SAS)을 취미용 하드웨어에서 구현

- ✅ W5100이 **TOE/TCP 모드**로 HTTP 서버와 HTTP 클라이언트를 *동시에* 수행

- ✅ SD + SAS + RFID로 이미 포화된 8비트 MCU에서 TCP/IP 스택 전체를 오프로드

- ✅ 명령/미터 신뢰성을 위해 Wi-Fi가 아닌 유선 이더넷을 의도적으로 선택

- ✅ 네 개의 메이저 버전에 걸쳐 활발히 유지보수 (최신 빌드 20260623)

- ✅ 완전하고 재현 가능한 시스템: 펌웨어 + Game Manager 앱 + 트래킹 서버 + PDF 매뉴얼 3종

- ✅ 머신 하드웨어를 교체하지 않고 개조로 재활용

- ✅ 카지노급 티켓팅·멤버십 장비 역시 WIZnet 칩이 조용히 자리 잡은 또 하나의 영역임을 보여줌

**그리고 리치 포인트:** 슬롯머신 뒤의 티켓팅·플레이어 트래킹 전자장치 — 취미용 이더넷과는 거의 아무도 연결짓지 않는 도메인 — 조차 WIZnet 칩 위에서 돌아간다.

### 07 — WIZnet Makers 내 유사 프로젝트

이 프로젝트는 WIZnet Makers에 이미 존재하는 두 계열의 교집합에 놓여 있다. **네트워크 기반 캐시리스 결제/자판기 컨트롤러**와 **이더넷 게임 주변기기**다. 이들 모두 돈, 크레딧, 혹은 입력 데이터를 머신 밖으로 옮기기 위해 WIZnet 칩의 TCP 링크에 의존한다 — TITO가 가진 것과 정확히 같은 아키텍처적 필요다.

- [**mdb-arduino-cashless**](https://maker.wiznet.io/Hannah/projects/mdb-arduino-cashless/) — Arduino Uno가 **MDB(Multi-Drop Bus)** 자판기 프로토콜을 네트워크 캐시리스 결제 흐름으로 브리지하고, MFRC522 RFID 리더로 태그 결제를 처리한다. TITO의 가장 가까운 사촌이다. MDB가 자판기에서 하는 역할이 SAS가 슬롯머신에서 하는 역할과 같다 — 이 보드가 네트워크로 끌어올린 표준 시리얼 프로토콜인 것이다.

- [**Vending Machine / Cashless Device Implementation**](https://maker.wiznet.io/rena/projects/Vending-MachineCashless-Device-Implementation/) — 자판기 캐시리스 장치(Nottingham Hackspace의 Vend2 계보)로, 역시 RFID와 TCP 기반 네트워크 결제 백엔드를 결합한다. "카드 인증 → 머신에서 거래 승인"이라는 루프가 TITO의 카드 인식 이벤트와 동일하다.

- [**Ethernet gaming controller with W5500**](https://maker.wiznet.io/ronpang/projects/ethernet-gaming-controller-with-w5500-1/) — W5500 기반 이더넷 게임 컨트롤러. TITO의 *유선 이더넷 기반 게이밍 주변기기* 각도를 공유하지만 방향이 반대다. 게임의 **출력**을 계측하는 게 아니라, 플레이어의 **입력**을 게임으로 보낸다.

#### 비교

| 프로젝트 | 핵심 MCU | WIZnet 역할 | 머신 프로토콜 | 카드/인증 | 데이터 방향 | 서버/클라이언트 |
| --- | --- | --- | --- | --- | --- | --- |
| **Arduino TITO & Player Tracking** (본) | Arduino Mega 2560 | W5100 · TCP (TOE) | **SAS** (슬롯머신) | MFRC522 RFID | 미터 **아웃** + 원격명령 **인** | **양쪽** (HTTP 서버+클라이언트) |
| mdb-arduino-cashless | Arduino Uno | W5x00 · TCP | **MDB** (자판기) | MFRC522 RFID | 결제 인증 | 클라이언트측 결제 흐름 |
| Vending / Cashless (Vend2) | Arduino | W5x00 · TCP | 자판기 (Vend2) | RFID | 결제 인증 | 네트워크 백엔드 |
| Ethernet gaming controller | (컨트롤러 보드) | W5500 · TCP | — (HID형 입력) | — | 입력 **인** → 게임 | TCP 링크 |

### Q&A

**Q. 어떤 WIZnet 소켓 모드를 쓰며, 왜 UDP가 아닌가?** A. **TOE / TCP 모드(`Sn_MR_TCP`)**를 쓴다. 웹 관리 콘솔(인바운드)과 플레이어 트래킹 보고(아웃바운드) 모두 HTTP이며, HTTP는 TCP 기반이다. 미터 데이터와 원격 명령에는 신뢰성 있고 순서가 보장된 전달이 중요하므로 UDP보다 TCP가 올바른 선택이다.

**Q. 비용 절감을 위해 ENC28J60을 쓰면 안 되나?** A. ENC28J60은 MAC+PHY일 뿐이라 MCU가 소프트웨어/SRAM에서 TCP/IP 스택을 돌려야 한다. README 변경 이력은 이더넷+SD 소프트웨어 경로의 메모리 총량이 Uno급 하드웨어에서 실제 불안정성의 원인이었음을 기록한다. W5100의 칩 내장 스택은 이 RAM 압박을 없앤다 — Mega가 이미 SAS, SD, RFID, 키패드, 디스플레이 코드를 돌리고 있을 때 필수적이다.

**Q. W5500이나 W55RP20으로 옮길 수 있나?** A. 깔끔하게 가능하다. 표준 `Ethernet.h` 라이브러리가 W5100/W5200/W5500 계열 전체를 지원하므로, W5500 실드는 더 많은 소켓과 더 높은 SPI 처리량을 갖춘 거의 드롭인 업그레이드가 된다. W55RP20(RP2040 + W5500 패키지 통합)은 흥미로운 단일칩 현대화이지만, Mega 전용 SAS 타이밍을 RP2040으로 포팅해야 한다.

**Q. 이거 합법인가 / 부정 장치 아닌가?** A. 아니다. 표준 SAS 미터를 읽고 *소유자*가 통제하는 머신을 관리할 뿐이며, 이는 정당한 카지노 호스트 시스템이 수행하는 것과 동일한 읽기/명령 동작이다. 제3자의 머신을 조작하는 게 아니라, 자기 하드웨어를 관리하는 가정 수집가와 소규모 업장을 대상으로 한다.

---

Source: https://maker.wiznet.io/Lihan__/projects/arduinotito-playertracking/