Gold Elite pathing problem

[IMBEJames]

Im working on ironing out some audio issues involving a patch from an 800MHz Smartnet talkgroup to a conventional VHF resource. With the patch active (initiated at a Gold Elite Op position), audio from the SN talkgroup to VHF and vice versa is distorted and has a slight echo. 800MHz subscriber to 800MHz subscriber audio is clear, and the same is true of audio from VHF to VHF subscribers. Console audio on the trunking resource and the VHF conventional resource is also clear regardless of whether the patch is active.

The console is on a 3-CEB Embassy system, and none of the components are new. The trunking and conventional resources have been in place for some time now.

The VHF conventional system is an MTR repeater with a co-located JPS comparator at a remote site, and a voting receiver with a UHF link to the comparator. There is no console connection to the comparator; it is through a control station (4-wire circuit to a CPI tone remote adapter on a PM400 mobile, in the same building as CEB). The system was optimized

I listened to the audio on the control station wireline as well as demod audio on my service monitor while there was traffic on the 800 talkgroup. It's clean. No noise at all. Receive audio from the control station is also clean. I disabled the VHF voting receiver and the UHF link transmitter, and no change.

And just for comparison along the way, I disabled said patch and initiated a different one from the same 800 talkgroup to a VHF simplex resource. Audio was crystal clear.

Am I missing something? Any help would be appreciated before I rip my hair out over this one. It's driving me nuts.

[The Pager Geek]

Very thorough IMO. Can you better explain this statement:?

And just for comparison along the way, I disabled said patch and initiated a different one from the same 800 talkgroup to a VHF simplex resource. Audio was crystal clear.

How did you test another patch? Using the same 2 groups with a different means of patching (2 radios back to back)? Or did you test the same 800 group with a DIFFERENT VHF resource on the console, and it worked ok?

tpg

[IMBEJames]

The other patch was initiated at the same Op position as when the audio was lousy, only it was patching the same 800 talkgroup to a conventional VHF base on a simplex frequency.

Same 800 talkgroup, different conventional VHF base. Same patching method.

[The Pager Geek]

The other patch was initiated at the same Op position as when the audio was lousy, only it was patching the same 800 talkgroup to a conventional VHF base on a simplex frequency.

Same 800 talkgroup, different conventional VHF base. Same patching method.

Ok, cool. So it's resource dependent and not ALL patches do this. Did this work before, but now doesn't? Or is this the first time you've used a patch on these resources and notice issues?

First thought is the VHF resource is set-up for 4-wire full duplex (or something close), and the muting jumpers aren't right. Does it have a signaling modem on it by chance? I'd lean towards the muting jumpers given the "echoing" comment. You could swap BIMs with the VHF resource that works (adjust TDM switches and mux/bux jumpers accordingly) and see if the problem follows the BIM.

Other options, but possible:
Perhaps very old BIM firmware revision problem, but unlikely.

The other thing that comes to mind that it COULD be (but doesn't excuse the behavior) is if it is cross-muxing, and the CEB is having a problem with it. For example, the 800 resource is Mux/Bus1 and you are patching to Mux/Bus2.

If you get this far, I'd be curious to know what the mux/bus are for:
The 800 resource
The VHF resource having the problem
The VHF resource not having the problem

That's off the top of my head.

I'd lean towards 4wire muting issues first though.

tpg

[IMBEJames]

The VHF resource is 4-wire... but I'm a little fuzzy on the muting jumpers. It does have a Stat-Alert modem.

All the BIM's in the CEB except for one or two (which aren't involved in the patch) are the same vintage and haven't moved, so I'm thinking firmware isn't the issue. Not too many things have changed from what you'd see in the as-built doc's.

I'll be working on this stuff again tomorrow, so I'll round up the info I didnt have when I posted, ie, mux/bus, etc for each resource.

[Jim202]

The VHF resource is 4-wire... but I'm a little fuzzy on the muting jumpers. It does have a Stat-Alert modem.

All the BIM's in the CEB except for one or two (which aren't involved in the patch) are the same vintage and haven't moved, so I'm thinking firmware isn't the issue. Not too many things have changed from what you'd see in the as-built doc's.

I'll be working on this stuff again tomorrow, so I'll round up the info I didnt have when I posted, ie, mux/bus, etc for each resource.

There is a chance the jumper settings on the BIM cards are different. There is also a JU7 jumper that should be cut for use interfacing into a trunking system. This effects how the audio is detected and controls the keying of the RX audio into the trunking system. Generally it will show up as delayed and chopped audio. Have found this to be a major problem when trying to interface some of the BIM cards when using an external radio interop gateway. After cutting the JU7 jumper, it all starts playing well. Not saying this is your issue, but wanted to make you aware of it.

Jim

