Poker table - without RFID

Here's an idea we had quite some time ago, while proposing ideas for the HackLlan show-and-tell session in November last year. It was for a poker table which could read cards without using expensive RFID hardware.

Well, at BuildBrighton we're talking about holding our first poker night - so it'd be really cool if we could broadcast it live - complete with overlay graphics, just like they use on the telly!
The original idea for identifying cards was to use "intensities of light" and non-primary colours to determine which grid pattern was showing over a single exposure. After a bit of trial and error, we found it difficult to tell when one, two or three squares of the same colour were showing in a pattern and the card detection device failed.

That's not to say we're giving up!
Nick at Custom Stuff has arranged to create some decks of customised playing cards, entirely to our own design rather than through their online editor, so we're now thinking about a different layout. The latest idea is this:

Each card will have "index" numbers in all four corners (this is an option you can set in the custom stuff online editor) BUT we're going to put each index into a different coloured square.
We'll have an LDR under each corner of the playing card (which sits on a black plate with holes cut in the corners, so only the colour in each corner is displayed from underneath) and then flash an RGB LED through red, green and blue.

By measuring the reflected light from each corner, we should be able to work out which colour is at which corner (and thus, which card is face down on the detector)

We've come up with this pattern sequence for our playing cards. The idea is to find which corner contains the black or white square (if black, the LDR under this corner will always return zero, if white, it should always return full brightness) and then read the colour pattern off the card.
If every card has only one black or white square, then we can convert a sequence of colours into a card value and it won't matter which way around the card is placed on the detecting plate.

The beauty of this design is that we don't have to work out intensities of colour - simply set a threshold value and if that value is met, we can detect the presence of a particular colour; it turns the result into a binary operation once more.

For example, let's say we've put the six of diamonds onto our detector (for the sake of example, let's assume it's the same way around as the blocks in the diagram above).
We flash the RGB red and read the values, clockwise, from each LDR at each corner of the card (the LDRs are inside black tubes, so are only reading reflected light, not direct or ambient light from the LDR).

The first LDR (top left) reads 190 which is above our threshold value of 100.
The second LDR (top right) reads 180 which is above our threshold value.
The third LDR (bottom right) reads 30 which is below our threshold value.
The fourth LDR (bottom left) reads 54 which is below our threshold value.

We need to allow for a little bit of leeway in our threshold, in case any ambient light creeps in, or if the blue, for example, is not an exact blue with absolutely no red pigment in the ink. This is where our "intensity" approach failed last time - the inks were not perfectly exact colours and the range for error was greater than our range for detecting colour. This time, we're simply saying "is this corner red, green or blue?"

Now let's flash the RGB blue and read the values again.

The first LDR (top left) reads 43 which is below our threshold value of 100.
The second LDR (top right) reads 176 which is above our threshold value.
The third LDR (bottom right) reads 156 which is above our threshold value.
The fourth LDR (bottom left) reads 78 which is below our threshold value.

Lastly, flash the RGB green and read the values once more:

The first LDR (top left) reads 57 which is below our threshold value of 100.
The second LDR (top right) reads 185 which is above our threshold value.
The third LDR (bottom right) reads 41 which is below our threshold value.
The fourth LDR (bottom left) reads 158 which is above our threshold value.


Now collating these results, we can see that the first LDR (top left) responded only to the red light. So let's say that is red. The second LDR (top right) responded to all colours, so that must be our white square (if it was black, it would be the only one to respond to none of the RGB flashes). The third LDR (bottom right) only responded when the RGB was flashed blue and the fourth (bottom left) only responded to green light.

So we have red, white, blue, green. In our look up table, this corresponds to only one card in the deck - the six of diamonds. To look up the card in our microcontroller, we'll probably cycle the colours until we either start with black or white - so our sequence would be white, blue, green, red. This means we don't have to store all possible permutations of each colour sequence to be able to perform an accurate look-up
(we don't want to try to look up red, white, blue, green and have no matches because the microcontroller is comparing against white, blue, green red!)