Ethernet shield + NRF24L01 network running

Hello All

For the past 4 weeks I have been mashing wires and sketches together trying to get a “home” network working. I started out with the RF24_Master library and got 4 NRF boards talking to one receiver. I wanted to jump to the next level so I added a LCD display on the receiver to display the incoming time stamps. I changed one of the nodes to send data from a temp probe in my dining room about 22 feet away. Success. I wanted to move off the 4 line display because of limitations. Searching the internet I found this site

http://shanes.net/how-to-use-an-nrf24l01-rf24-with-an-arduino-ethernet-shield/

that meshes together an Ethernet shield with the NRF boards. More wire, code meshing and dragging out my old college HTML book, I managed to get the same data that is displaying on my LCD display to display on a web page. Great Success.

So the next step is to figure out how to get past the 6 node limit!!

Thanks

John Frankforther

LCD.jpg

johntech2011:
So the next step is to figure out how to get past the 6 node limit!!

Are you referring to the 6 pipes in an nRF24 ?

You could communicate between a master and many slaves using a single pipe on the master. I am using that system to control model trains.

The pipes only come into play if the master needs to receive a number of messages simultaneously.

...R

Hi Robin
I guess from what I have been reading I thought you could only get/have access to 6.

I am setting up a home network with sensors around the house for temperature and possible water in the basement. If what you say is correct , how would you know which sensor you are reading from?

Also right now I am only receiving 1 piece of data from each node. I need to figure out how to send, say temp and detect an open/closed switch from the same node.

Thanks for any information

John

johntech2011:
how would you know which sensor you are reading from?

