I'd be suspicious of any channels that are weeks old with a hit count of 1 and first / last seen timestamps that are the same.
See channels 30, 127, and 482. These may have been caused by false decodes.
Paul,
The screen name above and the name of the software being the same is not a coincidence. I do not know Mr Unitrunker personally, but I have to admire him for the amount of work he must have put in to this software, and he shares it with us for free! I wouldn't expect much, if any, support for individual questions or problems, and yet in many cases he does post in our forum with some (usually brief) information. He must make a living somehow w/ a day job, and then he does provide some support during his personal time for 50+ forums? Wow. True, it is possible that he misunderstood our issue, and it is also possible that we might misunderstand his reply. That being said, I put my complete trust in any information he does provide regarding his own software. I also feel compelled to share any knowledge I have gathered with users of our local forum, especially those users who I think very highly of such as you, Paul. I will try to clarify below what I think he means with his post.
UT, if I were a betting man I wouldn't bet on channels which had a million hits....I've discovered the count provided may be helplful for some stuff but ......this count is also tainted with things like someone turning their radio to a particular channel which registers as a "join" and when the channel on the radio is switched to a different channel or the radio is turned off it registers a "leaves."
I don't completely follow you on the first part of this. On the last part, I have not noted that a "join" or a "leave" registers as a hit. This is based on when my UT setup sees a site for the first time and/or the site is seldom used, in which cases it is easier to recognize a small change in the hit counts. I feel pretty confident on this, but I cannot verify as I don't have Unitrunker set up at the moment, but I could be wrong.
There are also false entries when one person may call dispatch from a specific RID and if there is another radio listening in with a priority flag set in their radio for this particular channel it also registers a "call" from the idle radio but no voice traffic is present in that conversation. So if one unit turns on a radio at the beginning of duty and calls dispatch with a 10-41 and dispatch responds in kind along with two radios set with priority flags there are 6 or 7 entries for that one call alone.....but only two of them are actual voice communications.
Whoa! You must be way beyond my understanding of UT. It seems like this info would require a very intimate knowledge of the Motorola trunking system, as well as UT. You might be completely correct, it's just that I don't know how you or I could know such details - what-up?
Here are some bits of info that I have noted from using UT that may or may not apply directly to your post.
At home, I normally use an older scanner w/ an audio discriminator tap and I program all the local CC freqs into it as analog channels. This of course connects to the audio-in of my computer, then UT decodes whatever data channel (aka: trunking site) I have selected. As you know, when UT first sees a data channel, it takes a few seconds to decode enough data to decide which site it is. During this time there
is activity on the "currently unknown" system, and UT names it "Adhoc" until the site is identified. You agree, right?
Whenever I change channels from one site to another, there is this same delay before UT realizes that the data stream is coming from a different site. During this time, all the activity on the new site is mistakenly logged on the old one, including any LCN's (and therefore frequencies) being used. This becomes a HUGE problem for people like you and I who are trying to keep track of frequencies and hit counts for multiple sites. I have minimized this issue by putting a zero or unused freq between all the active ones in my scanner. Now when I change channels, I pause on the in-between 'quiet' channel long enough for UT to realize that the CC has been completely lost. Then when a new CC is selected, UT sees it as a different site and does not create the false entries. Sometimes I don't pause long enough, in which case I have to click on the 'Channels' tab in UT and delete the false channels, which really came from a different nearby site.
When I travel I use newer scanners w/ direct data outputs, and the same thing happens, only worse. First, the signal tends to fade in and out as I drive, causing data errors. Then if I want to listen to the scanner as I drive, the scanner is constantly changing CC's across multiple sites. If I forget to disable UT while scanning, things get REALLY screwed up and very quickly !
I think what Mr Unitrunker meant was whether a false entry is due to what I have described or due to an error in decoding the data stream, it can usually be recognized by a very low hit count and/or the first and last dates being identical, especially if that date is at least a few weeks old. This condition would indicate a channel that showed up very few times, on one single day, and has not showed up since. The examples he used from your post were LCN's 30, 127, & 482.
Another way I indentify false entries is demonstrated in the image below. For some sites I have verified each frequency against the FCC database. When I do that, I enter the call sign as the label on each freq and mark it as confirmed. When a new freq shows up that has no label, it better have a consistently growing hit count, or it gets deleted. I know this forum has a lot of talk about UCAN freqs being used on the wrong sites and changing frequently, but I have personally found that to be the exception, not the rule. That is: 1) After I remove and keep up w/ all the false entries, 2) Now that rebanding is a distant memory, and 3) after a new site has been up and running
and in-use for a period of time. As Jon said, sometimes changes and additions are needed, and there are a few mistakes or wrong freqs in the system, but really not that many.
Some interesting points from your UT pics and mine: 1) The CC always has zero hits (it is never used for voice). This would only be true for systems like UCAN who rarely, if ever, rotate the CC freq. 2) The alt's always have fewer hits than the main voice channels --> I think the system can use them for voice, but only as a last resort if all other channels are busy. This would be a good indicator for how often a certain site is nearing max capacity - how many hits are on the alt CC's ? 3) Simulcast sites always have 1 CC and 3 alts. Other sites always have 1 CC and 1 alt. 4) Any valid CC or alt CC is updated in the data stream every second, unless the system is
very busy w/ voice traffic. Therefore, if you can decode a data stream from any given site, the CC and alts will always show up and update, even if there is no voice traffic at all. I think this is when I noted that radios can join and leave, while the hit counts do not change. I guess that makes sense, since no voice channels were used by those actions.
-B.Christensen
.