[Bill_G]

Check for dual patches in place. Another console might have them patched, but you aren't aware of it. Set up the patch, and knock it down on all positions, and then set it up on the console of interest again to see how it sounds. You may have to restart all positions.

[IMBEJames]

No simultaneous patches anywhere. I looked a little closer, and it turns out the wirelines are punched down for 4w but are configured for 2w.

I looked at the BIM muting jumpers. They are fine, but I did open J7.

All resources are on the same mux/bus.

[The Pager Geek]

No simultaneous patches anywhere. I looked a little closer, and it turns out the wirelines are punched down for 4w but are configured for 2w.

You are getting loopback echoing. Straighten out the 4W and 2W configs, you should be good.

tpg

[IMBEJames]

Do you mean changing it to 4W? That was my plan for tomorrow...

[The Pager Geek]

Yes, exactly.

tpg

[IMBEJames]

So I converted the VHF resource to 4W and no change. Audio was exactly the same. I also swapped BIMs with a different conventional VHF resource where the patch worked. Still no change.

I'm running out of ideas.

[The Pager Geek]

I'm running out of ideas.

Me too.

So, just so I have a clear picture in my head:
VHF resource works ok, unpatched
800 Resource works ok, unpatched
VHF resource while patched at console position is ok (You don't hear the distortion on the console)
800 resource while patched at console position is ok
Audio from VHF subscribers at the 800 subscribers is distorted, and V/V

Correct?

tpg

[Jim202]

Not wanting to dilute the focus here, but by any chance have you measured the audio levels from the radios in RX as they go to the BIM cards? This level should not go over 0 db as measured with a TIMS unit in the "BRIDGED" mode. Plus I wouldn't expect the RX audio level to be much below a -15 db or so on the average. If you by accident have the unit in the "TERMINATED" mode, you will load the line down and get a wrong reading.

The other issue that could cause this, it should have shown up long ago, is that there is a slim chance the line setting jumpers are set wrong on the BIM cards. If you spend a few minutes going through the manual, you should find the jumper settings and be able to verify them on each of the BIM cards. The normal default settings would be where I would expect the jumpers to be.

Another point I would also inject here is are the radios tone control? I have seen weird things take place on new cards installed that we thought were programmed for tone control and were not. The 2175 Hz low level idle tone will leak through and cause all sorts of complaints from the dispatchers. The users out in the field will also hear the low level 2175 Hz tone on the mobile and portable receivers if the 2175 Hz notch filters are not installed on the base transmitters. Plus they hear the high level 2175 Hz wake up tone.

Jim

[IMBEJames]

I think I found the issue. Did some more testing Friday afternoon. Let me know if this sounds reasonable:

Definitely seems to be an audio level problem. The BIM levels, base wireline levels, and comparator have all been tuned within the last couple months on the VHF system, so I dont think that's it. The SmartNet system has also been tuned recently during annual PM. I think the problem is that the patched audio (we'll just use the 800 -> VHF as an example) is just too hot. It likely would not be a problem if the VHF base was controlled over wirelines, but it is using a control station. So with the comparator tuned for proper subscriber audio levels and no AGC on the SVM cards, the patched audio blasts in and distorts somewhere in the comparator. The MTR has automatic level control so the transmit deviation is still at the appropriate level, but the audio is horrible.

It seems as though at this point, installing wirelines might be the only way to really resolve this. Then the comparator's CIM and the MTR2000 will handle the different audio levels without clipping/distorting and retransmit clean audio.

[IMBEJames]

I'm running out of ideas.

So, just so I have a clear picture in my head:
VHF resource works ok, unpatched
800 Resource works ok, unpatched
VHF resource while patched at console position is ok (You don't hear the distortion on the console)
800 resource while patched at console position is ok
Audio from VHF subscribers at the 800 subscribers is distorted, and V/V

Correct?

tpg

Correct. Forgot to mention in my last post...

[The Pager Geek]

I think I found the issue. Did some more testing Friday afternoon. Let me know if this sounds reasonable:

Definitely seems to be an audio level problem. The BIM levels, base wireline levels, and comparator have all been tuned within the last couple months on the VHF system, so I dont think that's it. The SmartNet system has also been tuned recently during annual PM. I think the problem is that the patched audio (we'll just use the 800 -> VHF as an example) is just too hot. It likely would not be a problem if the VHF base was controlled over wirelines, but it is using a control station. So with the comparator tuned for proper subscriber audio levels and no AGC on the SVM cards, the patched audio blasts in and distorts somewhere in the comparator. The MTR has automatic level control so the transmit deviation is still at the appropriate level, but the audio is horrible.

It seems as though at this point, installing wirelines might be the only way to really resolve this. Then the comparator's CIM and the MTR2000 will handle the different audio levels without clipping/distorting and retransmit clean audio.

