doug408
Member
- Joined
- Dec 13, 2004
- Messages
- 59
hit counts
I had almost exactly the same idea. Let's suppose a new trunking system is coming on line. Suppose I know I will want to monitor it but do not know what talk groups will be used, or how. So I park my PSR-500 in the corner for a week, letting it collect info 24/7 on what talk groups are in use. I can then go back and listen to these later (possibly with the help of others) and try to figure out how they are used (and report that to the RR database team for the benefit of others).
If I could just enter a TSYS and a WILDCARD TGID, and the PSR-500 would be smart enough to automatically NEW a TGID for me each time a WILDCARD matches a TGID that is not otherwise in use (including incrementing the hit count in the TGID entry regardless of whether or not it is new and perhaps not waiting for the transmission to finish before moving on) then this becomes a much simpler exercise. By sorting the TGID counts (perhaps after uploading the hit count data to WIN500, PSREdit or ARC500) I could also focus on first identifying the talk groups that have the most traffic, then perhaps temporarily lock those out until the less frequently used ones are identified.
[That reminds me of another question that I don't think I saw documented anywhere. How many bits wide are the hit counts, and if they overflow, do they wrap or just stop at the maximum value?]
A similar approach might be useful with SWPR searches. If, during a SWPR search, the PSR-500 finds an active frequency, in this mode it would just STOR it (if not already stored), increment the hit count and move on quickly, regardless of how active that channel is. (Though I suppose this creates some ambiguity in the meaning of hit counts if the search wraps back to the same frequency while a long transmission is active. Fortunately, it's not really important if the hit count is 160 or 6600; just that it's "a lot" or "a few" or "none.")
For both of these, this would imply the ability to specify a 'scratch' scanlist to hold the newly discovered entries, and it might be desirable to flash the LED and temporarily light up the screen the first time each NEW TGID entry is discovered.
I haven't yet given much thought to this whole idea, but it sounds promising and within a reasonable difficulty of programming. It would greatly simplify the process of discovering how a given trunked system is used.
I had almost exactly the same idea. Let's suppose a new trunking system is coming on line. Suppose I know I will want to monitor it but do not know what talk groups will be used, or how. So I park my PSR-500 in the corner for a week, letting it collect info 24/7 on what talk groups are in use. I can then go back and listen to these later (possibly with the help of others) and try to figure out how they are used (and report that to the RR database team for the benefit of others).
If I could just enter a TSYS and a WILDCARD TGID, and the PSR-500 would be smart enough to automatically NEW a TGID for me each time a WILDCARD matches a TGID that is not otherwise in use (including incrementing the hit count in the TGID entry regardless of whether or not it is new and perhaps not waiting for the transmission to finish before moving on) then this becomes a much simpler exercise. By sorting the TGID counts (perhaps after uploading the hit count data to WIN500, PSREdit or ARC500) I could also focus on first identifying the talk groups that have the most traffic, then perhaps temporarily lock those out until the less frequently used ones are identified.
[That reminds me of another question that I don't think I saw documented anywhere. How many bits wide are the hit counts, and if they overflow, do they wrap or just stop at the maximum value?]
A similar approach might be useful with SWPR searches. If, during a SWPR search, the PSR-500 finds an active frequency, in this mode it would just STOR it (if not already stored), increment the hit count and move on quickly, regardless of how active that channel is. (Though I suppose this creates some ambiguity in the meaning of hit counts if the search wraps back to the same frequency while a long transmission is active. Fortunately, it's not really important if the hit count is 160 or 6600; just that it's "a lot" or "a few" or "none.")
For both of these, this would imply the ability to specify a 'scratch' scanlist to hold the newly discovered entries, and it might be desirable to flash the LED and temporarily light up the screen the first time each NEW TGID entry is discovered.
I haven't yet given much thought to this whole idea, but it sounds promising and within a reasonable difficulty of programming. It would greatly simplify the process of discovering how a given trunked system is used.
kikito said:
