I'm doing a project and I ran into a bit of a difficulty. I hope someone can help me out!
Basically I need to make a 'quizmasters controller' which multiple quizbuttons with lights in them can be wirelessly connected to. I was thinking about using bluetooth or RF or maybe infrared. The buttons can have individual uC's in them which each store a unique ID. They need to be able to send the controller some kind of message saying "hey I was pressed". And at power-up (initialization of the game) they need to be able to communicate to the controller so that it knows which and how many buttons are participating. Also the controller needs to be able to send commands to the buttons telling them to for instance blink their light. And to send them an acknowledgement of participation in the initialization.
I don't know what the best approach would be for this. I was thinking RF would the best solution but infrared might also be a good alternative. Anyway I hope some of you can give me some advice or someone has experience with something like this. Please let me know!
RF would work pretty well. You could use NRF2401 radios which are about $3 each and have 50m+ range; they are bidirectional. Use the RF24 library and variants. The RF24 radios can actually listen on multiple channels at the same time so the master controller could have 1 channel for each radio.
Isaac96:
RF would work pretty well. You could use NRF2401 radios which are about $3 each and have 50m+ range; they are bidirectional. Use the RF24 library and variants. The RF24 radios can actually listen on multiple channels at the same time so the master controller could have 1 channel for each radio.
Hi Isaac96,
I didn't know about the NRF2401, I am definately going to check it out! I think it might suit my project perfectly. Thank you.
You have not said, but I suspect the idea is to identify which competitor presses his/her button first.
That is not at all easy to do with wireless. A wired solution would be much simpler.
The big problem with wireless is that if two or more competitors press their buttons at nearly the same time so that the wireless messages overlap then all the messages will be garbled.
You can avoid that risk by having the master poll the slaves one after the other (several times per second) but that would mean that if A and B pressed their buttons at the same time A would always be deemed to have been first.
In theory you could have each slave record the time when a button is pressed to the nearest few microseconds and send the time as part of the message. But it is very difficult to synchronize the clocks on the slaves to that level of accuracy. Perhaps a slave could record the value of micros() when a button is pressed and when the request comes from the master it would send the number of microsecs that has elapsed between the button being pressed and the request arriving. Then the master could calculate relative times knowing exactly when it sent its request to each slave. That sort of system would not require the clocks in the slaves to be synchronized.
Yes you are correct, the controller needs to know which button was pressed first. Preferrably also which one was second and third and so on. I do realize that that part will be very tricky. Your idea of doing this time based is very good. I imagined something like the main controller sends a broadcast signal to all the buttons at once a few times per second. The broadcast could carry some form of time constant. The buttons get triggered when they receive the message and start counting from that time constant. When one has been pushed it can send back to the main controller its address and time it took from let's say t0 until push. The controller could then figure out which one has the shortest time.
The thing is that it's not an option to do it wired. This is going to be used around drunk people and like pub quizzes and it's proven that buttons with wires and controllers don't last very long. But it's a nice challenge!
Having a system that switches between "all listening for the same message" and "each one sending its own message" will get very messy IMHO.
My first approach to the problem would be to use the 2nd example in my Tutorial - which uses the ackPayload feature that makes 2-way communication very simple. That was the context in which I suggested "send the number of microsecs that has elapsed between the button being pressed and the request arriving". There would be no need for the master to broadcast any time data.