dfw1417 said:
The 996T is FULLY computer programmable even more so than the 796 especially since we can now control the squelch and volume controls!
Although I do like the addition of volume and squelch, I respectfully -- but strongly disagree, but I'd love to be disproven. The fact that you have to go through so many hoops just to change the channel, and even then you aren't really changing the channel, disproves the claim that the 996 is effectively controllable. I submit that you cannot really go to a particular channel on the 996T. You can fake it (and at that, only for conventional, not trunked, channels), but not really select a channel, like you could do (by channel #) on previous models.
There are many other things that cannot (at least reasonably easily or predictably) be done, and almost nothing can be done without putting the scanner in program [PRG] mode, which completely disables the scanner's use as a scanner, at least for the time it takes to process the command. [The only documented commands that work in non-PRG mode are GID, KEY, QSH, STS, GLG, MDL, VER, VOL, SQL, P25, GCA, and RMC.] I don't mind using indeces instead of channel numbers, but having to disable the scanner while I look something up is crippling.
Start with the basics. Turn the 996 on or off programmatically. Nope. POF (kinda funny if you speak Brit-english -- P-Off] is crippled in the 996, and there's no "PON" (hehe).
Stop the scanner from scanning. Programmatically hit the "Hold" button? But you first must find out if the scanner is already scanning, or else hitting that button will act as "Resume." And there is no deterministic way to tell if the scanner is scanning, without doing some crazy parsing of the STS command's return, unrealiable at best. GLG and GID don't do it.
Read the contents of a memory. Or of anything, for that matter. Not without putting the scanner in PRG mode. [You've said you can extract everything from your
program's current "copy" of the scanner's data, but that is
not "controlling the scanner." The fact that programmers have to resort to building a virtual scanner in memory and controlling the virtual, rather than real scanner, demonstrates that the real scanner is not being controlled. And how to handle if the user changes something from the keyboard, and not your program? Unlike, e.g., Kenwood radios, the scanner does not echo to the program user changes, so there is no way to guarantee that you're keeping sync'ed up.]
[Kenwood got this {almost} correct; I'd commend their model to Uniden's review. KW's programming model is entirely asynchronous. Any changes to the radio's state, be they from the user {e.g,. from the front panel}, from the computer {e.g., by programming commands}, or even from the real world {e.g., from a signal coming in} are echoed immediately to the computer.]
The whole point of computer-control of the scanner is, IMHO, to be able to
add functionality to the radio that you
can't do from the keyboard. The whole paradigm of constraining computer "control" to programatically "looking at" the display and "pressing" keys is fundamentally inconsistent with this, as it is necessarily limited to providing the user with next-to-nothing more than he could do himself from the real radio. My 2.1 cents.
...R
