> My feeling is that that could best be done on the software level. > The application reading the serial input would see that buzzer n was > on, would make a note to itself and establish priority of that > buzzer; then if that buzzer was on for, say, either of the next two > passes, it would trigger. Granted, this does make a higher frequency > desirable. Hm...maybe the thing at first just checks if any buzzer > switch on *either team* is closed, and only then check which > one...that makes the logic more complicated, though. There are obviously several ways to do this, but to me this is one of the less-obvious ones. It's much easier to do all of this on the hardware side (say, in a PLD). Then you'd negate any speed limitation of the serial bus by only using it when someone had actually buzzed. > There's a trick around that. You give each buzzer two frequencies: > a "receive" frequency and a "transmit" frequency. You build one > circuit at the receive frequency and one at the transmit frequency > and connect them through a transformer. Put a switch on > the "receive" side. The core element of the buzzer is continually > putting out power at the receive frequency for each buzzer. You > close the circuit with the switch and the receive side resonates, > which means the transmit side resonates too -- transformers are very > efficient. It puts up a range restriction, but really, when is the > buzzer going to be more than, say, 30 feet from the master unit? I'd > worry more about frequency band...too high and, with the amount of > power you need, you start heating people's fillings. Dude, what the hell are you talking about? Seriously, this makes no sense at all. Trying to be polite, but actually terrified that someone might take this man seriously. J.p.
This archive was generated by hypermail 2.4.0: Sat 12 Feb 2022 12:30:47 AM EST EST