[Elecraft] Split not available

[Joe Subich, W4TV]

> I'm going to ask you to describe a scenario where an operator who
 > desires to go to SPLIT operation actually wants to get the SPL/NA
 > response from his K3.

There is no disagreement that the nobody wants to see Split N/A.
However, your "fix" is worse than seeing that reminder than the
other VFO is on a different mode.  Simply, when one sees Split N/A,
it is a reminder to the operator that he needs to synchronize the
VFOs ... *BUT* I don't want the K3 to take that decision away from
me.  I may have the other VFO in a different mode or different band
because I want the ability to switch to it. monitor a separate pile
or band, work cross mode/cross band on VHF or some other equally
valid purpose.

Your "solution" of forcing the other VFO to the same frequency and
mode as the main VFO guarantees, that any time the user toggles
split they will be transmitting on top of the DX station ... and
if they happen to have saved data in VFO B it is gone without any
chance to get it back.

 > So, I popped VFO A over to 7024 and heard them calling and I
> Pressed and Held the SPLIT button (*STEP 1*) and guess what? I get
> the stupid SPL/NA message because VFO B is still on 14030. So what do
> I  have to do? I have to do steps 2 through 6 - AGAIN!

There are two solutions available for you that don't destroy current
capability that I (and others) rely on ... you can set VFO IND = OFF
so that VFO B will recall the last used frequency on the new band
(and by the way, retain the frequency on the old band when you switch
back) or you can program a function key with a Quick Split" function
(SWT13;SWT13;FT1; - from the K3 Utility example macros).

 > Can't you see that there is no other logical action in this scenario?

There is an illogical action ... it changes the contents of VFO B.
I don't want VFO B to change unless I specifically change it.  That
can be by a double tap of A->B, using A/B, a command from my logging
software, a macro that I know will copy VFO A to VFO B and turn on
split, etc. but *NOT* by the K3 without direct input.  If I tell the
K3 to do something that is an error (e.g., split between CW and Data)
I *want* the K3 to tell me I made an error and *not* think it knows
what I want it to do.

> If the operator has already tapped VFO A to VFO B and then Pressed
> and  Held SPLIT - nothing should change and the VFOs should not
 > be synced!

Tapping A -> B will sync the VFO frequencies ... it simply won't sync
the mode and other receiver parameters.  If the operator has tapped
then held A -> B, I have no problem forcing the same mode.  That is
not the same as forcing the same *frequency and mode* any time the
user turns on split.

If you're concerned about calling on top of the DX because of "Split
N/A", I have no problem if Split N/A remains on the display and
transmit is locked out until the user takes specific action to clear
the error (even if it is holding split again to "turn split off").

> None of what I am suggesting makes anything "arbitrary" or does
> anything "unrelated". I am not asking for any change in functionality
> as you are evidently objecting to - aside from never seeing the
> stupid SPL/NA  message.

No, your change - cause Split to synchronize VFOs instead of display
Split N/A when engaging split is an error - is making an arbitrary
change.  It *assumes* one possible course of action to clear the error
and changes the frequency/mode of VFO B (and the sub Rx if it is on)
and ignores other options.  In doing so, your "solution" allows the
K3 to make a change that the user may not have intended (error by
the K3) instead of allowing the user to make an error (transmit on
a band other than the "main receiver" band or mode).

If the user makes a mistake let the radio indicate that mistake -
turn on split but lock out the transmitter -  don't allow it to
penalize other users by doing something that it should not do
(setting VFO B or the subRX to the same frequency as VFO A/Main).
90% or more of your problem can be resolved by using VFO IND = OFF
why can't you do that rather than seek a "solution" than breaks
features that other operators use?

73,

    ... Joe, W4TV


