Project

# Title Team Members TA Documents Sponsor
18 RFID Poker Board
Darren Liao
KB Bolor-Erdene
Satyam Singh
# Team Members:
- Satyam Singh (satyams2)
- Darren Liao (darrenl4)
- Khuselbayar Bolor-Erdene (kb40)

# Poker

Traditional poker tables rely on the dealer and players to track cards, bets, and pots. This process can be slow and error prone, especially in casual games where the dealer is inexperienced. Players may misread cards, deal incorrectly, or lose track of the state of the game. Live poker also lacks many of the conveniences of online poker, such as automatic hand evaluation, instant game state updates, and precise tracking of actions. Online platforms further enhance the player experience with detailed statistics, and hand histories while live games rely entirely on player knowledge.

# Solution

An RFID-enabled poker table with tagged cards helps to bridge this gap by bringing digital intelligence into the live poker experience. By embedding RFID readers in the table, the system can automatically recognize cards, display the game state in real time, and evaluate hands without error. Game state management features such as LED indicators can track dealer position, blinds, and turn order, giving players visual cues that keep the game running smoothly.

A dedicated companion app would serve as the primary user interface, providing players with immediate feedback. The app can also highlight blind positions, display whose action it is

At a high level, we will stick 13.56 MHz HF RFID sticker tags onto poker cards (and possibly chips later), place small antenna pads under the “seat” zones in front of each player, and a larger one in the middle for the community cards. We will build a main PCB with an ESP32, a single HF reader IC, and an RF MUX switch so the microcontroller unit (MCU) can scan all pads sequentially. The MCU will resolve tag UIDs into chip denominations or card identities, then send compact state updates to a small UI over Wi-Fi in near real-time.

# Solution Components

## Subsystem 1: RFID Cards and Antenna Network

Each card and chip will have a 13.56 MHz HF RFID NFC sticker (ISO 15693) attached. Antenna pads will be embedded under each player’s seat zone and a larger pad will be used for the community cards. All pads will be routed through an RF multiplexer (e.g., a 16:1 analog switch like the HMC7992) into a single HF RFID reader IC (such as PN532 or MFRC522). The microcontroller will sequentially energize each pad, cycling through them at a fast interval per pad to collect tag UIDs, filter duplicates, and reliably detect card positions in near real time.

## Subsystem 2: Central Microcontroller

The system will use an ESP32-S3 (dual-core with Wi-Fi) as the central controller. It will interface with the RFID reader via SPI or I2C and control the RF multiplexer using GPIO select lines. The microcontroller will maintain an internal mapping of card and chip UIDs to their identities (rank/suit or chip denomination) and update the game state. Once the game state is compiled, it will be serialized into JSON format and transmitted to the visualization app over HTTP for low-latency communication.

## Subsystem 3: Game Visualization App

The visualization layer will be a cross-platform application (built with Python + Flask) that receives JSON packets from the ESP32. It will display each player’s hole cards and the community cards, highlight blinds and active turns, and compute win probabilities for each player using either Monte Carlo simulation or a precomputed odds lookup. As a stretch goal, the app will also store hand histories and send LED or LCD commands back to the ESP32 to synchronize the physical table indicators with the digital state.

# Criterion For Success

- 100% accuracy in tracking the cards currently in play through 5 rounds of gameplay
- Game state is accurately updated on the app within 2-5 seconds of updating
- Board can correctly differentiate between folds and players accidentally moving their cards away from antennas

# Stretch Goals
If we have the time, we would also like to enhance the player experience by adding small LED indicators for the game state (big/small blinds, betting rounds, LCD screen showing the pot size) to help each player better understand the game without having to rely strictly on the app.

Tracking chips can be more challenging, since stacking with RFID can be difficult. However, we would love to implement this so we can build on the tech idea above and display the total pot size directly on the board along with the app.

Additionally, if desired, we could use algorithms and machine learning in the app to help players make the best decisions given the current game state.

CHARM: CHeap Accessible Resilient Mesh for Remote Locations and Disaster Relief

Martin Michalski, Melissa Pai, Trevor Wong

Featured Project

# CHARM: CHeap Accessible Resilient Mesh for Remote Locations and Disaster Relief

Team Members:

- Martin Michalski (martinm6)

- Trevor Wong (txwong2)

- Melissa Pai (mepai2)

# Problem

