MTR2000 / "access code" / audio path issues

[thebigphish]

Hey folks,
I am not going to put all the particulars of this issue up here tonite, as it will take me the better part of a week to get all the information in, but i need some help. I have an MTR2000 which is programmed for PL activation on a conventional channel, and is using an AuxIO audio path & wireline to pass "discriminated" audio over to another MTR2000 which is using it like a 2nd RX unit. For some reason, the 1st MTR is passing DPL information over in a wholly different range, AS WELL AS the correct PL. I'm looking for someone who is intimately familiar with the MTR2k & "access code" & MTR programming to help me dope some problems out, so that i can find out why this MTR is programmed for a PL & why it's passing everything under the sun as DPL. (And i checked the basics, the channel is NOT set up for anything other than the correct PL & freq, audio path is set up for "carrier & PL" and there is no reference to CSQ or DPL in the access code (which i am seconds from disabling to make sure that even if there is one list in the access code table, being the correct PL, i might just remove it to eliminate that as a problem).

I've found all the spelling errors in the MTR manual, all but fired a radio shop for their shoddy install, and need someone who's familiar with wildcard & the MTR-ese programming so i can dope this out.

Someone's gotta speak MTR.

[wavetar]

Could you elaborate a bit on your set-up? I've cross-banded many an MTR over the years in various different ways, and haven't run into this issue. You mention both Aux IO discriminator audio and wireline audio...which output are you actually using to feed the 2nd MTR? What pins in the J5 system connector or MRTI connector are you using?

[thebigphish]

Trying to recover a botched install from a vendor who is now P.N.G. with our agency.

2 MTR2000s, 1 VHF-hi & 1 UHF which are colocated in tower rack. Goal was full time bi-directional patch & repeat. System works GREAT going U to V, however, the V MTR2k is essentially an open collector, and right now is passing most everything - CSQ, TPL, DPL, etc....

"4 wire" wireline connection appears to have been used to move the audio paths between the two, along with 2 jumper wires between System Connector J5 on the units. (Unable to determine which pins were captured, will hope to see them up close tomorrow - appears to be something early in Row A (1st quarter of it) and something near the end of Row B (20s i'd say). Don't know where they are going yet, will trace them real soon. (limited access to site @ this time)

RSS reveals channels are set correctly on the UHF, 'access code' disabled in the UHF, and channel, audio (set to carrier & TPL) & Enccode / Decode tabs all make perfect sense, appropriate PL information, TRC & Wireline tabs set to map Ext PTT to wireline, levels are good...and this side of the link works great. MRTI is off, Wildcard off & Aux IO card installed by vendor.

VHF MTR has 'access code' enabled in config (although only 1 entry - being the correct PL we use), MRTI off, Wildcard ON, Aux IO card installed by vendor, channel info makes sense, Encode & Decode tab show "access code 1" entry rather than pl/DPL settings (as they should with access code enabled in config), audio path was originally set to (PL/DPL and not "Carrier & TPL" - changed last week, no appreciable change in situation) now shows "Carrier & PL/DPL", TRC & Wireline tabs match UHF unit, levels are good.



The backplane j5 pins appear to be the same for both units, but i don't know which pins they are, i will find out. MRTI is bare. I have limited knowledge of the RSS, and have been stumbling thru some reading as to how Wildcard IO works, and what it does...So i don't know if the VHF for some reason has a goobered up wildcard setting. The Wildcard tables as i can figure @ this time are totally blank, no software jumpers set @ this time. Looking at the info in the manual, maybe pins that were used were A5 & B21 (which would relate to GPI_3 & RdStat - respectively, which would be what was needed to do the required (COR & Ext PTT).

Only other simple differences i have found between the two codeplugs is some TRC commands. The UHF shows Monitor @ 2050 & Select CH 1 & TX w/ LLGT @ 1950, and the rest are blank. The VHF shows same two, and then Repeat ON @ 1450, Repeat OFF @ 1350.

I'll be more than happy to ship you the two codeplugs, so you can look. How would this work one way, and not back? The VHF still repeats just fine, it just repeats & broadcasts EVERYTHING, and the UHF doesn't know any better, it just blasts out what the VHF hears.

More info is avail off list if you want, i appreciate any help you might have.

[GEMOTO]

I have done this before but with a completely different method, using a voting comparator. The 2 MTR's are considered base stations rather than repeaters. The receive audio from both 800 and UHF stations are wired to the comparator, the line out (tone keying) is then wired to the MTR's. When user keys up on 800, the comparator will send that audio over UHF and 800, when a user keys up on UHF it will do the same thing. Additionally since these stations and the comparator are all co-located the audio level setting is a breeze. If two people talk at the same time one on each band it sounds a bit weird, no hertodyne, you will just hear the person that is hitting either system the strongest, it usually flips back and forth though.

With this method you can patch stuff all day long as long as you have enough slots in the comparator and pad the output correctly to achieve 600 Ohms.

Just a thought from some previous projects I did.

[Vercomm]

What you are describing is a pretty basic setup. Using the 4wire audio is the best way to achieve your goal, you will probably have to play with the 4 wire audio settings either in the output of the VHF or the input of the UHF. To do this and have it exact you're going to need a service monitor. It sounds like your radio shop didn't quite know what they were doing or know all the in's and out's of the MTR.

Just and FYI for you, the reason that your vendor installed the Aux I/O card is because the Rx Active pin can only output an active high when Rx is in use. The PTT input for the MTR is active low only, so as you can see this doesn't work. The way to be able to change active levels on pins is to install the Aux I/O card, but that is quite an expensive solution for something as simple as changing the active state of a single pin from High to low. Wavetar gave me a diagram of a basic transitor diagram that takes the Rx active high and changes it to a low and thus eliminating the need for the Aux I/O cards.

This problem could be a bit difficult without being onsite with test gear to see what's going on. A basic way to make some simple inspections would be to verify that the RSS levels of the 4wire card on the VHF are the same as the UHF. That should give you a basic starting point for levels since the output of the UHF and the input of the VHF are working well.

Another thing to check is to make sure that "output +/-" go to the "input +/-" and are not crossed (i.e + into - and - into +). It could be that the output of the UHF is correctly connected to the input of the VHF, but the output of the VHF isn't connected correctly to the input of the UHF. Also check and see if there is a station earth between the 2 MTR's.

Also make sure that the 4wire card is the correct one that is chosen in the RSS config. Can't remember the part number off hand.

Also, make sure that you have the most recent firmware R03.04.003 as per FSB10174 ( you can see what firmware you have if you go into station information). All software prior to and including R03.04.002 are affected by the possibility of the following:
- Lockup in transmit with no PL being Tx
- Something with Line 2 being muted after cold reset and requiring something be done in the alignment screen of the RSS to restore line 2 audio.

Feel free to send me copies of the codeplugs and I'll see if there is anthing out of the ordinary, unfortunately the alignment values cannot be checked from a saved codeplug so you'll have to do that when you're onsite. jamie.mcphee@vercommwireless.com

See where that gets you and let us know what u find.

Good Luck.

Jamie

[thebigphish]

Massive, massive programming weirdness. Removing the "Carrier & PL/DPL" from the requirements & selecting only PL/DPL fixed 99% of it. For some reason, and i can't figure out why i thought this, but i was thinking that it meant that "Carrier WITH VALID PL DPL" was required to activate, and not "Carrier OR valid PL/DPL" (which it actually meant). I guess it blew by every set of eyes on that codeplug.

So far, so good. Now we wait, time will tell.

And those pins on the J5 are J5:A10 & J5:B21. The wirelines are correctly cross connected, + & - appropriately. The MRTI was disabled in both units config, as was the wildcard option. Now both Channel Info pages have identical Encode / Decode settings. Audio boost for both was disabled. Levels & Audio sound "fantastic" (per dispatch), and both units now appropriately pass audio w/ qualifying PL on it.

And i reiterate, now we wait.

[Vercomm]

hhhhhhhhhhhmmmmmmmm, anybody have the rss manual for the MTR? I was always under the impression that when you selected Carrier and PL/DPL that the receiver would only unmute(activate) with correct carrier AND correct PL/DPL instead of OR like chris is seeing.

Todd, could you elaborate any?

Jamie

[chpalmer]

Yes it is AND. What do you have for repeater hold in?


Why are you using "Access Code" on the VHF?

[thebigphish]

The "Access Code" was removed and replaced with standard setup for single PL operation. The unit apparently has suffered 8 yr old onset alzheimers, and was taken offline & is out for repair. The programming as fixed 1 week ago was correct, discriminated the correct PL for 3 days, and then started doing it again in the middle of the day w/o warning.

[thebigphish]

reanimating this post for future problemsolvers...
bad code plug

end of story.

Talked to moto at length, got some factory guys cellphone numbers, as they had done 2 depot trips on the unit w/o resolution. Moto sez that when the MTR is being reprogrammed, it is safer to take a default codeplug and create new codeplug with the changes in it, rather than the old DL --> CHANGE --> UL maneuver that almost everyone does. Small changes are ok, like a PL change, but anything that diddles with wildcard, channel assignments, system controls...SHOULD be done on a default codeplug. Apparently the units have a unique ability to create crap in the codeplugs over time, and will do various bizarre things...and uploading and downloading the codeplugs frequently w/o a new creation of one, is a surefire way to manifest this issue.

this unit has been running for 10 mos now w/o fault.

thx to all for their help.