Which wireless platform?

I'm having trouble trying to decide which wireless platform I should use for a project I'm working on. I've had look at XBee/Zigbees, nRF24 and RFM95 LoRa modules in depth so far but I have some concerns.

The network will have a coordinator/master and up to 20 nodes that it will talk to. The majority of payloads will only be 4 bytes but I'd like to be able to send them reliably and without blocking. For example, I've been testing some RFM95s with the Radiohead library and between sending and receiving an acknowledgement it is taking 70ms. The code is also blocking which means the coordinator can only send one payload every 70ms.

The nRF24 modules have a limit of 6 pipes for transmission so a larger network will be difficult to implement as it will need collision detection as multiple nodes will be using the same pipe etc.

I'm thinking that a Zigbee mesh/star network may be more suitable but I'm not sure about network latency or whether it would have to ability to send multiple acknowledged payloads in a short amount of time. Does anyone have experience with these modules?

SamIAm93:
The nRF24 modules have a limit of 6 pipes for transmission so a larger network will be difficult to implement as it will need collision detection as multiple nodes will be using the same pipe etc.

It is a common misunderstanding to think the number of pipes imposes a limit.

Have a look at the second example (using the ackPayload feature) in this Simple nRF24L01+ Tutorial. The Master code can easily be extended to communicate with multiple slaves in succession while all the time just using 1 pipe. IIRC the round-trip time for a single message and acknowledgement is a few millisecs. With the master in charge there is no problem with data collisions. I am using this concept to control model trains.

In my experience the nRF24 is cheap and reliable and easy to use.

...R

Hi, might worth having a look on this question and answer: http://arduino.stackexchange.com/questions/29440/options-for-wireless-data-broadcasting-to-hundreds-of-nodes - using a master to “time” things seems to be a good way to prevent conflict.

Thanks for the replies, guys. I'll try to explain the design constraints a little more. The coordinator will be receiving 4 byte payloads through the serial port, from a PC that is running a script. The coordinator will relay the packets to the appropriate node/s. I need to have the ability to send a particular packet to more than 1 node with acknowledgements. I envision each node having a unique ID as well as a user-settable slave ID, with the coordinator keeping track of which node is set to what channel etc. I'd like to be able to send the packets through with some non-blocking code so I don't have to wait for acks before sending to the next node.

The other option is to send all the cue information from the script to each module so it knows what it's doing and keep them in sync with a heartbeat signal from the coordinator.

SamIAm93:
I'd like to be able to send the packets through with some non-blocking code so I don't have to wait for acks before sending to the next node.

The regular acknowledgement process (or the ackPayload feature) of the nRF24 is so fast that there is no need to worry about blocking time. It is also essential if you want to use the auto-retry feature in case a message fails to get through.

There is extensive behind-the-scenes error checking in the nRF24 and there is no need to get the slave to resend a message to prove that it was received correctly.

...R

Multiple modules may be set to the same address, though, which could cause ack collisions.

I could use RF24Network and let the coordinator handle the addressing I guess.

Do you have any experience with RF24Mesh? A self healing mesh would be ideal as long as the hops don't induce too much latency.

SamIAm93:
Multiple modules may be set to the same address, though, which could cause ack collisions.

Agreed. But you say you want acknowledgements so give each one a different address.

Giving several slaves the same address only makes sense if you don't need acknowledgements.

I could use RF24Network and let the coordinator handle the addressing I guess.

Do you have any experience with RF24Mesh? A self healing mesh would be ideal as long as the hops don't induce too much latency.

The Network is another layer on top of the basic system and the Mesh is a layer on top of the Network. They will inevitably slow the system down due to the extra communication involved. I would only use the Network where I needed to communicate from A to C via B because C was too far from A.

How many messages per second do you want your Master to send (to all the slaves added together)?

...R

I think I need acknowledgements from a reliability point of view.

The nodes will have a settable address that can be changed via 2 buttons and displayed on a seven segment display. This address will be changed periodically and some nodes will be set as the same address so they both/all receive certain packets.

