RFID-system for detecting score

[leheim]

Hi guys!

We are a group of electrical engineering students (2nd year) working on a project where the goal is to design and implement something useful for the curling sport. We’ve come up with an idea that is about detecting the score of a game, based on the analog scoreboard that most curling arenas have. The detected score is to be broadcasted to a webpage. We want to keep things cheap and simple for the curling clubs, that’s why we plan on modifying the scoreboard they already have installed. The scoreboard consist of two rows, one for each team, with multiple slots where cards according to the score are placed. Check out the attached image for an illustration of the ideo. In order to detect the card, we are thinking of placing RFID-tags on the backside of each card, and a reader/antenna in each slot. The range must not be shorter than 1 cm, and preferable not exceed 8 cm in order to avoid “double detection”.
We are not too familiar with all the different RFID components available, therefore we would be really grateful for some advise regarding which components that are suitable. Maybe you also could come up with a simpler solution to the problem.

Thanks in advance.

[Ian.M]

Why not use a four bit binary code on each card?  That would give you 15 distinct card codes + no card present.

The cheapest minimally intrusive arrangement would be up to four small neodymium magnets epoxied to the back of each card, well spaced out, and preferably in milled or drilled recesses so they don't get knocked off, with either hall sensors, or if the scoreboard is thin enough or can have recesses routed in the back of it, reed switches.  If you are using reed switches, and incorporate a diode in series with each, you can simply wire the scoreboard as a 5x8 key matrix.   nd robust connectors so it can survive minimally qualified maintenance techs.

Other options would be pulsed retroreflective IR sensors looking through small holes in the scoreboard, with matte black paint to the back of the cards and squares of aluminum tape where you want the other bit state, or if drilling the scoreboard isn't an option, non-ferrous metal proximity sensors, again with aluminum tape on the cards for one of the bit states.

The only fly in the ointment for the reed switch matrix is it would make the whole project too simple - just use off-the-shelf security reed switch sensors screwed to the back of the scoreboard, using a spare terminal to fit the diode inside each, and wire the matrix to an ESP32 board or an Arduino + Ethernet shield depending on the desired connectivity, and one competent programmer could knock up the code to post to the server over a long weekend! OTOH if you've got a good hardware designer, embedded programmer and web programmer on your team you could still get enough project work out of it by designing a custom PCB, and having it manufactured and assembled e.g. by JLCPCB so it doesn't look 'arduinoish', and also to allow you to add proper input protection, and robust connectors.

The other sensor options would benefit from a sensor board for each digit so you don't have to wire up the sensors individually.   Maybe give each sensor board local intelligence and use MODBUS to connect them back to the main controller board to permit simple 'daisy-chain'

Another option that may not get you much credit unless your course is heavily computer science oriented, would be a Raspberry Pi or similar with its camera module, + custom optics to get a decent full frame image of the score board, and run image recognition  to 'OCR' the score board on the Pi, and also the webserver for it.  OTOH it would be the cheapest/easiest for rinks to actually install - mount and cable one box where it can see the scoreboard, manually adjust aim, zoom and focus, then train it to OCR the existing cards.

[leheim]

Thank you for the detailed suggestions!

We really liked the idea with the reed switches. Our plan now is to implement something similar to what is shown in the attached image. A decoder and a multiplexer is used in order to reduce the number of I/O-pins needed. Also, a display with a UI will be implemented, so that the user will be able to override/start/stop etc.

[Ian.M]

I note you've reduced the scoreboard to eight columns. The multiplexer only saves you one pin.  IMHO not worth it.   Use 2x 74HC138 wired as a 4:16 demux to scan the matrix and read the four inputs for each card directly on I/O pins.

However you want a full UI and WiFi, which is likely to be a PITA on an AVR as limited in pins and memory as an ATmega328P.   You could use shift registers as port expanders for both the edges of the matrix, with one or two 74HC595 on the driven side, and a 74HC165 on the input side, for a SPI-like interface to the Arduino to work around that.  N.B. the 74HC165 doesn't have a tristateable output so if you want it to coexist with other SPI devices (e.g. a touchscreen display), you need a single gate tristatable buffer controlled by a /SS line between its data out and MISO.  I wouldn't do it that way unless I was trying to omit the AVR and run the whole thing on an Espressif WiFi module, as simply using an Arduino Mega2560, or possibly an ATmega1284P if you are designing your own board, to get enough I/O pins without the use of port expanders considerably simplifies the design, with at most a small cost penalty.

N.B. doing reasonably future-proof and properly secured IoT stuff over WiFi on a small embedded system is *HARD*.   Its simple enough to get something working fairly quickly, but making sure you haven't inadvertently created a vulnerability and maintaining security and network access capability for the life of the product is far from simple and involves a long-term support commitment you may not be in a position to make.  OTOH if you use wired Ethernet, security is somewhat less critical as an attacker would require physical access to the network.   If WiFi is an essential requirement, consider using an off-the-shelf WiFi access point to translate Ethernet to WiFi which can be replaced/upgraded as required to maintain security and handle future advances in WiFi standards, even if your device's firmware is no longer being maintained.   e.g Its quite practical to connect 30 year old hardware to a WiFi LAN without significant security problems as long as it 'talks' TCP/IP or UDP over 10baseT or better Ethernet.  Are you still going to be in a position to support your project decades later if it gets taken up by more than just your uni's rink?