RFID chessboard - "switchboard" similar to relay multiplexer and other questions - Page 1
Forum section: electronics / projects

author: Rora
author_rank: Newbie
timestamp: January 23, 2019, 08:39:54 am
content: 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!

author: Domagoj T
author_rank: Frequent Contributor
timestamp: January 23, 2019, 09:11:13 am
content: 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.

author: Rora
author_rank: Newbie
timestamp: January 23, 2019, 10:31:45 am
content: 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 23, 2019, 10:41:58 am
content: 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 likeiOne 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 23, 2019, 10:54:22 am
content: 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.5VIf 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.

author: Rora
author_rank: Newbie
timestamp: January 23, 2019, 11:07:10 am
content: Quote from: mikeselectricstuff on January 23, 2019, 10:41:58 amThank you so much for the in-depth reply! It's going to take me a while to unpack everything you wrote.Quote from: mikeselectricstuff on January 23, 2019, 10:41:58 amTotal 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?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 23, 2019, 12:45:23 pm
content: Quote from: Rora on January 23, 2019, 11:07:10 amyou 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

author: Rora
author_rank: Newbie
timestamp: January 23, 2019, 03:19:52 pm
content: Wow, /thread. Those are some brilliant ideas, pretty sure I have more than enough to make this happen. Thanks a ton, seriously!