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.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).
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.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.
Concurrent codes have no problem with overlapping signals -- that's precisely what they were developed to deal with.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.
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.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.
|Thread starter||Similar threads||Forum||Replies||Date|
|R||Game show buzzer automatic reset||The Projects Forum||1|
|B||Game show buzzer using a microcontroller||The Projects Forum||1|
|S||Game show buzzer conundrum...||The Projects Forum||12|
|R||Game Show Buzzer (PIC16F887, MPLAB, Hi-Tech C)||Embedded Systems and Microcontrollers||8|
|T||Game Show Buzzer Help!||The Projects Forum||15|