Ok here's the deal right now we have 2 repeaters one in town for local coverage (MTR2000) and one on a mountain for regional coverage (Quantar). Both are on the same input / output frequency with the same output PL different input PL. The problem we are having is dispatch pages us on the Mountain repeater and can only talk on the mountain repeater. We have very poor in building coverage in town with the mountain repeater so we are missing some of the pages but we can talk back to dispatch on the local repeater. Our dispatch has enough problems paging us so switching channels is not an option for them.
We have a wireless link between the in town location and the mountain site that offers less than 10ms ping time with a jitter of less then 2ms. I want to use the link to create a Simulcast (or some other type of) system using the link.
Anybody have any suggestions.
Thanks,
John Moore
ROIP Linking
Moderator: Queue Moderator
Re: ROIP Linking
Yes - you might be able to simulcast them. Both station will accept an external reference clock. However, because they are different models, you will have difficulty getting the equalization correct. I've used both Dalman and Harris equipment over ip links with success. The Dalman offers more equalization control, but has a lengthy import process. Harris is in country but has little equalization control. Harris is more robust than Dalman. Both have lean support. Both require some talent to build and maintain. And neither are cheap.
Simulcast solutions is a good place to start investigating tying the two sites together.
http://www.simulcastsolutions.com/audio-delay-IP.htm
A simpler solution is to multicast. Have your MTR on a different output than the Quantar, but give both a common input & pl. Now any transmissions on the input are repeated on two different outputs to serve two different but overlapping areas. Have your pagers programmed to scan, or have your personnel manually select the best channel for the areas they are in.
Obviously, this could be expanded to include a comparator (with or without transmitter steering). The best receive audio will be repeated at both sites rather than one being noisy and the other good.
Hope that helps.
Simulcast solutions is a good place to start investigating tying the two sites together.
http://www.simulcastsolutions.com/audio-delay-IP.htm
A simpler solution is to multicast. Have your MTR on a different output than the Quantar, but give both a common input & pl. Now any transmissions on the input are repeated on two different outputs to serve two different but overlapping areas. Have your pagers programmed to scan, or have your personnel manually select the best channel for the areas they are in.
Obviously, this could be expanded to include a comparator (with or without transmitter steering). The best receive audio will be repeated at both sites rather than one being noisy and the other good.
Hope that helps.
Re: ROIP Linking
Bill_G wrote:Yes - you might be able to simulcast them. Both station will accept an external reference clock. However, because they are different models, you will have difficulty getting the equalization correct. I've used both Dalman and Harris equipment over ip links with success. The Dalman offers more equalization control, but has a lengthy import process. Harris is in country but has little equalization control. Harris is more robust than Dalman. Both have lean support. Both require some talent to build and maintain. And neither are cheap.
Simulcast solutions is a good place to start investigating tying the two sites together.
http://www.simulcastsolutions.com/audio-delay-IP.htm
A simpler solution is to multicast. Have your MTR on a different output than the Quantar, but give both a common input & pl. Now any transmissions on the input are repeated on two different outputs to serve two different but overlapping areas. Have your pagers programmed to scan, or have your personnel manually select the best channel for the areas they are in.
Obviously, this could be expanded to include a comparator (with or without transmitter steering). The best receive audio will be repeated at both sites rather than one being noisy and the other good.
Hope that helps.
I question that you would be able to hold the audio delays close enough to keep them in the proper phase to allow
simulcasting. An IP connection over a circuit you don't control is like asking for failure.
I would lean to the different TX output operation as Bill has suggested. It means user common sense, but that is to
control than the functionality of a dispatcher. Deal with them almost every day and find that I am surprised that some
of them can even find their way into the dispatch room on a daily basis. On the other hand, have met some very smart
and radio savvy dispatchers over the years. They will put some of the better radio techs to shame.
Jim
Re: ROIP Linking
Jim - ip delay and jitter are extraordinarily high compared to a full T1. Modern simulcast equipment now have sufficient bulk delay buffers to compensate. 10000us (10ms) delay is actually quite low for an ethernet system, and 2000us (2ms) jitter over wireless is phenomenal, but they were quite normal in a frac T1 that used adpcm encoding to increase the number of ds0's. In the past 30000us was generally the maximum delay control you had. So, two hops of adpcm links was all you could tolerate before your simulcast blew up. These days you can get 1000000us of buffer allowing even average ip links over dsl to work well. It can have one heck of an "echo", but the large buffers give each transmitter plenty of time to accumulate packets before launching. And with gps disciplined controllers, every transmission is perfectly phased. You can just dial it right in.
Same on the receive side. You can set the buffers sufficiently high so that they accumulate lots of packets before passing them to the comparator and/or the console. Occasionally you will hear a conversation skip a vowel, or repeat a vowel as the comparator switches sites dynamically, but not very often. The receive stays synced up pretty good with no dropouts associated with the transport layer.
What they still haven't worked out well is equalization and signal-to-noise rcvr voting. The pass filters of 300 to 3K audio have tight skirts requiring (A) you gen in phase PL at each transmitter site rather than inject it at the simulcast controller along with the main audio payload, and (B) the recovered receiver audio is not high frequency rich enough for a comparator to work well. You have to have your PL deviation within 5hz from each site to prevent a growling beat note in the user receivers. It is almost more distracting than anything other noise in a simulcast because it is constant, and potentially LOUD. On the receive side, you have to throw a lot of noise into the rx site link encoder so that some noise will be recovered at the comparator. You have to play with the deemphasis curve, apply a tonal control, or a graphic equalizer to the receive audio to achieve that just so the comparator has enough noise to work with to make voting decisions. It takes finesse. The industry needs to widen the audio band pass of the ip link sampling encoders to allow us a single PL injection point, and to either give us better voting noise, or a method to relay to the comparator the quality of the received signal. Essentially a distributed comparator. Put the SQM at the site and use the transport to carry the common audio bus back to the controller.
Other than that, simulcast over ip works pretty good.
Same on the receive side. You can set the buffers sufficiently high so that they accumulate lots of packets before passing them to the comparator and/or the console. Occasionally you will hear a conversation skip a vowel, or repeat a vowel as the comparator switches sites dynamically, but not very often. The receive stays synced up pretty good with no dropouts associated with the transport layer.
What they still haven't worked out well is equalization and signal-to-noise rcvr voting. The pass filters of 300 to 3K audio have tight skirts requiring (A) you gen in phase PL at each transmitter site rather than inject it at the simulcast controller along with the main audio payload, and (B) the recovered receiver audio is not high frequency rich enough for a comparator to work well. You have to have your PL deviation within 5hz from each site to prevent a growling beat note in the user receivers. It is almost more distracting than anything other noise in a simulcast because it is constant, and potentially LOUD. On the receive side, you have to throw a lot of noise into the rx site link encoder so that some noise will be recovered at the comparator. You have to play with the deemphasis curve, apply a tonal control, or a graphic equalizer to the receive audio to achieve that just so the comparator has enough noise to work with to make voting decisions. It takes finesse. The industry needs to widen the audio band pass of the ip link sampling encoders to allow us a single PL injection point, and to either give us better voting noise, or a method to relay to the comparator the quality of the received signal. Essentially a distributed comparator. Put the SQM at the site and use the transport to carry the common audio bus back to the controller.
Other than that, simulcast over ip works pretty good.