As far as we are concerned here, simulcast is the simultaneous transmission of a single audio signal over multiple different, geographically diverse radio transmitters operating on the same frequency. For the sake of brevity my explanation of how a simulcast system works will be limited to how it works using AllstarLink. There are different types of systems that accomplish the same task in different ways but we will not be going into them here. In all honesty, when you understand what is going on with this system, other types of systems become very easy to grasp.
So, knowing that simulcast uses multiple transmitters on the same frequency, using the same transmitted audio, most wonder how this is made possible? This is done through the use if GPS derived timing equipment that gets is time and accuracy largely from the highly accurate atomic cesium clocks in the GPS satellites. The signal from the GPS satellites is received by a GPS receiver clock that references itself to the GPS signal to maintain accuracy. These GPS clocks ensure that the transmitters carriers are locked to within 1 or 2 Hz of each other. Along with that, the clocks precisely time the receive audio streams for proper receive voting and timing of the transmit audio streams to the transmitters.
Now, with everything timed correctly the transmitters will have some areas where their signals will overlap each other. The image below is s rough depiction of a two site simulcast installation in theory.
Where all the accuracy and precision come into play is the overlap areas as well as moving from site to site while mobile. For the sake of simplicity, all my references will be for a simulcast system that is analog and uses Wideband 25 KHz channels. With Narrowband analog 12.5 KHz channels all the theory is the same but the tolerances are tighter.
Radio Simulcast Variables and tolerances
Radio energy travels at the speed of light which happens to be 186,000 miles per hour through a vacuum. this can vary a bit (slow down) when going through a medium such as the atmosphere but for our purposes, there is not enough difference to make a difference. For the purposes of simulcast, we can take from this and calculate that radio energy travels about 1 mile every 5.2uS. This constant is very important when it comes to overlap.
There is also the FM capture effect when it comes to Wideband. You can read more about it HERE. In short, the FM capture effect is when your receiver hears multiple FM signals but only the strongest signal gets demodulated by the receiver. You can commonly hear this when taking a long drive listening to your cars FM radio and hear two different stations on the same frequency popping in and out from each between each other. This is dependent on the bandwidth of the signal heard and its strength at the receiver. For our purposes here, assuming LMR (Land Mobile Radio) Wideband the FM capture effect occurs when one or more of the FM signals is 10dB stronger than the others.
When it comes to Wideband, in order to maintain intelligible audio in the overlap region we need to maintain a phase shift between all the transmitters of no more than +/- 30 Degrees, this works out to +/- 70uS. Knowing that radio propagation travels at about 5.2uS per mile we know that our acceptable overlap region is about 13.5 Miles between transmitters. In practice, you need some overlap so that you can move around the system and maintain communication but you want to minimize it as much as is practical. So, 13.5 Miles is the extreme and in my experience reducing the overlap to no more than 8 or 9 miles produces much better results.
The last component for acceptable audio in the overlap region is the deviation levels between the transmitters. This level needs to be adjusted to about +/- 0.2dB between the transmitters in a given overlap region. Knowing this, I adjust my transmitters using an AC RMS voltage measurement and use +/- .01 VAC RMS for my target for acceptable operation. I always advise using tighter tolerances due to the thermal expansion and contraction of components over time causing your adjustments to shift. This allows for these external forces to happen while maintaining acceptable operation of the system.
Knowing these variables, if you haven't already noticed. You can see how site placement, antenna types, antenna patterning, and transmitter output power will effect how good your simulcast system sounds in the overlap areas.
When first getting a simulcast system on the air, I recommend using relatively low power for all your transmitters and then drive test your system. Unfortunately, most people do not have access to coverage prediction software with Time Domain Interference prediction. This kind of software allows you to see with reasonable accuracy where the overlap areas will be along with areas of possible destructive Time Domain Interference. For those that don't have this software, drive testing and listening will be your main method of testing the overlap areas and making adjustments.
There are some exceptions when it comes to certain areas, one of these exceptions is mountain tops. Sometimes when you are on a high vantage point (not where one of your transmitters happens to be) you will hear transmitters far out of phase from others. This is because in this particular spot, you are hearing transmitters you normally wouldn't be hearing. Unfortunately, there is little to nothing you can do about this sometimes.
Simulcast Audio Delay and Synchronization
The audio that is delivered to all the simulcast transmitters originates from a single source, in our case that source is our host computer running Allstar and the Voter module software in Allstar. Due to the very inconvenient laws of physics, even though our intended transmit audio originates from a single source, it doesn't arrive at our transmitters at the same time, this is where transmit buffers come into play. The voter boards/RTCM's contain a certain amount of storage for a transmit audio buffer. The job of the buffer is to allow all the Voter Boards/RTCM's enough time to enable synchronization of the audio transmitted out all of our transmitters.
The setting in our Voter Board/RTCM's is for our TX Buffer is defined in audio samples. every 8 samples is equal to 1 millisecond, so 80 samples is 10 millisecond and 800 samples is 100 milliseconds. This setting should be set to 1/2 of the average ping time value to you longest responding transmitter plus about 50 percent more for padding to ensure you don't experience dropped TX audio packets to that site. You may be asking "Why half the ping time?" Well, this is because when you ping a device, the time it returns is the time it takes for the ping request to travel to the device and the response traveling back to you. Since the TX audio is only traveling in one direction, we only need to be concerned with half of the ping time.
Example:
Average ping time to longest responding site: 40 milliseconds
Half of that ping time: 20 milliseconds
additional buffer padding: 30 milliseconds
Voter Board/RTCM TX Buffer Length Value: 30 X 8 = 240 samples
My advice here would be to start out with a value of 1500 for your TX Buffer Length. Once your system is up and working you can trim this back if you wish. Remember, this buffer value needs to be the same at all your simulcast transmit sites.
So, now you know about how the TX buffer works, here is the rest of the story. These buffers once properly set, allow the devices to use the GPS time stamps applied to the audio packets, to line the packets up and ensure that the packet with the identical time stamp goes out at the same time on all the transmitters. For the most part, this is what you want to happen.
TX Audio Launch Delay
Sometimes, due to where a particular transmitter or transmitters are located you may have to shift the time in which a particular transmitter or multiple transmitters transmit their audio. This is accomplished by using this setting in the device:
19 - Simulcast Launch Delay (0) (approx 200 ns, 5 = 1us, > 0 to ENA SC)
The need for this typically occurs when you have one site that has a massive coverage footprint causing your audio in the overlap region between this transmitter and others to be out of that 70uS window. In this case, you kind of have to think backwards. If you have this one site covering a huge area which causes this situation, you need to add launch delay to the OTHER TRANSMITTER(S) that have smaller coverage footprints. The other transmitter(s) will then delay their audio so that it is back in that 70uS window of acceptability.
The above setting allows for an added delay in increments of 200 nanoseconds. This works out to a geographic shift of approximately 203 feet. a 200 nanosecond delay is a rather fine adjustment which is a good thing for fine tuning the system. In my experience my delay shifts are done in increments of 1uS which equals about 1015 feet.
You might be thinking, you could accomplish this the other way around by decreasing the TX buffer number by in my experience, it doesn't work. If someone else has done this with success I would certainly like to know.
Receiver Voting
This process is similar to transmitting but in reverse. The way the Allstar Voter module votes is much the same as any other signal-to-noise voter. As with the transmit side of things, the receiver audio is packetized and transported over Ethernet to our host computer running Allstar. Each one of these audio packets have a time stamp derived from the GPS data provided to the Voter Board/RTCM at each receive site. When this packet arrives at the host computer, they will arrive at different times, because of this a receive buffer needs to be employed. This buffer allows the Voter Module to line up the packets using their respective time stamps and then compare the audio packets to each other to determine which packet has the best audio to be chosen (or Voted in our case) to be sent to the transmitters and/or out over any remote links.
In much the same way we set the transmit buffer, we need to set a receive buffer. This particular buffer is set within the voter.conf file in Allstar in the /etc/asterisk directory. The setting is under the [general] stanza shown here:
[general]
port = 667
buflen = 250 <<<<<<<<<<
This setting is defined in milliseconds. My determination for this buffer is done the same way as my TX buffer in the Voter Board/RTCM. The difference is, since this setting is done in milliseconds, no calculations are necessary.
Set this buffer to half the value of your longest ping time and add 50 percent for buffer padding. Knowing this, there is an unadvertised issue with this value and if you don't know about it, you will get very frustrated for awhile so here is the warning about it.
If you set you buflen value below 200, you may experience problems with voting receivers voting.
I have found that a minimum setting of 250 to be the minimum I can set so that everything works as it should. All my sites (all 7 of them) have ping times of no more than 10 milliseconds. My educated guess here is that the buffer needs a sufficient amount of audio packets in it, in order to make its receive audio voting decisions. I don't know if this is exactly why but the logic seems to agree anyway.
So long story short, if your longest ping time is less than 200 milliseconds, set the buflen = 250 and you are done.