I would not read from the sensors, I would let them send and receive their messages.
Part of the message would be the id of the sending node.

   // if there is data ready
    uint8_t pipe_num;
    if ( radio.available(&pipe_num) )
    {
      // Dump the payloads until we've gotten everything
      unsigned long got_time;
      bool done = false;
      while (!done)
      {
        // Fetch the payload, and see if this was the last one.
        done = radio.read( &got_time, sizeof(unsigned long) );
        //----
        // Spew it
        printf("Got payload %lu from node %i...", got_time, pipe_num + 1);

Here is the section of the sketch that gets the data from the node. It gets the pipe_num and the got_time which is the data sent from each node. How would I set the up data structure "got_time" to be able to send/receive more than just a pipe number and time stamp. ?

John

You do not receive a pipe number, a packet will be received by a pipe.

Define a structure that holds all you information, keep its length below 32 bytes,
send the structure and receive it.

radio.read(&myStructure, sizeof(myStructure));

The pair of example programs in this link are derived from my model train system. The idea is that the master calls each slave in turn and the slave sends its data as part of the acknowledgement process.

Each slave will have a different ID. It is unfortunate that most of the nRF24 examples use the word "pipe" for the name of the variable holding the ID number.

By using the master to poll the slaves one at a time you eliminate the problem of overlapping transmissions and there is no confusion about which slave is replying.

...R

Whandall:
You do not receive a pipe number, a packet will be received by a pipe.

Define a structure that holds all you information, keep its length below 32 bytes,
send the structure and receive it.

radio.read(&myStructure, sizeof(myStructure));

Would all my Nodes have to send the same data structure so the receiver will know how to decode it?

Say node 1 is sending Temp and Humidity, Node 2 is sending light, switch open/close and temp sensor.

Would I just have an empty variable for node 1 as opposed to node 2?

Could you possible give me and example how I would set up myStructure and send it?

Sorry for so many questions but the only examples I have seen are just sending & receiving time stamps.

Thank you!!

John

One solution is to include some identifiers in the message. For example T:18.3, H:87 or S:0 and then the receiving Arduino will be able to figure how to treat the values (T = temp, H = Humidity, S = Switch etc). This has the advantage of making the data definition separate from the identity of the nRF sending it.

There are probably a dozen other options.

...R

Robin2:
One solution is to include some identifiers in the message. For example T:18.3, H:87 or S:0 and then the receiving Arduino will be able to figure how to treat the values (T = temp, H = Humidity, S = Switch etc). This has the advantage of making the data definition separate from the identity of the nRF sending it.

There are probably a dozen other options.

...R

Robin
That is a good idea. So how would you set that up? I might have the following data to send:

R: room of the house or node
T: temperature
H: humidity
L: 1= 0n and 0= off

sData[0]=R:B (basement)
sData[1]=T:70
sData[2]=H:48
sData[3]=L:0

then do a radio.write(sData, sizeof(sData)); I'm guessing that will send all the data to the receiver? If that is correct then I would have to some how decode that data at the receiver so I could display it on my LCD display or web page. How do I calculate how many bytes my data is so I don't go over the 32 byte limit?

That is what is so confusing! The sketch I currently have running NRF24_master(starping) has the nodes set up so that each has their own node number and read/write pipe address.

So what you are saying is I only need 1 address but each node is numbered? Is the "node number" hard coded?

John

I would declare a structure that holds and identifies the data and the sending node, something like

typedef struct sPacket {
  byte packetType;  // groups the sensor packets
  byte sensorId;
  byte roomId;
  int temperature;
  int humidity;
  bool lightState;
} Packet;

Packet mPack;

// init
mPack.packetType = 'S';
mPack.sensorId = '1';
mPack.roomId = 'L';

// variable data
mPack.temperature= 223; // in 10th °C
mPack.humidity= 340; // in 10th %
mPack.lightState= false;

radio.write(mPack, sizeof(mPack));

I would use dynamic payload length if the packets are different in length.
(radio.getDynamicPayloadsize(); gives the length).

For the one way communication (sensors to concentrator) you only need to know the address the concentrator is listening to.
The sensors do not need a node-id if they are never addressed.

If you want to have personal addresses for each node, you could pick a common 4 byte prefix
and use the node id of the node (stored in EEPROM?) as the LSB.

Whandall:
I would declare a structure that holds and identifies the data and the sending node, something like

typedef struct sPacket {

byte packetType;  // groups the sensor packets
 byte sensorId;
 byte roomId;
 int temperature;
 int humidity;
 bool lightState;
} Packet;

Packet mPack;

// init
mPack.packetType = 'S';
mPack.sensorId = '1';
mPack.roomId = 'L';

// variable data
mPack.temperature= 223; // in 10th °C
mPack.humidity= 340; // in 10th %
mPack.lightState= false;

radio.write(mPack, sizeof(mPack));



I would use dynamic payload length if the packets are different in length.
(radio.getDynamicPayloadsize(); gives the length).

For the one way communication (sensors to concentrator) you only need to know the address the concentrator is listening to.
The sensors do not need a node-id if they are never addressed.

If you want to have personal addresses for each node, you could pick a common 4 byte prefix
and use the node id of the node (stored in EEPROM?) as the LSB.

A couple more questions for this evening and I will have to re-evaluate my sketches to see what I need to change. I'm trying to understand how the structure is layed out and how to use it in my sketch.

  1. The receiving node, "concentrator" will get the data from the sending node by:
if ( radio.available(&pipe_num) ) // pipe_num being the node you want to get the data from?

--
--
 radio.read(&myStructure, sizeof(myStructure)); // get the actual data

Am I correct there?

  1. What does this represent?
    byte packetType; // groups the sensor packets
    byte sensorId;

I get the rest for room, temp, humidity and light.

  1. In the starping sketch he is using 5 talking pipes and 5 listening pipes all with different addresses. So I only need 1 address for talking and listening and the node number I want the data from? I am trying to think why I may need 2 way communication between the send and receiving nodes. I would like to make that available if needed in the future.

I would like to thank both of you for replying? I am working on a home automation system from scratch and trying to learn as much as possible. That way when something breaks I know enough about the code to troubleshoot it and fix it. I may have more questions later, if you don't mind answering, as I clean out the stuff I don't need from the current sketch I'm working on. Memory has become a premium commodity while meshing the Ethernet shield and the NRF board together.

John

  1. Yes, you will get the data from each sensor with code like the on shown (add a call to radio.getDynamicPayloadLength() to get the sent length in case of different sized packets).

  2. I use packetType in my system to distinguish between different packet streams, if you only have one stream, you can omit it. sensorId is the sending sensor, roomId its location. This information is static and you only have to inititialize it once, the dynamic data gets filled in fresh before each send.

3a. For a strict one way communication, you only need one address. The receiver listens to that address, the sensor nodes all send to it. Acknowledgements can be used without problems (if the sending node really wants to know that its packet made it) because only one pipe will listen to that address and issue the acks as needed.

3b. If you need a back channel, you could give each node a personal address, for instance with the prefix plus node-byte schema. This mode would change the operational mode of the sensors from pure PTX to PRX with sprinkled in switches to PTX to fire the announcements.

3c. An alternative methode for passing data back to the reporting node would be to use the acknowledgment payloads. But because the data has to be preloaded, the 'answers' will be one packet late.