Non-RFID poker cards - full set

We've called these poker playing cards, but obviously they could be used for any card game.
One of the exciting ideas we came up with, was playing a game with an absent player - no longer does your regular poker night need to be disrupted because one or more players can't make it! Using these special playing cards, and a card-reading table, you can deal your friends in, and have them play over the 'net.

Anyway, that's way off in the future - we've yet to prove that the idea even works yet. But that'll be made much easier, now we've received this full deck of playing cards from Custom Stuff:

Can't wait to get making at BuildBrighton tonight, to see if we can actually read the cards using a few LDRs and a PIC microcontroller....

Non-RFID poker cards printed and cut

Here they are, in all their printed glory!
The only thing we may need to adjust is the spacing and size of the dots on the border(s). Only because at the minute, cutting is absolutely critical (we're going to put the cards into a fixed-size holder, and it's important that the dots on the cards line up with the holes in the reader). Slightly bigger dots, slightly further apart over smaller holes will at least allow for a bit of movement/printing/cutting error from one card to the next.

But other than that, the cards are really starting to look good. All we need to know now, is whether they work or not!

Non-RFID poker cards update

Just prior to printing and cutting our newly designed poker cards for our non-RFID poker table, Nick from Custom Stuff contacted us with another (better) idea.

The face cards were ready to print, but the black outlined circles got in the way, if we want to use traditional playing card faces (we weren't too fussed and were going to use our own images, but went with "standard" just to keep things simple). So Nick moved the dots off the face of the card and put them onto the border.

The end result is yet again better than our original idea!

(print preview - before printing and cutting - of our re-designed, re-design. Note how the dots are quite inconspicuous compared to earlier attempts!)

Nick suggested keeping the dots the same colour for the other suits - so instead of black and white dots on the hearts (red) diamonds (blue) and clubs (green) we use red/white, blue/white and green/white combinations. We must admit, these cards are looking like the best yet, so how to implement these changes?

Well, if we go down this route, the first thing to do will be to flash the RGB different colours, to work out what colour the border is. Once we know the colour of the border, we simply flash the RGB a complimentary colour to read the dots. Since the dots are white, we'd expect them to reflect all colours of light. But if we're flashing, say, a green LED onto a red card, the red dots on the red border would "appear" black (they would not reflect the LED light).

It's a little bit more complicated than our original idea - but not by much.
And the final result - the finished cards - look a hundred times better than our first efforts, so it'll be worth the extra effort!

Playing cards with binary dot values

By placing 5 LDRs in a line, and flashing a different coloured RGB LED onto the face of a card, we're hoping to read the numerical value and the suit of the card using our PIC microcontroller.

The numerical value of the card can be displayed as a 4-bit binary representation of the number. So, for example, an Ace has the numerical value 1, which is represented by 0001. Similarly, a five would be 0101 and so on. Whether we use a black dot or a white dot as a "one" in our binary representation doesn't really matter!

(yes the binary dots don't match the value on the card, and blue is traditionally associated with diamonds, not clubs, but this was just a quick mock-up provided to us to demonstrate a basic idea!)

We're going to use the colours:

• black = spades
• red = hearts
• green = clubs
• blue = diamonds

Here's a chart showing what we'd expect to see on each LDR and the card value we could deduce from it:

New poker card design

After spending hours last night updating and re-writing their printing routines, Nick from Custom Stuff emailed over some print previews of playing cards with coloured boxes in each corner, according to our latest ideas.
In short, some of them looked horrible.

With the correct photo, with the correct border, on the correct coloured background, sometimes it doesn't look ghastly (Queen of spades in the example photo) but mostly, the garish coloured blocks just distract from the images on the card and look awful (9 of spades).
Yes, we could make playing cards with "regular" card faces, pips and spades and diamonds and the like. But even then, each suit would have three picture cards with a jack, queen and king on them. So they'll still look terrible!

This morning, Nick showed us some left-over offcuts from a deck made overnight.
The customer had asked for a different coloured border around each of the cards, to signify which suit the card was (they were for teaching games to adults with learning difficulties). Apparently, thanks to the rise in internet poker and in particular, tiny graphics in mobile poker games, it's not uncommon for poker cards to use different colours for different suits - black = spades, red = hearts, blue = diamonds, green = clubs. This makes identifying your cards easier on a small-screen device (apparently).

My guess is that the programmers chose "primary" colours (let's not get into yellow being a primary colour and green a mixture of blue and yellow - we're dealing with lights, not pigments here!) to make each suit easily distinguishable from the others. Whatever the reasoning, this is quite fortuitous for us!

Having explained our card-reading idea, Nick suggested an alternative card layout:

The entire border of the card could be coloured to match the suit on the card (this was a quick mock-up, my guess is that clubs would probably be green, not blue). The numerical value of the card could be shown via a series of 4 black and white dots. Nick explained that these dots are much less conspicuous than large multi-coloured blocks, and we have to agree!

Of course, a 4-bit value gives us a range of values 0-15 (or 1-16 if you prefer).
Which is perfect: we can determine the suit of the card by detecting the colour of border, then read off the black/white dots to get the value. It does mean that we'll need 5 LDRs instead of four (the fifth will be under the border of the card, immediately to the outer edge of the dots) but the symmetrical layout of a playing card means we can just put all five in a line and the orientation of the card will make no difference.

We're quite excited by this new development.
The cards look great (we've yet to see a physical card, as Nick has a lot of work to do getting her programmer(s) to re-code their website for us!) and how it works should be quite simple.

By using black and white dots, our LDRs should be able to read a white dot value, irrespective of the colour being reflected off the face of the card - we can use this as a double-check; if we flash a red light and read back two white dots, we would expect the same response when we flash it blue and green.

Exciting stuff. We're already building prototype boards (using black tubes over the LDRs like we did with our invisible instrument last year) for reading the black/white dots, and we're pretty confident we'll have this working quite quickly. The only bit we haven't yet tried is the colour detection. More posts coming soon!

Non-RFID playing cards update

It didn't take long before we started getting emails about our last post, outlining colour combinations to identify each individual card in a deck of 52 playing cards.
The messages went something like "you've got lots of repeated patterns - that'll never work!"

And the people sending them were not wrong!
In fact, there were more than a couple of repeated patterns, including those for AS+2S, AH+3H, AC+6C. There are plenty more if you care to look for them. Instead, we've re-designed the entire card deck from scratch.

Here's our latest effort. There shouldn't be any duplicates this time. But if there are, don't hesitate to get in touch and let us know!

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!)

Here's a grid of 54 blocks of colour - each with a unique combination of RGB values, one for each playing card in a regular deck (52 cards + two jokers). We're hoping to use these with a colour sensor to build a device which can "read" playing cards placed in a special holder.

Creating unique colour combinations for playing card reader

Ok. With the numerous problems and repetitions in our previous attempt, we've turned to Excel to help us solve this conundrum. We need to be sure that every playing card has a unique combination of red, green and blue in the colour block (whether we settle for a single colour in the block, or stick with the 2x2 grid approach, we'll have to wait and see, once we know how sensitive our LDR is going to be).

Each colour will have an intensity of zero-to-three.
By writing out all possible permutations, we get 64 combinations (three colours, four intensities, 4^3=64)

Red	Green	Blue
0	0	0
0	0	1
0	0	2
0	0	3
0	1	0
0	1	1
0	1	2
0	1	3
0	2	0
0	2	1
0	2	2
0	2	3
0	3	0
0	3	1
0	3	2
0	3	3
1	0	0
1	0	1
1	0	2
1	0	3
1	1	0
1	1	1
1	1	2
1	1	3
1	2	0
1	2	1
1	2	2
1	2	3
1	3	0
1	3	1
1	3	2
1	3	3
2	0	0
2	0	1
2	0	2
2	0	3
2	1	0
2	1	1
2	1	2
2	1	3
2	2	0
2	2	1
2	2	2
2	2	3
2	3	0
2	3	1
2	3	2
2	3	3
3	0	0
3	0	1
3	0	2
3	0	3
3	1	0
3	1	1
3	1	2
3	1	3
3	2	0
3	2	1
3	2	2
3	2	3
3	3	0
3	3	1
3	3	2
3	3	3

We only need up to 52 colours, so we've decided to do away with the "darker" colours

(e.g. a block with the colour combination 0 1 0 would have one single green square and three black ones in a 2x2 grid). The easiest way to do this was to sum the totals of RGB and any block with a total of two or less was discarded (0-1-0 gets binned, 0-1-1 gets binned, but 0-0-3 can stay, as can 0-1-2 and so on)

This leaves us with 54 colour combinations:

Red	Green	Blue
0	0	3
0	1	2
0	1	3
0	2	1
0	2	2
0	2	3
0	3	0
0	3	1
0	3	2
0	3	3
1	0	2
1	0	3
1	1	1
1	1	2
1	1	3
1	2	0
1	2	1
1	2	2
1	2	3
1	3	0
1	3	1
1	3	2
1	3	3
2	0	1
2	0	2
2	0	3
2	1	0
2	1	1
2	1	2
2	1	3
2	2	0
2	2	1
2	2	2
2	2	3
2	3	0
2	3	1
2	3	2
2	3	3
3	0	0
3	0	1
3	0	2
3	0	3
3	1	0
3	1	1
3	1	2
3	1	3
3	2	0
3	2	1
3	2	2
3	2	3
3	3	0
3	3	1
3	3	2
3	3	3

Where the total sum of colours in a block exceeds three (1-2-3 for example represents 1R-2G-3B) we'll have to mix the colours to make secondary colours (magenta, cyan, yellow) and maybe even black and/or white. But hopefully, using these colour intensity charts as a guide, we'll come up with colour blocks that enable us to uniquely identify a card based on the RGB values received by the LDR/light sensor.

Seeing playing cards with an LDR and RGB LED

It didn't take long after posting about our intelligent poker table for the emails to come in pointing out a few mistakes on our colour-block image.

We'd tried to come up with at least 52 unique combinations of colour blocks, using only primary (red, green, blue) and secondary (magenta, cyan, yellow) colours. We thought we'd done a pretty good job until Matt from BuildBrighton pointed out -

Looking at the top-left block of colours, it's easy to see that we've two red, one green and one blue block. Let's write this as 2R-1G-1B.

Now on the top row, look at blocks three and five.
Block three has two red, one magenta and one green.
Magenta is made up of equal parts (1:1) red and blue.
So block three is 3R-1G-1B

Block five is made up of two red, one yellow and one blue.
Yellow (as most people who paid attention in physics class will tell you) is made up of red and green light (yes, when mixing paint, yellow+blue = green, but when mixing light, red+green = yellow. Just accept it!)
This makes block five also 2R + 1R+1G + 1B = 3R-1G-1B

So although we'd used unique combinations of colour pigments for our blocks, we've actually repeated intensities of light for a lot of the colour combinations. In fact, looking through the image, we can see we've actually repeated ourselves quite a few times!

Back to the drawing board....

Intelligent poker table without RFID

As a member of HackLlan (Llangollen's Hackspace) we're trying to get some ideas together for a show-and-tell session in November and to organise a robot kit for a weekend-workshop.
This means a few of our other projects have been sidelined, while we try to find projects that are both simple enough to explain in a few hours, but complex enough to keep people's interest for the whole day.

One project we're looking at is an intelligent poker table. You know the sort - players put their cards face down on the table and a graphic appears on-screen showing their "hole" cards. This was first seen in the UK on Channel 4's Late Night Poker, where the rather lo-tech solution was to put a camera behind a sheet of glass at every player's position.

This approach is still used in a lot of televised poker tournaments, and they are available on the 'net to buy, but you'd have to be a dedicated poker player to house a full-sized 10 seater table in your house!
A variation on this theme is to have cameras mounted in the "rail" of the poker table, which sneak a peak at each player's hand, as they bend their cards upwards to have a look at them.

For home-games, an alternative approach is becoming popular, but it still quite expensive - RFID playing cards. Each card in the deck has a tiny RFID tag, and each player has an RFID reader in front of them. As the cards as placed on the reader, the unique ID is read from each tag and the system knows which cards the player holds.
This is infinitely simpler than having up to ten webcams under a table, but RFID tags are expensive. Each tag costs 50p-�1 and a professionally made deck of cards costs �100 or more. You can make your own cards, by simply applying an RFID label to each playing card, but this increases the thickness of the deck significantly and the labels are still susceptible to breaking if players bend the cards too much.

We're after a much more low-tech (i.e. cheaper solution) that should be accessible to almost anyone.
One of the ideas we're investigating is a colour sensing circuit and a 2x2 grid of colour, unique to each card.

The idea is to have an RGB LED and a light sensor (either an LDR or something like a light-to-voltage sensor) under an opening onto which the card is placed. By flashing the LED red, then measuring the amount of reflected light, then green, then blue, should allow us to work out which combination of colours is showing.

At the minute it's all just a fancy idea - but hopefully this week we'll find time to put together a proof-of-concept prototype to see if it's feasible to continue.