...
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