[Top] [All Lists]

[TRLog] Band Map Scanning

Subject: [TRLog] Band Map Scanning
From: (
Date: 7 Dec 1999 18:34:14 -0000
> There have been some good suggestions, but let's keep in mind that the band
> map has two quite different uses.  One is working multipliers from packet
> spots; the other is to make S&P more efficient with or without packet.  The
> S&P requirements are pretty minimal, and I'd like to see S&P operation kept
> simple.  There's no reason the packet-specific features can't be included, as
> long as they don't compromise the basic S&P operation.  For example, going to
> the next non-dupe should not take more than one keystroke.

There have been some good ideas thrown around and I think at least a
few of them will work their way into the next release.  However, it is
a bit overwhelming to think about them while I am in the middle of
solving the packet/multi crash bus - and the Icom read issue.  

The "QSY to the next unworked spot" sounds like a good one that will
probably be implemented as a function key command (or also footswitch).
That would be pretty sexy - just hit the footswitch to QSY to the next
guy.  For reasons having to do with how the data is stored, the QSY will
always be up.  I could wrap around at the end however.

The idea of clearing out the contents of the call window when QSYing
also sounds good - but only after we get rid of the frequency read


FAQ on WWW:     
Administrative requests:
Feature Wishlist:

<Prev in Thread] Current Thread [Next in Thread>