There are many situations in which it is difficult to access communicative networks. In disaster areas, internet connectivity is critical for communication and organization of rescue efforts. In remote areas, a single internet connection point often does not cover an area large enough to be of practical use for institutions such as schools and large businesses.

# Solution

To solve these problems, we would like to create a set of meshing, cheap, lightweight, and self-contained wireless access points, deployable via drone. After being placed by drone or administrator, these access points form a WiFi network, usable by rescuers, survivors, and civilians. Our network will have QoS features to prioritize network traffic originating from rescuers. Having nodes/access points deployable by drone ensures we are able to establish timely connectivity in areas where search and rescue operations are still unable to reach.

Over the course of the semester, we will produce a couple of prototypes of these network nodes, with built in power management and environmental sensing. We aim to demonstrate our limited network’s mesh capabilities by setting up a mock network on one of the campus quads, and connecting at various locations.

# Solution Components

## Router and Wireless Access Point

Wireless Access for users and traffic routing will be the responsibility of an Omega2 board, with onboard Mediatek MT7688 CPU. For increased signal strength, the board will connect to a RP-SMA antenna via U.FL connector.

The Omega2 will be running OpenWRT, an Linux-based OS for routing devices. We will develop processes for the Omega2 to support our desired QoS features.

## Battery Management System

This module is responsible for charging the lithium-ion battery and ensuring battery health. Specifically, we will ensure the battery management system has the following features:

- Short circuit and overcurrent protection

- Over- and under-voltage protection

- An ADC to provide battery status data to the microcontroller

- 3.3v voltage regulation for the microcontroller and other sensors

In addition to miscellaneous capacitors and resistors, we intend to use the following components to implement the battery management system:

- The MT2492 step-down converter will be used to step down the output voltage of the battery to 3.3 volts. Between the GPS and extra power the microcontroller might consume with an upgraded Wifi antenna, low-dropout regulators would not provide sufficient power in an efficient manner. Instead, we will implement a 2 amp buck converter to improve efficiency and ensure there are no current bottlenecks.

- We will utilize two button-top protected 18650 3400 mAh lithium ion batteries in series to power each node. Placing two of these batteries in series will ensure their combined voltage never falls below the minimum voltage input of the buck converter, and accounting for the buck converter’s inefficiency these batteries should give us about 21 Wh of capacity. The cells we plan on using include a Ricoh R5478N101CD protection IC that provides over-voltage, under-voltage, and over-current protection. Using a standard battery form factor will make them easy to replace in the future as needed.

- A USB-C port with two pulldown resistors will provide 5 volt charging input with up to 3 amps of current, depending on the charger.

- The MT3608 step-up converter will boost the input voltage from the usb-c port and feed it into the charging controller.

- The MCP73844 Charge Management Controller will be used to charge the batteries. This controller supports CC/CV charging and a configurable current limit for safe and effective battery charging.

- The TI ADS1115 ADC will be used for battery voltage monitoring. This chip is used in the official Omega2 expansion board, so it should be easy to integrate in software. We will use a voltage divider to reduce the battery voltage to a range this chip can measure, and this chip will communicate over an I2C bus.

## Sensor Suite

Each node will have a battery voltage sensor and GPS sensor, providing the system with health information for each node. On top of the Wifi-connectivity, each module would have a series of sensors to detect the status of the physical node and helpful environment variables. This sensor suit will have the following features and components to implement it

- Ultimate GPS Module PA1616D will be used for positioning information. This chip utilizes 3.3V which is supplied through our battery management system.

Battery Voltage Monitor

- The TI ADS1115 ADC (mentioned in the BMS section) is for battery voltage monitoring. It interfaces via I2C to the Omega2.

## System Monitor

A system monitor which provides visibility of the overall system status for deployed network nodes. Information that we will show includes: last known location, battery health, and network statistics (e.g. packets per second) from the physical devices.

We plan on using React to provide an intuitive UI, using google-map-react and other React packages to create an interactive map showing the last known location and status of each node.

The backend will be hosted on a server in the cloud. Nodes will continually update the server with their status via POST requests.

# Criterion For Success

We aim to achieve the following performance metrics:

- 1.5 kg maximum mass

- Cover 7500 m^2 (North Quad) with 4 nodes

- Display the last known location, time connected, and battery voltage for all nodes via our system monitor

- 3 hour battery life

- 5 Mb/s WiFi available to laptops and smartphones in the coverage area

[*Link*](https://courses.engr.illinois.edu/ece445/pace/view-topic.asp?id=71252) *to assciated WebBoard discussion*