> 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
errors!
Tree
--
FAQ on WWW: http://www.contesting.com/trlogfaq.html
Submissions: trlog@contesting.com
Administrative requests: trlog-REQUEST@contesting.com
Problems: owner-trlog@contesting.com
Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
|