Author Topic: RFID chessboard - "switchboard" similar to relay multiplexer and other questions  (Read 2977 times)

0 Members and 1 Guest are viewing this topic.

Offline RoraTopic starter

  • Newbie
  • Posts: 7
  • Country: ca
My idea is to use a single RFID reader connected to an 8x8 crosshatch of antennas. One lead of each antenna would be joined with all others in its row, the other lead with all others in its column. Each row and column would have a switching mechanism then join together to run to the terminals of the reader. This would allow antennas to be connected to the reader individually by activating one row and column at a time.

I need a way to toggle the rows and columns. I know a relay multiplexer could do this, but it's a bit oversized, most use physical contacts, and possibly a little slow for such purposes. I was wondering if there's a board or IC that can act as a set of programmable SPST switches.

I'm planning to use 125Khz RFID for very short range/to eliminate the chance of scanning an adjacent piece. I don't suspect the additional lead length (roughly 24" max) shared by "dead" antennas would affect the reactance so drastically that it can't read, but wanted to run this by those of you who know more about RF.

Since I only need one reader, I can afford one with high performance features. Does anyone have any suggestions? Being able to adjust the power level and tune antenna characteristics would be nice, ideally being able to take a reading with custom antenna values tweaked for each squares characteristics.

Any input or other ideas are much appreciated!
« Last Edit: January 23, 2019, 08:47:12 am by Rora »
 

Offline Domagoj T

  • Frequent Contributor
  • **
  • Posts: 505
  • Country: hr
Is there a reason you want to use RFID and not something simpler, like a reed switch or hall sensor?
Chess starting positions are known, and moves are done one by one, so a microcontroller can easily keep track.

Thinking more about it, hall sensors are better, since you can polarize magnets on the pieces so that white has north and black has south. That makes keeping track of pieces being captured a bit easier.
 

Offline RoraTopic starter

  • Newbie
  • Posts: 7
  • Country: ca
It's true you can do almost everything required with deductive logic, however there are several reasons that I'm doing it this way such as automatic piece promotion and illegal move detection.

The primary reason, though, is because this is actually for a robotic arm that plays against you. Per-piece identification ensures a consistent experience by validating whether pieces are where the programming expects them. The player can't set up the board wrong and the goal is that pieces cannot otherwise end up where they shouldn't be (illegal move detection), or for example the player promoting the computer's pieces with the wrong type (a queen is not always desired) and the arm grabbing said piece in the wrong place, etc.

It does complicate things a bit, but it also simplifies the code for getting the board state and detecting changes. For instance, as you say a means to detect black or white is still required with deductive logic, in the case where a piece moves/disappears off of a square and could have taken one of two different enemy pieces. Computer vision is also a solution people have used, although I think this is slightly more reliable. There's trade-offs with each solution, this one just offers the ability to do some fancier features down the road and this is a project I plan to be working on for many years.
« Last Edit: January 23, 2019, 10:35:29 am by Rora »
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 14117
  • Country: gb
    • Mike's Electric Stuff
For close-up reading like this, 125KHz RFID reading is trivially simple - you can do it with an opamp and simple data slicer, and decode in software. Antenna tuning is very noncritical.

The main issue you need to deal with is that the signal is bipolar, so you can't easily use diodes to isolate the matrix nodes as you can with buttons or LEDs, and that you need to avoid activating tags on adjacent squares.

If I was doing it I wouldn't bother with a matrix - I'd use a reader topology that grounds one end of the RFID coil ( so you only need to switch one end), and use a 1:64 analogue mux, with a bipolar +/- 5V supply. 5V should be enough to read button-sized 125KHz tags at a range this close, but you could up this to whatever your mux can handle - 4000 series could do +/-7.5v, I'm sure there are plenty that will do more. 

The circuitry would be something likei
One leg of RFID coil to common ground, with a parallel damping resistor. Other leg to the multiplexer.
Reader would be a 125khz TTL-level squarewave, fed via a tuning cap and series resistor, maybe back-to-back zener clamps, to the mux common. This node is also connected to  a diode detector, then to a limiting amplifier and adaptive data slicer - both functions could be done with a single LM358.

An issue you may have is the read time of a 125khz tag, which will probably take several seconds to read the whole board. Maybe split it into four 16-square sections that you can read simultaneously using either four small MCUs, or something a bit more powerful to handle all channels simultaneously.
 

 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 
The following users thanked this post: kony, Rora

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 14117
  • Country: gb
    • Mike's Electric Stuff
Just found a schematic of a reader I did many years ago - this has additional zeners as it was intrinsically safe, and also had some other functions, which can be ignored . This used an antenna about 50mm dia, to read credit-card sized card from about 75mm away.

Ignore U2 - the output of U2A is a 125KHz squarewave from a PWM or compare peripheral.
D6 provides limiting to avoid saturation issues with strong signals.

Your board would just be 64 coils, each connected to a mux input, and the mux output connected to the C1/D1 junction. It may be possible to avoid the need for a bipolar mux supply if you split the supply and connect the coil ground to +2.5V

If you can, use the larger ~20mm dia disc tags.
If you want to use PCB coils, you'll need to use less than the 1mH inductance, and increase the tuning cap to match, but tuning isn't too critical and you don't want a sharp resonance due to drift issues.   

Note that without clamping, the voltage across the coil can reach many tens of volts, so you may want a parallel damping R from the mux input to ground. 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 
The following users thanked this post: Rora

Offline RoraTopic starter

  • Newbie
  • Posts: 7
  • Country: ca
...

Thank you so much for the in-depth reply! It's going to take me a while to unpack everything you wrote.


something a bit more powerful to handle all channels simultaneously.

Total scan time is indeed a pitfall here, especially considering during the player's move it takes a scan cycle to detect a change from last board state, then another cycle to ensure the player is done moving, possible wait times to make sure scanner is not picking up pieces as the player moves them across the board, etc. Followed by chess algorithm crunch time.

Something capable of scanning everything would be ideal, but I have yet to find something capable of it. Any ideas where to look?
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 14117
  • Country: gb
    • Mike's Electric Stuff
...

Thank you so much for the in-depth reply! It's going to take me a while to unpack everything you wrote.


something a bit more powerful to handle all channels simultaneously.

Total scan time is indeed a pitfall here, especially considering during the player's move it takes a scan cycle to detect a change from last board state, then another cycle to ensure the player is done moving, possible wait times to make sure scanner is not picking up pieces as the player moves them across the board, etc. Followed by chess algorithm crunch time.

Something capable of scanning everything would be ideal, but I have yet to find something capable of it. Any ideas where to look?
you don't need to scan everything all the time, just scan all the pieces "fast enough"
there is scope for some optimisation here based on the current position - e.g. there will always be pieces that can't be moved, and squares that pieces can't be moved to, so you can not scan those ( or at least scan them less frequently).
Once a piece is lifted there is only a small number of possible places it can be put down legally.
 It is probably the case that unoccupied squares can be detected much more quickly than the full read time, and skipped.

Splitting into something like 8 or 16 zones doesn't add too much cost as the read hardware is cheap - some passives,  2 opamps ( you'd need multiple muxes anyway for 64 channels), and some CPU cycles so you need to work out what the read time is and how much latency you can tolerate.
There is probably scope to optimise the zoning to maximise the number of pieces per zone in typical play position - e.g. for 4 channels you don't want one one reading 16 peices when another reads none as this increases maximum time to read all pieces.
Maybe 8 channels, oriented along the direction of play.   

