To further revise my solution, I would like to add the following:
The more I think about it, this scanner really IS the best scanner for searching out new systems. Of course, my solution is considered theoretical until someone with a PSR-800 actually implements it, but there's no reason why it wouldn't work. The reason this scanner would work so well for this is that due to its virtually unlimited storage space, there's actually an incentive to actually adding the new TSYS arrangements into the current V-scanner after all. Almost nobody actually needs 200 scanlists, so why not implement the following:
The following would have channels allocated for 80 single-frequency LTR TSYS objects, ordered sequentially:
Scanlist # 101 - 451 MHz LTR: (451.000 - 451.9875, 12.5 KHz increments)
Scanlist # 102 - 452 MHz LTR: (452.000 - 452.9875, 12.5 KHz increments)
.....continuing thru 453, 454, 460, 461, 462, 463, and 464 for Scanlists 103-109...
The following would have channels allocated for 80 single-frequency Motorola TSYS objects, ordered sequentially:
Scanlist # 110 - 851 MHz Mot: (851.000 - 851.9875, 12.5 KHz increments)
Scanlist # 111 - 852 MHz Mot: (852.000 - 852.9875, 12.5 KHz increments)
... continuing on...
There's really no reason why, with unlimited storage space, you couldn't set up ALL possible TSYS objects to cover LTR, Motorola, and P25 for all of the associated trunking bands (450-470, 851-869, 700 MHz, 380 MHz, even VHF) in the CURRENT V-scanner profile. Granted, it may take you a while
to locate the correct TSYS object, depending on how the browser is set up, but the fact remains that it would already be programmed into your scanner and would really just be a matter of adding the correct TSYS object to an active scanlist, unless you were just scanning the entire scanlist.
And the great thing about this arrangement is that if you were travelling somewhere and wanted to search out new systems, you could actually just enable the particular scanlists for the correct frequency ranges and trunking types that you're searching for. So if you suspect there may be some UHF LTR systems nearby, you could just enable the scanlists for 450-470 MHz LTR and go! The scanner would (theoretically) only stop on active frequencies, and then automatically determine the LCN and scan the channel for active talkgroups. I doubt that speed would be an issue since if I am correct, the scanner would only spend time "scanning the system" if it actually gets an active transmission. It may be required, however, to scan those segments in smaller increments, like 461-465 MHz instead of the entire 450-470 MHz band at once. This is because the scan rate is listed at 70 channels per second, outside of trunking, and so it just wouldn't be feasible to scan too large of a segment due to the time it would take to scan the entire thing.
I'll bring up another side topic now, related to the issue of whether the PSR-800 is really the best scanner for searching out new frequencies. Of course, the audio-recording feature alone makes it incredibly valuable for this purpose, as you can leave the scanner unattended and have it working for you while you are busy doing other things. But there is another issue that has been plaguing me as I determine whether or not to invest in one of these scanners...
The question, which may or may not even be an issue, has to do with the software not allowing any kind of sorting for channels. Now I honestly don't know if it actually applies to conventional frequencies or not, but I noticed that you apparently can't sort talkgroups logically. It appears that the software/scanner sorts the talkgroups by the binary talkgroup ID, making it impossible to browse objects in the scanner's browser in a logical order like Ch 1, Ch 2, Ch 3, etc. If I am incorrect on this, please feel free to correct me.
Where this actually becomes a problem is in searching out new users that share a frequency with other users. Take, for example, a scenario where you are in a shopping center. Stores typically use 467.850, 467.875, 467.900, and 467.925 for common frequencies, setting up different PL/DPL tones for their own use. Sitting in a parking lot can sometimes yield five or more different users sharing the same frequency. My usual method is to arrange my frequencies like this:
467.850 251 DPL - Toys R Us
467.850 532 DPL - Michael's
467.850 Search - ???
This would arrange the scanner so that if someone keys up on 467.850, it would identify it as either Toys R Us or Michael's, or it would show up as a new frequency and display the tone. This kind of arrangement is fairly necessary to the kind of user who is always searching out new frequencies. However, if the ordering is disabled, you may end up with something like this instead:
467.850 Search - ???
467.850 251 DPL - Toys R Us
467.850 532 DPL - Michael's
And now, no matter who shows up on 467.850, it will show it with the tone on the search channel, leaving you to rely on your own memory or on a written list to keep track of who is using each freq/tone combination. I believe I have a solution to this problem as well, however, and it has to do with scanlists. Again, if I am incorrect, please feel free to say so, but I believe scanlists are scanned in the order of their own numbering, so that scanlist 102 would be scanned just before scanlist 103, if both are active. In this way, if you had extra scanlists available, you could allocate each one with one channel of a specific freq/tone combination, and save the last one for searching. That way, you would force the scanner to scan the channels the way you want it to, saving the search channel for last.
Having noted that there really are solutions to the issues of not being able to add TSYS objects and not being able to order conventional channels, I have to say that if these solutions work 100%, the PSR-800 really IS the best scanner for searching out new frequencies and trunked systems. I would love to hear what others think of all this...
