6 sensors hooked up with RF to one receiver ?

OK lets says i have 6 motion sensors hooked up with 6 transmitter, and i want to have only one simple receiver with 6 leds corresponding to the 6 sensors., and if a sensor become active it ll send RD date to the receiver and lit the corresponding LED.

is it possible, what kind of transmitter should i get, and obviously which receiver capable of handling 6 differents signal, can i ID the the transmitters ?

Thanks for any advice Regards Jey.

This is possibly not possible using simple transmitters. What is to stop the transmitters broadcasting at the same time? What you probably need is some sort of network system and protocol so that data is transferred in an orderly manor. Look at things like Zigbee and Xbee

ok thanks for the inputs and would it be possible if the transmitters arent broadcasting at the same time ?

edit : oh and they only need to transfert small data like "on and off" status"

would it be possible if the transmitters arent broadcasting at the same time ?

If they were all on the same frequency then yes. But how are you going to synchronise them so they don't?

I don't see why you couldn't do this, with the understanding that some messages may get garbled.

For transmitters, you would need an arduino like a promini, ardweeny,RBBB, etc, with a transmitter like this http://www.sparkfun.com/products/8946 and whatever sensor you are reading to make a decision to send something.

For the receiver, the mating part http://www.sparkfun.com/products/8950

and virtualwire for all.

Program each transmitter to send a unique address as part of its message so the receiver knows who its coming from. If the format of the messages is short, like 2 bytes - one for the senders address (say 11,22,33,44,55,66), 2nd for 8 bits of status (FF,BB,DD,EE) representing the on state of 1 of 4 things with a 0), maybe a 3rd that is some manipulation of the first (1F, 2B, 3D, etc), then you could determine fairly quick that you have a good message or not.

OK great ! so i really need a mini controller for each sensor/transmitter...to encode a special recognition thing for the receiver. Nice. thanks a lot.

I don't see why you couldn't do this, with the understanding that some messages may get garbled.

The problem is that the garbling might sometimes turn out, quite by chance, to be a false message and then it all goes wrong.

Could also add in some time restrictions as to when each could transmit - use millis() and give each its own 10 second window or something. Or work up to more complicated protocols as you suggested earlier. Do a ring kind of thing. Instead of just transmitters, have a recevier on each also. #1 must see a message from #6, pause briefly, and then send its message. #2 must wait to see #1's, #3 must wait for #2, etc. If the main receiver is not seeing any messages, it sends a "reset comms" message to all, telling #1 to ignore missing data from #6 and send status. Course if you had 2 way comms, I suppose the main receiver could just query the others for status, and signal an error if one was not responding. Set up each transmitter with 8MHz promini running on 3.7V LiPO battery with 5v wallwart & max1811 charge control chip, if AC power goes down it moves to battery power.

This sounds like a fun project.

If the main receiver is not seeing any messages, it sends a "reset comms" message to all,

So at a stroke you have added receive requirements at all the transmitters and a transmit requirement at the receiver. This sort of thing is very similar to network protocols of old, only with the added entertainment of a radio link and the possibility of going out of range or receiving a corrupt message.

This sounds like a fun project.

Not exactly my idea of fun when you could do it with an Xbee to begin with.

The "Mode S Squitter" method may work here.

Each transmitter simply blurps out its message every m +/- n milliseconds, where n is a random number. They do not attempt any CSMA nor do any listen before transmit, therfore no receiver is required at the transmitters. The scheme is reliable at low duty cycle, for Mode S the squitters are a fraction of a millisec and m +/- n may be typically 1000 +/- 200 millisec.

This is how ADS-B works on airplane transponders. In case two "intruders" happen to have their clocks nearly synchronized, each one rolls the dice to randomly determine how early or late to transmit, so collisions are rare and do not repeat. There is no "master" and intruders may freely enter or leave at any time. It can work under a load of over a hundred transmitters in an area.

The receiver has to listen and decode squitters, discard any garbled squitters, and keep the freshest data from each address.

This should work well for you depending on choice of M and N.

N needs to be many times the length of one transmission. M should be several times N. The shorter M and N are, the more often you can get sensor updates, but the collision rate goes up.

The faster you transmit, the better. Mode S transmits packets with a payload of 54 or 112 bits at a a rate of around 1 mbps which is why it supports so many non synchronized transmitters at very high reliability. For only six sensors 1000 +- 200 mS should work fine if your packets are shorter than 1 mS and you can stand 1/2 sec average delay.

BTW just as in CSMA there is NO LIMIT on the maximum delay. Using example above the worst case delay is 1.2 seconds until the first squitter. If the packet is 1 mS long there is a 0.6 % chance of collision, in whihc case an average of 1 sec is added to the delay, and any motion event shorter than that may be missed..

But you could hit the lottery twice in a row. Or more. The chance in this case of having 4 collisions in a row is less than 1 in 1.3 billion. But it could happen, and you'd be out of data for as much as 5 seconds and would miss an event that started and ended during that time.