2

I would like to build approx 100 arduino devices that can talk to each other, I have a set of constraints that I'm looking to get some insight on :

  • all devices would operate within a 300 meter proximity of each other

  • the devices each need to broadcast some data (their speed and orientation from a gyro) to the rest of the devices in the group for storage

  • They need to update each other roughly every 500ms/1s
  • Some of the devices need to be added and removed from the pool regularly
  • The devices need to start broadcasting their data to the rest of the devices in the pool immediately when added (<1s delay)
  • The spectrum needs to be public & unlicensed

Which method of communication would you recommend? For the range, it seems like a 433hz RF transceiver and receiver would be appropriate or wifi could work but I have concerns about overloading the channels. Bluetooth seems like it has too long a handshake period and the range is too low.

Are there any other options I'm missing? What would be the best way to implement this?

Many thanks for you answers

Update : Data estimation

So the data payload I estimate consists of :

Speed (km/ph) : ok so this will be max 3 decimal numbers, so one short int should be enough here (2 bytes)

bearing : so this will be a standard bearing, let's assume between 0-360 so another short int should be fine (2 bytes)

Velocity : ok, so also a short (2 bytes)

Long : well this needs to be a 32 bit float so it's going to take 4 bytes

Lat : same as above 4 bytes

It's possible with some hackery I could combine speed, volcity and bearing into one short to only take 2 bytes. But let's assume I'm probably going to need 14 bytes, in best case 9.

  • 1
    nRF24L01+ with power amplifiers? Cheap on eBay... – Majenko Sep 20 '16 at 20:31
  • 1
    In fact, if they are always close enough to a neighbour you could scrap the amplifiers and go for the non-amplified version and run a self-healing mesh. – Majenko Sep 20 '16 at 20:42
  • Looked at Zigbee? – James Waldby - jwpat7 Sep 20 '16 at 21:48
  • RFM69 or talk2.wisen.com.au/product-talk2-whisper-node-avr? Just need to do some calculation to see how load the whole network will be. Need to consider messages clashing with each other... keeping the communication as short-as-possible might be the answer. – Talk2 Sep 21 '16 at 1:47
  • 1
    Re Message Payload : What about an extra byte for an identifier for the transmitter, this will be necessary when the nodes are two close to each other to be differentiated by LatLong. You only have around 5ms to collate the data broadcast it receive and store it, so you may want to look at optimised solutions rather than just high bandwidth solutions. – Code Gorilla Sep 21 '16 at 13:27
1

In terms of Radio, the RFM69 is a good option for range, speed and reliability at low cost. A board like this one https://talk2.wisen.com.au/product-talk2-whisper-node-avr/ would have all ready to go, just add your sensors.

The link can run on 433MHz, 868MHz or 915MHz band, which cover 99% of unlicensed/open frequencies worldwide.

Whisper Node

For the protocol/software you need to reduce the message as much as possible. As you mentioned, you could have 9 bytes for the payload if you "share" some bytes, which is the correct approach in this tight network. Add some 2 extra bytes for "operation/command", "sender" and "receiver". Additional to that, you need to consider the bytes added by the radio itself, like Preamble, Sync-word, Network ID, Length, CRC, etc.

RFM69 Frame

The biggest challenge in my opinion would be to not have the RF network flooded with messages, causing multiple radios to transmit at the same time and messages being lost.

Let's suppose you have a total of 20 bytes for all headers+payload per message. If your network is running at 80Kbits/sec (or 10KBytes/s), that would allow a maximum of 500 message/second (2ms per message) in a perfect scenario, without considering any kind of delay between messages.

Bring down to the real-world a 1/3 link utilization is a bit more realistic, giving you a bit over 150 messages of 20 bytes per second. In other words, if the network had an evenly message distribution a node would transmit a 2ms message followed by 6ms of silence.

Now, you can't count that 100 nodes would have perfect synchronization to send a 2ms message and stay quiet for exactly 998ms before sending a message again. There are so many variables which require you to have some sort of control.

One way of doing that is by using a pooling mechanism, where you have a "tick" or "clock" node, which is the only one allowed to talk without being asked. This node will be sending "pooling" requests, a small message with 1 or 2 bytes, containing a command and the destination address, for example: 0x99 0x0A, where 0x99 is the address of the node being polled and 0x0A is the command, like "send me the instrumentation readings, you have 2ms".

Now, instead of the node 0x99 start reading the sensors, it already have it all stored in memory and ready to go, sending the broadcast message to everyone interested. The node 0x99 will also start collecting the new sensor data and preparing the message, so as soon it'll be asked it's ready to go again.

This way you can control how noise the network is and also implement other commands to capture additional information if necessary, etc.

Another implementation would be similar to the old "Token-Ring", but I believe having a master would be more beneficial in this case.

Notes:

  • The RFM69 can go over 200Kbp/s, but only tests would tell the maximum reliable speed. I use 80Kbp/s to make maths easier.
  • Design your system so it would survive if a message is lost, like UDP packages, send it and "pray". Adding Ack and re-transmission is probably worst as it would slow down the whole cycle.
  • The radio also offers encryption, but it might take a few uS extra
  • If one node will be expected to receive every single message, bear in mind that it would have only a few milliseconds available to process the message and do whatever it needs to do before another message arrive. If you need to perform lots of processing/logs/control actuators you might need to delegate this task to other MCU(s)

Cheers,

  • Thanks for all the input. I really like your hardware, and think it's definitely the way to go. I am still struggling with the contention issue though. I like the master/slave, but I need all the nodes to have access to all the data from the other nodes. Also, the nodes in the pool will be swapped out fairly regularly, like one every two minutes or so, so it's highly likey the master will leave the pool and then one of the other nodes would need to take over it's responsibilities. – Simon Kenyon Shepard Sep 22 '16 at 15:07
  • Understand... the only thing you need to keep in mind is that you're going to have very little time after receiving a message to do something. About a master leaving, can you control that or it would simply shut-down? If you can control, the master can send a "command" back to the last sending node to take over. – Talk2 Sep 22 '16 at 23:55

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.