I don't recall offhand what the bit-rate is but I think in the low kbit range, so even a low-end ARM MCU ought to be able to decode quite a lot of streams at once.PSOC5 may be worth a look as you can probably implement lost of capture channels - with hardware capture, reading multiple channels would be very easy - you could probably also use the analogue  resources to eliminate the opamp/slicers, so all you'd need is a few analogue muxes and a few passives.

Btw there is a way to optimise read speed by up to 2x compared to the most more 'obvious' algorithm ( for simple tags that spit out an ID as soon as energised). When you energise a tag, it will start spitting data out in a repeating loop, and as it takes time for the tag's supply to stabilise etc., and teh tag may still be moving into the read field, you may start reading data somewhere in the middle of one cycle of the loop.

The "obvious way" to decode is to wait for the start, then read the code, however if instead you read the data bits continuously into a buffer, and attempt to decode starting from every possible position in the buffer whenever you get a new bit in, you get a read in the fastest possible time. I have some PIC code somewhere that does this for the very common EM4100(?) tags
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 
The following users thanked this post: Rora

Offline RoraTopic starter

  • Newbie
  • Posts: 7
  • Country: ca
Wow, /thread. Those are some brilliant ideas, pretty sure I have more than enough to make this happen. Thanks a ton, seriously!
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf