[Elecraft] K3 command mode default k30 k31

[Matt Zilmer]

Humble opinion time...

Having K31 persist across reboots might be a Bad Idea too.  It's a
mode dependency, meaning more than one state might be possible at
start-up time.  This may cause some PC programs to go into brainlock
if K31 responses are not what's expected.  Plain K3; is what most of
them expect (I think...).

Imho, Wayne has this right.  There should only be a single start-up
state.

73,
matt zilmer
K3 #24

On Fri, 02 Oct 2009 11:19:15 -0400, you wrote:

>
>Don, 
>
>> I thought we were talking about a Microham Router command 
>> that does not work at times until the user issues a terminal 
>> K31 command manually. 
>
>No, we are not talking about ANY Router command.  microHAM 
>interfaces (DigiKeyer, microKEYER, microKEYER II and MK2R/MK2R+) 
>can generate FSK from a PS/2 keyboard attached to the interface 
>IF the transceiver is in RTTY (FSK) mode.  Unfortunately, the 
>K3 reports its "Digital" mode as DATA A (AFSK) unless the K3 
>response set is used.  
>
>As I've stated several times, Router does not change the CAT 
>mode (form of the IF response) because it might "break" any 
>software that requires specific responses to the DS and FW 
>command.  
>
>This is not a matter of Router's programming ... it is a 
>case where 1) the K3 does not report the information needed 
>and 2) once the user has changed the mode of the K3, that 
>change does not survive a reboot. 
>
>The most logical solution would be to make "K31" persist 
>across reboots and/or make the "d" byte active in the auto- 
>information (IF) reports. 
>
>73, 
>
>   ... Joe, W4TV 
> 
>
>
>
>
>> -----Original Message-----
>> From: elecraft-bounces at mailman.qth.net 
>> [mailto:elecraft-bounces at mailman.qth.net] On Behalf Of Don Wilhelm
>> Sent: Friday, October 02, 2009 7:56 AM
>> To: elecraft at mailman.qth.net
>> Subject: Re: [Elecraft] K3 command mode default k30 k31
>> 
>> 
>> Joe,
>> 
>> I thought we were talking about a Microham Router command 
>> that does not 
>> work at times until the user issues a terminal K31 command manually.  
>> Yes, the user power cycled the K3, but I believe proper 
>> software should 
>> recover from that event with no input from the user - that 
>> usually comes 
>> under the category of 'error recovery'.
>> 
>> For commands that require K31 mode to work as expected,  the software 
>> *must* "change the state (mode) of the radio" or assure that 
>> the K3 is 
>> already in that state.  I believe it is the responsibility of the 
>> software to assure that the K31 mode is set on rather than 
>> depending on 
>> (assuming) any state of the radio.  That can easily be 
>> circumvented by 
>> using a bracketed command string.  See the excerpt from the K3 
>> Programmer's Reference below.
>> 
>> "Meta commands can be sent as often as you wish. You can even 
>> use them 
>> to bracket one or more selected
>> commands if you don't want to permanently change the mode. 
>> For example: 
>> K31; FW; K30; selects command
>> mode K31 just for the benefit of the FW command, then returns to mode 
>> K30. (This allows the FW command to
>> set/read the bandwidth in 10-Hz units.)"
>> 
>> If the K3 does not behave as indicated in the Programmer's Reference, 
>> that is the fault of the K3, but if software is failing to work as 
>> expected because of a particular state of the radio, then I 
>> think that 
>> fault lies with the software.
>> 
>> This case may be a moot point in the future, because I see Wayne has 
>> just stated that he will make changes to not require these modal 
>> commands.  I trust that can be accomplished without creating problems 
>> for the many bits of software already out there, but that 
>> remains to be 
>> seen.
>> 
>> This is my last post on this subject.  It is obvious to me 
>> that my view 
>> of what constitutes proper software is different than that of 
>> at least 
>> one programmer.
>> 
>> 73,
>> Don W3FPR
>> 
>> Joe Subich, W4TV wrote:
>> >> I beg to differ.  The K3 does provide the information on 
>> the command 
>> >> state via the 'K2n;' command and the 'K3n;' command.
>> >>     
>> >
>> > Bull.  The K3 does not provide the information in response to
>> > the K3n; command.  The K3 changes its CAT response - specifically 
>> > changes the information reported in the IF (auto information) 
>> > data and its response to several other commands based on the 
>> > status of K3n; 
>> >
>> >   
>> >
>> ______________________________________________________________
>> 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