On 2/12/2011 5:49 PM, Bob Naumann wrote:
> Well Joe, it seems you're attaching a lot of emotion to this issue, but I
> think you still miss the point.
>
> I apologize if I'm not making this issue clear enough to you, but I'm afraid
> you're attacking when you should be supporting. I therefore must conclude
> that I am just not able to communicate with you clearly and focus my
> comments on the underlying issue due to some limitation in my vocabulary and
> I apologize for my lack of communication skills.
>
> Oh, one thing I would make clear is that I am not "too damn lazy". If I was,
> I probably wouldn't bother trying to help you understand the issue that
> you're criticizing in error.
>
> In addition, all of your critiques of my suggestion are incorrect. Sorry.
> Nothing I am suggesting will change any current function or force anything
> "arbitrary" or "unrelated" to the commands we're discussing. If you think
> so, please provide support for your incorrect claims. I'm willing to learn.
>
> One last try:
>
> I'm going to ask you to describe a scenario where an operator who desires to
> go to SPLIT operation actually wants to get the SPL/NA response from his K3.
> I'm hoping that you will agree that the answer is that there is no scenario
> where an operator wants to see SPL/NA. I don't - and this is the entire
> point.
>
> Today, if his VFO A and VFO B are not already on the same band, this is what
> he gets (SPL/NA). This is not what he wants. How does that fit into your
> ergonomic rules?
>
> How does this occur? As I have described, it happens all the time. Every
> time there is a major DXpedition, I am reminded of how frustrating it is to
> get the SPL/NA message over, and over again. Most DXpeditions operate SPLIT
> - the DX station transmits on one frequency and everyone else (except the
> frequency cops) transmits somewhere else. Recently, I was trying to work the
> VP8ORK operation on 20m CW. They were transmitting on 14024 and listening up
> the band a few kHz. I was operating SPLIT with VFO A on 14024 and VFO B on
> 14030 or so. (I probably got the SPL/NA warning when I went to go SPLIT
> initially and went through all 6 steps as I described previously but that's
> not important now). After calling for a while, I saw that they were spotted
> on 40m on 7024. So, I popped VFO A over to 7024 and heard them calling and I
> Pressed and Held the SPLIT button (*STEP 1*) and guess what? I get the
> stupid SPL/NA message because VFO B is still on 14030. So what do I have to
> do? I have to do steps 2 through 6 - AGAIN!
>
> * Step 2 - Recognize the SPL/NA message in the VFOB display
> * Step 3 - Tap VFO A ->   VFO B
> * Step 4 - Press and Hold Split (Again)
> * Step 5 - Set the VFO B Frequency
> * Step 6 - Work the DX Station
>
> Doesn't all that seem like a lot to do when all I wanted was to go SPLIT on
> 40m?
>
> Wouldn't this be better? (Again, *ONLY* if my VFOs are not already on the
> same band).
>
> * Step 1 - Press and Hold SPLIT which also sets VFO A ->   VFO B (Please,
> please recognize that the VFO A->  VFO B should happen ONLY if the VFOs are
> not already on the same band!!!!)
> * Step 2 - Set the VFO B Frequency
> * Step 3 - Work the DX Station
>
> It is this scenario, which I imagine was repeated ad infinitum around the
> world by thousands of K3 users in VP8ORK pileups when they change bands and
> in error Press and Hold Split before they tap VFO A ->  VFO B.
>
> Can't you see that there is no other logical action in this scenario?
>
> If the operator has already tapped VFO A to VFO B and then Pressed and Held
> SPLIT - nothing should change and the VFOs should not be synced!
>
> Again, if the operator is Pressing and Holding the SPLIT button and his VFOs
> are on different bands, this is what he wants.  If he did not want this,
> then he would not have Pressed and Held the SPLIT button - would he? What am
> I missing?
>
> None of what I have described will alter your use of VFO B as "scratchpad".
> If the VFOs are configured such that they would permit SPLIT operation now
> (being on the same mode and band), there's nothing in what I'm suggesting
> that would alter that behavior so I am perplexed as to what you are so
> concerned about.
>
> I'm talking about making the K3 easier to use and reducing the number of
> steps required to change to SPLIT when your two VFOs are not already on the
> same band. Isn't this a simple enough concept?
>
> I detailed out what one must do with the confines of the current logic in
> the 6 steps I described in my previous email. If I have erred, please tell
> me what I have described in those steps that is in error.
>
> None of what I am suggesting makes anything "arbitrary" or does anything
> "unrelated". I am not asking for any change in functionality as you are
> evidently objecting to - aside from never seeing the stupid SPL/NA message.
>
> 73,
>
> Bob W5OV
>
>
>
>
>
>
> -----Original Message-----
> From: Joe Subich, W4TV [mailto:lists at subich.com]
> Sent: Saturday, February 12, 2011 3:24 PM
> To: Bob Naumann
> Cc: 'Elecraft Reflector'
> Subject: Re: [Elecraft] Split not available
>
>
>> While there may be some who on some rare occasions need VHF
>> Cross-mode AND Split at the same time, this is not a valid
>> justification for the radio to behave in the illogical way it does
>> now.
>
> The VFOs do not behave illogically.  They behave as one would expect
> by holding their band and mode information until it is specifically
> changed.
>
>> And, no, the VFOs should not be tied to each other all the time so
>   >  changing the VFO IND parameter is not the answer to this.
>
> If you expect the VFOs to be on the same band turning VFO IND OFF
> is the solution to that.  Otherwise, leave them alone until the
> operator specifically changes them.  For the radio to *ARBITRARILY*
> change VFO frequency and mode when the operator makes another
> *UNRELATED* change in operating conditions is an absolute violation
> of proper ergonomic design.  The first rule is do not cause an
> unexpected change.
>
>> There is also no need to sync the VFOs when turning SPLIT OFF and
>> that is not being suggested.
>
> But turning split off and then turning it back on will sync the
> VFOs ... it does not matter if they are snynced when split is
> turned off or turned on the result is the same.  The Off/On cycle
> results in VFOs on the same frequency ... and the lids transmitting
> on top of the DX station.
>
>> The current logic forces one to have to perform 3 completely
>> unnecessary steps to go to Split operation when VFOB is not on the
>> same band/mode as VFOA.<<<  This happens all the time!!!
>
> SO WHAT!!!  If you want both VFOs on the same band use *VFO IND OFF*.
> If you want a command that syncs the VFOs, use a macro to create a
> Quick Split option.  *DON'T* destroy current functionality because
> you are too damn lazy to tap A>B twice.
>
>> The 3 extra steps, that the current logic forces are simply a waste
>> of  time.
>> If it worked the way I am hopeful it will someday, it would eliminate
>
> No they are not.  They assure the principles of "do not do anything
> that the operator has not specifically commanded" and "do not cause
> *unexpected* operation.  *DON'T* take away current capabilities just
> because some operators are lazy.  Your "sync" VFOS when turning on
> split would exponentially increase the number of lids transmitting
> on top of the DX station ... and would eliminate the ability for
> anyone to use VFO B as a scratchpad memory all because you're too
> lazy to manually sync VFOs.
>
> 73,
>
>      ... Joe, W4TV
>
> On 2/12/2011 11:19 AM, Bob Naumann wrote:
>> While there may be some who on some rare occasions need VHF Cross-mode AND
>> Split at the same time, this is not a valid justification for the radio to
>> behave in the illogical way it does now.
>>
>> And, no, the VFOs should not be tied to each other all the time so
> changing
>> the VFO IND parameter is not the answer to this. There is also no need to
>> sync the VFOs when turning SPLIT OFF and that is not being suggested.
>>
>> The current logic forces one to have to perform 3 completely unnecessary
>> steps to go to Split operation when VFOB is not on the same band/mode as
>> VFOA.<<<   This happens all the time!!!
>>
>> Think about this: Is there any reason one would press and hold Split aside
>> from wanting the radio to be placed into SPLIT mode? I cannot imagine any
>> circumstance where you would deliberately press and hold SPLIT and not
> want
>> to go SPLIT.
>>
>> Once again:  ***if VFOB is not on the same band/mode as VFOA***, and you
>> press and hold SPLIT [Step 1] (which clearly means you want to go SPLIT)
>> this should cause a VFOA->   VFOB and then turn on SPLIT all in one step.
>>
>> The way it works now, is that when you try to do this, the radio will not
> do
>> anything but the VFOB display shows SPL/NA and you have to recognize that
>> this has happened [Step 2].
>>
>> As it is now, when this happens, one has to then TAP VFOA->VFOB (STEP 3]
> to
>> make the VFOs the same, then Press and HOLD SPLIT (AGAIN) [Step 4] to go
>> SPLIT, and then set VFOB's frequency [Step 5]. You can then work the DX
>> [Step 6].
>>
>> Again, ***IF and only IF VFOB is not on the same band/mode as VFOA***,
> here
>> are the 6 steps currently forced by this bad logic:
>>
>> Step 1 - Press and Hold SPLIT
>> Step 2 - Recognize the SPL/NA message in the VFOB display
>> Step 3 - Tap VFO A ->   VFO B
>> Step 4 - Press and Hold Split (Again)
>> Step 5 - Set the VFO B Frequency
>> Step 6 - Work the DX Station
>>
>> There is no other way to do this ***if VFOB is not on the same band/mode
> as
>> VFOA***.
>>
>> The 3 extra steps, that the current logic forces are simply a waste of
> time.
>> If it worked the way I am hopeful it will someday, it would eliminate the
>> need to do Steps 2, 3, and 4.
>>
>> Again: ***IF and only IF VFOB is not on the same band/mode as VFOA*** - it
>> would be like this:
>>
>> Step 1 - Press and Hold SPLIT which also sets VFO A ->   VFO B
>> Step 2 - Set the VFO B Frequency
>> Step 3 - Work the DX Station
>>
>> Much more efficient!
>>
>> Again, when one presses and holds SPLIT, there is nothing else one could
> be
>> trying to do but to go SPLIT - if the VFOs must be on the same band to
> allow
>> that, then make them the same and turn on SPLIT, then dial up your VFOB
>> Frequency and work the DX!
>>
>> 73,
>>
>> Bob W5OV
>>
>>
>> -----Original Message-----
>> From: Joe Subich, W4TV [mailto:lists at subich.com]
>> Sent: Saturday, February 12, 2011 8:10 AM
>> To: Bob Naumann; Elecraft Reflector
>> Subject: Re: [Elecraft] Split not available
>>
>>
>> If VFO B is not on the same band, you are correct.  However, there
>> are plenty of times that one might want to use cross mode split -
>> it is quite common in VHF operation.
>>
>> You can avoid the "VFO on the wrong band" issue simply by setting
>> CONFIG:VFO IND = No.  Therefore again, making the VFOs synchronize
>> VFOs as the default operation when turning split on/off is a bad
>> idea.  Quite simply, I regularly use VFO B as a quick memory and
>> have a PF key for B ->   A to take advantage of that.  Your "Make
>> VFO B = VFO A" when turning spit on/off would completely destroy
>> that capability.
>>
>> Anyone who wants VFOs to synchronize when turning split on or off
>> can easily write their own "quick split" macro (tap, tap, hold).
>> There are several examples of such a macro in the archives of this
>> list and probably an example in the Help files for the K3 Utility.
>>
>> 73,
>>
>>       ... Joe, W4TV
>>
>>
>> On 2/12/2011 4:36 AM, Bob Naumann wrote:
>>> Joe,
>>>
>>> Again, ***if VFOB is not on the same band/mode as VFOA***, and you press
>> and
>>> hold SPLIT (which clearly means you want to go SPLIT) this should cause a
>>> VFOA->    VFOB and then turn on SPLIT.
>>>
>>> Please explain how this is a bad idea and under what circumstances this
>>> would cause a problem.
>>>
>>> 73,
>>>
>>> Bob W5OV
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Joe Subich, W4TV [mailto:lists at subich.com]
>>> Sent: Friday, February 11, 2011 10:15 PM
>>> To: w5ov at w5ov.com
>>> Cc: Shel Radin KF0UR; elecraft at mailman.qth.net
>>> Subject: Re: [Elecraft] Split not available
>>>
>>>
>>>> If the "Split" function were to include a A->B like I suggested
>>>> recently, this would not be an issue.
>>>     >
>>>     >    Some condemned this suggestion as a "bad" idea, but I doubt that
> they
>>>     >    operate much or they would know what a pain in the neck this is.
>>>
>>> No, I operate More than enough to know how much of a pain it would
>>> be if the VFOs were synchronized every time one turned split off -
>>> for example to move one VFO to a different pile-up.  Only to have
>>> lost the frequency saved in VFO B when returning to an original
>>> pile-up.
>>>
>>> Synchronizing VFOs every time the split status is changed is *still*
>>> a terrible idea but if you want to do that, you can use the K3 Macro
>>> capability to build your own "quick split" macro without causing
>>> inconvenience to others.
>>>
>>>     >    If VFO B is already on the same band and mode as VFO A, then just
>> turn
>>>     >    Split on.
>>>     >
>>>     >    I find that the second condition NEVER occurs.
>>>
>>> I find the second condition is almost always the case and if it isn't
>>> two quick presses of the Split button is all it takes.
>>>
>>> 73,
>>>
>>>        ... Joe, W4TV
>>>
>>>
>>> On 2/11/2011 11:30 AM, w5ov at w5ov.com wrote:
>>>> If the "Split" function were to include a A->B like I suggested
> recently,
>>>> this would not be an issue.
>>>>
>>>> Some condemned this suggestion as a "bad" idea, but I doubt that they
>>>> operate much or they would know what a pain in the neck this is.
>>>>
>>>> The logic should be:
>>>> When Holding Split: if VFO B is not already on the same band and mode,
>>>> then it should do a VFO A ->     VFO B, and then Split should be turned
> on.
>>>>
>>>> If VFO B is already on the same band and mode as VFO A, then just turn
>>>> Split on.
>>>>
>>>> I find that the second condition NEVER occurs.
>>>>
>>>> 73,
>>>>
>>>> Bob W5OV
>>>>
>>>>
>>>>
>>>>>
>>>>> Exactly.  I'm a new K3 owner (~1 week) and had the same issue a few
> days
>>>>> into
>>>>> ownership.    VFO B was in a mode other than DATA A.
>>>>>
>>>>> To prevent it from happening again, I added a double tap of A->B to my
>>> "go
>>>>> to RTTY"  macro, which copies the mode of VFO A to VFO B, so both VFOs
>>> are
>>>>> always the proper mode.
>>>>>
>>>>> GL&     73,
>>>>>
>>>>> Shel  KF0UR
>>>>> --
>>>>> View this message in context:
>>>>>
>>>
>>
> http://elecraft.365791.n2.nabble.com/Re-Split-not-available-tp6012850p601619
>>> 3.html
>>>>> Sent from the [K3] mailing list archive at Nabble.com.
>>>>> ______________________________________________________________
>>>>> Elecraft mailing list
>>>>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>>>>> Help: http://mailman.qth.net/mmfaq.htm
>>>>> Post: mailto:Elecraft at mailman.qth.net
>>>>>
>>>>> This list hosted by: http://www.qsl.net
>>>>> Please help support this email list: http://www.qsl.net/donate.html
>>>>>
>>>>
>>>>
>>>> ______________________________________________________________
>>>> Elecraft mailing list
>>>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>>>> Help: http://mailman.qth.net/mmfaq.htm
>>>> Post: mailto:Elecraft at mailman.qth.net
>>>>
>>>> This list hosted by: http://www.qsl.net
>>>> Please help support this email list: http://www.qsl.net/donate.html
>>>>
>>>
>>>
>>
>> ______________________________________________________________
>> Elecraft mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:Elecraft at mailman.qth.net
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>>
>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:Elecraft at mailman.qth.net
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
>