﻿ ﻿Experiment 32: Enhancing Ovid - Make: More Electronics (2014)

# Make: More Electronics (2014)

### Chapter 32. Experiment 32: Enhancing Ovid

You’ll remember from Experiment 23 that I wanted a better way to distinguish between one player’s token and the other player’s token when two people are playing Ovid’s Game. At that time, the best I could do was to suggest that each person should identify himself by pressing a button.

With sensors, this is no longer necessary.

Suppose one player uses magnetic tokens while the other player uses nonmagnetic tokens, all of which will fit into the same holes in the playing board. If each hole is equipped with a Hall-effect sensor (which will respond to the magnetic tokens but not to the others), and if each hole also has a transmissive IR sensor (which will respond to all of the tokens), we should be able to distinguish one type of token from the other type automatically.

This sounds like a logic problem to me, so my first step will be to express it in words.

The Logic Option

Here’s how it should work:

If the IR sensor is triggered, AND the Hall sensor is NOT triggered, we must have a nonmagnetic token in the hole.

If the IR sensor is triggered, AND the Hall sensor IS triggered, there’s a magnetic token in the hole.

This can be represented by the logic diagram in Figure 32-1. Note that the inverted triangle with the small circle at the bottom is an inverter, which changes a high input to a low input and a low input to a high input. I mentioned inverters in Make: Electronics but have not found a reason to use one in this book until now.

Figure 32-1. Two AND gates and an inverter can be used to activate the appropriate “Who wins?” logic network in Ovid’s Game, depending whether a magnetic token (from Player 1) or a nonmagnetic token (from Player 2) has been inserted in the playing board.

The output from the righthand AND gate would go to a logic network to detect if the player who is using the nonmagnetic tokens has placed three in a row to win the game. The output from the lefthand gate would go to a logic network to detect a win for the player who is using magnetic tokens. One of those logic networks is shown in Figure 23-4. Each switch in that figure would be replaced by ANDed sensors, as shown here.

One snag is that the sensors won’t be activated simultaneously. The Hall sensor is likely to switch on first, because it will be triggered when a magnetic token is still approaching the sensor.

However, I don’t think this will matter, because nothing will happen until there is an output from the optical sensor. This is required to activate either of the AND gates.

What concerns me more is that this sensor system is too complicated. The complete game has nine playing positions on the board. Implementing this logic will require five quad two-input AND chips and two hex inverters. That’s a lot of wiring. Is there some way to do it more simply?

Switching It Around

As usual, there is no methodical process that can help with optimization. It just requires some creative thought. The first step is to reconsider the roles of the sensors. Really, they perform different functions:

§ The optical switch says, “Is any type of token inserted?”

§ The Hall-effect sensor says, “Is it a magnetic token or a nonmagnetic token?”

This is really a two-stage operation. Step 1 has a yes-or-no output. That sounds like a logic gate. But step 2 has a “one thing or the other” output. That doesn’t sound so much like a logic gate. It sounds more like . . . a double-throw switch! So maybe a Hall-effect sensor isn’t really the best tool for the job. How about if I substitute a single-pole, double-throw reed switch?

I mentioned previously that double-throw reed switches do exist. I also said that reed switches create problems for logic gates, because their contacts bounce. Still, the contacts settle very quickly, and if the reed switch is activated first, as the player inserts the token, the contacts should have time to settle while the token slides into place and activates the optical switch. By the time the switch says, “I see a token,” the reed switch should be saying what type of token it is, without any hesitations.

Therefore the sensing circuit can be simplified to eliminate logic gates completely. The optical sensor provides an output that is high or low, while the reed switch routes it to the AND gates for Player A or Player B. This is shown in Figure 32-2.

Figure 32-2. Use of a SPDT reed switch instead of a Hall sensor can eliminate the logic gates that were necessary in the previous version of the token sensing circuit.

The only snag is that a switch will leave one circuit open, and logic gates must never have an open circuit connected to one of their inputs. Therefore we will have to add pulldown resistors. These resistors must have a relatively high value so that the signal from the optical sensor will be able to overwhelm them and change the input voltage.

In Figure 32-2, the pullup resistor for the optical switch will probably be around 2K. Each pulldown resistor for a logic network would be 10K.

