Anthony Clay  wrote:


> The main idea is to know how long the button was pressed,
> and on what transmitter.
> [...]
> The problem that is kicking my butt is contention.  If two transmitters
> are triggered simultaneously, no good can come.

I don't think contention for such a small data package is going
to be a problem, but if you must not miss events and the frequency
of events wrt to time is large, then consider:

An event transmission consists of a packet containing:

- the id of the device
- a timestamp (or similar--e.g. a counter)
- length of the button push (or whatever
     payload you require)

Now, since you must program each device with a unique id
anyway, include a hash function in its programming
that maps its id into a sufficiently large delay space.  For
example, multiply by some "large enough" prime, mod by
another.  Use that result as a delay for multiple transmissions.
Even 2 transmissions will reduce collisions dramatically.

Now, since the id and timestamp form a unique event identifier,
your receiver simply discards any events its already seen.  The
history list for this operation only has to be long enough to
handle the longest delay times the number of transmissions
from a device.

This solution lets you adjust for your real-world use by simply
changing number of transmissions or hash space size across
the board.

Note that this doesn't *guarantee* that no packets will
be missed--that would require an acknowledgement channel
or collision detection--but it would provide high confidence.
Your choice will depend on the relative cost of missing a
packet.

> I also thought of having the PIC send the signal multiple
> times at random intervals, to overcome the odds.  But the
> practicality of this approach diminishes quickly as the
> number of transmitters increases

I'm not sure why this is so.  But if there is a reason, then the
above solution might not work.  Would you clarify?

  -greg