Did you have some particular form of 'data' in mind? On/Off signal? Fixed-width pulses? Variable width pulses? Analog voltage? Asynchronous serial data? Synchronous serial data?
all this hard work has been done for you, many times even. There's a lot of different network protocols out there which have been thoroughly planned to cover every possible sequence of events. How do you choose?
In my personal experience, your biggest challenge will be in "error control and recovery". If you have determined a message from any device is corrupted and needs to be resent, how does that work.
Sorry that I missed that important detail. I plan to send short words. Perhaps three or four bytes, at a high rate.
And you also missed the important detail of what you mean by 'high rate'
What I am struggling with, when I look at the diagram in the Original Post, is how the devices can be connected together. It is all very well to join them with squiggly lines in a diagram on a page - but the real world needs something a bit more substantial.Are you aware of the Mesh library for nRF24L01+ wireless transceivers. I have not used it but it seems to have the characteristics you are looking for....R
I2C can do what you want. It allows for multiple masters and collision handling (bus arbitration).
Only few controllers (Due?) have two I2C buses.Every single byte is acknowledged, in hardware. If not, the transmission terminates with an error. A newly plugged node can broadcast a message, telling its address to all other nodes.