1

Actually I'm using the RF24 Library mantained by TMRh20 (https://github.com/TMRh20/RF24). I'm trying to get some type of direct communication between multiple modules working, but I don't want to use the RF24Network Library (https://github.com/TMRh20/RF24Network) which creates a mesh of connections.

I currently have several arduinos that have to communicate between them. Every arduino has its own address starting from 0x0001 (0x0000 is for a main module that manages everything) and finishing to 0xFFFF. I want to directly communicate between the two NRF24L01+ modules without any intermediator, because I don't have problems of distance.

The main thing that I want to be able to do is communicate directly not with just one module, but choose if I want to broadcast to all the modules in an area (I know that it can be done with range power modifications in the code) or talk with just one module.

What is the best way to do this type of communication?

  • I'm unaware of any broadcast method inside the NRF. You could just have all the devices have the same address, an use the first byte of data to indicate who it is for. Or have them all listen to their own address and a separate "multicast" address (e.g. 0xFFFF). These modules can listen to upto 6 addresses, so you could even create several subnets. Also see this related question – Gerben Nov 19 '14 at 16:40
  • Is there a reason you don't wish to use RF24Network? – Avamander Aug 17 '15 at 23:25
  • I have already tried using RF24Network and I don't want to use it for two specific things: 1. It creates a mesh and I don't need it 2. It is a very big library and for a 328 processor is too much if I have to keep also other big parts of program – Stefa168 Aug 23 '15 at 8:06
  • The RF24Network library would not provide a mesh, but a network layer over RF24 links. The RF24Mesh library (by the same maintainer) indeed provides a mesh. – sekdiy Apr 5 '16 at 10:55
1

Both of the Libraries you mentioned are well written. I've used both, but decided to write my own based those libraries. For me, the network libraries were written for their project and didn't really fit my needs. So I decided to write my own. I combed the internet for a bare bones NRF24 Library and found this one. This was my starting point. It didn't need the Arduino Core Library and handled all the SPI functions. Then I read the NRF24L01 datasheet several times, then read it again.

With that said, you can broadcast up to 6 radios at a time. Per the datasheet, the receiver knows which radio sent the packet. The STATUS register (0x07), should tell you who sent the packet:

STATUS Register 0x07

I was unable to get this working (I am still working on it), so for now, I send my packet as a struct:

typedef struct  {

uint8_t id;
uint32_t data;

}
Packet;

Packet pck;
pck.id = 2; // id of my second radio

Keep in mind when you program your Arduino as the receiver, you have to tell it who it will be receiving from. The transmitter and receiver have to be on the same RF channel, speed and same pipe. To choose who receives the packet may not work the way you think, but as I mentioned you can program the receiver to know who the transmitter was and code around it.

I would suggest you dig into the datasheet.

0

If you set pipe 1 to a common address (let's call it the broadcast address) anytime you send a packet to that address all the modules will receive it on that pipe! It's as simple as that, but you will not be able to use auto-ack (you will receive multiple acks, one per each receiver) and you can't also use ack payloads.

I wrote a series of blog posts on this modules and I'm going to keep writing on the topic.

0

You need to dig into the datasheet and read about ESB (Enhanced ShockBurst). This is technology that is integrated into the radios and allows for broadcasting and direct pipes. One of the limitations is that the mesh only works for up to 6 pipes, so be aware that this limits the number of devices that will be able to hear your transmission.

Another option is to have all the nodes listening on the same pipe, and then when node x wants to talk, he stops listening on pipe 1234 and starts writing to it. You would put some sort of addressing header in the payload section of the packet, then when all of the nodes receive that packet, they can check that address and see whether or not to process it. This might work well in your situation.

For example, if you have a packet that is sent on the communal pipe with a payload of [broadcast address,data] then your receiving nodes (those within "earshot") can receive the packet, see that it is a broadcast, then process the data. If you want to send to a single node, create a packet that has a payload of [destination node id,data]. When each node receives that packet on the communal pipe, they will check the destination, and when it doesn't match either their own address or the broadcast address, then they dump it. Only the intended receiver will actually process the data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.