You're inquiring about some fairly complex issues and
without better specification of what the questions are and
what the variables and configuration options are, it's hard
to come up with suggestions.
Crystal timing drift between sets of crystals is usually
difficult to estimate without having measurements of
the individual units. This is because the oscillator circuit's
engineering has some effect on the crystal oscillation
frequency, and because there's intrinsic variability in the
stability and frequency of timing of the crystal oscillators
themselves. Generally one will buy crystals or
crystal controlled oscillators with an accuracy specification
of so many parts per million maximum frequency error
over a specified range of operating conditions
(age, temperature, humidity). Often the PPM error of
the nominal oscillation frequency is somewhere
between 100PPM and 25PPM over age and temperature
for many inexpensive commercial units. Individual samples
of these oscillators are deemed working if the frequency
they generate is anywhere within this specified error band.
However any individual unit will likely have some base error
that is its 'normal' error relative to the nominal frequency,
and it will tend to repeatably oscillate near that repeatable
offset frequency. It will then drift in frequency relative to
temperature variances, and also the drift and random
short term error will increase as the unit is subjected to
instability due to being newly powered on before it
stabilizes, due to abrupt vibrations, abrupt changes in
temperature, etc. Over a longer time once a stable
environment is created after minutes or hours of time,
the frequency will become more stable and then tend to
stay at its current value showing only very slow (months,
years) drifts if the operating conditions / environment do
not change.
Hence you can pretty much accurately predict the
accumulated time error of a set of crystal controlled timing
devices because unique to their particular oscillators the
error will be mostly stable and predictable, and the error
will not usually vary much once you know the value for
the units. Hence you can say that "unit #3 has a clock
drift of -28 seconds per week", or "unit #7 has a clock
drift of +52 seconds per week" etc. and program in
compensations relative to the mostly fixed individual errors.
If the units are GPS connected, however, it seems sensible
that they will reset their real-time clocks frequently
based on the GPS time broadcast which will maintain
all units' clocks in near perpetual perfect accuracy
so long as they can frequently correctly receive the
GPS signal.
As for modeling the transmit / receive error situations
related to signal attenuation, noise,
multiple active transmitters, et. al. I'm afraid you'll either
have to deal with a very simplified "educated estimate"
of reliability, or be prepared to create a detailed analytical
model of the various variables (signal power, antenna
pattern, receiver sensitivity, RF noise in the bandwidth,
interference from multiple units, signal modulation type,
packet structure, packet length, bit rate, presence of any
type of integrity parity/checksum/CRC, presence of
any forward error correction encoding in the data,
probability of how many transmissions will overlap based
upon transmission timing / frequency / length, possibility
of signal obstruction by intermittent material movements,
possibility of battery depletion, possibility of units failing
to receive GPS temporarily, possibility of
software/hardware error causing units to reset or lose
some of their timing / time data, etc. etc.).
It's not all that complex to model the system fairly
accurately if you know the details, but if you're so short
on time / expertise to invest, and may not be privy to all
the technical data required to model the system, it's
a difficult prospect to get more accuracy than a rough
initial guesstimate.
In a unidirectional communication,
redundancy of transmission, and presence of forward
error correction information will help reliability greatly.
If you can devise to schedule the transmissions to occur
as far apart from each other in time as possible, that'll
help eliminate the opportunity for errors due to multiple
simultaneous transmissions.
The best situation would be to ensure GPS based time
clock resynchronization of all tag units at least every couple
of days, and allow each node a unique real time clock
interval of a certain hour, minute, and ten second window
in which to transmit. Then ten nodes could transmit
in sequence each over its own 10 second period and the
whole set would be received withon 100 seconds. I'm
guessing that 10 seconds is long enough for each node
to transmit all its data at least two or three times for
redundancy in case unrelated receiver noise or fault
causes a reception error for one of the transmissions.
If node battery life is suitable to allow such retransmissions
then they'll add a good amount of extra reliability to the
system.
If a 10 second window is too long for your aplication you
could shorten it to something like 1 or 2 seconds, though
of course you'd have to make sure the units synchronized
their real time clocks often enough that they're each
always within 1 second of the precisely correct time,
which probably means taking a GPS time fix at least once
or twice a day if their clocks are quite prone to drift as
many are.
Ensuring the whole set of nodes transmits their data
redundantly perhaps 10 minutes apart from the primary
scheduled time will help improve reliability in the case
that the main receiver or its computer has a fault and
needs to be quickly rebooted / replaced or whatever.
