Wireless button/keypad

Started by Mada Jimmy October 20, 2004

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.




In a message dated 10/20/2004 10:34:39 AM Eastern Daylight Time, m...@polman.astra.ac.id 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 ...




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, Im 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?

 

Its 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.

----- Original Message -----
From: Phil
To: p...@yahoogroups.com
Sent: Thursday, October 21, 2004 8:05 AM
Subject: [piclist] Re: Wireless button/keypad


--- In p...@yahoogroups.com, "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.



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