[Elecraft] Feature request
Ian White GM3SEK
gm3sek at ifwtech.co.uk
Mon Feb 16 17:33:36 EST 2009
Joe Subich, W4TV wrote:
>
>I have to disagree ... quick split would cause too may
>other problems like losing the frequency if one has
>already set VFO B (subreciever) to the desired place.
>
>Except for actions explicitly designed to change frequency
>(tune the VFO, change band, recall a memory, etc.), the user
>interface should never change the frequency and it should
>never change the frequency of the "other" VFO.
>
This shows why everything needs to be an OPTION - there are so many
different operating styles.
The industry-standard "quick split" function is designed for people
whose operating style is to tune the DX station on VFO A, and then want
a quick way to set the up the rig to call on a split frequency using VFO
B (and the sub-rx if available).
Quick split has become an industry standard because significant numbers
of users do find it valuable, for two major reasons:
1. Speed
2. Reducing the risk of errors - above all, avoiding the cardinal sin of
transmitting on the DX frequency.
Users of quick split know all about its disadvantages too. Obviously,
quick split will not be suitable for all circumstances (it would be
great to have the option to make it a PF toggle). Obviously, any
existing VFO B frequency will be lost. Also any pre-configured split can
only be an individual operator's best guess, so it needs to be
configurable; but *any* offset is better than zero - see point 2 above.
Even people who value quick split will only use it when the advantages
override those disadvantages. They are also aware of others who would
not like this function, wouldn't need it, or simply can't see how any
sane person could ask for such a thing. That's fine, because it is being
requested as an *option*. If Elecraft does decide to introduce it, there
would be no adverse impact on anyone who doesn't wish to enable it.
It may also be well to remember that the *only* purpose of discussion
about feature requests is to set out the issues for Elecraft to
consider. The rest is up to Elecraft.
--
73 from Ian GM3SEK
More information about the Elecraft
mailing list