I would agree with you, however at SOME POINT you should be able to find the crappy audio.

Based on your theory above, I would put a TIMS:
Wireline at the Control Station (Tests BIM to Control Station)
Wireline input to comparator of the receiver voting the control station (Tests Control Station audio at the comparator)
Wireline output of comparator to the MTR2000 (Tests Comparator to MTR2000)

If the above is:
Good
Good
Bad

Then you know it's a comparator problem like you think.

The thing that is throwing me off is why is it doing it on the 800mhz subscribers also?

tpg

[Bill_G]

I think I found the issue. Did some more testing Friday afternoon. Let me know if this sounds reasonable:

Definitely seems to be an audio level problem. The BIM levels, base wireline levels, and comparator have all been tuned within the last couple months on the VHF system, so I dont think that's it. The SmartNet system has also been tuned recently during annual PM. I think the problem is that the patched audio (we'll just use the 800 -> VHF as an example) is just too hot. It likely would not be a problem if the VHF base was controlled over wirelines, but it is using a control station. So with the comparator tuned for proper subscriber audio levels and no AGC on the SVM cards, the patched audio blasts in and distorts somewhere in the comparator. The MTR has automatic level control so the transmit deviation is still at the appropriate level, but the audio is horrible.

It seems as though at this point, installing wirelines might be the only way to really resolve this. Then the comparator's CIM and the MTR2000 will handle the different audio levels without clipping/distorting and retransmit clean audio.

In your first msg you said the consoles access the VHF through a PM400 control station. If VHF operation from the console is good, but 800 crosspatch through the console is distorted, then the problem is in the console. I will say I am not familiar enough with Gold Elites to say where or how the crosspatch levels are set. It could also be that the BIM for the VHF control station is set a tad hot. Dispatchers with poor mic technique come through fine, but processed full level audio from the 800 side blasts it. You can verify that by listening to the control station xmit OTA.

[The Pager Geek]

In your first msg you said the consoles access the VHF through a PM400 control station. If VHF operation from the console is good, but 800 crosspatch through the console is distorted, then the problem is in the console. I will say I am not familiar enough with Gold Elites to say where or how the crosspatch levels are set. It could also be that the BIM for the VHF control station is set a tad hot. Dispatchers with poor mic technique come through fine, but processed full level audio from the 800 side blasts it. You can verify that by listening to the control station xmit OTA.

Easy way to test the BIM level is to reset it and watch the TX level. A reset BIM will generate a series of tones (1000hz, 300hz, 3000hz) on reboot.

tpg

[Bill_G]

Thanks tpg. There's a button on the front to do that too. Do you know if there is such a thing as crosspatch level settings, or is it wysiwyg?

[xmo]

There are so many Motorola system configurations it's hard to tell from a distance what might be applicable to your situation, but you might want to review PSB-907b.

One of the items it addresses states:

"Patch Audio too loud when the source of the audio is a BIM (SPI/DPI) or DR board. The AGC’ed level from these boards is 5dB louder than radio-to-radio audio. BLN6656E version BIMs and BLN6656D/BLN1145C version DRs ship with jumpers that can be cut to reduce the receive audio level of these boards...."

[The Pager Geek]

There are so many Motorola system configurations it's hard to tell from a distance what might be applicable to your situation, but you might want to review PSB-907b.

One of the items it addresses states:

"Patch Audio too loud when the source of the audio is a BIM (SPI/DPI) or DR board. The AGC’ed level from these boards is 5dB louder than radio-to-radio audio. BLN6656E version BIMs and BLN6656D/BLN1145C version DRs ship with jumpers that can be cut to reduce the receive audio level of these boards...."

That would make sense. You can test this by looking at the BIM audio output. If you hear crappy audio, it's the Rx BIM with the issue... not the one you are measuring.

tpg

[IMBEJames]

I dont know the part numbers of all the cards in the CEB (I have them documented, just not with me of course)...

I'm kinda wondering if this will apply to the TBIMs too.

The PM400 VHF control station is connected to a CPI tone remote adapter which recommends a line level of 0dB. I have the BIM set to -14dB right now just to make the patched audio intelligible. The console audio is definitely quieter, but it's a temporary "happy medium" until I can dive back into this.

In talking to the console group at Moto, the patch audio never leaves the backplane in Gold Elite, and there's really no way to adjust it without touching the levels at the Rx BIM.

[xmo]

This sort of issue surfaced as many entities have begun using their CCII consoles as interoperability gateways, often associating a smart VOX system [e.g. Raven] with the console.

Ideally, you want all your outbound transmit audio to be at the same level regardless of source. Normal transmit audio levels in the CCII series are all established by design and firmware. There is only the single level control on the BIM which sets the master output level. As you were advised by the Motorola console group, the relationship between different audio sources is fixed.

