I'm working on setting up a home automation sensor/control network that is secure and failure resistant. This includes using 2 master nodes for redundacy. I've already figured that RF24Network and RF24Mesh are not ideal for my purpous. So I'm trying to get familiar with the "simple" RF24 library. I got some of the basic examples working, but despite reading the documentation, and searching online quiet extencively, I have some questions remaining.
Lets start with a simple question: The GettingStarted example gave me a round trip of 17xx us, is this a typical round trip time for a 4 byte message? Just veryfing everything works as it should, with a broken arduino and the required cap, its been a challenge to get it up and running.
As for the workings, I'm getting confused on the addressing. As far as I can understand each pipe has an address, and nodes themselfs do not have an address or identifier of sorts. Is this correct?
This would mean that you typically need 3 times more addresses then nodes. And given that 5/6 pipes need to share the top bytes, a topology like this can "only" handle 256/3 = 85 nodes.
I've also seen an example where for a multi node network, each node listens to a pipe from the master that is named after the "nodeID" of the slave, and the master node only listens to a pipe with its name, but each slave is able to open a similar named pipe. Does this work? Or will there be issues if multiple slaves attempt to write at the same time? Will it then get no data, or wrong data?
If this NodeID = pipe method works, is it sensible to have two masters with antenna modules that can reach all of the (max) 254 nodes? Or will this cause issues?
Monitou:
Lets start with a simple question: The GettingStarted example gave me a round trip of 17xx us, is this a typical round trip time for a 4 byte message?
If that means 1700µsecs then that matches my experience - about 2 to 3 millisecs.
As for the workings, I'm getting confused on the addressing. As far as I can understand each pipe has an address, and nodes themselfs do not have an address or identifier of sorts. Is this correct?
This would mean that you typically need 3 times more addresses then nodes. And given that 5/6 pipes need to share the top bytes, a topology like this can "only" handle 256/3 = 85 nodes.
I can't make sense of what you have in mind. A simple diagram might help.
In many (most?) situations there is no need to use more than one address for every nRF24. The pipes are just a convenience to help identify where a message comes from. I just put a byte in my messages that identifies the sender.
Wireless problems can be very difficult to debug so get the wireless part working on its own before you start adding any other features.
The examples are as simple as I could make them and they have worked for other Forum members. If you get stuck it will be easier to help with code that I am familiar with. Start by getting the first example to work
There is also a connection test program to check that the Arduino can talk to the nRF24 it is connected to.
The Tutorial includes an example for a master and 2 slaves that can easily be extended to a larger number of slaves.
A common problem with nRF24 modules is insufficient 3.3v current from the Arduino 3.3v pin. The high-power nRF24s (with the external antenna) will definitely need an external power supply. At least for testing try powering the nRF24 with a pair of AA alkaline cells (3v) with the battery GND connected to the Arduino GND.
Robin2:
If that means 1700µsecs then that matches my experience - about 2 to 3 millisecs.
Yup, microsecond is indeed what I mean, so that's good I guiss.
I can't make sense of what you have in mind. A simple diagram might help.
Ok so let me clarify my statement of needing more addresses then nodes in a redundant topology. If the topology has as many pipes as nodes, this means each node is only accessable via 1 route. A soon as you add in redundancy, this means a single node is accessed by multiple pipes. This drastically reduced the max number of nodes in a network. Basic example of a (say 6 node) Fully Connected Network
The pipes are just a convenience to help identify where a message comes from. I just put a byte in my messages that identifies the sender.
So, this, combined with your linked tutorial led my to my 3th alinea in the starting post:
if the master uses
OpenReadingPipe(1,MasterAddress)
and there are many (>10) slaves. and slaves use
OpenWritingPipe(MasterAddress)
Does this work (I guiss so based on the linked tutorial. But checking to make sure I understand.) This would mean multiple pipes using the same address, so a non- unique way of connecting to the master node. What happens when multiple slaves send at the same time? Does the master get some data, but the data is wrong? Or no data at all?
Monitou:
If the topology has as many pipes as nodes, this means each node is only accessable via 1 route.
I don't understand that at all.
Each nRF24 has a single wireless device so it can only receive one message at a time. If transmissions on the same channel from several devices overlap they will all be garbage.
All the messages for the 6 pipes must come through the same wireless one at a time - hence I see little value in using pipes.
The idea of pipes can be a bit confusing. Think of them as 6 shelves onto which the mail for different residents in an apartment block can be placed. All the letters come through the same mail slot (the radio receiver listening on Channel N) and when they fall on the floor someone picks them up, looks at the name of the recipient (the address the message was sent to) and puts them on the correct shelf (the pipe that has been assigned the same address as the message) or shreds them if they are for a recipient who lives in another block (i.e. if they are for an address that is not assigned to any of the pipes on this nRF24)
Robin2:
All the messages for the 6 pipes must come through the same wireless one at a time - hence I see little value in using pipes.
This is like arguing sockets in the IP world don't add value, because the messages come over the same interface.
With the NRF you have a hardware packet classifier for six different communication channels.
Whandall:
You really should read the data sheet of the NRF24L01+ at least once.
Yea, forgot to mention, I had skimmed through it looking for addressing info before posting. But just had a more elaborate readthrough. And it does clear some things up, but also leads to more questions.
I don't understand that at all.
Ok let my try again with my topology argument: If you have n slave nodes, and you want each pipe to have an unique address. Any tree or star topology has n pipes. Starting from the master each slave connects to either a slave or the master directly, adding 1 pipe for each slave added.
Now if you want to make it failure proof you need each slave to connect not to 1 node, but to at least 2 nodes, using up addresses twice as fast, and with even more redundancy 3 times as fast.
All the messages for the 6 pipes must come through the same wireless one at a time - hence I see little value in using pipes.
First one:
I'm trying to embrace this statement, as it would make my life easier. But I can't help but wonder what issues it will result in. Theres two scenario's that I can't really figure out what would happen:
Slave1 transmit's msg1 to Master1, Master1 sends ack, but ack is not received.
Slave2 now transmits msg2 to Master1, master sends ack, ack is received
Slave1 Auto retransmits msg1 to master1, master sends ack, ack is received
Does this mean that master1 received 3 messages, and a retransmit will have to be delt with softwarematically?
Second one:
master transmits msg1 to slave1, and waits for ack
slave2 transmits msg2 to master1
slave1 transmits ack to master1
Will msg2 just be ignored and received once the ack is received? Or will receiving msg2 when waiting for ack screw up the ack waiting loop forcing the rf24 module to retransmit msg1?
Any other issues one may expect if the writing pipe of all slaves has a shared address?
Monitou:
Ok let my try again with my topology argument:
I think this is one of the misconceptions, the topology is a single shared medium.
Packets on the correct channel, with the correct address len and a correct crc
can be received if one of the configured (max six) addresses match.
Acknowledge can be controlled globaly, per pipe or per packet.
Up to three pipes can deliver data with the acknowledge.
Whatever node topology you define with the above building blocks is up to you.
Some prefer a rigid polled master and slave concept,
some prefer to use peers that communicate freely when needed.
Monitou:
Now if you want to make it failure proof you need each slave to connect not to 1 node, but to at least 2 nodes, using up addresses twice as fast, and with even more redundancy 3 times as fast.
First one:
I'm trying to embrace this statement, as it would make my life easier. But I can't help but wonder what issues it will result in. Theres two scenario's that I can't really figure out what would happen:
Slave1 transmit's msg1 to Master1, Master1 sends ack, but ack is not received.
Slave2 now transmits msg2 to Master1, master sends ack, ack is received
Slave1 Auto retransmits msg1 to master1, master sends ack, ack is received
Does this mean that master1 received 3 messages, and a retransmit will have to be delt with softwarematically?
While @Whandall and I might disagree about the usefulness of pipes that is just a matter of personal preference. My preference for avoiding them is mainly due to the sort of confusion they seem to cause which is nicely exemplified by this Thread.
Regardless of our preferences I have the strong feeling that you are over-thinking yourself into a dizzy spell.
You have correctly identified some of the complexities of wireless communication - there is a chance a message is not received and also a chance that an acknowledgement is not received.
The number of pipes is completely irrelevant as far as that is concerned.
One reasonably simple way to identify missing messages and repeated messages is to include a message counter within the message - for example count up to 16 and then repeat (assuming you don't expect more than 16 consecutive messages to fail). Then if the master receives message 2 followed by message 4 it can know that there ought to have been a message 3. Similarly if it receives message 2 twice it can identify that.