# game show buzzer help

Discussion in 'Electronics Resources' started by boltoner66, Nov 23, 2012.

1. ### boltoner66 Thread Starter New Member

Nov 23, 2012
1
0
does anybody know where i can get a circuit diagram to build a wireless gameshow buzzer circuit with twelve handsets for my class to build as a project

2. ### elec_mech Senior Member

Nov 12, 2008
1,513
193
Welcome to AAC.

Twelve wireless sets could be difficult depending on what you want to do.

How would you like this to work?

Are you wanting each of twelve remotes to sound a unique buzzer (twelve buzzers) or the same one?

If the latter, how do plan to determine which of the twelve students hit his or her button first?

Two ways of doing this: 1) twelve of the same remote on the same frequency triggering one buzzer for all - won't be able to tell who hit their's first or 2) twelve unique frequencies that set off the same or multiple buzzers - LEDs could be used to indicate at the buzzer which student hit his or her button first.

In either case, you'll likely need to hack an existing product, especially if you want twelve unique frequencies.

Another option is wired or partially wired. If you could accept having the twelve buttons wired together, you could put an LED at each student's button (or use a lighted button such as this: https://www.sparkfun.com/products/9181). You could then send a single wireless signal to a buzzer on the other side of the room. I think this would give you the best of everything. This could certainly be done fully wired too.

3. ### crutschow Expert

Mar 14, 2008
13,501
3,375
You could use the same frequency if each button generates a unique code that would use some simple from of pulse modulation (turning the RF signal on and off) which would be interpreted by the receiver.

You might get some further ideas here.

4. ### WBahn Moderator

Mar 31, 2012
18,087
4,917
The codes that each receiver generates need to be carefully considered. Remember, the receiver is going to be receiving a signal that is the sum of between one and twelve signals and has to be able to decide which ones it is receiving and which signal started first.

This is actually a perfect application for concurrent codes (provided a bit of latency can be tolerated). The transmitters can be very simple, but the receiver has to run a concurrent decoder, which is not too complicated but really needs an FPGA or a microcontroller.

