[Elecraft] K3 command mode default k30 k31
Joe Subich, W4TV
lists at subich.com
Fri Oct 2 01:18:06 EDT 2009
> 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;
> I repeat, any software that needs to issue K31 commands must
> assure that the K3 is capable of accepting those commands.
Router can not arbitrarily place the K3 into K31; mode since
it must operate with software that relies on the K30; and
certain K2x; behaviors - Ham Radio Deluxe among others. Since
Router already relies on the data in the autoinformation packet
to determine operating frequency (band) and mode if another
application is controlling the K3 it does not poll independently
for Mode (MD;) and data sub-mode (DT;).
> IT IS NOT A MATTER OF NOT CHANGING THE STATE OF THE RADIO - the
> situation is that the software is trying to issue a command that
> requires the K31 state.
No, the K3# commands alter the state of the K3 command set and
CHANGE THE STATE OF THE RADIO. They specifically change the way
the K3 interprets certain commands (DS; FW;) and changes the
behavior of the "b" and "d" bytes in the auto-information report.
Full details are in the Programmers Reference Manual.
> That fact that other radios 'do it differently' is not a reason
> for software which supposedly supports the K3 command set to make
> assumptions about the state of the K3.
Router does not "make assumptions about the state of the radio."
It understands fully if the "d" byte in the autoinformation report
is "0" the data submode must either be Data_A or the radio is in
K30; mode. Since the K3 does not indicate which is the case, Router
treats DATA mode as AFSK/PSK (which is what is being reported) and
will not generate FSK from the keyboard or memory since that is
inappropriate in the DATA_A submode.
To say that Router is at fault because it does not arbitrarily
change the K3 CAT mode is hubris. The fact is that the K3
reports "DATA A" in the autoinformation packet unless the
K31; extensions are enabled. That is simply a "fact of life"
just as the fact that Kenwood transceivers and Icom transceivers
prior to the "Pro" series have no way to identify AFSK operation
is a "fact of life."
> I do come from a long background that says any software that
> makes assumptions (without checking) is faulty programming.
And I come from a long background that says any control system
that does not provide accurate information is a defective
control system. However, I don't go around saying the Elecraft
implementation of the Kenwood command set is defective even though
it clearly indicates that the default data mode is DATA A.
In this case, the command set simply does not provide the
information necessary for Router to enable its internal
FSK keyboard support. That support is also not enabled
for the K2 in which "RTTY" = AFSK. In the case of the K2,
Router had to be specifically coded to handle the "RTTY"
mode differently than any other supported transceiver.
You simply have no right to declare another company's software
(product) "defective" and I resent it.
73,
... Joe, W4TV
> -----Original Message-----
> From: Don Wilhelm [mailto:w3fpr at embarqmail.com]
> Sent: Thursday, October 01, 2009 10:15 PM
> To: lists at subich.com
> Cc: don at w3fpr.com; 'Hugo pa4la'; elecraft at mailman.qth.net
> Subject: Re: [Elecraft] K3 command mode default k30 k31
>
>
> Joe,
>
> I beg to differ. The K3 does provide the information on the command
> state via the 'K2n;' command and the 'K3n;' command. The K30
> state is
> clearly documented as the default.
>
> I repeat, any software that needs to issue K31 commands must
> assure that
> the K3 is capable of accepting those commands.
>
> This is a task for the programmer who says they support the
> K3 command
> set.
>
> IT IS NOT A MATTER OF NOT CHANGING THE STATE OF THE RADIO - the
> situation is that the software is trying to issue a command that
> requires the K31 state. The command cannot be received if
> the radio is
> not in the K31 state - so either the software must use an alternative
> method or it must set the K31 state. If the software must
> restore the
> radio to the K30 state afterwards (to be "good programming")
> than by all
> means, issue the K30 command at the end of the process.
>
> That fact that other radios 'do it differently' is not a reason for
> software which supposedly supports the K3 command set to make
> assumptions about the state of the K3.
>
> I do come from a long background that says any software that makes
> assumptions (without checking) is faulty programming.
>
> 73,
> Don W3FPR
>
> Joe Subich, W4TV wrote:
> > Don,
> >
> >
> >> That sounds like a programing deficiency in the Microham MK2. The
> >> fact that the K3 defaults to K30 on power on is documented in the
> >> Programmer's Reference as default.
> >>
> >
> > That's uncalled for.
> >
> > The K3 "RTTY" mode is ambiguous in its default configuration. There
> > is no way for software to distinguish among the four
> > data sub-modes with the default "K30" response set.
> >
> > The hallmark of good software is that IT NEVER CHANGES THE STATE OF
> > THE RADIO UNEXPECTEDLY. This is particularly true for microHAM
> > Router since it has to interoperate with a multitude of logging and
> > data programs - some of which require K30 mode and some of which use
> > the K31 configuration.
> >
> > The appropriate "fix" would be for the "data sub mode" report to be
> > present in the IF (autoinformation) report at all times
> > - but that's not the way the K3 currently operates - or for
> > the K3 to add two "new" modes to indicate audio based data
> > submodes (AFSK_A or DATA_A) like Yaesu did in their Kenwood
> > like protocol for the FT-9000/2000/950/450.
> >
> > The lack of information on AFSK/PSK vs. FSK simply means that this
> > one feature of the microHAM interfaces (DigiKeyer, microKEYER,
> > microKEYER II) is not supported with the K3 because the K3 fails to
> > provide the necessary data.
> >
> > Except for the K2 and K3 (and Flex-Radio), the RTTY mode in every
> > other transceiver manufactured in the last 20 years (and all Kenwood
> > transceivers except the TS-440) is always FSK.
> > With the K2 "RTTY" is AFSK and with the K3 "RTTY" is ambiguous.
> >
> > 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: Thursday, October 01, 2009 7:48 PM
> >> To: Hugo pa4la
> >> Cc: elecraft at mailman.qth.net
> >> Subject: Re: [Elecraft] K3 command mode default k30 k31
> >>
> >>
> >> Hugo,
> >>
> >> That sounds like a programing deficiency in the Microham MK2. The
> >> fact that the K3 defaults to K30 on power on is documented in the
> >> Programmer's Reference as default.
> >> If a device needs to use an extended mode command, it should
> >> query the
> >> state - the K3 command can be used as a GET or a SET, so the
> >> programmer
> >> can determine the state before issuing the command.
> >>
> >> 73,
> >> Don W3FPR
> >>
> >> Hugo pa4la wrote:
> >>
> >>> I am playing with my Microham MK2 and have learned that,
> >>>
> >>> the K3 must be in extended (k31) command mode for the MK2
> >>>
> >> to switch
> >>
> >>> correct between audio or fsk data modes
> >>>
> >>>
> >>>
> >>> When the K3 is powered on, the mode setting is always
> standard k30.
> >>>
> >>> Putting the k31 command via a terminal is not a big issue
> >>>
> >> but it would
> >>
> >>> save a couple of mouse clicks :)
> >>>
> >>>
> >>>
> >>> Is there a way tot save the k31 setting or a way to make k31 the
> >>> default setting?
> >>>
> >>>
> >>>
> >>> Tnx in advance,
> >>>
> >>>
> >>>
> >>> Hugo pa4la
> >>>
> >>>
> >>>
> >> ______________________________________________________________
> >> 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
> >
> ----------------------------------------------------------------------
> > --
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 8.5.409 / Virus Database: 270.14.1/2407 - Release
> Date: 10/01/09 06:34:00
> >
> >
More information about the Elecraft
mailing list