Nrf24l01+ and RF24Network

Hi, I hope someone can help me with a problem that I don’t seem to be able to figure out. I have been trying to create a small network with these Nrf24l01 modules using RF24Network examples at https://tmrh20.github.io/RF24Network/examples.html helloworld_rx.ino and helloworld_tx.ino . I have managed to get 2 TX’s sending to a single RX unit all on Uno’s and a Nano and can see the data printed out in the RX monitor which is great but both TX’s are sending same struct payload_t structures with slightly different data but in the real world I wish to connect 4 TX’s all sending different data struct’s and have a problem sorting out the data to display on a small TFT screen at the press of an appropriate button, I have put an ID into the data struct so I can see where the data is coming from but if each TX is sending different types and length of data I can’t see how I can sort it.

In short I wan't to send varied types of data from 4 different units to one receiver, then store it in appropriate variables ready to display.

I must admit I’m not the sharpest knife in the draw and a little long in the tooth, but I have not been working with Arduino and wireless for very long, so I hope someone can help.
Peter

You could let the 4 slaves send to different addresses and display the packets according to the pipe they were received on.
This will work for up to 6 clients.
Different packet sizes are no problem if you enable dynamic payload size.

In my applications I use byte id's (with a common 4 byte brefix) and the following structure:

typedef struct Packet_s {
  byte Type;
  byte To;    // nodeRemote
  byte From;  // nodeLocal
  byte Num;   // incrementing packet id
  byte Data[28];
} Packet;

Thanks for the fast reply Whandall

Whandall:
You could let the 4 slaves send to different addresses and display the packets according to the pipe they were received on.

Not too sure what you mean by this.

This will work for up to 6 clients.
Different packet sizes are no problem if you enable dynamic payload size.

This sounds promising but have never used it, I try to keep things as simple as possible :slight_smile: but I shall do some research. Many thanks

The chip signals the pipe it received the packet on, the slaves can use different addresse hence different pipes.
Look up how your library passed that information on reception.

With a packet header like the one I posted, you can use one pipe and multiplex by the From field.

I use both. :wink:

@Pwagg, do you really need a network? Perhaps it would be sufficient to designate one Arduino as master and arrange for it to poll each of the others (slaves) in turn? That way the master would never be confused about which slave it was talking to. And there is no practical limit to the number of slaves.

The pair of programs in this link are a simplified version of a system I have for controlling model trains.

...R

Thanks Robin that sound like a very simple solution (I like simple) Another idea I had was to put a struct containing an ID for the first variable followed by dummy variables for all I need, a couple of "floats" and a handful of "int's" etc and let each TX fill in what it needs leaving the others blank, then have the RX look at the ID and call a function to extract the data depending on the ID number and ignoring the variables not used, maybe not as elegant as the other suggestions but would it work OK, I may try it out when I have some more time.

The fixed field approach was my first try, but I felt soon how little flexibility it offers,
and it wastes databytes in the packet and hence bandwidth.

My current way to handle generic information

  • all nodes use a common header (type, to, from, count/addinfo)
  • nodes broadcast a description of their data record format from time to time
  • nodes send their data only record regularly, or on changes/events
    The description packet: standard header followed by one byte for each data byte. Single entities are described by their number in all bytes that belong to that entity, allowing easy formation of arbitrary length entities. There are 28 (0x1C) useable bytes behind the standard header, so the top 3 bits can be used to signal non-standard/special handling like unsigned, msb etc. A mechanism to propagate names/types/attributes for the fields could be added.
struct dataExample {
  byte one;
  int two;
  byte r,g,b;
  long three;
};

byte descBytes[sizeof(dataExample)] = { 1, 2, 2, 3, 3, 3, 4, 4, 4, 4 };

Thanks once again Whandall, I think more experiments tomorrow. I am a relative novice at programming and I have read all the documentation for rf24network but mostly fail to get the syntax correct, can you explain how to get info out of the header.

The mechanism I described works on raw packets, it does not use the rf24network stuff.

Sorry, I can not be of much help in that respect, I never used it.