For this application, I would probably recommend 512-bit codewords generated from 8-bit messages with 8-bit checksums, giving an expansion factor of 32. If the codewords are transmitted at 19.2kbaud, then the packet latency would be under 30ms, which is probably more than adequate for this application (and it would be fair because all transmitters would incur identical latencies and you could resolve which transmitter's code arrived first to resolution of about 50us).

5. ### crutschow Expert

Mar 14, 2008
13,501
3,375
Certainly concurrence of received code is a concern, but you only need to resolve which one is first. If 50μs is a good resolution criteria then, if the code bit-rate is 120kHz, a 4-bit code could be detected in 50μs (assuming one start and one stop bit). Then you just ignore any code after that.

6. ### WBahn Moderator

Mar 31, 2012
18,087
4,917
It might work. But consider that you have 12 buzzers and that, at least some portion of the time, a bunch of people are going to try to be buzzing in very close to the same time. You'd have to run the probabilities, but I think you will find that you would expect an unacceptable chance of the first two respondents colliding and someone that buzzes in later getting recognized as being first. It will only take a few times of that happening when the person that gets recognized clearly wasn't the first to buzz in for people to lose all faith in the system.

7. ### crutschow Expert

Mar 14, 2008
13,501
3,375
OK. So what's the solution to resolving when two buttons are pushed within less than 50μs apart (which is what both our techniques cannot do)? The obvious way is to use separate frequencies for each button but that makes for a complicated receiver.

8. ### WBahn Moderator

Mar 31, 2012
18,087
4,917
Concurrent codes have no problem with overlapping signals -- that's precisely what they were developed to deal with.

Remember, my 50us came from using a 19.2kbaud signal, while yours came from using a 200kbaud signal. At 200kbaud, the resolution of my system is 5us.

But, even if the resolution is 50us, mine will correctly say that all twelve responded at the same time if, in fact, the signals from all twelve started arriving within the same 50us chip window. It might be possible to get the resolution down to a fraction of a chip, but that would take a lot more work.

While I don't see a concurrent-code based system as being practical for this OP's project, one of the many applications that I think concurrent-code based systems would be a natural fit for at things like classroom clickers. Contest buzzer systems are another natural application.

9. ### John P AAC Fanatic!

Oct 14, 2008
1,638
225
You could have a bidirectional system, where each unit receives a time signal from the master. Then when its button is pressed, the unit doesn't have to say "My button was just pressed". It says "My button was pressed at time=X". Then the master can correlate them all and decide who won. They could each transmit at some unique time based on the clock, and that would eliminate conflicts.

Actually if a session begins with all the units plugged into the master, they could each set their clock then and not require any updates over the period for an operating session, so a bidirectional link wouldn't be needed. Accuracy of timing could be as good as a digital watch for very little money.

10. ### crutschow Expert

Mar 14, 2008
13,501
3,375
That seems to be the simplest wireless system proposed here. Each sender would have a crystal oscillator which is synchronized at the start of the session. A μP with a crystal clock could likely do all the required logic and send the time-stamp signal to it's transmitter at the appropriate time.

But the system would still require a significant amount of design effort to build by an experienced designer. If the OP wants a design already done, I suggest reducing the scope of the project and looking at some of the wired approaches that have been build.

11. ### WBahn Moderator

Mar 31, 2012
18,087
4,917
Having each unit send a timestamped message addresses a number of issues. If the signal is unidirectional, then each unit should transmit each message several times, with random delays, to increase the likelihood that one of them will get through. The receiver, of course, has to wait some maximum amount of time after receiving the first packet to be sure (with some level of confidence) that it has received any other messages that might be rebroadcasts of messages with earlier timestamps. That window has to be kept sufficiently narrow so that the user's don't notice the latency that results.

But, how accurate do the oscillators need to be?

We've been throwing around 50us resolutions, but it's probably hard for people to firmly perceive differences much less than 50ms. Most of these games probably last between 15 min and 25 min. Since we have to allow for one unit running fast and one unit running slow, we should allow 25ms of accumulated error after 25 minutes, which is ~17ppm. That's doable, but pushing it.

But one question that would need to be considered: The unit that runs faster will give that team a systematic advantage allowing them to win close contests (be recognized as having buzzed in earlier even when they actually buzzed in later) while units that run slower will give those teams a competitive disadvantage. So the question is: How much of a competitive advantage/disadvantage of this time is acceptable while still being able to call the game "fair"?

I can think of a number of ways to return "fairness" to a system like this. One way is to have the units synch'ed up to the master unit for a minimum amount of time and use that time to have the transmitter's calibrate their oscillators by capturing the accumulated error at the end of the sync time and adjust their timestamps accordingly. If a 32.768kHz watch crystal is used, then there will be 32,768 pulses at the end of each second. At the end of just a 32s sync time there will be 1024^2 pulses to work with. Take whatever the error is at that point (in pulse counts) and have the transmitter store that value and every 1024^2 pulses that it sees from then on it adds or subtracts accordingly. If one unit is 20ppm fast (or slow) it will only accumulate a bit over 0.5ms of error before being pulled back to something very close to the "correct" time. In fact, if you use a method like this, you could use 200ppm oscillators and probably never accumulate enough error, even after a game lasting an hour or so, for anyone to notice or enjoy a significant advantage.

But you might want to let them sync for longer period of time. You might also have them adjust their clocks more frequently. Say you still had them sync for 32s and one of them was off by 200ppm. The accumulated error might a bit over 200 counts. Instead of adjusting the clock every 32s (1024^2 pulses), you could have it adjust every second by 1/32 of the error and tweek the adjustment up by one every time the residual error accululates to a full pulse. Or, you could simply make an adjustment of the residual amount every 32s.

12. ### crutschow Expert

Mar 14, 2008
13,501
3,375
Another (perhaps simpler) way to correct for clock error is for each unit to have it send its local time (at the time it transmits) along with the time the button was pressed. That way the receiver can apply a correction to each received signal and determine which button was pressed first. There would be no need to synchronize the unit clocks or even have them particularly accurate (a 32kHz clock crystal would be more than adequate) since we are only concerned about relative time and the correction would be done after each transmission of each transmitter. Any latency in this process should be equal between units so should not affect the accuracy. This technique also requires only one-way communication.

The one possible problem with this is that the transmission occurrence of each would be at random times. But as WBahn noted, sending the message several times at random intervals with relatively large gaps between transmissions may solve that conflict.