The 4 bytes that the coordinator will receive via serial are a start byte (0xFF) a slave ID byte (1-30) a cue number byte (1-48) and a 9-bit cyclic redundancy check.

The slave ID byte determines which node needs to receive the message. As there may be more than 1 node set to the same address I can assign each node a unique address. The coordinator can keep track of which node ID is set to which slave ID and can swap the address byte out and send it to each relevant node.

With the error checking built-in to the library the CRC is probably redundant.

I think the most messages I would need to send at the same time (or close enough to the same time as you can't perceive the difference) is 5 or so, which shouldn't take more than 0.1s.

SamIAm93:
The nodes will have a settable address that can be changed via 2 buttons and displayed on a seven segment display. This address will be changed periodically and some nodes will be set as the same address so they both/all receive certain packets.

Why not design a system that is easy to implement given the available technology. Give each Arduino a different wireless address.

If you really need to change an identifier on an Arduino you could have a variable the holds an ID which can be changed at will and which can have duplicates. The ID can be included in the message.

If you explain what you are trying to achieve (rather than how you think it might be done) it will be much easier to make useful suggestions.

...R

I'm building a wireless firing system to fire fireworks displays. It will be an extension of a wired system that I built a few years ago that used wired RS485 communication. The firing software that we run outputs fire packets through the serial port. The coordinator will relay those packets as they are received. All the nodes will be identical in terms of hardware. We would like to have the ability to have 2 nodes set to the same address for easy symmetric firing. (i.e. set the outer firing points to the same channel as they fire together) The number of nodes, and the nodes used will differ from show to show and I hope to build 12+ nodes to begin with.

The second byte that the coordinator receives will be the intended address and any nodes that are currently set to that address need to receive that message. Does that make it clearer?

That makes things a lot clearer.

When you say "... to the same channel as they fire together" what is the maximum acceptable variation between the firing times?

I suspect, no matter how you configure your wireless systems, that it will be impossible to guarantee that they all receive a message.

And if you use any sort of acknowledgement system you will need to hold-off the firing event until all the acknowledgements have been received. But how is that possible without sending another message to say it is now OK to fire - which message might also not be received.

I reckon if you want things to fire together those things must be triggered by a single Arduino.

...R

The most nodes we would fire from at the same time (or as close as possible) would be around 5. The issue I had with the RFM95 modules was it was taking 70ms between sending a fire command and receiving an ack so when firing from 5 nodes there would be 280ms between the first and last one. If the RF24 modules are substantially quicker this may not be a problem.

The other option I’m considering is exporting the firing script from our software as a .csv and use Processing to send it through the serial port to the coordinator and it can give each node it’s cue numbers and firing times and keep nodes in sync by sending a heartbeat signal.

SamIAm93:
If the RF24 modules are substantially quicker this may not be a problem.

Like I said in Reply #1 the round trip time is a few millisecs.

…R

From what I understand, the master/coordinator would need to continuously open pipes to every possible node to keep track of the network. The nodes can't transmit to let the master know it's there unless the master is listening for it. Is that correct?

SamIAm93:
From what I understand, the master/coordinator would need to continuously open pipes to every possible node to keep track of the network. The nodes can't transmit to let the master know it's there unless the master is listening for it. Is that correct?

That is not the model in my mind.

Using either the first (simple acknowledged) or second (ackPayload) examples in my Simple nRF24L01+ Tutorial all of the slaves will always be listening and the master will send a message to each in turn. None of them needs to use more than 1 pipe.

I suspect you misunderstand the role of pipes. There is only 1 transmitting pipe and there is only 1 piece of receiver hardware. The 6 pipes allow the receiver to allocate received messages into different compartments depending on the address in the message. Imagine that the postman gives all the letters for an apartment building to the doorman. Then the doorman sorts them into different piles for the different residents.

Because there is only 1 receiver using multiple pipes cannot speed things up.

In your case the program in your Master could decide to send messages in succession to any or all of the slaves and in any order that suits your needs.

...R