Re: Using garage door remotes as a voting system?

Mike Harrison wrote:
> On 9 Apr 2005 14:11:45 -0700, "Steve" <popmusic@xxxxxxx> wrote:
>
> >Thanks for the replies. I'd like to do this on as low a budget as
> >possible (under $1000?, under $500? :-)), and set it up for around
20
> >people to begin, with the option to expand. Audience members should
be
> >able to vote at the same time and shouldn't be counted twice if they
> >press the button twice.
> >
> >There's a keychain transmitter at http://www.automicro.com.tw/ that
is
> >"rolling code" which I understand means that it creates a unique
code
> >every time it's pressed. There's also a shareware program called
> >"girder" that I think I could use.
>
> Using keyfob type remotes as-is is not going to work reliably as
there will be collisions due to
> simulataneous transmissions. Although keyfobs usually send repeated
codes, the intervals are likely
> to be the same so it would not help the collision problem.
>
> What you need is for each transmitter to send the data several times
at random intervals, over a
> period of a few seconds.
> You need to do some statistics to work out the optimum timings based
on packet length, receiver
> timing requirements and number of users. Each transmitter would have
a unique address so the
> receiver could distinguish each user and ignore the repeats.
>
> I would suggest you look for a keyfob that uses the Microchip RFPic
12F parts, as you could change
> the firmware to do this, while still having a ready-made RF stage and
casing etc.
>
> You would need to write some code at the receiver end, but it would
not be especially complicated -
> it would just log each address received and the data for that
address.
>
> Typical data rates for a cheap hardware keyfob would be 1200 baud.
You need to send, say, 2 bytes of
> data (12 bits address, 4 bits vote, 1 byte for error checking, and a
few bytes of preamble to let
> the receiver settle down, so probably about 6-8 bytes total.
> This gives a packet length of about 65mS. Even for 20 users, this
means that if all timings were
> optimum it would take 1.3 seconds for all packets to get through. By
the time you have enough
> repeats to get good probability of receiving all of them I would
think you are well into tens of
> seconds if not minutes. This time would also scale nonlinearly with
more users.
> So you probably want higher performance RF stuff capable of
significantly higher baudrates - this is
> do-able but may need more expensive hardware - 100Kbit RF modules are
available, and the extra cost
> is mostly at the receiver so it may be feasible.
> I would say you probably want to be using FM, not AM for better data
integrity
>
> An alternative would be to have the fobs synchronise into defined
timeslots from an external master
> controller, however this adds the cost of receive hardware to each
keyfob.

On $500 the lot, by someone without the skills to do it?


NT

.