Squelch tail on MSF 5000

whatnext · Post by **whatnext** » Thu Nov 27, 2003 12:30 pm

I have an MSF 5000 with a Connect Systems TP 154 tone panel on it.. I have it interfaced as per Connect Systems and this board..

I have a problem with a long squelch tail (25ms+/-) on the PL decode.. DPL is OK due to the Turn off code being sent by the subscriber units..

I have tried the COS level adjustment with no help.. The COS line is going to TP 6 which seems to have hysteriesis on it..

Any suggestions are welcome..

Post by **batdude** » Thu Nov 27, 2003 3:16 pm

this has been discussed at length both here and on repeater-builder (yahoo group)

bottom line

in some cases, you can't eliminate the tail.

is this an analog or digital station?

doug

RKG · Post by **RKG** » Thu Nov 27, 2003 5:52 pm

Try setting the repeater tail for 2 seconds (*nnn#07#20#) and disabling tone during tail (*nnn#02#0#). (These are per user commands, where nnn represents the user number; use 999 to gang for all users.) This should cause the repeater to continue sending freq w/o tone long enough for most portables and mobiles to squelch their audio.

whatnext · Post by **whatnext** » Fri Nov 28, 2003 6:01 am

The problem is on the release of the PTT on the subscriber unit.. The repeater (MSF) Rx has a lag on the COS line which causes the TP 154 to hold the RX audio line open for a split second.. Thus allowing the discriminator noise to be repeated until the COS line shuts off..
This is an analog MSF 5000..

The TP 154 works like a champ.. Just want to kill the squelch tail..

Has any one added a delay line on an MSF before??.. If so, any quirks??

Thanks,
Dave

kcbooboo · Post by **kcbooboo** » Fri Nov 28, 2003 6:21 am

No delay line, but I did interface a CAT-200 repeater controller, with their DL-1000C audio delay board, to an MSF5000 digital-capable station, and also experienced a very long squelch tail on PL signals generated by non-Motorola radios. Something like 250 mSec delay was needed to almost eliminate the noise. The next setting, 500 mSec, was too long in my view.

Not sure if it's the internal microprocessor algorithm for decoding the tone, or something in the PL filtering section, thats causing the longer-than-desired delay. If it's the micro, nothing we can really do about it.

Bob M.

apco25 · Post by **apco25** » Fri Nov 28, 2003 9:01 am

THis is one of hte primary reasons I don't like aftermarket repeater cotnrollers......

kcbooboo · Post by **kcbooboo** » Fri Nov 28, 2003 1:54 pm

This particular problem isn't being caused by the aftermarket controller; it's being done entirely within the MSF5000 SCCB. An aftermarket controller, with its own squelch and PL decoders, would NOT necessarily have this problem. At least with aftermarket stuff, you would have the ability to design it yourself so there is no long squelch tail; with the built-in controller on the MSF5000, you're stuck with whatever the Motorola engineers designed, for better or worse. For the kinds of uses the ham community seems to want, the built-in controller really gets in the way, and it's almost better not to use it if possible.

Bob M.

Post by **xmo** » Fri Nov 28, 2003 2:54 pm

"...you're stuck with whatever the Motorola engineers designed..."
________________________________________________________

But he's not using it the way the Motorola engineers designed it.

He has a Connect Systems device attached to it. That's not Motorola's problem. The MSF won't have a squench tail on PL signals, regardless of whether you are using the stock internal decode capability, the Motorola MCS [Multi Coded Squelch] or the SAM [Station Access Module]

As far as that whole 120 degree vs. 180 degree reverse burst issue - you can't blame the Motorola engineers for designing the product to work properly with Motorola subscriber units.

apco25 · Post by **apco25** » Fri Nov 28, 2003 8:42 pm

Thanks XMO, that was my point. Aftermarket controllers are known for inserting squelch tails in motorola repeaters for the following reasons.

1. Setup Programming error - someone doesn't take the time to set up the box correctly.

2. 120 vs 180 phase for reverst burst issue

3. Motorola repeater in ham service with rice burner rigs that don't even know what reverse burst is.

A nice clean quiet repeater without voice prompts, beeps, boops or squelch crashes is the way it should be......

k4wtf · Post by **k4wtf** » Fri Nov 28, 2003 11:18 pm

The local PD has TERRIBLE squelch tail on 99% of all of their units. The repeater removes PL about 75ms before dropping RF so, even my rice rigs mute fine for the REPEATER but, the portables, most of the mobiles and especially dispatch sound like absolute crap. Combine that with "untrainable" officers who think it's correct to reach up to their PSSM that is hanging on their left shoulder with their right hand, "cupping" the microphone, turning their head to the right to look at whateverthe%^# and whispering. You then have to have the volume on YOUR unit up max to hear the idiots and when they unkey, you lose another 10% of your high frequency hearing.

When ducting is in effect, we get some mixing with something local that puts a very low volume (have to strain to hear it) 1800Hz or so tone right on the input freq. I love it when that happens. It completely kills the squelch tail and since the repeater requires PL, it doesn't keep it hung up. It just removes the tail.

That might be something for you to consider if it's YOUR repeater. build a VERY low power TX on your input freq and put it somewhere that it hits your repeater with just enough to kill the squelch tail but not enough to cause hetrodyne on even your "weakest" subscriber unit.

I know... This is the jerry-rig way to do it but I'll be damned if I wouldn't love to do it to a few PS repeaters locally!

John

Post by **xmo** » Sat Nov 29, 2003 8:35 am

You would sure think that the squelch tail issue could be corrected.

As far as officers having low modulation - I have noticed that on many public safety systems. Public works - that's different - the guy driving a dumptruck knows how to talk into the mic.

I have never been sure why that is, but it's possible that it's all Motorola's fault! Most of the time that officer is talking to dispatch - not car to car. If dispatch couldn't hear him - the dispatcher would tell him to repeat his traffic. The dispatcher would keep after that until the officer got it right. At least our attack-dispatchers would!

However - Motorola builds this great AGC - Digital Level Memory system into the consoles. Pretty much everybody sounds the same to the dispatcher whether they talk up to the mic or not. Without the dispatcher to encourage good practice - the officers get used to not having to speak up.

OK, so other consoles besides Motorola have AGC, so it can't be just their fault, but that's one theory anyway.

whatnext · Post by **whatnext** » Sat Nov 29, 2003 9:03 am

Thanks for all of the comments, be it good or bad... The problem still stands.. The COS line at TP 6 has hysterisis and I dont need it.. Whether its a Moto, Zetron, Comm Spec, Connect Systems controller, The problem still remains on PL decode.. There is a squelch tail that is annoying and I want to eliminate it..

By the way, This is not a HAM repeater, It is a commercial community repeater in a rural town.. 99.5% of the current users are using MOTO JUNK (Maxtracs,CDM's,M1225's)..They all have reverse burst engineered BY MOTO engineers to MOTO specs for use on MOTO repeaters and the MOTO repeater still has the MOTO squelch tail..The other 5% are Kenwood handhelds..

Any other MOTO ideas on eliminating a POORLY engineered MOTO problem???

Post by **xmo** » Sat Nov 29, 2003 9:51 am

"...99.5% of the current users are using MOTO JUNK (Maxtracs,CDM's,M1225's)..They all have reverse burst engineered BY MOTO engineers to MOTO specs for use on MOTO repeaters and the MOTO repeater still has the MOTO squelch tail..The other 5% are Kenwood handhelds..

Any other MOTO ideas on eliminating a POORLY engineered MOTO problem?
_____________________________________________________________

This is NOT a Motorola problem - the aftermarket box is decoding the PL's - not the MSF. As indicated earlier - if you were using either of the Motorola multi-user solutions - MCS or SAM - there would be no problem.

Motorola engineering can hardly be called poor because some aftermarket device works poorly and fails to meet your expectations.

In view of your opinion of Motorola products, perhaps you should seek assistance elsewhere. Start with Connect Systems.

apco25 · Post by **apco25** » Sat Nov 29, 2003 1:12 pm

Like I said its the controller since its handling the PL decoding.

try removing the controller and using the MSF without it and let it natively decode PL.

Squelch tail will be gone.

Post by **wavetar** » Sat Nov 29, 2003 3:59 pm

xmo wrote:
As far as officers having low modulation - I have noticed that on many public safety systems.

There is an option in MTR2000 repeaters called 'analog boost', which we had enabled on a newly installed trunking system, since the Help menu made it sound like a great thing. It didn't take us long to turn it off, talk about over-modulation with the field radios! When we questioned Motorola about the feature, they indicated it was primarily for use in public safety systems, since officers have a tendency to put out low modulation (the description above of how they tend to use their PS mics is a perfect example of why). I'm not sure if this option is included in MSFs & Quantars or not. Might solve some systems issues.

Todd

Post by **xmo** » Sat Nov 29, 2003 5:36 pm

'Analog boost' is an RSS option in Quantar. It basically duplicates the effect that you had on earlier radios like Micor where the book told you to set the repeater level for modulator sensitivity +6 dB.

Most of us like to set repeaters up for 3KHz in = 3 KHz out, but you sometimes need that boost for public safety systems.

I actually had to add a couple dB "gain" through the USCI on our simulcast system because of the officer low modulation issue. When the repeated deviation is also low it is even harder to copy on a simulcast system in overlap areas.

Nand · Post by **Nand** » Sat Nov 29, 2003 7:04 pm

whatnext wrote:Thanks for all of the comments, be it good or bad... The problem still stands.. The COS line at TP 6 has hysterisis and I dont need it.. Whether its a Moto, Zetron, Comm Spec, Connect Systems controller, The problem still remains on PL decode.. There is a squelch tail that is annoying and I want to eliminate it..

By the way, This is not a HAM repeater, It is a commercial community repeater in a rural town.. 99.5% of the current users are using MOTO JUNK (Maxtracs,CDM's,M1225's)..They all have reverse burst engineered BY MOTO engineers to MOTO specs for use on MOTO repeaters and the MOTO repeater still has the MOTO squelch tail..The other 5% are Kenwood handhelds..

Any other MOTO ideas on eliminating a POORLY engineered MOTO problem???

If you are using TP 6 now, you could change or remove the 2.2uF capacitor C1562 connected to pin 3 of U 1552A, or jumper diode CR1530 instead or do both.

The delay you see on closing the squelch is caused by the components between U1551C and U1552A. The capacitor will charge quickly through CR1530 and R1566 when U1551C pin 10 goes low and discharge slow through R1565 when this pin goes high. This causes a delay on squelch closing.

It surprises me that you feel a need to criticize the Motorola engineers without the ability to do your own re-engineering in the above circuitry.

Nand.

Will · Post by **Will** » Sun Nov 30, 2003 4:47 pm

Darn it, Nand IS right again..

BUT you shold be using the squelch circuirct to do the COS, it has a MUCH faster squelch action... NOT the COS........

whatnext · Post by **whatnext** » Mon Dec 01, 2003 4:40 pm

Thank You NAND.... You are true technician... Not a "book tech"..

I will try the component changes you suggest..

The critisisim was driven by the comments from the " Moto Techs" spouting off about all the "Rice rigs"and "Ham" repeater controllers.. The problem is between the Moto COS circuit and the Connect Systems TP154.. The hysterisis you described is what is causing the squelch tail..

The MSF as a single user repeater worked as designed, but I had to change it to a community, multi user repeater which called for the TP154.. and the problem became apparent then.

Thanks again,
Dave

whatnext · Post by **whatnext** » Mon Dec 01, 2003 4:45 pm

Thank You NAND.... You are true technician... Not a "book tech"..

I will try the component changes you suggest..

The critisisim was driven by the comments from the " Moto Techs" spouting off about all the "Rice rigs"and "Ham" repeater controllers.. The problem is between the Moto COS circuit and the Connect Systems TP154.. The hysterisis you described is what is causing the squelch tail..

The MSF as a single user repeater worked as designed, but I had to change it to a community, multi user repeater which called for the TP154.. and the problem became apparent then.

Thanks again,
Dave

kcbooboo · Post by **kcbooboo** » Mon Dec 01, 2003 5:13 pm

I wish to point out that the components in the circuit described by NAND will affect the carrier squelch open and close times. The presence, or lack, of PL/DPL would over-ride the gated audio circuitry elsewhere on the SCCB, so while the test point being mentioned may indicate a closed squelch faster than before, it may also be more susceptible to flutter and other mobile signal degradation.

Somewhere I thought the original post was more concerned with a long squelch burst when a non-Motorola radio unkeyed. As I recall, the carrier squelch circuit closes very fast upon loss of signal, especially a strong signal, so that would not produce a long squelch burst. The PL decoding, however, probably is being done in the microprocessor, and if the engineers designed it to produce a long tail when no reverse burst is present, there isn't much one can do except decode the PL themselves.

I could run a test on my MSF5000 and see just how fast the squelch burst is when I've disabled PL decode. Something tells me it'll be on the order of milliseconds, as compared to the hundreds of milliseconds the same test would produce if PL was present in the signal.

Or am I completely missing the boat (or object) here?

Bob M.

Nand · Post by **Nand** » Tue Dec 02, 2003 12:07 pm

kcbooboo wrote:Or am I completely missing the boat (or object) here?

Bob M.

Dave wants to use the slow decay squelch for a COR. TP6 can provide this when you circumvent the RC delay circuit made up with C1562, R1565, R1566 and CR1530. These components cause TP6 to go quickly high (un-squelched) but slowly low (squelched). Other than that, the squelch circuit is like any typically other one.

The MSF5000 also has a separate adaptive squelch circuit that functions similar as the famous Micor squelch used for audio. In the MSF, this circuit is controlled by the microcomputer to be either adaptive or not.

Nand.

kcbooboo · Post by **kcbooboo** » Wed Dec 03, 2003 9:24 am

The original poster said:

"I have a problem with a long squelch tail (25ms+/-) on the PL decode.. DPL is OK due to the Turn off code being sent by the subscriber units.."

so I "assumed" that it was the long squelch on PL decode that I also have on my MSF5000. Without PL enabled, the carrier squelch is nice and quick, and if that's due to the adaptive circuit/program, so much the better.

Perhaps his external hardware is also looking at a COS line and doing some form of AND or OR function with the PL decode logic. Not being familiar with his outside circuitry, I can't offer much more help.

Sorry if I confused anyone.
Bob M.

Post by **batdude** » Wed Dec 03, 2003 3:37 pm

the biggest problem with using some kind of "and" squelch with the built in MSF controller is that the only way to get a PL detect signal is using a wildcard and taking it off the muxbus.

of course, i was always under the impression that if you programmed the MSF as a CSQ BASE STATION that most of these problems completely went away since the outboard controller takes care of PL decode.

i had a TP154 on my old micor station - i had to use DPL only b/c the PL decode circuitry would false terribly when the band was open on GMRS...

d

whatnext · Post by **whatnext** » Wed Dec 03, 2003 4:52 pm

Well we are on track.. The MSF is programmed as a carrier squelch base station.. The TP 154 does ALL of the required PL/DPL encoding and decoding.. The only " MSF " feature used is the COS voltage at TP6 which tells the TP 154 that the carrier has dropped and to close the audio input..

The long squelch tail is actually as NAND has described, A slow decay on the COS line inside the MSF SCCB board..

I have the mod info in my vehicle and plan to try it the weekend while up at the site..

Again, Thanks to all for the input and I will let ya know what I find.

Dave

RADIOMAN2002 · Post by **RADIOMAN2002** » Fri Dec 05, 2003 1:42 pm

I havn't played with a MSF5k in a while. I have installed Zetron 38's with no problem, but I do know that the TP-54 has no internal squelch circuit, so you have to hunt for it on the MSF controller board. Does the radio have a long squelch tail when the speaker is on, if not try and find that point, probably somewhere in the audio section. It might have a quicker response. Or if all else fails, use the on board MSF5k audio path for repeat audio and use the TP-54 to enable the TX and pl detect functions.

MOEtorola · Post by **MOEtorola** » Fri Dec 05, 2003 6:05 pm

I INSTALLED A AUDIODELAY MODULE DIRECTLY INTO THE TP-154+ AND IT WORKS GREAT. THE SQUELCH CRASH I HAD WAS DUE TO THE TP-154+.

whatnext · Post by **whatnext** » Sun Dec 07, 2003 8:45 am

MOEtorola... What delay board did you use??
Dave

MOEtorola · Post by **MOEtorola** » Mon Dec 08, 2003 2:32 pm

the delay board i used was made by RLC the part number is RLC-ADM they run about $60 dollars i believe.

whatnext · Post by **whatnext** » Wed Jan 14, 2004 9:20 am

NAND... you had the solution... Thanks !!

Nand · Post by **Nand** » Wed Jan 14, 2004 9:44 am

I was wondering how this turned out. Glad to hear about your results and glad to be of help.

Nand.

Squelch tail on MSF 5000

Squelch tail on MSF 5000

msf

pl detect

GOT IT !! Thanks