Q&A Game Project with MEGA 2560 and Key Fobs
A key fob is a common device we use in our daily life. This project is dedicated to building Quiz Game by utilizing Arduino MEGA 2560 and Key Fobs that can give you a great experience.
Many of you have a key fob on your key chain. The fob originally was an attachment to a pocket watch, so it could be removed easily from a pocket. A pair of pants often had a special small pocket especially for pocket watches. The fob may have been tethered to a belt or belt loop, to prevent it from being inadvertently left somewhere and lost.
Today’s fobs can unlock your car, open your garage door, or even unlock your front door. Many include built-in authentication, providing more security for your personal devices. Attachment to your key ring or simply placed in your pocket ensured it was easily accessible when needed. How many of you have set off your car alarm by “butt dialing” the panic button on your fob?
While searching for an item on the Internet, I came across several key fob/relay combinations that were meant for adding some level of automation to your car, home, or another project. These usually come with one or two fobs and a receiver capable of controlling one or more devices through onboard relays. One product that popped up was a receiver with five fobs (Figure 1) for about $34. Each fob had four buttons and a receiver with four relays, I thought this might be useful for some projects. I knew that I could buy a 433MHz transmitter and receiver pair for just a few bucks. However, the packaging was usually a major stumbling block to many projects, unless you had a 3D printer and plenty of time to design some custom plastics.
This four-channel AC DC12V 24V 433MHz remote relay module wireless RF switch, five transmitters, and one receiver were found on Amazon for about $34. It was the only unit I found that had five transmitters. If you already have a 433MHz receiver, a search for “Remote Control Key Fob” will find you four similar transmitters for about $16.
DELIVERY ISSUES
We’ve all experienced the “pandemic” effect on the supply chain, which previously had been pretty darn speedy, even from across the pond. Well, now the “non War” seems to be adding to this issue, even though the back-up in our ports has been eased. I am continually amazed at Amazon’s ability to deliver a wide variety of products from its warehouses in a timely fashion. What I can’t understand is how China can ship and deliver goods within weeks at a delivery cost that is often cheaper than I can send a letter.
At the time I ordered it, this product was in stock and I received it in two days. I was excited to open up the package and play around a bit with it. Each of the buttons on any key fob could be used to turn ON, OFF, or alternately toggle one of four relays. This was pretty much what I had expected. But I had a completely different use for this product in mind. I would need to dig a little deeper into just what I had.
I wanted to figure out what a fob was sending as a transmission. To do this I would need to tap into the output of the receiver. I pulled out the oscilloscope and looked at the output of the RF receiver that was populated on the receiver/relay PCB. Without any RF transmissions, this output looked as though it was toggling at some random rate. It seemed as if this was a result of a receiver with a high-gain front end. Any noise it sees triggers the input.
— ADVERTISMENT—
—Advertise Here—
These transmitters came nicely packaged as key fobs with A, B, C, and D buttons. You can get bare transmitter/receiver pairs for less than $5, but the packaging is always an issue. The packaged transmitters and a receiver fit my purposes perfectly. When I captured a key press by looking at the output of the receiver with my oscilloscope, it was clear that the protocol was simple—3 bytes. For any key fob I looked at, it was only the last 4 bits that changed; the first 5 nibbles seemed to stay constant. When I changed fobs, I saw a new value for the first 5 bytes; again the last 4 bits were consistent with the same button presses.
I hate to admit this, but it wasn’t until after I looked at the transmissions on the receiver with an oscilloscope that I actually attacked a fob transmitter with a screwdriver. I usually open a new device up as soon as I receive it… something about appreciating the artistry that you find hidden inside. Figure 2 shows what I found inside a fob. Note that it is powered by a 12V battery that is smaller than an AAA cell. These are noted as MN21 or A23, and cost about $1 apiece. Many circuits made overseas have all their nomenclature removed from the ICs. I guess they are paranoid about having someone copy their designs. This particular one did not. It is identified as an EV1527 OTP encoder from Silvan Chip in China—essentially, a 4-pin micro programmed (in this case) for a specific purpose. Figure 3 shows the data format from their datasheet. It aligns with what I saw on the oscilloscope.
When I took apart a transmitter, I found it used an EV1527 chip from Silvan Chip. This crystal-controlled RF transmitter uses ON-OFF Keying, a simple form of amplitude modulating the RF carrier. Note the small black plastic shield below the buttons. This slides up to cover the buttons so they can’t be activated inadvertently.
![Figure 3
Data format from the EV1527 datasheet [1]. It shows a high pulse followed by a long low time, forming a sync bit of around 350µs. This will be followed by 24 data bits, where each bit has either a 33µs/11µs high/low time (1) or an 11µs/33µs high/low time (0).](https://i0.wp.com/circuitcellar.com/wp-content/uploads/2022/12/2022-08-385-Bachioch-Fig3.jpg?ssl=1)
Data format from the EV1527 datasheet [1]. It shows a high pulse followed by a long low time, forming a sync bit of around 350µs. This will be followed by 24 data bits, where each bit has either a 33µs/11µs high/low time (1) or an 11µs/33µs high/low time (0).
When I searched for a compatible decoder on Silvan’s website I could not find one. Perhaps that’s why the 4-pin decoder on the receiver PCB didn’t have any markings. The receiver requires 12V to 24V AC or DC, and reduces this to a regulated 5V to run the circuitry. A 433MHz receiver module is soldered onto the PCB. The receiver output goes into a 4-pin unidentified device, which I suspect is a micro. Four outputs from this device feed a ULN2003 driver chip, which controls four, 10A relays. The receiver allows any of the fobs to control any of the relays. Each relay could operate separate devices, such as a garage door, lights, or an alarm. There are some test points that suggest a way to reprogram the chip; however, I decided to remove the RF receiver and put a 4-pin socket in its stead, so I can use the RF receiver elsewhere, but put it back if I wish at some future time.
ARDUINO
I have found no easier way to prototype an idea than to (at least) begin with an Arduino. I began with an UNO, but found that I quickly ran out of data space, for reasons you will see once we get into the project a little more. I then turned to the MEGA 2560, which has 8x the flash, 4x the SRAM, 4x the EEPROM, and a ton more I/O. Since I began with the UNO, I had used an UNO-sized protoboard; however, the MEGA has an extended length for all its extra I/O. Its SPI is brought out on different pins that are past the protoboard, so this was an issue. Fortunately, the MEGA also passes this SPI through the 6-pin programming connector that is under the protoboard, so a minimum amount of rewiring was needed.
The protoboard contains four pushbuttons, four LEDs, an SD card interface, and the 4-pin RF receiver interface. This schematic is shown in Figure 4 and the MEGA/prototype stack in Figure 5. I wasn’t sure if the pushbuttons and LEDs would be needed, but it’s always good to have some I/O to aid in debugging. The first thing I needed was a way to gather the RF data.
Schematic of the protoboard that fits atop an Arduino processor board. I started with a UNO, but ran out of data space once I started reading in files from the SD card. I moved to the MEGA 2650, which has lots more memory and I/O, but it also has a longer length to accommodate the added I/O.
The short prototype board holds the RF receiver and the micro SD card interface. I had room to fit four pushbuttons and four LEDs. One switch allows the fobs to be identified, and the LEDs were used in debugging to indicate when players 1-4 selected an answer by pressing a button on their fob.
I found a library that could be used both to identify and send/receive RF codes from 315/433MHz devices. I installed the RCSwitch library and ran the ReceiveDemo_Simple.ino program. As long as I pushed a button on a fob, the application repeated a message:
Received 4509796 / 24bit Protocol: 1
This indicated that the library was able to receive 24 bits with a value of 4509796 using protocol 1. I found the protocols somewhat defined in the library file RCSwitch.cpp.
{ 350, { 1, 31 }, { 1, 3 }, { 3, 1 }, false },
// protocol 1
where…
350 = sync(microseconds)
1, 31 = a sync bit (high of 1 pulselength and a low of 31 pulselengths)
1, 31 = a ‘0’ bit (high of 1 pulselength and a low of 3 pulselengths)
31, 1 = a ‘1’ bit (high of 3 pulselengths and a low of 1 pulselength)
false = not an inverted signal
— ADVERTISMENT—
—Advertise Here—
If you refer back to Figure 3, you’ll find this matches the format. A pulse length is based on the transmitter’s clock rate. The library file didn’t name a manufacturer’s part for this protocol; however, some protocols in the file have named transmitting devices. If I translate the value 4509796 into a hex number (0x44D064), it is a bit easier to understand. The device’s 20-bit ID is 0x44D06, and the remaining nibble is the button pressed, in this case, “4.” Pressing each of the buttons, one at a time, you can see the button value for each button.
A=4
B=2
C=8
D=1
CLASSROOM FUN
My daughter happens to be a teacher at a local CREC school. I thought she might be able to use a tool that could reinforce learning, provide some competition, and be fun at the same time. So this project will use these key fobs as answer input devices. I have five fobs, so one will become the host or teacher’s device, while the other four are the players’ or teams’ devices. I marked them H and 1, 2, 3, 4. To make this work, I need to identify the five devices. The MEGA has EEPROM that I will use to remember these devices. This only needs to be done once, unless you wish to substitute or add a new fob. Note that you can purchase additional fobs and increase the number of players, but I’ll keep it simple for now, and stick with four player fobs.
Since we have the ability to store data while the device is OFF, we need to look at the EEPROM when we power up the MEGA, to determine whether the fobs have been or need to be identified. I’ll use one of my buttons on the protoboard to force this routine, should you want or need to rerun the identification routine. To identify the fobs, I present a series of instructions to the user through the user interface (at this time a serial port), asking the host to press any button on the H fob. When a transmission is identified, the ID value is saved as the host or teacher’s fob. Similar prompts are presented for the players’ fobs 1-4. Now all the IDs can be saved for future reference and used as application input devices. Any time a device button is pressed, the resulting transmission is received, and the application can compare the stored IDs to find who is signaling, and also which key on the fob is being pressed. Now we can move on to the Q&A part of the project.
STORAGE DEVICE
It might be clear at this point why the SD interface was put on the protoboard. We need some way of accessing some data. In this case, the data is in the form of files containing questions and answers that our application will serve to the class. Each question presented will offer four answers labeled A, B, C, and D. Students or teams choose an answer from the ones provided, and signal with their fobs by pressing the appropriate key on their team fob.
The SD card has been prepared ahead of time with various files the teacher can choose from. The file structure is simple—just a simple text file with a list of question and answers in the format: question, correct answer, alternate answer 1, alternate answer 2, and alternate answer 3. I created three files—History, Science, and Math—for testing. Here’s a typical question with answers from the Math file.
What is another name for a right triangle?
Isosceles
Acute
Obtuse
Scalene
I placed these files in a folder named “Quizes” on the SD card. The SD.h library for Arduino supports FAT16 and FAT32 file systems on standard SD and SDHC cards. It uses short 8.3 names for files. For the best readability, keeping the file name to eight or fewer characters will prevent the shortening of names with a number suffix. For example, Mathematics is shortened to Mathma~1.
The first thing we need to know is what files are available to choose from. I keep this code simple by keeping the files on the SD card to four or fewer. This allows the teacher to choose from a list of up to four using the key fob’s A, B, C, and D buttons. More files would require a more sophisticated selection process, where you would need to display the files and allow scrolling through the list before choosing. Since I’m not trying to make this overly complicated, I’ll leave this as an exercise for the reader, should you wish to expand this.
Initializing the SD card is straightforward. We start with the SD.begin(chipSelect) function that establishes an SPI path to the SD card using the SPI interface using the “passed” I/O pin that will be used as the chip select. The SD.open(“/”) function will allow a search for all the files (and directories) beginning with “/”, the root directory. The SD library has several examples you can use to experiment with SD cards. I modified one of the routines from an example to produce the following routine to search and grab .TXT filenames. It is quite complex and recursive, which means it can call itself.
This routine printDirectory(File dir) begins in the root directory and looks for all the directories and files in that directory. Should the directory “QUIZES” be found, the routine will call itself, which tunnels down to the “QUIZES” directory and again looks for all the directories and files in this directory. This time, when a file with a .TXT suffix is found, the file name is stored in an array, myFiles[fileCount]. This continues until all the files have been identified and saved in the array. Any additional files or directories are merely skipped over until we have returned to the original iteration and the program flow continues.
With the number of text files in the directory “QUIZES” and each of their file names identified, we can display the file names and allow the teacher to choose one from the list that has been displayed:
Choose a Quiz File
A – HISTORY
B – MATH
C – SCIENCE
…waiting for Host to choose a topic
Once a file has been selected, it is then opened and the text file is read from the SD card. Since we know the format of these files, we can place the first text line into the question array, questionArray[maxPossibleQuestions]. The following four text lines are placed into the answer array, answerArray[maxPossibleQuestions * 4]. Note that this array holds the four answers, with the first answer being the correct one. This process repeats until the end of file (EOF).
To make this more interesting and allow the same file to be replaced with a new look, the questions are presented in random order. In addition to that, the four answers listed for each question are also presented in a different order each time. When a question is presented, a timer begins ticking down. This could be any value, but I’m using 15 seconds. It’s not a race; but each player or team must decide on the correct answer and answer before the timer expires. Unanswered questions are graded as wrong. Each player or team, 1 to 4, has an indicator at the bottom of the screen that changes from a player/team number to a “?” when they have answered the question. Once all players/teams have answered or the timer has expired, each one’s answer replaces the “?” and the correct answer is revealed. Once all the questions have been answered, the scores for each player/team, 1 point for each correct answer, are shown, and a winner or winners are announced.
— ADVERTISMENT—
—Advertise Here—
The host controls the progress of the game by signaling when the next question will be presented, and after each game, what will happen next. After each game, the host can choose to play a new game, repeat the same game, show the game credits, or quit.
GAME DISPLAYING
Many classrooms are equipped with a large screen monitor. PCs and MACs can be cast to this screen for teaching purposes. I found that the parallax-serial terminal is a great application to accept formatted serial output, because it will accept control codes to clear the screen and position the cursor. I make use of these in the application. In addition, you can adjust the type size and produce a display with large characters that can be seen at a distance. Casting this display to a large format monitor on the classroom wall makes a display everyone in the room can read (Figure 6).
Using parallax’s serial terminal program on my PC, the font can be enlarged so the text is viewable from several feet away. While my 21” monitor is fine for small groups, casting it to a large screen can make it viewable to a whole classroom of students.
Now that I have an application running, I can think of many ways to expand on this. I’ve already mentioned changing the number of files on the SD card. The number of Q&As in each file currently is limited to 10. This was an arbitrary value, but it does affect the amount of data storage necessary to hold the Qs and the As. One alternative might be to read a single question (and answers) at a time, and then discard it . This would really cut down on the memory necessary, and would allow a file to contain more questions. If you had 100 questions, for example, you could randomly choose 10 per game; so each game could be different using the same file.
You might want only the first player to answer correctly to get a point. Maybe the points could be based on how quickly they answer. Increasing the number of players is also a possibility. While this application could have been done with wired switches, there is no “cool factor” in that.
Finding these RF key fobs and putting them to use them as inexpensive portable input devices is a novel application. While my application uses them in a competitive way, you may already be dreaming up other ways of using them. I hope you’ll share those ideas with me. Too much to do, so little time.
REFERENCES
[1] EV1527 data sheet.
http://www.sc-tech.cn/en/EV1527.pdf
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • AUGUST 2022 #385 – Get a PDF of the issue
Jeff Bachiochi (pronounced BAH-key-AH-key) has been writing for Circuit Cellar since 1988. His background includes product design and manufacturing. You can reach him at: jeff.bachiochi@imaginethatnow.com or at: www.imaginethatnow.com.
