Is this still an issue if it's low power nodes in a mesh network that has infrequent
overlap and a shared system that pre-emptively mitigates this with geolocation data?
If you don't do synchronization, then you just have a bunch of independent transmitters that're transmitting roughly the same program. -ish. Sorta.
Suppose you put an RDS/RBDS subcarrier under the audio, so receivers can display metadata or whatever. If a given receiver drives between transmitters, or if FM capture and phasing effects mean it's constantly bouncing between transmitters, then it corrupts the data frame(s) being transmitted at the time.
Or if the desynchronization is more than about 20ms or so, it can be audibly annoying to the listener, disorienting and unpleasant if it happens too often. (We've all probably experienced a phenomenon when creeping forward at a red light, the audio fades, and comes back, and fades again. Same effect, but imagine the program glitching back and forth a bit each time because every few inches, the capture effect switches sources.)
If you synchronize, then you have effectively one transmitter with a bunch of antennas. The program is exactly the same except for microsecond-level discontinuities when moving between transmitters, and that's not enough to corrupt either the subcarrier data or the audio. (In the creeping-forward scenario above, it would behave exactly like a normal radio station -- fading and restoring, but not glitching.)
Now, in Europe, they do the many-transmitters-same-audio thing, but they do 'em on different frequencies, and use RBDS to inform the receiver of all the alternate frequencies (AF list) carrying the same program. When RSSI on the current signal drops below a threshold, the receiver checks the others, then doublechecks their RBDS program identification (PI field) to make sure they really are the same program, then selects the strongest one and makes the switch. This only happens once in a while though, say 10-30 minutes as you drive through a valley, not several times a second, so the timing glitch isn't problematic.
Suppose you put an RDS/RBDS subcarrier under the audio, so receivers can display metadata or whatever. If a given receiver drives between transmitters, or if FM capture and phasing effects mean it's constantly bouncing between transmitters, then it corrupts the data frame(s) being transmitted at the time.
Or if the desynchronization is more than about 20ms or so, it can be audibly annoying to the listener, disorienting and unpleasant if it happens too often. (We've all probably experienced a phenomenon when creeping forward at a red light, the audio fades, and comes back, and fades again. Same effect, but imagine the program glitching back and forth a bit each time because every few inches, the capture effect switches sources.)
If you synchronize, then you have effectively one transmitter with a bunch of antennas. The program is exactly the same except for microsecond-level discontinuities when moving between transmitters, and that's not enough to corrupt either the subcarrier data or the audio. (In the creeping-forward scenario above, it would behave exactly like a normal radio station -- fading and restoring, but not glitching.)
Now, in Europe, they do the many-transmitters-same-audio thing, but they do 'em on different frequencies, and use RBDS to inform the receiver of all the alternate frequencies (AF list) carrying the same program. When RSSI on the current signal drops below a threshold, the receiver checks the others, then doublechecks their RBDS program identification (PI field) to make sure they really are the same program, then selects the strongest one and makes the switch. This only happens once in a while though, say 10-30 minutes as you drive through a valley, not several times a second, so the timing glitch isn't problematic.