Experimenting with a DIY RFID Table and Broadcast Overlay (3 Viewers)

Guts in:

9.jpg

10.jpg

11.jpg




I did about 15 minutes of testing this morning and there are some clear initial issues that need to be handled in software:

1. Leaving the cards sitting on top of the readers is fine when using just a few positions, but 3+ handed and something gets overwhelmed with all the data being passed (I'm guessing it's the reader trying to keep up with the HTTP posts). I'll need to figure out the best strategy for muting positions after their cards have been read and then reenabling. This is trickier than it sounds (essentially keeping the state of the hand reliably in software - side note: this leads to something else I think I might need to add - an admin page that will let the dealer manually reset/clear hands etc. when something goes wrong)

2. A timeout period after a hand has been identified as over so that any cards left sitting on readers aren't immediately scanned and counted as a new hand. Should be easy enough, add in like a 15-20 second shuffle period during which input from the reader is ignored or similar. Also tricky to fully reliably automate, but doable I think.

I'm hoping to do a split-screen video at some point this weekend of me dealing on the board and simultaneously what happens on the overlay.
 
Burn cards don't need to be read.

Theoretically, burn cards are just cards that are never put into play. They are not something that anyone should have seen, so getting that info is something that is not used when calculating odds.
 
Looks awesome!

What's causing the interference? Low power?
Part of the inconsistent picking up of cards I think comes from me not having any markings to help in card placement. Sometimes I was simply off the mark by a bit.

Some of it is likely from me using small RFID stickers on the cards. Smaller antennas mean reduced read range. Actual RFID cards I believe use larger antennas internally and I hope will aid and read consistency.

Since the idea seems to work, I went ahead and ordered a deck of RFID cards from China. We'll see what difference that makes.

Some other thoughts here but on mobile so I'll get to that later.

Overall, I'm super encouraged that it performed as well as it did for basically a first test. Stuff to fix/tweak/adjust? Yes. But very promising results!
 
That looks very promising. Yeah, markings on the felt for where to place the cards would help a lot. For your temporary build, you could just mark the locations with a sharpie.

Having an "admin" feature would be great, so that if you have a producer on site, they could even add chip stacks and bet amounts.
 
Some good progress on the coding front - after the so-so performance of the Pepper C1's REST functionality for sending scanned tags to the app I decided to give their WebSocket server a shot.

Using the Pepper C1 socket server functionality is not ideal because it doesn't support SSL and it can only act as a server and not as a client. This means we have to open port 80 inbound so the app can connect back to the Pepper C1/mini table. Thinking long-term, this will be tricky for normal users with having to open firewall ports and possibly having set up dynamic DNS, then configuring the app to connect back to the right IP address, etc. The folks at Eccel (who make the Pepper C1) said they'd consider adding WebSocket client capabilities in a future release but who knows. This all just adds additional motivation to create our own RFID reader board.

Anyway, performance using sockets is WAY better. In limited testing, scans seemed to be getting missed far less often, I can leave cards sitting on top of antennas without it impacting the ability of other antennas/cards to be picked up, and things are just functioning over all way more smoothly.

I also tweaked how I'm using the odds calculator to make the calculation process run asynchronously using a web worker so it not longer locks up the UI while it's calculating odds (see previous videos, there's always a short hang when a player's second card is scanned). Now, as cards are scanned, the UI continues to update seamlessly while the odds calculations happen in the background and are displayed in the UI once they're done.

I'm hoping to do a new video soon showing how well the board is currently working.

I started work on an admin page where (so far) you can scan in a new deck of RFID cards (one at a time, saving the UID tag to card mapping) or import a deck in bulk from a properly formatted JSON object. Other features I have tagged so far for the admin page are setting player names, adding player pictures, hand admin stuff (clearing cards/resetting hands, etc - for when something goes wrong). This part is still very rough and nebulous in my head so if anyone has input or feedback I'm all ears.

Found and fixed a number of bugs and implemented that "shuffle" delay that I'd mentioned in a previous post - seems to be working well.

I ordered a deck of RFID cards from China and they should be here around mid-June. Looking forward to testing those because my test deck with RFID sticker tags is about twice the thickness of a normal deck, lol. It's a pain in the ass to handle and shuffle.


On the hardware side, I've been doing a bunch of research and picked up some of the stuff I need to prototype a board including the IC I'm hoping to use and a breakout board for it, reflow'd:

17.jpg


18.jpg


Not pretty but it checks out:





19.jpg




Next step is to get it wired up to an esp32 and make sure it works. Then get an antenna hooked up to it and try to read a tag. If that goes well, try to figure out how to multiplex more than one antenna (have some ideas). This part is going to be slow going. Lots to learn.


edit:

timelapse

 
Last edited:
Some good progress on the coding front - after the so-so performance of the Pepper C1's REST functionality for sending scanned tags to the app I decided to give their WebSocket server a shot.

