Greetings,
I working on a volunteer project for an elementary school to develop a wireless “game-show” application for use in some of their classes. Some of the “highlights” include:
-
up to 100 wireless handhelds simultaneously in use
-
.NET application displaying questions pulled from a SQL Server
-
display of questions and scores on a projector durign each round
I have hacked together a proof of concept solution (5 controllers and a central “hub”) using an ATMEGA and the Nordic wireless modules (http://www.sparkfun.com/commerce/produc … cts_id=151). I have also mated a USB to TTL adapter (http://www.hvwtech.com/products_view.asp?ProductID=409) with an ATMEGA and nRF2401A for the PC side of things. With that being said, I wondered if anyone had any ideas on how to handle the possibility of everyone answering at exactly the same time? I have a hack right now that includes having each unit on its own channel and switching the channel of the receiver to see if there is any data coming in. This worked fine for the proof of concept, but there has to be a better way. One major concern is that if 50 people answer at the exact same time, how do I handle making sure everyone gets their answer registered? Not to mention that I need to work on maximizing distance allowance from the transmitter to the receiver! Wow! Lots of work to be done, any thoughts would be greatly appreciated!
BTW, stumbled across some of brennen’s posts and just went to http://www.diyembedded.com/ to poke around a little.
There’s not a tremendous amount that you can do to avoid having a bunch of people answer at the same time. But keep in mind that as long as you keep the data packet short (easier if you’re just using a few buttons on a remote instead of a whole keypad/keyboard), you’re not on the air for very long. It’s even less time if you use the 2 Mbps data rate (but you get reduced range).
I’m not sure about the 2401A, but I know that the 24L01 has a bit called “CD”, which stands for Carrier Detect. If the 24L01 detects a signal for something like 120 microseconds, it sets the bit. Unfortunately, neither the 2401A or the 24L01 has any type of RSSI (Received Signal Strength Indicator), which would be of great use to you in this situation to be able to tell if another radio has the air.
The best way to handle this in general is basically just to transmit a packet from the remote and get the hub unit to send it a response if it got anything. Then the remote would know (with reasonable but not complete certainty) whether the hub got its data or not. If you were using the 24L01, you could use the hardware Enhanced Shockburst mode to do this in hardware. You could also set each remote to listen for an arbitrary amount of time, and if it hears no traffic, then let it transmit. You would still want to wait for an acknowledge as I described before.
Unfortunately, though, there really isn’t any 100% guarantee that you’ll never have collisions. You just have to write the software such that 1) the remotes know whether or not their data got to the hub and 2) the remotes can handle the case of a collision gracefully, whether you choose to try to retransmit or not.
Let me start by saying that I am grateful for the feedback already provided!
Just to provide a little more detail, the input from the user will be from a 4 button keypad (A-B-C-D only) and my plan was to simply transmit the controller ID number and the answercode (A=1, B=2, C=4, D=8) to the PC. In this applicaiton it is entirely likely that 50+ people will be answering at exactly the same time so I wondered if a two prong approach would be best:
-segment the controllers to multiple receivers (i.e. IDs 1-25 = Receiver1, 26-50 = Receiver2, etc) to maximize “listening time” for each receiver
-implement a form of “Ready to Transmit - Ready to Receive” protocol between the transmitters and the receivers (as discussed in brennen’s response)
I want to make sure my approach based on what I am reading is somewhat sound, if thats at all possible. I am planning on putting each controller on its own channel. In the “segmented receiver” scenario, this would mean that Receiver1 would listen to channels 1-25 and constantly switch the channels. Each transmitter would then transmit a ready-to-transmit packet and wait for a response from the receiver. Once the transmitter gets the go-ahead-and-transmit packet, it sends its data and waits for a OK packet from the receiver. The receiver then goes on to the next channel after sending the OK packet.
On a side note, I had planend on switching over to the 24L01 as it seems to have a number of enhancements and it has a more desirable form factor (at least from SF). I am really concerned about maximizing the distance between transmitter and receiver; it appears that the 24L01 helps with that also.
As always, thanks for any help/feedback and feel free to tell me if I am WAY off or if there is a better way. I look forward to everyone’s feedback.
Thanks!
Using separate channels is certainly an acceptable solution to the problem. I think if I were doing it personally, I’d just use one main unit connected to the PC and let all the remotes be on one channel. That would simplify the design and get rid of some extra hardware. It would make the software more complicated, but software is free. 
Just deal with on-air collisions in software, while using the Enhanced Shockburst feature on the 24L01 (that you’re planning on upgrading to). I would probably make the retransmit time variable, maybe based on some function of the remote address. That would keep you from having two nodes continuously collide.
When it comes down to it, if two people were to try to transmit at the exact same time, it’s indeterminate to you who answered first regardless. So if a collision occurs, it doesn’t matter, since there isn’t any way to figure out who got there first. I would just give it to the first person that gets a good message through. And in the vast majority of cases (especially if you send very short packets), this will be the first person to buzz in. If you could keep it down to no more than 64 remotes transmitting at the same time, you would only have to send one byte of data (6 bytes for address and 2 bytes for keypad button selected).
jtaggart:
Just to provide a little more detail, the input from the user will be from a 4 button keypad (A-B-C-D only) and my plan was to simply transmit the controller ID number and the answercode (A=1, B=2, C=4, D=8) to the PC. In this applicaiton it is entirely likely that 50+ people will be answering at exactly the same time so I wondered if a two prong approach would be best:
-segment the controllers to multiple receivers (i.e. IDs 1-25 = Receiver1, 26-50 = Receiver2, etc) to maximize “listening time” for each receiver
-implement a form of “Ready to Transmit - Ready to Receive” protocol between the transmitters and the receivers (as discussed in brennen’s response)
If I could get a clarification on whether the order of response is critical, i.e. do you care who presses the button first? One method of simplification would be to implement a master slave protocol. This would eliminate the need to deal with collisions. You could poll 100 boxes in a fraction of a second.
Thanks to both brennen and muntron for their responses!
Muntron - to clarify, I do not care who presses teh button first… I just need to assign the appropriate number of points for the timing of their response. For example, after the question is posed to the group, a timer starts ticking down. As it counts down, the points awarded also decrease:
Example
30 secs - 28 secs left = 100 pts
27 secs - 25 secs left = 90 pts
24 secs - 22 secs left =80 pts
etc.
As long as I can find out “when” in the timer cycle they pressed their button, I do not care the order in which they pressed it. Hope that helps clarify things a little.
Brennen - Sounds like I have a lot of reading to do and some trial and error ahead of me. I am a novice in the RF realm and have never had to deal with collision detection. I plan on ordering some hardware today from SF and Digikey to implement the tutorials on your website. Hopefully they will aid me in trying to figure out the most effective way to muddle through this project.
As always, I appreciate the feedback and look forward ot any other questions/comments/concerns anyone has.
jtaggart:
As long as I can find out “when” in the timer cycle they pressed their button, I do not care the order in which they pressed it. Hope that helps clarify things a little.
I get it, like those trivia games in bars. In that case, you should transmit a timestamp together with the ID and answer. This is not absolutely critical for the first version, but might be preferred so that points are not deducted when transmission is missed due to collisions.
One other way to avoid collisions might be to use a wireless technology that handles them for you, eg. zigbee.
muntron:
I get it, like those trivia games in bars. In that case, you should transmit a timestamp together with the ID and answer. This is not absolutely critical for the first version, but might be preferred so that points are not deducted when transmission is missed due to collisions.
This would be a good idea, but collision detection would still have to be implemented in software. The master unit would send each remote a packet with the time in it. This would also mean that each remote would have to keep time in some way (timer or RTC hardware would be the best).
muntron:
One other way to avoid collisions might be to use a wireless technology that handles them for you, eg. zigbee.
The Zigbee modules from SF actually cost about the same as the 24L01 units. You may want to consider them before you make your final purchase, since they come shipped with software that you are going to have to write yourself if you go with the 24L01's. You may also be able to get them from Digikey and/or Mouser.
Muntron - exactly like the systems in the bar (NTN is the company by the way)! That is where the person that roped me into this project asked, “hey, couldn’t you develop something like this for my students to keep them interested in the material and make things fun?”. Of course it was also, “couldn’t you do this CHEAPLY… i.e. for free?”. Being a sucker for friends and kids, I said I would… now here I am.
I figured that if I take brennen’s suggestion of a “Ready to Answer”/“OK to Send”/“OK I got it” protocol for the transmitter and receiver, I will be able to get the timing of each pretty accurately. So in practice:
Question is asked… a “OK to Answer” is sent to all transmitters
When a participant answers… a “Ready to Answer” is sent to the receiver and the transmitter begins counting Millisecs
Once the receiver is ready… it transmits a “OK to Send” to the transmitter and receives the address, answer, and timing info to assign proper points
The transmitter then sits in a waiting state for a set time period until it either times-out (need to re-transmit) or gets a “OK I got it” message from the receiver
If a new button is pressed, then start the process over…
Sounds real straight-forward… 
Straight-forward… not easy…
To expand on your ideas, here is something that may take all three of our ideas and put them together. This would work similar to the NTN systems in bars/restaurants, where you simply have a certain amount of time to answer the question. You could even use this method to assign points exactly like the NTN systems do based on the difference in time from the master’s current time and the timestamp received from the remote:
-
Master sets its own time and starts a timer.
-
(Optional step) Master polls each remote to see if it is active.
-
Master sends its time to the remotes (this should be a single broadcast message that goes all remotes simultaneously).
-
Each slave starts a timer to keep time at the same interval as the master.
-
When a question is ready to be answered, master sends “OK to answer” message to all remotes (broadcast message as in 3).
-
When a player presses a button on a remote control for the answer, the slave saves its timestamp for that button in memory.
-
The master sends “No more answering” message to all remotes (broadcast message as in 3).
8 ) One by one, the master polls each remote that was detected in step 1 (or all possible remotes if step 1 was skipped) to see what its answer was. This way there is no possibility of collisions with other remotes, and you only need one master, operating on one channel.
jtaggart:
Question is asked… a “OK to Answer” is sent to all transmitters
When a participant answers… a “Ready to Answer” is sent to the receiver and the transmitter begins counting Millisecs
Once the receiver is ready… it transmits a “OK to Send” to the transmitter and receives the address, answer, and timing info to assign proper points
The transmitter then sits in a waiting state for a set time period until it either times-out (need to re-transmit) or gets a “OK I got it” message from the receiver
If a new button is pressed, then start the process over…
Sounds real straight-forward…
Straight-forward… not easy…
Yes, that is how network protocols work, except that there is H/W collision detection. If a collision is detected, the sender backs off an amount of time (usually random), before trying again. this ensures that the collision can be resolved. Using the protocol that Brennen proposed, limits collisions since no remote transmits without being asked.
Or you can look at a commercial solution like [iclicker, or [turning point.](http://www.turningtechnologies.com/)](http://www.iclicker.com/)