Go Down

Topic: How to transmit multiple signals from multiple transmitters with NRF24L01+ ? (Read 1 time) previous topic - next topic

Manisha15

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 :)

PaulS

Quote
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.
The art of getting good answers lies in asking good questions.

CrossRoads

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.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

CrossRoads

There might be a library for the Multiceiver, that's beyond anything I've tried.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

Whandall

All libraries if have seen allow opening up to six pipes at the same time.
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

CrossRoads

Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

Whandall

Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

Robin2

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
Two or three hours spent thinking and reading documentation solves most programming problems.

Arctic_Eddie

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.

Robin2

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
Two or three hours spent thinking and reading documentation solves most programming problems.

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.

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.



Robin2

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
Two or three hours spent thinking and reading documentation solves most programming problems.

Whandall

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.
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

Arctic_Eddie

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.

Arctic_Eddie

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

Go Up