Batboard

We recently added another channel to our LTR system. Controller is a CSI LT-4200 and the radio is a TKR-750, same as the rest of them. Mobile radios are almost entirely TK-7180s. The problem is that when a radio requests a channel on this trunk, the radio has a hard time decoding the DCS and realizing it has been granted a channel, hence it goes kerchunk-kerchunk-kerchunk until it either decodes the DCS or gives an intercept tone to the user. Other times it will work fine. The problem seems to be more prevalent when the signal is weak.

I set up this controller per the instructions. For DCS deviation I used our 1200S service monitor and set it to be the same indicated deviation as another trunk which was set up for us by a profesional in the business, that was about .85 KC (it is narrowband).

I am thinking there may be some kind of distortion or something that we are not noticing here. Maybe we need to increse the gain of the DCS from the controller and decrease it in the radio or something along those lines. Although if memory serves me the controller adjustment is almost maxed out to get the right level.

Thanks,
Birken

My two bits worth:
I have seeen this on a system using an MSF 5000.
The "VCO compensation" was out of adjustment.

I am not familiar with the Kenwood, however your problem seems to be the same.

See if the digital code has nice flat top and bottom, or if it is "slanted"

Hopefully Kenwood has a VCO compensation procedure.

The compensation is required because during very slow speed digital modulation, the Synthesyzer loop is going to do what it is supposed to do: correct the VCO output frequency.

This is seen as a slope in the signal that is supposed to look like a square wave.
The compensation adjustment corrects this problem.

The mod scope looks much like the procedure for compensating a X10 'scope probe.

Higher frequencies do not have this problem because of the time constant in the VCO loop filter.

Does the controller decode the incoming request from the radio (repeater keys up) when the radio is keyed?
If so, maybe a timing issue? There is usually a pre-key time setup in the controller.
Does it ever get channel assignment? If never, maybe a data polarity issue. Usually jumpers to set both RX and TX polarity.

Yes, the controller decodes the request just fine, which is why it begins transmitting. But the radio does not hear that when it switches back to recieve so it transmits the request again, over and over. Sometimes it will finally pick up the fact that it has been granted the channel, other times it will not, sometime on the first try it will go ahead just fine. It appears to be vaguely related to signal strength. Timing does sound like it might be worth pursuing but my main thing is that this repeater setup is identical to all the others and it doesn't perform the same. I understand about the VCO compensation idea but I am pretty sure the flat tops are pretty much level on the scope but I will definitely check again the next time I get the chance. That did help me understand what is going on a little better, they do have a section on that in the alignment but they didn't explain why.

Birken

On further thought I realize that it can't be keyup timing, because the thing continues to kerchunk as the radio repeatedly asks for permission. Timing would only cause the radio to miss the first packet, not all of them. So I will have to look elsewhere.

Birken

Do you have a good way to look at the repeater's output during the key-up? Is there a lot of frequency drift at key-up?

I have seen gear that starts out a KHz or more out, then settles to the "correct" frequency after a few hundred ms. If you have a DC coupled receiver and 'scope (or a service monitor) you can watch what the signal does as the repeater keys.

The signal may look fine in the steady-state, but at key-up may be drifting all over.

Can you swap controller and exciter - put the exciter from another channel on the controller, and see if the problem follows the exciter?

DCS and LTR are 2 very differnt signaling formats
but one can fales the other---

My two bits worth:
The signalling format is of very little concern.
It does not matter if we are dealing with DPL, LTR signalling, Motorola Secure, Motorola 6809 trunking, or digital paging.

The decoder in the receiver is supposed to have a fast "attack time",
expects to see a nice clean signal with proper wave form and amplitude.

Should the signal be corrupted with AC hum, Phase noise from the VCO,
PL tone, VCO compensation or other signalling tones, you may have problems decoding.

These problems may not be noticed in analog systems.

All good suggestions, but the problem continues to recur when the mobile repeats its request for the channel, at which point the transmitter is still on, and remains on for the second go around, and the third, fourth....

Unfortunately, business has been booming, so that I have not had any time to take a closer look at the darn thing.

Birken

we had issues similar to the "kerchunk-kerchunk-kerchunk..(ad-nauseum)" on TX that were traced back to a bad channel card in the controller cage. Couldn't tell you that much more about it, but they replaced that card...and it solved that problem
..for now.

Have not been able to determine if all the mobiles are doing it yet. But it appears that way. Don't want to piss off the customers though.

The site is decoding the mobile fine. Since it issues a channel and keys up. The mobile is not decoding the site though. Then the mobile keys up for another try at what it thought was a failed attempt, over and over until it dies usually. Occasionally after 5 or so of these it will realize it is connected also. Or it will connect on the first try. So usually it is the first try or nothing at all, but sometimes it will on subsequent tries.

Sorry I have nothing new to report on this though. I really need to get back up there and try some things.

Birken

I am with Bernie on this one,

I have experienced the same problem on an MTR2000 / Radier controller before going through the full aligment procedure outline in the raider manual. You need to have a nice square wave when looking at the TX on the service monitor. I was experiencing the exact same problems even though I had thought I had aligned it properly using the COM-120 - another crack using the IFR-1200S revealed one ugly data stream.

See if the digital code has nice flat top and bottom, or if it is "slanted"

Hopefully Kenwood has a VCO compensation procedure.

The compensation is required because during very slow speed digital modulation, the Synthesyzer loop is going to do what it is supposed to do: correct the VCO output frequency.

This is seen as a slope in the signal that is supposed to look like a square wave.
The compensation adjustment corrects this problem

Well tentatively the problem is fixed. It was the VCO compensation I guess, on the TKR-750 it was listed as DQT balance. I did not know about that setting until I called the guy that helps us out, who is more experienced in this and he told me. The wave looked OK on the service monitor before but adjusting the balance really helped square it off. I will monitor for a while to see if it is truly fixed.

Birken