Reading and writing search groups is a similar process to reading and writing channels. The only real difference is that the information isn't the same. This can already be done from the command-line interface, just not the GUI. The same GUI code can mostly be reused for both channels and search groups, but it needs to be made more flexible.

The goal is to systematically instruct the scanner to jump to individual channels while monitoring the line in audio for something other than silence. (How to detect non-silence isn't entirely clear, but as a very crude start, applying certain heuristics to the bytes received from /dev/dsp would likely be sufficient.) This would not only provide a (potentially) more customizable mode of scanning, but would also allow the software to analyze the "interestingness" of different frequencies, based on how often a signal was detected throughout the course of one or more entire days of continuous operation. The thought is that it could be a user-definable option whether the scanner should pause to listen or not when it picks up a signal. The potential advantage of NOT stopping to listen is that it would facilitate the unattended analysis better. The end-goal is to have a ranked list of frequencies from "most interesting" to least interesting" along with other data, so it can be decided which ones to monitor.

The current implementation is restricted to only the most important features (the ones that I believe are significantly eased or enhanced through use of a computer vs. being done on the device itself). However, supporting all scanner programming features would be nice anyway.

It was already my intention that Device::SerialPort should not be required, but the implementation of direct I/O with the device was very buggy. Device::SerialPort works very well, but since it is not necessarily installed by default, providing a reliable alternative would be nice. The buggy alternative still exists but is currently disabled.

Although this seems like a pretty safe bet in most cases, it's conceivable that the device would not appear as /dev/ttyUSB0, but perhaps /dev/ttyUSB1, or maybe even /dev/ttyS0 or something entirely different. Part of the automatic driver setup should be determining which device in /dev is the result of the newly loaded usbserial driver and using that device (perhaps falling back to /dev/ttyUSB0 as a "best guess").

As it is now, plain perl data structures are used. This works fine, and is probably more efficient, but it's a sloppier design. Turning rowinfo and multi-rowinfo into objects that are self-validating would likely make the calling code considerably cleaner by hiding the underlying data structure and focusing on actions.