This looks promising. But in Ovid’s Game, a player can remove a token to reposition it in another slot. Will we get switch bounce, once again, when the magnetic field is released?

Yes, but by the time the removal of the token allows the reed switch to flip back into its other position, the output from the optical switch will have changed from high to low. And internal hysteresis in the optical switch insures that it has a clean output.

Magnetic Issues

Another issue that has to be resolved, here, entails matching the magnet with the reed switch. The magnet has to be strong enough to operate the switch reliably, but not so strong that it affects adjacent switches. I’m thinking that the holes in the game board will have to be spaced at least an inch apart, and the reed switches must be located a safe distance underneath so that none of them will be activated if a player simply drops a token on the board.

The token could be like a peg with a magnet at the tip. Suppose you use little rectangular magnets, about 1/4” × 1/2” and 1/16” thick. You could cut a slot in the bottom of a wooden or plastic peg and glue the magnet into the slot.

We also have to be sure that the reed switch and the magnet are properly oriented. While a SPST reed switch isn’t very fussy about its placement relative to a magnetic field, the reed in a DPDT reed switch must be “pushed” or “pulled” from one contact to the other. I’m thinking that the game tokens must be shaped so that they won’t fit into a hole the wrong way around. They could be T-shaped in cross section, to fit T-shaped holes in the playing board.

This leads me to yet another possibility. If the peg was sufficiently wide, it could have a magnet mounted on one side, but not the other. Player 1 could have magnets on the left sides of the pegs, for instance, while Player 2 could have magnets on the right sides of the pegs. You could then get rid of the optical sensors and have two reed switches on opposite sides of each hole. One set of reed switches would be activated by the pegs used by Player 1, while the other set of reed switches would be activated by the pegs used by Player 2. Figure 32-3 shows how this could work.

Figure 32-3. Simplified rendering of a version of the game with one set of reed switches activated by magnets on Player 1’s tokens, and a second set for Player 2. To avoid simultaneously triggering two reed switches on opposite sides of a wooden divider, the divider should probably be thicker in a functional version of the game.

The advantage of this configuration is that you could just replace the manual pushbuttons in the original schematic for Ovid’s Game with SPST reed switches. Job done!

Careful testing would be required to make sure that the system would be reliable. This is the down side of using sensors: you have to deal with mechanical attributes of the real world.

Make Even More: Microcontrolling It

Ovid’s Game is difficult to adapt to a microcontroller, because there are nine positions on the playing board, and each of them can have three states: empty, occupied by Player 1, or occupied by Player 2. That represents a lot of inputs.

However, the number of inputs can be greatly reduced by matrix encoding—the same system that is often used to detect if someone has pressed a key on a key pad. In a three-by-three matrix, the microcontroller polls one row at a time while checking each column to see if there is a connection at the intersection. The basic idea is shown in Figure 32-4. Using this system, instead of requiring nine inputs, the microcontroller just uses three inputs and three outputs. Note that the diodes are necessary to prevent current from following incorrect pathways if multiple switches are closed.

Figure 32-4. The basic concept of matrix encoding.

In Ovid’s Game, if two sets of reed switches are used for the two players, matrix encoding can be modified as shown in Figure 32-5. The two sets of switches have been colored pale red and pale blue in this figure to indicate that one set will be operated by one player’s tokens, while the other set will be operated by the other player’s tokens.

Figure 32-5. Matrix encoding of Ovid’s Game where the two players activate separate sets of reed switches, colored pale red and pale blue.

Alternatively, could a phototransistor that uses visible light distinguish between two sets of player tokens, if one was matte black and the other was glossy white?

Or would a phototransistor be able to distinguish between two colors of tokens—say, red and green—if they were illuminated by different colors of LEDs? The color green appears bright in green light and dark in red light, while red appears bright in red light and dark in green light. You could use a comparator to determine if a green token or a red token was in the slot.

Probably you can think of other methods for token identification. The best will be the one that is reliable, cheap, easy to use, aesthetically pleasing, and reasonably easy to build. I’d love to see any ideas that you come up with.

But now that I have kept my promise to suggest some ways to improve the user input for Ovid’s Game, I want to move on to other types of sensors.

﻿