Wireless project using 8 transmitters and 1 receiver, simultaneous communication

Hello everyone,

I’m starting a project to build an Arduino “quizz machine” similar to this one, but with wireless buzzers (buttons that players press to answer questions):

I was thinking of using a Due or Mega for the receiver (control console) and Nanos for the transmistters (buzzers), and nRF24L01+ modules for wireless communication. I foresee two potential major roadblocks, and was wondering if anyone had ideas on how to overcome them:

1- As far as I can tell, the nRF24L01+ can listen simultaneously to a maximum of 6 “pipes” on the same frequency. However, I’m not sure if this limits the number of devices. For instance, could multiple buzzers be configured to communicate with the receiver on the same pipe, and identify themselves to the receiver by having different payloads? If that is not possible, is there a way for the receiver to listen to 8 or more devices at the same time?

2- In a quizz game, it happens fairly often that several players press their buzzer nearly simultaneously. I imagine that could cause significant wireless interference/collision problems. As a possible solution, would it be possible for the receiver to listen on more than one frequency at the same time? If not, what would be a good way to prevent collisions, and still ensure that the person who pressed their buzzer first also triggers the receiver first?

Let me know if you have any ideas on how to solve these problems using the nRF24L01+, or if other RF hardware would be more appropriate for this application.

Thanks!

Any number of transmitters can use the same pipe, on the same frequency, to communicate with one receiver, as long as transmissions don't overlap. Transmissions on different pipes also cannot be allowed to overlap.

The receiver operates on only one frequency at a time, so it is up to you to resolve collisions.

If you can't avoid the possibility of overlapping transmissions, one approach is to have each transmitter make several transmissions of the same data packet at randomly chosen intervals, in the hopes that one will get through. The error checking protocol will discard almost all collisions.

The only reliable way to do this is to use 8 transmitters and 8 receivers all on differant frequencies if the required outcome is to determine which button was pressed first.
Alternatively another way to do this is to have accurate clocks in each box and when the button is pressed, the time it was pressed is sent to the receiver.
This way , the actual time it takes for the transmissions to be received is not relevant any more, but you then need some way to synchonise the clocks.
A wired solution would far easier.

mauried:
Alternatively another way to do this is to have accurate clocks in each box and when the button is pressed, the time it was pressed is sent to the receiver.
This way , the actual time it takes for the transmissions to be received is not relevant any more, but you then

Radio transmissions are never going to be 100% reliable, some 'button presses' will not be received. Therefore there needs to be a send and acknowledge protocol, to ensure button presses are not missed due to interference.

The only way I can see a send and acknowledge system being reliable, is if you know exactly when (in absolute time) each button was pressed.

If I was doing that project I would have the Master poll each of the slaves in turn at regular intervals - maybe 10 times per second. That avoids transmission collisions.

The master could include its own millis() value in each message and the slave can use that to get a near universal time for all slaves. Then the slave records the time (with correction) when its own button was pressed and sends that to the master when next requested. The master can then review all the messages and decide which button was pressed first.

See the seconds example in this Simple nRF24L01+ Tutorial

...R
PS ... it is important to remember that the people playing the game will have no data about who pressed his/her button first with which to contradict the Arduino.

Hey guys,

Thanks for the replies!

Mauried, yes, a wired solution is almost trivial, and it already exists, the challenge of doing this wirelessly is part of the objective of this project :smiley:

Robin, I’ll try your solution, I had something similar in mind if there was no way to listen to multiple frequencies at once. Transmitting the receiver’s clock to each buzzer as part of the polling process is a great idea, I wasn’t sure how to keep them reliably on the same clock. Any reason to use millis() instead of micros()?

And yes, with that approach, there might be some kind of delay during which a user could be pressing their button without the machine triggering, and then it triggers for someone else, which could be frustrating, but I’m guessing the time gap between the first valid press and the machine triggering would at worst be measured in milliseconds, so probably not noticeable. Either way, the machine is always right, haha! In actual games with the wired equipment, we still get a lot of “damn, I’m sure I pressed first” moments anyway…

Akramelag:
And yes, with that approach, there might be some kind of delay during which a user could be pressing their button without the machine triggering, and then it triggers for someone else, which could be frustrating, but I'm guessing the time gap between the first valid press and the machine triggering would at worst be measured in milliseconds, so probably not noticeable. Either way, the machine is always right, haha! In actual games with the wired equipment, we still get a lot of "damn, I'm sure I pressed first" moments anyway...

