Hey,
I want to transmit multiple signals from multiple transmitters to one receiver using NRF24L01. Please help how to do it. I tried using one array(to store multiple signals) for one transmitter but the problem is when signals from different transmitters will reach at receiver end how it will detect that which signal array is from which transmitter??
Please reply soon as it is urgent project..Thanks in advance 
how it will detect that which signal array is from which transmitter??
Your receiver is acting like a kindergarten teacher who allows students to yell out anytime they like. It is NOT possible to identify which device transmitted some data UNLESS the senders include an ID as part of the packet.
NRF24L01 supports 2 way comm's yes? So have the receiver act as the master and coordinate things -
slave 1, send me data
slave 1 sends
slave 2, send me data
slave 2 sends
:
:
slave 6, send me data
slave 6 sends
repeat.
Alternately, NRF24L01 also supports a "6 data pipe MultiCeiver",
learn how to implement that.
There might be a library for the Multiceiver, that's beyond anything I've tried.
All libraries if have seen allow opening up to six pipes at the same time.
Got a link to share?
I got my nRF24s working with this Tutorial
I suggest you use the TMRh20 version of the RF24 library - it solves some problems from the ManiacBug version
The pair of programs in this link may be useful.
If you are content for one Arduino to act as master and poll the other "slaves" in turn my code can easily be extended to do that.
...R
Look at the 'starping' example in the TMRh20 library. That allows multiple slaves to talk to one master. The master identifies the sender's ID by which pipe number was used. Each slave uses just one unique pipe.
Arctic_Eddie:
identifies the sender's ID by which pipe number was used.
Do you mean "pipe number" (0-5) or the 5-byte ID number?
...R
It returns the pipe number index, 0-5, that was used by the sender. It might have been 1-5 but definitely not the 40 bit value.
The master is set up to listen on all pipes and each slave sends on only one of them uniquely. The master knows who sent the message as the pipe number is returned in the function call. Essentially, it's the index of the pipe number in the master's array of pipes.
There is one limitation mentioned in the data. The high 32 bits of the full pipe value must all be the same and the low 8 bits must be unique. It is helpful to the programmer for the last hex/dec digit to match the index number and hence the returned value. For example, slave #1 would use pipe #1 = 0x?? ?? ?? ?? ?1 or pipe #n = 0x?? ?? ?? ?? ?n. The extra spaces are just for textual readability.
Arctic_Eddie:
It returns the pipe number index, 0-5, that was used by the sender. It might have been 1-5 but definitely not the 40 bit value.
Thanks for the clarification.
I have not used the system you have mentioned which probably allows a greater sense of "simultaneous" communication than my polling system. However the polling system is not limited to 6 slaves.
...R
I would use one pipe for announcements (without ack) that all modules use to publish their personal address and the master(s) listen to.
No polling and autodetection of any number of nodes with any address.
In a small environment (less than 255 nodes) a common prefix for all addresses is quite handy and RAM/EEPROM conservative.
That's true, the polling system works fine if the data is not coming in rapidly, overlapped, and from an unsolicited source. The unsolicited part is probably the most important feature. As long as the master initiates the transaction and only the addressed slave responds then your polling method and a pipe value unique to the slave will work fine for numerous devices. I suppose that if there is any doubt as to who is responding then an ID byte could be included in the data packet going both ways.
OT?
Is this the method you use in your train control system? When my Father and I built a huge HO gauge layout in the basement in Michigan back in the 40's and 50's it was just the case of turning up the voltage and hoping the polarity and track switches were set correctly. Until just a few years ago, nobody would have ever believed that an Arduino might be hiding in the train cab.
I would use one pipe for announcements (without ack) that all modules use to publish their personal address and the master(s) listen to.
Excellent idea and more food for thought.
Arctic_Eddie:
and a pipe value unique to the slave
I know I am being pedantic but it seems to me very unfortunate that many of the examples use the variable name "pipe" to hold the 40 bit address. It would be so much clearer if that variable were called nodeAddress (for example) so it is quite clear that it is a separate concept from the 6 pipes.
When you say "pipe value" in the piece I have quoted I presume you mean the 40 bit address. That is certainly how I have my programs organized.
As far as the train control system is concerned I have two systems with almost identical software. For my own use I have a battery and an Atmega 328 + nrRF24 in the locomotive. I have also made some units for my model railway club which control the track power of a traditional layout but replace the traditonal wired hand-controller with a wireless one. The wired and wireless controllers are interchangeable. The purpose is to eliminate the problem of tripping over wires.
The intention for my own system is to use a single master nRF24 to convey PC generated commands to a number of battery powered locos.
...R
Regarding pipes, I assume it started with the data sheets then continued on by the library writers. When first encountered, it took a little thought as to just what it meant. Like you, I wish a different term had been used.
On trains, very impressive method of controlling the system. Well done.