Using the Pepper C1 socket server functionality is not ideal because it doesn't support SSL and it can only act as a server and not as a client. This means we have to open port 80 inbound so the app can connect back to the Pepper C1/mini table. Thinking long-term, this will be tricky for normal users with having to open firewall ports and possibly having set up dynamic DNS, then configuring the app to connect back to the right IP address, etc. The folks at Eccel (who make the Pepper C1) said they'd consider adding WebSocket client capabilities in a future release but who knows. This all just adds additional motivation to create our own RFID reader board.

Anyway, performance using sockets is WAY better. In limited testing, scans seemed to be getting missed far less often, I can leave cards sitting on top of antennas without it impacting the ability of other antennas/cards to be picked up, and things are just functioning over all way more smoothly.

I also tweaked how I'm using the odds calculator to make the calculation process run asynchronously using a web worker so it not longer locks up the UI while it's calculating odds (see previous videos, there's always a short hang when a player's second card is scanned). Now, as cards are scanned, the UI continues to update seamlessly while the odds calculations happen in the background and are displayed in the UI once they're done.

I'm hoping to do a new video soon showing how well the board is currently working.

I started work on an admin page where (so far) you can scan in a new deck of RFID cards (one at a time, saving the UID tag to card mapping) or import a deck in bulk from a properly formatted JSON object. Other features I have tagged so far for the admin page are setting player names, adding player pictures, hand admin stuff (clearing cards/resetting hands, etc - for when something goes wrong). This part is still very rough and nebulous in my head so if anyone has input or feedback I'm all ears.

Found and fixed a number of bugs and implemented that "shuffle" delay that I'd mentioned in a previous post - seems to be working well.

I ordered a deck of RFID cards from China and they should be here around mid-June. Looking forward to testing those because my test deck with RFID sticker tags is about twice the thickness of a normal deck, lol. It's a pain in the ass to handle and shuffle.


On the hardware side, I've been doing a bunch of research and picked up some of the stuff I need to prototype a board including the IC I'm hoping to use and a breakout board for it, reflow'd:

View attachment 904874

View attachment 904875

Not pretty but it checks out:





View attachment 904876



Next step is to get it wired up to an esp32 and make sure it works. Then get an antenna hooked up to it and try to read a tag. If that goes well, try to figure out how to multiplex more than one antenna (have some ideas). This part is going to be slow going. Lots to learn.


edit:

timelapse

This sets a new record for the post with the most words that I don't comprehend.

That includes @Coyote's posts... in Greek.
 
Some good progress on the coding front - after the so-so performance of the Pepper C1's REST functionality for sending scanned tags to the app I decided to give their WebSocket server a shot.

Using the Pepper C1 socket server functionality is not ideal because it doesn't support SSL and it can only act as a server and not as a client. This means we have to open port 80 inbound so the app can connect back to the Pepper C1/mini table. Thinking long-term, this will be tricky for normal users with having to open firewall ports and possibly having set up dynamic DNS, then configuring the app to connect back to the right IP address, etc. The folks at Eccel (who make the Pepper C1) said they'd consider adding WebSocket client capabilities in a future release but who knows. This all just adds additional motivation to create our own RFID reader board.

Anyway, performance using sockets is WAY better. In limited testing, scans seemed to be getting missed far less often, I can leave cards sitting on top of antennas without it impacting the ability of other antennas/cards to be picked up, and things are just functioning over all way more smoothly.

I also tweaked how I'm using the odds calculator to make the calculation process run asynchronously using a web worker so it not longer locks up the UI while it's calculating odds (see previous videos, there's always a short hang when a player's second card is scanned). Now, as cards are scanned, the UI continues to update seamlessly while the odds calculations happen in the background and are displayed in the UI once they're done.

I'm hoping to do a new video soon showing how well the board is currently working.

I started work on an admin page where (so far) you can scan in a new deck of RFID cards (one at a time, saving the UID tag to card mapping) or import a deck in bulk from a properly formatted JSON object. Other features I have tagged so far for the admin page are setting player names, adding player pictures, hand admin stuff (clearing cards/resetting hands, etc - for when something goes wrong). This part is still very rough and nebulous in my head so if anyone has input or feedback I'm all ears.

Found and fixed a number of bugs and implemented that "shuffle" delay that I'd mentioned in a previous post - seems to be working well.

I ordered a deck of RFID cards from China and they should be here around mid-June. Looking forward to testing those because my test deck with RFID sticker tags is about twice the thickness of a normal deck, lol. It's a pain in the ass to handle and shuffle.


On the hardware side, I've been doing a bunch of research and picked up some of the stuff I need to prototype a board including the IC I'm hoping to use and a breakout board for it, reflow'd:

View attachment 904874