When you present your project be sure to point out that there are 'errors' in the way it reports who pressed the button first.

Akramelag:
Any reason to use millis() instead of micros()?

And yes, with that approach, there might be some kind of delay during which a user could be pressing their button without the machine triggering, and then it triggers for someone else, which could be frustrating, but I'm guessing the time gap between the first valid press and the machine triggering would at worst be measured in milliseconds, so probably not noticeable. Either way, the machine is always right, haha! In actual games with the wired equipment, we still get a lot of "damn, I'm sure I pressed first" moments anyway...

There is no reason not to use micros() unless there is a risk that it might roll over during the short period when the contestants are excited. I have not thought carefully about whether that would be a problem. However I suspect a resolution of +/- 1 millisec would be quite enough - perhaps even +/- 10 mllisecs.

I don't understand what you think might give rise to the delay that you mention.

In my concept the master would not declare a result until it has received data from all the slaves.

If you want to validate the order in which the master thinks the buttons were pressed then temporarily set up a parallel wired connection between the slaves and the master. And don't expect the wireless system to give the answer as quickly as the wired system - it just needs to report the same order of button presses.

...R

Robin2:
There is no reason not to use micros() unless there is a risk that it might roll over during the short period when the contestants are excited.

Yeah, it would have to rollover during one of the receiver's polling cycles, AND contestants would have to be trying to ring in to answer a question during that specific cycle, AND you'd need more than one contestant trying to answer during that cycle. Extremely unlikely for sure, but I guess I could have something like "currentTime - triggeredTime" on the receiver instead of just "triggeredTime" and pick the highest result. That would work even with an overflow.

Robin2:
However I suspect a resolution of +/- 1 millisec would be quite enough - perhaps even +/- 10 mllisecs.

I have no hard data on this, but for the easier questions, you're likely to have all 8 contestants ringing in to answer at about the same time, and this happens a few times every game. I'd estimate a sub-1-ms collision probably occurs every other game, if not every game.

Robin2:
I don't understand what you think might give rise to the delay that you mention.

In my concept the master would not declare a result until it has received data from all the slaves.

If I understand your idea correctly, the receiver communicates with each buzzer in turn and says "The time is now ###. Did your player ring in since I last asked you? If so, when?" If the player did ring in, the receiver saves the time and cycles through every other player one last time to make sure nobody else rang in earlier. So, for example, say the receiver cycles through players 1-8 in order, and is currently polling player 1. Player 8 rings in, and immediately after, player 1 rings in. The receiver will poll everyone from 1 through 8 before announcing "player 8 can answer". If the polling process is slow enough to be noticeable to a human, there will be noticeable time during which player 1 has pressed their button, the receiver doesn't react, and then announces that player 8 can answer. Although this is the correct decision by the machine, it's probably a bit frustrating for player 1. I know for a fact that people get frustrated with the wired system, even though they have no reason to be (I assume the wired system works fairly and without delay).

Anyway. We're kind of outside electronics and into psychology here I guess. The polling is probably fast enough for this to be a non-issue.

Robin2:
If you want to validate the order in which the master thinks the buttons were pressed then temporarily set up a parallel wired connection between the slaves and the master. And don't expect the wireless system to give the answer as quickly as the wired system - it just needs to report the same order of button presses.

Great idea! I'll definitely implement that in my prototype.

Akramelag:
If I understand your idea correctly, the receiver communicates with each buzzer in turn and says “The time is now ###. Did your player ring in since I last asked you? If so, when?”

This business of “ring in” has me completely confused. I thought the idea was that each contestant has a push-button in his hand which s/he presses when s/he thinks s/he has the right answer

…R

Yes, you got it right, I just don't know what to call it. Press the buzzer?

I'm not a native English speaker, does "ring in" refer exclusively to calling a phone?

I used that expression because our current machine produces a ring-like sound when someone presses their buzzer to answer.

Where is this project going to be used?
No matter how well you design the electronics, any radios that you use will be subject to interferance from other users on the same frequencies, so some transmissions will simply not be received at all, so you must be aware of this and have some mechanism in place to address it.

Akramelag:
I'm not a native English speaker, does "ring in" refer exclusively to calling a phone?

That's the image that came to my mind - but maybe it's my age.

"Press the button" seems the most direct description of what the user does with the hardware in the image in your Original Post

...R