I am currently working with a "system" that uses 4 mtr2000 receivers and one mtr2000 transmitter...all new. the "hub" is a Spectratac comparator, with a "tone priority" card, fed with a Centracom gold console.
Bottom line, nobody likes the way it sounds, and I have had nothing but trouble with it not keying up every once in a while. also, I have a problem with the new receivers "buzzing" when the transmitter de-keys.
I am wondering if anyone has had similar problems?
Thanks...........Darrell
MTR2000/SPECTRATAC voted repeater problems?
Moderator: Queue Moderator
-
radiodarrell
- Posts: 3
- Joined: Tue Dec 30, 2003 11:12 am
It looks like you have at least two issues here. Try to pin down the circumstances of the no key up. Is it from the console or from the comparator? After a period of inactivity or following a trasmission?
I have been involved with systems of this type [Spectra-TAC with consoles connected to tone proiority] I did hear occasional complaint of no key up. I never had a chance to identify the problem but I suspected a possible timing situation where the priority module would get it wrong and the base transmitter could drop out.
As far as 'the way it sounds'. We did have one issue that Motorola never addressed. These systems were MSF5000 based but the MTR may have the same issue. The new base stations have AGC on the wire line. It sets the level for an entire transmission based on the level of the high guard tone at the beginning of each PTT.
This process works fine for the console because the relative level between the guard tone and the subsequent voice is set by firmware. The problem is that there is no relationship between the level generated by the Spectra-TAC tone keing module and the voted audio. Worse, there is no way to adjust it.
What happens is that even if you set the voted audio and the console voice audio exactly the same, the voter keying tones will not be the same as the console's keying tones. This results in inconsistent trasmit levels depending on where the initial key up comes from.
If that sounds like your problem, I could see if I can find my notes on what we did to solve it.
Does your 'buzzing' issue sound like guard tone bleed through? If so, check to see if JU-10 is 'IN' on the command module. That will enable the notch filter full time.
I have been involved with systems of this type [Spectra-TAC with consoles connected to tone proiority] I did hear occasional complaint of no key up. I never had a chance to identify the problem but I suspected a possible timing situation where the priority module would get it wrong and the base transmitter could drop out.
As far as 'the way it sounds'. We did have one issue that Motorola never addressed. These systems were MSF5000 based but the MTR may have the same issue. The new base stations have AGC on the wire line. It sets the level for an entire transmission based on the level of the high guard tone at the beginning of each PTT.
This process works fine for the console because the relative level between the guard tone and the subsequent voice is set by firmware. The problem is that there is no relationship between the level generated by the Spectra-TAC tone keing module and the voted audio. Worse, there is no way to adjust it.
What happens is that even if you set the voted audio and the console voice audio exactly the same, the voter keying tones will not be the same as the console's keying tones. This results in inconsistent trasmit levels depending on where the initial key up comes from.
If that sounds like your problem, I could see if I can find my notes on what we did to solve it.
Does your 'buzzing' issue sound like guard tone bleed through? If so, check to see if JU-10 is 'IN' on the command module. That will enable the notch filter full time.
voter
I have 3 voted MTR2000 3 RX'er and 1 tx, systems working now. But I use the Doug Hall Voter. Works great and the audio is very good.
-
radiodarrell
- Posts: 3
- Joined: Tue Dec 30, 2003 11:12 am
MTR2000/follow up
Thanks guys for your input, It is very helpfull! As for JU-10 on the command module, it is IN!...The problem was that during the "hang time" after a transmission..(from a unit in the field) You would hear a "buzzing" sound. The funny thing is, This did not happen with the old micor receivers, Over the last 6 months, I replaced the micors with the new MTR's (one at a time, over a couple of months) And as I did, the noise came up one new receiver at a time! If I have the "notch out" switch on the command module in the "notch out"position, (to the right) The noise pretty much goes away! I also have a 1 second "hang time", even though I have the jumper on the command module set for 0 seconds. The tone keying module has a jumper..(JU2) that says OUT FOR NO HANG TIME, but if I take it out, The console won't key up the transmitter! Any more input?.........Thanks in advance!.......Darrell
As for the int. Tx problem, the tone priority module may need extended HLGT. The standard 120ms may not be enough. There is a standard SP for extended HLGT. You can order increased time in 10ms steps. I worked on a system that had a Spectra TAC comparator that required 140ms HLGT to work correctly. The SP involves replacing the firmware chip in the BIMs that need the extra time.
Good Luck!
-SZ
Good Luck!
-SZ
Had a problem with intermitent key up failure on a Quantar. Found that if either the console or the SpectraTec attempted to key the Quantar while it was transmiting the P/L reverse burst the key command would be missed by the Quantar.
It's hard to believe how many times that the console would attempt to answer just at the instant that the repeater was attempting to unkey but it was happening about 10 times an hour when it was busy.
I got Big M to admit there was a problem and 1 flash upgrade later it was fixed. Took way to long to find but at least it's fixed
It's hard to believe how many times that the console would attempt to answer just at the instant that the repeater was attempting to unkey but it was happening about 10 times an hour when it was busy.
I got Big M to admit there was a problem and 1 flash upgrade later it was fixed. Took way to long to find but at least it's fixed
Cause Motorola said so that's why