MIP5000 Patch

[webby52]

Looking for some advice,

Have just switched from a repeated conventional uhf system to a county trunked system now using a new 2 position MIP5000 with 11 resources. The trunked system has left us with some coverage issues and the whole low power footprint from FCC doesn't help. The issue at hand is I'm looking to patch the trunked channel and the conventional repeated channel together so if they are getting bonked on trunk channel they can switch to repeated conventional and the units still on trunked channel will hear them. The repeated conventional system is a canopy system that has 5 sites routed to a rad mux filtered to a spectra tac that transmits to a quantar. When I patch channel 1(trunk) and 2(repeated conv) at the console, when the repeated channel keys up it effectively transmits over channel 1. The issue is when the audio stops the two channels start to "ping pong" against each other and never stop transmitting. I'm guessing ch 2 keys up and ch 1 sees activity so it opens up. But then when channel 2 stops it still sees activity on channel 1 and they bounce back and forth keying up and never stopping.

I have had the system administrator set the hang time on the trunked system to 0, and changed the jumper setting for the hang time on the tone control card to 0 on the repeated system. Still happens. Anything else I can do to the MIP settings? What am I missing here?

I know it can be done, just maybe not with Moto, as the County Comm center has done it with the old repeated VHF channel to the new trunked ops channel thru the "Acom".

[akash1]

that is always a problem when you are using audio path to do the patch. Very hard to avoid ping-pongs without a lot (i mean a lot) of work and that too it is not 100%. Best way to do this would be radios with COR signals.

[RFguy]

that is always a problem when you are using audio path to do the patch. Very hard to avoid ping-pongs without a lot (i mean a lot) of work and that too it is not 100%. Best way to do this would be radios with COR signals.

+1

I have never seen a VOX patch that worked outside an environment of technical people operating it.

The patch you saw working on another console would have certainly had a COR connection to each patch radio providing a positive key up/de-key function.

[Jim202]

that is always a problem when you are using audio path to do the patch. Very hard to avoid ping-pongs without a lot (i mean a lot) of work and that too it is not 100%. Best way to do this would be radios with COR signals.

+1

I have never seen a VOX patch that worked outside an environment of technical people operating it.

The patch you saw working on another console would have certainly had a COR connection to each patch radio providing a positive key up/de-key function.

The use of a COR signal control is about the best way to get over the ping pong effect that is going on. Without some sort of delay adjustment that some gateways have, your SOL. You don't have any delays available in most console setups.

Jim

[Bill_G]

+1 on the COR / E&M hardware control. Turning the squelch tails to zero was the right move, but the vox detect is what is still killing you.

[webby52]

So any suggestions on the hardware needed to resolve the issue?

[RFguy]

So any suggestions on the hardware needed to resolve the issue?

A Zetron console.

[Bill_G]

The simplest way is a crossband repeater - back to back mobiles - one on the talkgroup, one on the conv rptr. Essentially a permanent patch.

[webby52]

So a friend suggested to disable the remote sites and just leave up the main site where the repeater is. I did this and was able to patch with no issues. Whether I can start to bring up the other locked out sites is doubtful. I can only imagine that when the spectra tac is polling for sites to pick the best one causes the ping pong?

[webby52]

Attempted to connect consoles APX7500 (trunk) to consoles CDM1550 (repeated conv) using a RICK. Even with the COR delay still ping pongs. The initial feeling is the delay from when the canopy system translates the audio heard from the satellite site it locked onto to the spectra tac it takes too long for the rad mux to translate it back to audio. My next test will be dropping out all the sites again, but then seeing if I can get one other site up without getting the ping pong effect. This would give me somewhat baseline coverage...having only the main site active gives me horribly low inaudible audio. (thanks narrowbanding) I doubt this will work as the main site is directly connected to system, therefore there is no delay to convert from canopy system which is why is works without the distortion.

County says they have no coverage issues on the trunked system in our area...with an APX portable...says our XTS/XTL radios must be in need of alignment as we are not receiving the system. We get every third word or nothing at all on the receive side of things. My /\/\ dealer says that line usually auto tunes and we are pretty current on the last firmware update 10/14. We just seem to be stuck in the middle.

[RFguy]

I recall a back to back adapter made by IDA (I think). It had a feature called "anti-kerchunk" that prevented what you're describing. I think it ignored the COR on turn around for an adjustable time to break the ping pong cycle.

[webby52]

So an update to this issue, I've had a lot of time on my hands apparently. I've been reading the help menus and found a setting called "hangover delay". I went into the the MIP5000 CSDM>Radio Channel Parameters>TX/RX>Hangover Delay. The default setting is 2000 ms and I changed it to 500 ms. Rebooted the gateway uploaded the new settings and wow it seems to be working. Not 100% of course but I'm happy with the 95%. When transmitting from the console its pretty much flawless. Having the two channels patched together there is a slight delay on the conventional channel when a field unit is transmitting on trunked channel, but for the most part it will boost our coverage area. Now when officers go into a building or a TRS dead zone will just switch to channel 2 (conv) and the units on channel 1 (TRS) can hear them without switching themselves.

As for the ping pong, it only seems to happen when the field units transmit, but when it starts up a 1/2 sec goes by and the console just shuts them down. Complete silence...Golden.

[Jim202]

You have found out that any noise on the receivers that are connected to the patch can mess up the control of the patch. It may be a simple issue of no reverse burst on the tone squelch of the conventional radios. It could be that the users radios were not programmed for reverse burst on the non trunked system.

In reading your post, it is not clear which side was causing the ping pong to start. It could also be an issue of the audio levels being too high and bringing up the background noise. Whole bunch of things that can sneak into a patch that if your not looking at the audio lines with a storage scope, you might not catch it.

Changing the setting on the MIP5000 is a good place to start with. But there just might be a noise source sneaking in there that you haven't caught yet.

To slightly add to the point of the discussion here, the RIOS interoperability gateway solved this problem with a number of timing adjustments. These adjustments allowed the timings to be moved in or out to allow it to stop the ping pong problems like your seeing. The RIOS also allowed for a delay adjustment in the audio after keying up the system so you didn't loose or chop the first syllable of audio being passed. In other words, the gateway keyed up the transmitter and then sent the delayed audio to the transmitter. It did cause a delay in the output audio of the patch. This is something that you commented about in the patch you have using the MIP5000.

No matter who's console equipment you have or who's trunking system your using, if your standing next to a person talking on the trunking system, you will hear some audio delay coming out of all the other radios that are close by. This is normal in the audio processing between the originating radio and the receiving radio on the system. Digital systems make this delay even more noticeable.

Please keep the group updated on your work with this problem. Your not alone with the ping pong problem.

Jim