ESE516_Auto_Card_Dealing_Machine

2. Project Summary

Device Description

The Automated Card Dealer is an IoT-enabled device that distributes playing cards to multiple players with precision and consistency. It features a motorized card-dealing mechanism controlled via a mobile app or web interface, with support for various card games mode.

The system supports remote OTAU (Over-the-Air Update) for one-click firmware upgrades. Currently, it supports normal and Texas Hold'em modes, and future updates can easily expand to support more game types and flexible player configurations.

Additionally, it features card tray monitoring — the device automatically halts operation when no cards remain, ensuring safe and efficient gameplay.

Inspiration

Inspired by the success of automatic Mahjong tables in China, we are developing a compact, portable, and affordable automatic poker dealing machine. It supports player count selection, various game modes, and allows users to specify the starting dealer position.

As avid card game players, we wanted to eliminate human dealing errors and ensure fair card distribution in games. Traditional card dealing can be inconsistent, slow, and sometimes unfair — our system solves this while introducing IoT capabilities for remote control and real-time monitoring, enhancing both convenience and fairness.

Device Functionality

The core of our Internet-connected card dealer is built around the SAMW25 chip, which provides seamless WiFi communication and integration with a cloud-based dashboard via MQTT. The SAMW25 acts as the central controller, coordinating data exchange and motor control based on commands received from the user or environment.

Our system includes several mechanical and electronic components working together to deliver precise and intelligent card dealing:

BH1750 light sensor: Detects whether there are cards left in the tray. When the tray is empty, the system automatically stops the dealing process.
Stepper motor: Rotates the dealer arm to face the correct player based on user input.
DC motor: Controls the speed and number of cards being dealt by rotating a roller mechanism.

Mechanically, four rods are connected via springs and a pushpad to ensure continuous pressure on the card stack. A shaft coupling links the DC motor with the card feeder to ensure reliable transmission. Together, the stepper motor, DC motor, springs, rods, and pushpad form the integrated mechanical delivery system.
You can view an exploded view animation here for better understanding of the internal mechanical design.

The system is equipped with multiple interaction and control modes:

Normal Mode: Distributes a single card per player in a loop, typically used for casual play.
Texas Hold’em Mode: Implements predefined distribution logic based on Texas Hold’em rules (e.g., 2 hole cards, 5 community cards).
OTA Update: Allows the producer to remotely push firmware updates to the device for improved logic or game support (e.g., Dou Dizhu, Guan Dan). Firmware updates are protected with CRC verification — if the check fails, the system will automatically roll back to a stable golden firmware to ensure continued functionality.

All device states and commands are managed through a Node-RED dashboard. Users can select game modes, number of players, and start the dealing process remotely. Light sensor data is also visualized to monitor deck status in real-time.

Internet Connectivity

Our device uses WiFi connectivity to enable remote control through a Node-RED dashboard. Users can select the number of players, choose between distribution modes (normal or blackjack), and monitor the remaining cards in real-time through a web interface, making the card dealing experience more interactive and customizable.

Cloud Interaction: It handles Wi-Fi connection and communicates with the Node-RED dashboard over MQTT. Through the dashboard, users can:

Select game mode (Normal or Texas Hold'em)
Set number of players (2–3 supported)
Press "Start Distribution" to trigger the sequence
Perform OTA updates via a single button
Monitor real-time light sensor data

Block diagram of the device is shown below:

Challenges

Where did you face difficulties? This could be in firmware, hardware, software, integration, etc.

One of the most critical challenges we encountered was related to hardware stability. All three of our custom PCBs had issues, each with different root causes, which made debugging extremely time-consuming. Even after extensive testing and diagnostics, the problems persisted. This raised concerns that SN2 and SN3 might have deeper issues beyond the known USB communication faults, potentially threatening the success of our entire project. Given the limited time, we discussed with our TA and decided to temporarily switch to the SAM W25 Xplained Pro development board for integration and the demo dry run. All debugging and development, including completing milestone A12G, was carried out on the sample board.

After significant effort, we managed to restore USB communication on SN2 using fly wires, just days before the final demo. We then initiated a full migration of the project back to our custom board. However, we faced unexpected issues during this process, confirming that transitioning everything in just one day was unrealistic. Despite this, we ultimately succeeded in porting the project to our board, including re-enabling features like the screen which had previously been removed due to manufacturing flaws. This hardware migration was an immense challenge that required patience and extensive hands-on debugging.

Another major difficulty was in mechanical design. Since our system uses friction-based transmission with bearings and must precisely control card output (despite individual cards being extremely thin), the mechanical design demanded extremely high precision and consistency. We went through six different CAD design versions and 3D printed four of them. Each iteration required testing, observation, and adjustment. Tuning the model to achieve both smooth operation and accurate card count control was a long and iterative process.

How did you overcome these challenges?

These were not textbook or commonly documented problems — they were unique to our design. There were no ready-made solutions online or in datasheets. To address them, we relied heavily on trial and error, long hours of debugging, and systematic hardware testing. The PCB transition was completed just three days before demo day after two intensive days of effort. For mechanical issues, we took an iterative prototyping approach, refining our model one step at a time, which is why we ended up with four full 3D-printed assemblies.

No special method for the problems, we just spent huge amount of time on it.

Prototype Learnings

What lessons did you learn by building and testing this prototype?

It is honestly hard to summarize what I learned from this course and this project — not because I learned little, but because I learned too much. Every lecture, every assignment, every late night working with teammates, every Ed post we read (sometimes more than ten at once), every OH we attended — each moment was packed with learning.

I was deeply moved by ESE516. It’s hard to imagine that in less than 15 weeks, we designed our own PCB from scratch, had it fabricated, tested and debugged it, wrote drivers for hardware components, developed a file system and bootloader, implemented firmware flashing and CRC checking, built MQTT-based cloud control, and finally achieved full system integration with remote updates and real-time control. A difficult course usually overwhelms me, but the sheer intensity and workload of ESE516 left no time to panic. We just kept going — focused entirely on the project — until we forgot how difficult the path really was. Looking back, we’ve done so much. We did it, and we are proud of what we built.

What would you do differently if you had to build this device again?

This question makes me think of all the obstacles we faced — it’s hard to even single one out, because at the time each of them felt insurmountable. But I learned a lot: from the PCB design workflow to hands-on Altium use, from how to route traces to how to debug I2C, test voltages and power stages, perform load tests, and integrate hardware in a systematic way. I came into this course never having done PCB design — now I understand not only how to design a board, but also how to bring it up, test it, and fix it when things go wrong. On the software side, I also learned about MQTT communication, remote control, and integration with cloud services.

If I had to build this device again, I would refine my mechanical design — using a better transmission method, a lower gear ratio, and a higher torque stepper motor. For the PCB, I would reserve more test points and complete a comprehensive bring-up test plan, including checking all hardware subsystems individually before integration. These are things I learned the hard way, and next time, I’ll be ready.

Next Steps & Takeaways

What steps are needed to finish or improve this project?

In the future, we plan to expand the functionality of our automated card dealer by supporting more game modes and a greater number of players. We also aim to broaden compatibility with additional card-based board games, transforming the system into a general-purpose automatic game master. These improvements will involve not only software logic updates but also mechanical upgrades for scalability and reliability.

What did you learn in ESE5160 through the lectures, assignments, and this course-long prototyping project?

Through this course, we deeply explored a wide range of driver development tasks, including writing drivers for LCD screens, stepper motors, DC motors, and the BH1750 light sensor. More importantly, we built a foundational understanding of SPI and I2C communications under FreeRTOS, learning both the theory and hands-on integration from the ground up.

As a beginner with no prior experience in FreeRTOS, I also learned how to structure embedded applications using RTOS concepts — task scheduling, synchronization, and memory management. We practiced real debugging workflows using tools like breakpoints, Percepio Tracealyzer, and Saleae logic analyzers, which gave us practical skills in tracking down and fixing timing and signal issues.

Lastly, we completed a full-cycle embedded hardware development experience: designing our own PCB from scratch, testing power rails and signal interfaces, validating sensor connections, and integrating the whole system into a functional prototype. This comprehensive journey gave us the confidence to move from idea to hardware implementation and deliver a polished, real-world system.

3. Hardware & Software Requirements

3.1 Hardware Requirements Specification (HRS)

Overview:
The automatic poker dealing machine is built around the SAMW25 microcontroller, which provides Wi-Fi connectivity. Through the Wi-Fi module, users can control various settings via a mobile phone, including the number of players, game mode, starting dealer position, and randomization methods.

HRS 01 - Microcontroller Core: The project shall use the SAMW25 microcontroller, which provides Wi-Fi connectivity.

Check, we used our custom PCB for demo and video.

HRS 02 - Card Dealing: A DC motor will be used to control the number of cards dealt in a single turn. The quantity will be managed by adjusting the motor's speed and operating duration.

Check, the DC motor precisely controls the number of cards dealt by adjusting run time. The dealing process is smooth and without jamming.

HRS 03 - Direction Control: A stepper motor will be used at the base to control the card dealing direction. The motor will support 2 to 4 directions, allowing the system to accommodate games with 2 to 4 players seamlessly.

Check, the stepper motor supports dealing in multiple directions. Combined with the DC motor, it ensures cards are accurately delivered to each player.

HRS 04 - Card Count and Motor Optimization: Using a Reflective Photo Interrupt Sensor to calculate the number of cards dealt by measuring the time it is obstructed during operation. This sensor will also aid in the control and optimization of the DC motor to ensure precise card dealing, as achieving accuracy with a DC motor alone can be challenging.

Not completed. Due to PCB manufacturing issues, we could only allocate pins for one sensor. We prioritized the more critical BH1750 light sensor.

HRS 05 - Card Box Monitoring: A Light Sensor will be placed in the card box to monitor the remaining cards, ensuring the system can provide real-time updates on card availability.

Completed. The BH1750 sensor successfully detects when the card tray is empty. When no cards remain, the system stops dealing automatically, and pressing the "Start Dealing" button has no effect. Additionally, sensor data is uploaded and viewable on the cloud dashboard.

HRS 06 - Wi-Fi Internet Connectivity: Utilizing the integrated Wi-Fi in the SAM W25, the device will connect to the internet, enabling it to upload acquired data to a remote display and allowing for remote control.

Completed. The device successfully connects to the internet, supports remote card dealing, real-time sensor data updates to the cloud, and enables one-click OTAU (Over-the-Air Update) functionality.

3.2 Software Requirements Specification (SRS)

Overview:
This project centers on orchestrating several hardware components—namely the SAMW25 microcontroller, DC motor, stepper motor, and photo interrupt sensors—into an integrated, user-friendly system. It provides a secure, Wi-Fi–based interface to configure various game modes and player settings, executes a randomization algorithm to ensure fair dealing, and continuously monitors sensor data to guarantee accurate card distribution. Through its mobile app control, error detection, and optional over-the-air updates, the software delivers a robust, responsive, and maintainable platform for automated card dealing.

SRS 01 – Initialization and Configuration: The system shall initialize and configure the SAMW25 microcontroller, including setting up the Wi-Fi module and any necessary network configurations.

Completed. All system initialization and network setup functions worked as expected.

SRS 02 – Randomization and Shuffle Logic: The software shall implement a PRNG to randomize the sequence of card dealing, ensuring fairness.

Not completed. Due to limited heap space consumed by other FreeRTOS tasks, we chose to prioritize critical functionality and did not implement the shuffle logic.

SRS 03 – DC Motor Control for Card Output: The software shall determine the DC motor speed and duration based on the required number of cards per dealing cycle. It shall adjust motor operation in real-time, using sensor feedback to correct miscounts or jams.

Completed. DC motor control works smoothly and consistently, with accurate card output in each cycle.

SRS 04 – Stepper Motor Direction Control: The software shall rotate the stepper motor to direct the next card(s) to the selected player position (2–4 possible directions).

Completed. The stepper motor correctly adjusts direction to deliver cards to different players, working in coordination with the DC motor.

SRS 05 – Sensor Integration for Card Counting: The software shall continuously read the first Reflective Photo Interrupt Sensor to count cards as they are dealt, ensuring accuracy. A second sensor, placed within the card tray, shall monitor the deck supply, triggering low-deck or empty-deck alerts.

Not completed. As mentioned in HRS04, due to PCB fabrication issues, we were only able to connect one sensor — the BH1750 — and chose it over the reflective sensor for tray monitoring.

SRS 06 – Wi-Fi Connectivity and Remote Control: The software shall connect to a local network using the SAMW25’s Wi-Fi interface. The user shall be able to configure game parameters (e.g., player count, game mode, dealer position) through a mobile or web-based interface.