An RFID reader detecting a casino chip does not automatically mean that an entire smart table is ready for live operation.
Once installed inside a gaming table, RFID equipment operates alongside table materials, betting layouts, neighbouring antennas, dealer terminals, card-handling equipment and management software. Each part can affect whether chips are detected accurately and assigned to the correct betting position and game round.
Deployment testing should therefore evaluate the complete table under realistic operating conditions—not only a reader and several chips on a laboratory bench.
A practical acceptance test should answer four questions:
Can the table identify the chips it is expected to detect?
Can it assign each chip to the correct betting position?
Can it preserve accurate records when chips, devices or connections change?
Can staff identify and review incomplete or conflicting information?
RFID performance depends on more than the tag and reader.
The finished table may contain metal supports, decorative panels, cables, displays and other electronic equipment. Antenna position, reader power, chip construction, stack height and the distance between the antenna and betting surface can also influence detection.
Before testing begins, the project team should record:
Table model and game layout
RFID chip types and denominations
Reader and antenna models
Antenna locations
Reader settings
Software and firmware versions
Connected table equipment
Network configuration
Number and location of reading zones
Maximum intended chip-stack size
Testing should use the production table and the same equipment configuration planned for deployment. Results obtained from a different antenna position, table structure or reader setting may not represent the final installation.
ISO/IEC 18046 contains performance-testing methods for RFID devices, while the ISO/IEC 18047 series addresses conformance testing for RFID air-interface communications. These standards provide useful technical foundations, but a completed casino table still requires testing in its actual operating configuration.
The first test should confirm that individual chips can be identified in every intended betting position.
Each chip should be placed separately in the centre, edges and corners of the reading area. The table record should be checked to confirm:
The correct RFID identifier was detected
The correct denomination was returned
The correct betting position was assigned
The chip was connected to the correct table
The record appeared within the expected response time
Removing the chip updated the position correctly
Testing only one sample chip is insufficient. The test set should include several chips from each supported denomination and, where applicable, different production batches.
It should also contain chips with different operational states, such as active, inactive, promotional, suspended or unknown chips.
A readable RFID identifier does not automatically make a chip valid for play. The backend must determine whether that identifier is registered and permitted in the current operational context.
The electronic identities used by CTSOK RFID casino chips can be associated with denomination, category and operational status within a compatible management environment.
Casino wagers are not always formed from one chip placed neatly in the centre of a betting area. A position may contain several denominations, uneven stacks or multiple groups of chips.
Testing should reproduce combinations such as:
Several chips of the same denomination
Different denominations in one stack
Multiple stacks in one betting position
Aligned and uneven stacks
High-value and low-value chips together
A valid and restricted chip in the same group
Chips placed close to the edge of the reading area
The system should identify the individual chips and calculate the expected total without counting one identifier more than once.
If part of a stack cannot be read, the system should not silently present the remaining detected value as a complete physical wager. It should show that the record may be incomplete or generate an event requiring review.
Claims about maximum stack capacity should always be connected to a defined test configuration. A statement such as “reads 20 chips” has limited value unless it identifies the chip construction, antenna arrangement, stack position and completed table used during testing.
Testing only the centre of a betting position can hide weak areas near printed boundaries.
Each reading zone should be divided into repeatable test points:
Centre
Front and rear edges
Left and right edges
Corners
Printed betting boundaries
Areas closest to neighbouring antennas
The same chip samples should be placed at every point. The tester should record whether each chip was detected and whether it was assigned to the correct zone.
This creates a practical map of table coverage.
A chip placed within a valid physical betting position should not disappear from the record simply because it is near an edge. At the same time, a chip belonging to one position should not be accepted by a neighbouring position.
If either problem occurs, the operator may need to adjust the antenna layout, reader power, table materials or usable betting boundary.
Betting positions on baccarat, blackjack and other casino tables may be separated by only a short printed line. A chip placed near that line may enter the effective field of more than one antenna.
Boundary testing should determine:
Whether the same identifier appears in two positions
Which position receives ownership of the chip
What happens when the chip is placed directly on the boundary
Whether moving the chip changes its assigned position
Whether uncertain ownership creates a visible exception
Whether repeated detection incorrectly increases the wager total
Signal strength can assist zone assignment, but it should not be treated as the only source of truth. Chip orientation, stack height, nearby materials and movement may change the detected signal.
When the system cannot assign a chip confidently, marking the event for review is safer than silently placing it in an arbitrary betting position.
A static reading test does not represent normal table activity.
Players add, remove and move chips before betting closes. Dealers then need a defined wager record for the round. The table must distinguish legitimate movement from duplicate detection of the same chip.
The test should reproduce:
Adding a chip to an existing wager
Removing a chip before betting closes
Moving a chip between neighbouring positions
Sliding a stack across a zone boundary
Lifting a chip and returning it to the same position
Moving only part of a stack
Placing or removing a chip immediately before betting closes
Attempting to add a chip after betting closes
The tester should confirm which chips formed the accepted wager and whether that wager was connected to the correct round.
The betting-close event may originate from a dealer action, table-terminal command, countdown, card-handling event or another approved system rule. Whatever method is used, it must create a clear separation between changes accepted before betting closes and movements occurring afterward.
Late or uncertain movements should be rejected or identified for review according to the configured workflow.
RFID detection should not be accepted separately from the game workflow.
A complete test round should include:
Opening a new round
Placing and changing wagers
Closing betting
Recording the accepted wager
Receiving the card or game result
Calculating the expected settlement
Observing chip removal and payout activity
Closing the round
Reviewing the completed event history
The wager, result and settlement must remain associated with the same round.
A table might detect every chip correctly but still create unreliable records if a delayed event is attached to the previous or following round. Testing must therefore examine table state, timestamps, device messages and round identifiers together.
The CTSOK casino management system connects chip identification with table events, game information, settlement records and operational management. The specific workflow should be configured around the game type and the venue’s approved procedures.
A smart table may exchange information with several devices:
Dealer terminal
Electronic card shoe
Baccarat roadmap display
Local table controller
Backend server
Network equipment
Each device can work correctly by itself while the combined workflow still produces an error.
For example, an electronic card shoe may provide card-related events, but the management platform must still associate those events with the correct table and round.
Integration testing should check:
Device identity and table assignment
Event order
Timestamp consistency
Round identifiers
Missing or repeated messages
Result corrections
Display synchronization
Device-disconnection warnings
Backend reporting
The project documentation should define the authoritative source for important events. If a dealer terminal and another connected device provide conflicting results, staff need a controlled process for determining which record is accepted and how a correction is documented.
A successful connection during installation does not prove that the table will recover correctly from a communication failure.
The test team should disconnect selected components at controlled points during a round. It should then examine:
Whether staff receive a visible warning
Whether events are temporarily stored
Whether the table can continue operating
Whether delayed records retain their original timestamps
Whether stored events upload only once
Whether events return to the correct round
Whether incomplete data are marked for review
Whether recovery creates duplicate records
Restoring the network is only the first step. The system must reconcile records produced before, during and after the interruption.
Gaming Laboratories International’s GLI-13 standard covers monitoring and control systems and addresses areas including communications, significant events, audit information and reporting. GLI also makes clear that individual gaming jurisdictions establish their own requirements, even though many use GLI standards as a technical starting point.
Acceptance testing should not be limited to situations in which everything works correctly.
The table should also be tested with:
An unregistered RFID identifier
An inactive or suspended chip
An expired promotional chip
A chip assigned to another property
A visually similar non-RFID chip
A damaged or unreadable RFID chip
A duplicate identifier
A denomination that conflicts with the backend record
The system should distinguish between an unreadable chip and a readable chip that is not authorized for the current game.
These situations require different operational responses. An unreadable tag may require physical inspection, while an inactive or restricted chip may require verification of its lifecycle record.
An exception should include enough context for later review, such as the table, betting position, round, time, device and reason for the alert.
Automated alerts should support investigation. They should not automatically be described as proof of fraud or counterfeiting.
Testing should deliberately create events that require an authorized correction, such as an incorrect result, wrong chip status or wager assigned to the wrong position.
The test should verify:
Which user roles can request or approve a correction
Whether a reason must be entered
Whether the original value remains available
Whether the corrected value is clearly identified
Whether connected reports are updated
Whether the user and time are recorded
Whether settlement is recalculated when necessary
A correction should create a new accountable event rather than erase the original record.
This is also why user permissions must form part of acceptance testing. Dealers, supervisors, cage staff, surveillance reviewers, technicians and system administrators should not automatically receive the same access.
The final report should identify exactly what was tested and under which conditions.
A useful acceptance record may include:
Table and game identification
RFID chip models and test quantities
Antenna and reader configuration
Software and firmware versions
Connected equipment
Test cases and expected results
Actual results
Failed cases and unresolved issues
Corrective actions
Retest results
Supporting screenshots or logs
Test personnel and approval date
A passed result applies to the tested configuration. Moving an antenna, changing reader power, replacing table materials or installing a significant software update may require partial or complete retesting.
Factory testing, site acceptance testing, independent laboratory evaluation and regulatory approval are different processes.
A supplier can test whether equipment meets agreed project criteria. Site acceptance testing can confirm performance after installation. An independent laboratory may evaluate equipment against applicable standards. The relevant gaming authority determines which approvals are required in its jurisdiction.
GLI publishes different standards for monitoring systems, dealer-controlled electronic table games, electronic card shoes and other gaming technologies. The applicable document depends on the actual functions of the product or system.
Passing a project acceptance test should therefore not be described as automatic GLI certification or regulatory approval.
An RFID casino table should be tested as a complete operational system—not simply as a reader capable of detecting several chips.
A reliable test examines individual chip identification, stack performance, zone coverage, overlapping reads, chip movement, betting-close timing, game-round assignment, connected devices, network recovery, user permissions and exception records.
The most useful result is not the longest reading distance or largest possible chip stack. It is whether the table creates accurate, consistent and reviewable records under the conditions expected during real operation.
By defining acceptance criteria before deployment, testing the finished configuration and preserving the results, operators can identify integration problems before the table enters live service.
No. Individual-chip testing is only the first step. The completed table should also be tested for chip stacks, betting-zone boundaries, movement, game integration, device communication and recovery from failures.
No. Criteria depend on the game, table construction, antenna arrangement, chip design, operating workflow and jurisdictional requirements.
Not by itself. A system may detect a chip but assign it to the wrong betting position or game round. Zone accuracy and event context are as important as detection.
The event should follow the venue’s approved exception process. The system should avoid silently accepting incomplete or uncertain information as a valid wager.
No. Site testing verifies the installed system against agreed criteria. Regulatory approval and independent laboratory certification are separate processes determined by the relevant jurisdiction.
Technical references consulted for this article: ISO RFID performance and conformance standards, Gaming Laboratories International Standards, GLI-13 Monitoring and Control Systems, and GLI-25 Dealer Controlled Electronic Table Games. Requirements vary according to system functions, internal controls and jurisdiction. Reference to these materials does not imply certification, endorsement or regulatory approval of any CTSOK product.
Interested in our products? Click the button below to book a demo or get more information