View attachment 904875

Not pretty but it checks out:





View attachment 904876



Next step is to get it wired up to an esp32 and make sure it works. Then get an antenna hooked up to it and try to read a tag. If that goes well, try to figure out how to multiplex more than one antenna (have some ideas). This part is going to be slow going. Lots to learn.


edit:

timelapse

Please make this a package that our table builders can buy from you and install turnkey.
 
Please make this a package that our table builders can buy from you and install turnkey.
I have no idea where we'd be at legally. I'm 100% sure there are patents.

My goal is to make everything I create open source. There is the possibility that I'd offer assembled boards if I I'm able to end up successfully designing one. I also thought about a turn-key web portal folks can use for the software side so they can just point their table to it and pull the source into their broadcast software and they're off.

Worst case, hopefully there's enough information/a tutorial at the end of this where anyone can have the board and antennas made (by a fab+assembly house), install it in a table, install and configure the software (or use the portal), and be off and running.

I don't really care about making money, but I do want it to be easy for the community to use if possible. I think that'd be awesome.
 
Updated video. Not perfect yet, but much improved performance:


edit: also just noticed a bug where mucked cards (from player hands) aren't being marked as dead and so the odds are a little off - hand at 1:02, when the :jh::3c: folds, odds should be:

:8d::5c: - 25% (23% in vid)
:ah::7s: - 41% (39% in vid)
:jc::9h: - 34% (38% in vid)
 
Last edited:
I think I picked the wrong time to design a circuit board. The chip shortage is no joke. Seems like every component I pick is out of stock with a 1+ year lead time, lol.

Anyway, informal poll - for the rfid reader board power, Micro USB or USB-C?

I'm leaning USB-C, more modern, plus no wrong direction. Even though I've got a 50/50 shot to orient Micro USB correctly, somehow I'm wrong 100% of the time.
 
I keep thinking about how this could work with a rotating dealer, and the only thing that makes sense to me would be an RFID dealer button that could register it's position at a specific hand location. The problem still comes down to showing the community cards in a specific location. Is it possible for an RFID device to be a repeater? Maybe something battery powered that has it's own unique ID and can also read and transmit other IDs?

I guess if you wanted to get fancy like that, you might as well combine image recognition for the face-up cards...

Also, card durability. How long are the antennae in the cards expected to last with repeated flexing?
 
I keep thinking about how this could work with a rotating dealer, and the only thing that makes sense to me would be an RFID dealer button that could register it's position at a specific hand location. The problem still comes down to showing the community cards in a specific location. Is it possible for an RFID device to be a repeater? Maybe something battery powered that has it's own unique ID and can also read and transmit other IDs?

I guess if you wanted to get fancy like that, you might as well combine image recognition for the face-up cards...

Also, card durability. How long are the antennae in the cards expected to last with repeated flexing?
58” round with a lazy Susan spinner underneath an subsection of felt and a fixed rail & outer felt area.

Keep your chips, spin the felt.
 
Each seat has hole card antennas plus an antenna zone for either stud or community cards. We flag to the software what game we're playing through a web interface or even something physical on the table (game tokens over another rfid antenna?), or the software is smart enough to figure out the game based on the structure (only one player had board cards but everyone has 4 down? Ok, Omaha)

Or fuck it, the table tells us what game to play next
 
58” round with a lazy Susan spinner underneath an subsection of felt and a fixed rail & outer felt area.

Keep your chips, spin the felt.
You know, I realize this is in jest, but the design idea has some merit. The flop and muck antennae are mounted on a motor-operated lazy Susan underneath, and the system can rotate it based on dealer position. Now were talking some serious scope creep!
 
You know, I realize this is in jest, but the design idea has some merit. The flop and muck antennae are mounted on a motor-operated lazy Susan underneath, and the system can rotate it based on dealer position. Now were talking some serious scope creep!
It was designed to get some creative ideas flowing, like yours! I like your idea a lot- rotate the sensors. You could add some sort of indicator to show the position and alignment. (Assumes the signal works at that distance.)
 
Progress on the rfid reader board. Few more weeks of design/tweaking (biggest hurdle remaining is antenna connection and design) and we should be ready for some peer review to see how badly I screwed up/what we missed.

rfid.png


edit: this will be an initial non-multiplexing version (supports one antenna). baby steps to work out the kinks with a single antenna first, then we'll approach figuring out multiplexing
 
Last edited:
Great work so far @eightyWon! I Love that I stumbled onto this thread and I'm really looking forward to the progress. I played around with RFID for some work projects about 10 years ago and then personally for poker a few years ago. Looks like there are a lot of additional options today and availability for cards. I would definitely be interested in assisting and this checks a lot of personal interest boxes.
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account and join our community. It's easy!

Log in

Already have an account? Log in here.

Back
Top Bottom