options for wireless data broadcasting to hundreds of nodes

Question

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.

Answer 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.

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.

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,