For most cases, this works well. Operator position transmit audio, TRC tones, paging tones, and alert tones are all properly related. If you use the BIM test tone to establish your standard level, typically -10 dBm, you will find that the operator average voice will be at the same level as will the alert tone.

Actually, using the alert tone from the op position is one way to set the system transmit levels so that you don't have to reset the BIM cards. If you do reset a BIM to get a test tone, wait a while before you reset it a second time. If you reset it a second time too quickly, it will miss two 'sound-offs' and the ops will fail the resource [RED - X]

The problem arises with patch audio. You would think that if you send your standard test tone [e.g. 1000 Hz @ -10 dBm into the receive port one BIM, that it would come out of the associated patched BIM transmit port at -10 dBm the same as the test tone did, but it comes out too hot by 5 to 6 dB. Since the receive side of the BIM has DLM or AGC, you cannot solve this problem by adjusting the RX level going into the BIM, the DLM will simply compensate and your problem remains the same.

Because the test tone [and standard level setting tone level] is intended to represent the level of average voice [60% of system deviation], this 6 dB increase puts average voice into clip and voice peaks into distortion.

The fix is outlined in the PSB. If your BIM versions are too early to have the jumper, you can effect a modification to resolve the problem. When you get it right - you can put 60% deviation into any channel RX and get 60% out of any channel transmit, directly repeated OR patched - and you will have a great sounding gateway.

If you add the Raven box, you can also eliminate voice truncation due to VOX keyup delay. An alternative is to use hardware COR direct from your conventional repeater(s) to the console. This typically requires an E&M circuit plus an I/O card above the BIM to accept the COR.

Either alternative will largely put an end to user's whining about how patching works. It is possible to make the system operation so seamless that no one can actually tell which user is on which resource - local or patched.

[Jim202]

This sort of issue surfaced as many entities have begun using their CCII consoles as interoperability gateways, often associating a smart VOX system [e.g. Raven] with the console.

If you add the Raven box, you can also eliminate voice truncation due to VOX keyup delay. An alternative is to use hardware COR direct from your conventional repeater(s) to the console. This typically requires an E&M circuit plus an I/O card above the BIM to accept the COR.

Either alternative will largely put an end to user's whining about how patching works. It is possible to make the system operation so seamless that no one can actually tell which user is on which resource - local or patched.

Cutting of the JU7 jumper on the BIM card seems to eliminate the VOX delay that has caused many people this problem. So far in all the different trunking systems that I have had to interface a conventional radio into, this solved the problem. You don't need a COR or E & M lines to make it work.

Jim

[IMBEJames]

Hey guys, sorry for the delay in posting an update.

I tuned the comparator on the VHF system to lower the audio levels. Audio cleared up a lot, but the levels are not consistent enough for my liking. Looks like according to the PSB, all the TBIMs will have to be modified and will affect a lot of things that I'd rather take care of during the upcoming annual PM's (when we take care of all the audio levels anyway)... like the Rx audio at the console and LOMI outputs to the recorder.

So I came up with a temporary solution. If I were to replace the PM400 control station with a consolette, the patch audio from the 800, even if it is 5dB hotter, will be AGC'd by the consolette and audio should be transmitted cleanly at the proper deviation to the VHF system. Then I can just perform the AGC mod on the one conventional BIM, thereby fixing the VHF audio level being patched to the 800 system.

Anything in this plan that doesn't hold water?

[JRS]

I know this is a few months late, sorry for the delay...
I too have seen this "hot" audio patching from trunked resources to conventional resources on Gold Elite and Series II consoles.

Two things I would suggest:
1. Configure the BIM to the VHF resource to Relay Keying and control the radio via Extended Local Control, eliminates the Tone Remote Adapter and allows greater TX audio level control from the BIM to the control station.

or

2. A configuration I used at my last job. We had three VHF comparators and a trunked talkgroup on a state system. I used "console repeat" on the three VHF BIMs and patched them to a BIM to BIM on the state trunk. The audio amonsgt all paths was perfect, you could not tell where someone was coming into the system from.
In your configuration, you would need a four wire telco cirucit with E/M signalling (try a TLNA circuit, they will still do them, good luck though , configure the voter to be repeat disabled, configure the VHF BIM for console repeat and COR. In this arrangement, when a subscriber accesses the VHF system, COR will be asserted down the wireline to the BIM, which will then repeat the audio within the BIM and back up to the voter to be retransmitted out. This audio path when configured factors in the audio boost that you are seeing now, so when you set your levels in this arrangement your patched audio will be the same as your repeat audio level.

I hope this helps, again sorry for the delay.
I have been to this system, it is a very nice layout

-John