A discussion group for the PICMicro microcontroller. Also called the Microchip PIC, this list is dedicated to the use and abuse of this fine, simple, microcontroller. Close to topic posts are welcome, ie. general electronics.
|
Dear All,
I'm designing wireless button/keypad for quiz or survey with
up to 30 people capacity. For example, one person has 4 choices: A, B, C and
D. I think Radiotronix RCR-xxx (receiver), RCT-xxx (transmitter)
and 16F84 can be used to make communication each keypad to the master
controller. The problem is how to anticipate the signal if some keypads
are pressed in the same time. Scanning method may be work. But... note that Radiotronix only has 4800 baud max. It means that actually we cannot detect some keypads that pressed almost in the same time. This is important if we want to know who is the fastest answering the question. I have a plan to expand the participant capacity and sure this is a problem.
Please let me know your suggestions and ideas. Pointing some web resources is welcome.
web ref. :
www.qwizdom.com/software/lectures_keypads.pdf http://www.advancedsp.com/fleetwood/
Regards, Mada. |
|
|
|
In a message dated 10/20/2004 10:34:39 AM Eastern Daylight Time,
m...@polman.astra.ac.id writes:
<jma> ... my approach would be rf polled operation with slaves
responding with button information and clock information from on board timer synced to the
master via the rf polling signal ... the f84 could buffer several keystroke/timehack
blocks ...
|
|
|
|
Yes, you need a 'local' (to the box) time-stamp on when the person pressed their key. And thus you need to synchronize the on-the-box RTC so they are all in-sync (to within a mSec or so). You can then poll each participant's slave box to get their results. If it takes 10 mSec to poll one box, you can poll 40 boxes in .4 seconds. --- In , AveryHUA@a... wrote: > > In a message dated 10/20/2004 10:34:39 AM Eastern Daylight Time, > mada.jimmy@p... writes: > > Please let me know your suggestions and ideas. > <jma> ... my approach would be rf polled operation with slaves responding > with button information and clock information from on board timer synced to the > master via the rf polling signal ... the f84 could buffer several > keystroke/timehack blocks ... |
|
|
|
This sounds like a fun project. A lot depends on whether you need to figure out who pressed the button first. If you don't need to determine who was first, you could poll from the master. Assign each unit a code and when the unit sees its code, it transmits its current state. Basically, a syncronous protocol. If timing is needed, you could have each unit keep time and sync the time to the master, transmit timing info with the polling response. I'm pretty sure you will not get good overall response time for 30 units at 4800 baud. iirc, the Radiotronix stuff is half duplex. You might want to use multiple channels to improve response. Another approach would be to implement ethernet style multiple access, collision detect but I haven't a clue how to do that with radio. By the way, you should consider using something other than the F84 - its pretty old and there are much better PICs for much less cost out there. I'd suggest the 628A which has the same pinout as the F84 and about 1/2 the cost. If you only need 9 or fewer pins, you can go even cheaper with some of the 14 pin PICs as well - the 16F630 is around $1.50, for example. --- In , "Mada Jimmy" <mada.jimmy@p...> wrote: > Dear All, > > I'm designing wireless button/keypad for quiz or survey with up to 30 people capacity. > > For example, one person has 4 choices: A, B, C and D. > > I think Radiotronix RCR-xxx (receiver), RCT-xxx (transmitter) and 16F84 can be used to make communication each keypad to the master controller. > > The problem is how to anticipate the signal if some keypads are pressed in the same time. > > Scanning method may be work. But... note that Radiotronix only has 4800 baud max. It means that actually we cannot detect some keypads that pressed almost in the same time. This is important if we want to know who is the fastest answering the question. I have a plan to expand the participant capacity and sure this is a problem. > For some alternate solution, I looked WiPort from Lantronix, but it is very expensive, and more complicated. > > Please let me know your suggestions and ideas. > > Pointing some web resources is welcome. > > > web ref. : www.qwizdom.com/software/lectures_keypads.pdf > > http://www.advancedsp.com/fleetwood/ > > > Regards, > > Mada. |
|
A quick web search shows that the system used in the article is patented. So, make sure you either license the technology or don't step on it with your own solution. It's at: www.replysystems.com $1500 for the base station, $200.00 for each keypad remote, plus some amount for the 'sampling software'. This does not seem very pricey, considering what the system does. RF transciever modules tend to be expensive ($20.00 to $100.00). It's always nice to just *buy* the wheel, instead of re-inventing it all the time. --- In , "Allan Lane" <allan.lane@h...> wrote: > > Yes, you need a 'local' (to the box) time-stamp > on when the person pressed their key. And thus > you need to synchronize the on-the-box RTC > so they are all in-sync (to within a mSec or so). > > You can then poll each participant's slave > box to get their results. If it takes > 10 mSec to poll one box, you can poll 40 > boxes in .4 seconds. > > --- In , AveryHUA@a... wrote: > > > > In a message dated 10/20/2004 10:34:39 AM Eastern Daylight Time, > > mada.jimmy@p... writes: > > > > Please let me know your suggestions and ideas. > > > > > > <jma> ... my approach would be rf polled operation with slaves > responding > > with button information and clock information from on board timer > synced to the > > master via the rf polling signal ... the f84 could buffer several > > keystroke/timehack blocks ... |
|
--- In , "Allan Lane" <allan.lane@h...> wrote: > > Yes, you need a 'local' (to the box) time-stamp > on when the person pressed their key. And thus > you need to synchronize the on-the-box RTC > so they are all in-sync (to within a mSec or so). > > You can then poll each participant's slave > box to get their results. If it takes > 10 mSec to poll one box, you can poll 40 > boxes in .4 seconds. I suspect the poll/response cycle time will be the big challenge. A lean protocol will probably take 5-10 bytes per response packet and a couple of bytes per poll command packet. the response delay could be an issue. 10 mS is <5 bytes at 4800 baud (2 start, 8 data, 1 stop). IIRC the cheaper Radiotronix units require manchester or similar encoding so there is some overhead (time and size) and he's talking about the F84 which is slow. I'd bet he'll see less than 50% throughput. Its doable but will require a lot of care and tuning to get working really well. A well designed protocol is crucial. Also, a fair amount of attention to reliability will be needed (packet checksums, retransmit capability, ...). If it were my project, I'd pick 2 or 3 different frequencies and significantly improve the system throughput at the cost of some complexity to the master unit. |
|
|
|
--- In , "Phil" <phil1960us@y...> wrote: > > --- In , "Allan Lane" <allan.lane@h...> wrote: > > > > Yes, you need a 'local' (to the box) time-stamp > > on when the person pressed their key. And thus > > you need to synchronize the on-the-box RTC > > so they are all in-sync (to within a mSec or so). > > > > You can then poll each participant's slave > > box to get their results. If it takes > > 10 mSec to poll one box, you can poll 40 > > boxes in .4 seconds. > > > > I suspect the poll/response cycle time will be the big challenge. A > lean protocol will probably take 5-10 bytes per response packet and a > couple of bytes per poll command packet. the response delay could be > an issue. 10 mS is <5 bytes at 4800 baud (2 start, 8 data, 1 stop). > IIRC the cheaper Radiotronix units require manchester or similar > encoding so there is some overhead (time and size) and he's talking > about the F84 which is slow. I'd bet he'll see less than 50% throughput. > > Its doable but will require a lot of care and tuning to get working > really well. A well designed protocol is crucial. Also, a fair amount > of attention to reliability will be needed (packet checksums, > retransmit capability, ...). > > If it were my project, I'd pick 2 or 3 different frequencies and > significantly improve the system throughput at the cost of some > complexity to the master unit. Can some assumptions be made ? Less than 20% will be trying to be first at any time ? A 2 digit unit identifier of one *might* make it there first. It would be horrible if one sent out 12 and another sent out 34 and the reciever saw 13.... Another idea might be to broadcast a time signal and from that each reciever would know what time it is and they would all be set accordinlyly. then when the first button was pressed, indicating someone has an answer, the receiver would indicate "we haave a winner", then poll all units for teh time the button was pressed. That way, an instant notification would be seen, followed shortly by the polling to determine who was first. Almost too fast for the casual observer. Dave |
|
|
|
--- In , "Dave Mucha" <dave_mucha@y...> wrote: ... > > then when the first button was pressed, indicating someone has an > answer, the receiver would indicate "we haave a winner", then poll > all units for teh time the button was pressed. That way, an instant > notification would be seen, followed shortly by the polling to > determine who was first. > > Almost too fast for the casual observer. > > Dave What is the effect of interference? i.e. when 2 xmitters hit at the same time? Can the receiver's controller tell - does the receiver toss them away or does it pass the garbage to the controller? How do you poll for the winner with out some sort of synchronous protocol? Probably needs some experimentation. |
|
If 2 xmitters hit at the same time, I’m sure that the master
unit will receive garbage information. Imagine you have one serial port
(RS232) as an input and connect it together with another two serial port as
output. If one sends 10011000 and another sends 00100010 so master unit
will receive 10111010. Timestamp/RTC on each box is good idea. The problem is how to
sync all RTCs at the same time by broadcasting time information. It's impossible using
scanning method. My idea, we need difference radio frequency for broadcast time info, i.e. 418 MHz for timing and 433.92 MHz for data. Sure, this needs some experimentation. Anybody have RF experiments? It’s no problem if the polling time reach .4s, since each unit
have own time info. 16F84 is only example here; I will see other PICs that suitable for battery operated, fast and cheap.
www.replysystems.com ? Yes, this does not seem very pricey to me.
Mada.
|
|
Dave: When using boxes like this with a large crowd, generally you ask a question, then everyone tries to answer. As a result, it is MORE likely that you'll get lots of results at the same time. 20% sounds too low. Then, if you want to use this in a 'Million-Dollar Question' sort of way, *every* participant will be trying to be first. 90% simultaneous? The commercial system mentioned sounds like it does poll every remote individually -- in which case you could have the remote merely record how much time has passed between the button press and the last poll. The base station can use that to determine which button press was actually first. --- In , "Dave Mucha" <dave_mucha@y...> wrote: > > --- In , "Phil" <phil1960us@y...> wrote: > > > > --- In , "Allan Lane" <allan.lane@h...> > wrote: > > > > > > Yes, you need a 'local' (to the box) time-stamp > > > on when the person pressed their key. And thus > > > you need to synchronize the on-the-box RTC > > > so they are all in-sync (to within a mSec or so). > > > > > > You can then poll each participant's slave > > > box to get their results. If it takes > > > 10 mSec to poll one box, you can poll 40 > > > boxes in .4 seconds. > > > > > > > I suspect the poll/response cycle time will be the big challenge. A > > lean protocol will probably take 5-10 bytes per response packet and > a > > couple of bytes per poll command packet. the response delay could > be > > an issue. 10 mS is <5 bytes at 4800 baud (2 start, 8 data, 1 stop). > > IIRC the cheaper Radiotronix units require manchester or similar > > encoding so there is some overhead (time and size) and he's talking > > about the F84 which is slow. I'd bet he'll see less than 50% > throughput. > > > > Its doable but will require a lot of care and tuning to get working > > really well. A well designed protocol is crucial. Also, a fair > amount > > of attention to reliability will be needed (packet checksums, > > retransmit capability, ...). > > > > If it were my project, I'd pick 2 or 3 different frequencies and > > significantly improve the system throughput at the cost of some > > complexity to the master unit. > > Can some assumptions be made ? > > Less than 20% will be trying to be first at any time ? > > A 2 digit unit identifier of one *might* make it there first. It > would be horrible if one sent out 12 and another sent out 34 and the > reciever saw 13.... > > Another idea might be to broadcast a time signal and from that each > reciever would know what time it is and they would all be set > accordinlyly. > > then when the first button was pressed, indicating someone has an > answer, the receiver would indicate "we haave a winner", then poll > all units for teh time the button was pressed. That way, an instant > notification would be seen, followed shortly by the polling to > determine who was first. > > Almost too fast for the casual observer. > > Dave |
|
|
|
In a message dated 10/21/2004 4:11:37 AM Eastern Daylight Time,
m...@polman.astra.ac.id writes:
Timestamp/RTC on each box is good idea. The problem is how to sync all RTCs at the same time by broadcasting time information. It's impossible using scanning method. <jma> ... perhaps, but it is a question of resolution ... what
are the requirements of the application ... in many cases absolute time values are not
required ... in those cases a relative value which can be calibrated will suffice
... with full protocol control and a reasonable communications channel sub
millisecond resolution can result ... of course if full microsecond valid information
is the goal it gets a bit more sticky ...
|
|
--- In , "Allan Lane" <allan.lane@h...> wrote: > > Dave: > When using boxes like this with a large crowd, > generally you ask a question, then everyone > tries to answer. As a result, it is MORE > likely that you'll get lots of results at the > same time. 20% sounds too low. > > Then, if you want to use this in a 'Million-Dollar > Question' sort of way, *every* participant will be > trying to be first. 90% simultaneous? > > The commercial system mentioned sounds like it does > poll every remote individually -- in which case you > could have the remote merely record how much time > has passed between the button press and the last > poll. The base station can use that to determine > which button press was actually first. From my extended education while a youth one of my 'courses' was Jepoardy with Alec Trebec. Since I probably spent more time watching that TV show than any other single course (am I really admitting this ?) I always remember the contestants who whould have their hand above the lectern making violent motions when pushing the button. At the same time they would be upset that their button presses did not seem to register. I always assumed there was a time delay so that the person would press a button and some time would pass before anything was recognized and the buzzer went off. If you have 30 kids in a class room trying to answer a question they will deffinately notice the 0.4 seconds between a button press and a completed scan. That is why an 'instant' response that a button was pressed, could be a seperate receiver, so the people know the exact time as compared to their button press. As an added feature, you could even put in a display on each device that lit when pressed and showed the posistion in order for that unit and the time between their press and the winner. like, you were #4 and 0.001 seconds behind #1 Dave |
|
There is one issue that I do not beleive has been addressed with this applications protocol - if it has please forgive me. For each question there should first be an enable or "Question ready" transmission from the master terminal to 'reset' all of the slave units. This would then allow you to use the time elapsed from receipt of the "enable packet" internal to any individual slave as the response time. Each unit could be polled one at a time to see if it has the correct response. When any unit returns a correct response then all units are sent a disable or 'Give up' packet. Further optimization could be to stop polling during an 'enabled cycle' units who answered incorrectly. Also be sure to latch each slaves input to an off state the first time any button is pushed for any given question cycle (to prevent changing answers) I think the use of red, green, and amber LED's on each unit to display enabled, disabled, and 'choice made' status (statii?) would be a good idea, also. A sample exchange using this method might go something like: // three slaves, correct answer is 'C' MASTER: allUnits,enable //a question has been posed, all units start their timers MASTER: slave01,answer? SLAVE01: notYet MASTER: slave02,answer? SLAVE02: notYet MASTER: slave03,answer? SLAVE03: notYet ... MASTER: slave01,answer? SLAVE01: notYet MASTER: slave02,answer? SLAVE02: D MASTER: slave03,answer? SLAVE03: notYet ... // slave02 is no longer polled because they are dumb MASTER: slave01,answer? SLAVE01: C MASTER: slave03,answer? SLAVE01: C MASTER: allUnits,disable MASTER: slave01,time? SLAVE01: 65536 cycles MASTER: slave03,time? SLAVE03: 65535 cycles Thus slave03 was the winner with the first correct answer. Of course the above example was stylized - actual packets could be just a few bits, with the exception of the time-elapsed response. Again, if any of this has already been covered I apologize. -- Best regards, Patrick Griffin www.RedBinary.com |
|
|