Wow!, That is a lot of input, Thank you all!
Ok starting from the top:
you said 220m? sensors could be in 400m range? line of sight?
It would be 80 at most, and the general use case would be within 100m, however I am hoping to design in some margin, they will be in a flat field, with some burned shrubs
Pinging the nodes to request data may be problematic, Can you have a mains powered aggregator/gateway that would collect somewhat randomly timed node transmissions at a site, and then do a drive-by-query of that at a higher bandwidth?
Can you add a solar panel to each node, and only try to collect data when it is sunny?
I can definatly have an agregator node, even using much larger batteries (say 3x 18650 cells), however not mains powered, Solar panel is unknown, as the area may have dust storms, still the sensors would need to talk to this aggregator.
The nodes have a unique serial number programmed for identification.
What is the application?
reasonable to assume that you can transfer 2kBy in 8.6 seconds of TX time or less which would be an effective bit rate of ~2kbits/second net. It only gets better from there if you can transmit and shut up even faster.
if they detect the collection unit's transmission would they transition into a mode where they communicate their data with the collector over the next few seconds to allow all of the nodes time to transfer their data.
The application is ground water, salinity and composition sensors that are driven in to the soil. and are built to be both long lasting and fairly cheap.
If I go with the above suggestion of an aggregator, then a longer receive window should be possible, they are running off watch crystals, so accurately timed receive windows for the agregator should be possible.
To the others, I have internal timers that I can use for arbitration should 2 conflict, however if there is an existing protocol I would probably trust that more than my own dreams,
As for with no arbritation node, My previous experience with multidrop RS485 was if the Id packet was garbled, the base node sent back an error, and the effected nodes xor'ed there timer value by there ID and waited that long. and tried again.