UniTrunker / "phantom" channels?

[chief21]

I'm monitoring a Motorola system that is in the process of being upgraded to a multi-site configuration... possibly even SmartZone.

As in the past, only five channels are actually being used. However, over the space of a day or two, UniTrunker is displaying a full screen of phantom channels that are never used. Eventually, there are so many channels displayed that they run into (and through) the command area at the bottom of the screen and prohibit any other information from being shown.

Can anyone offer any suggestions as to how I might be able to prevent these superfluous channels from being displayed? I've cycled through all of commands and was unable to find anything that seemed to apply.

Thanks in advance for any help you can offer.

John

 

[Jay911]

Is this a clean signal (i.e. strong, no dropouts/fadeouts)? I get such frequencies on my home setup where the signal occasionally goes "out of range" and would be overrun by static, etc.

 

[chief21]

Hi, Jay -

Most of the time, the signal hovers around 75% but it DOES fade in and out from time to time. I doubt that the signal ever really goes away entirely (to static)... I think it's more a case of not always maintaining the signal level required by UniTrunker.

I'm wondering if there might be some setting that I've overlooked that will prevent these frequencies from displaying.

Is this a clean signal (i.e. strong, no dropouts/fadeouts)? I get such frequencies on my home setup where the signal occasionally goes "out of range" and would be overrun by static, etc.

 

[Jay911]

Personally, I would LOVE to have an option which disallows any new frequencies (and possibly other elements, i.e. talkgroup IDs, radio IDs, etc) from being added. My main concern is the frequencies/channels - I have a system where I KNOW I have all the frequencies entered, and would like to have the system consider any other frequencies found as bogus. That way, if I have a bad signal for a few hours, it wouldn't generate 40+ bad bogus freqs.

 

[SCPD]

I know Jay has been wrestling with this problem for a while.

The program has some immunity from bogus continuations.

Here's a quick way to nuke your channel list - delete the site where this occurs. Your group, system, and radio data remains intact. This also removes the valid channels but the program can re-discover those when it rebuilds the site info.

[F]ind -> Ste -> (type the current site #) ... press return. From the site editor, select [Del]ete. Poof - all site specific data is gone (including site label and bandplan).

(You can also hand-edit the HZ file if you don't like this).

John - you might want to try the above as a crude work-around. The program has a logging feature to record the control channel events to a file. If you can capture a flurry of these bogus channel additions to a log file (ie. have logging turned on when it occurs) - I can use the log file as a test pattern for validating new filtering schemes meant to solve this problem.

 

[chief21]

Thanks for the suggestions. I've been deleting the HZ file and letting the program re-build the information but within a day or so (at the most), it seems we're back up to a full screen of superfluous frequencies.

I'll try the log file suggestion for a period of time and see what we come up with. I know that you've cautioned others that this file can grow very big very quickly.

John - you might want to try the above as a crude work-around. The program has a logging feature to record the control channel events to a file. If you can capture a flurry of these bogus channel additions to a log file (ie. have logging turned on when it occurs) - I can use the log file as a test pattern for validating new filtering schemes meant to solve this problem.

 

[SCPD]

I know that you've cautioned others that this file can grow very big very quickly.

100+ megs per day. When left to run for more than a day, the program compresses the previous day's log to about 5 megs. Otherwise, 10 days' logs would eat 1 gig of disk space.

 

[chief21]

O.K. - I've captured a log file as you suggested. I have verified a number of lines that appear to contain bogus frequencies. What should I do with it now?

I know Jay has been wrestling with this problem for a while.

If you can capture a flurry of these bogus channel additions to a log file (ie. have logging turned on when it occurs) - I can use the log file as a test pattern for validating new filtering schemes meant to solve this problem.

 

[SCPD]

O.K. - I've captured a log file as you suggested. I have verified a number of lines that appear to contain bogus frequencies. What should I do with it now?

If it's small ... post here as an attachment. It it's too big ... email works for me.

-rick

 

[chief21]

Hi, Rick -

I'll shortly be sending you an 8 MB piece of the Unitrunker log (via e-mail) that has a number of bogus channels in it. As far as i can tell, only five channels are currently active on this system but, as you know, numerous channels are being displayed in Unitrunker.

The "correct" system channels are...

857.7625; 858.7625; 859.7625; 860.7625*; 860.9875

Please let me know if you need anything else from me. Thanks for your continuing commitment to this innovative and useful application.

- John

If it's small ... post here as an attachment. It it's too big ... email works for me.

-rick

 

[SCPD]

Got the file.

The decode rate is very, very low. Is this system far away? What are you using for a discriminator tap?

I'll see what I can do. Thank you.