[Elecraft] K4 and RTTY question

[Bill Frantz]

I don't think the logging software is the problem. Since the KY 
command works for both CW and RTTY, I tried an experiment: I 
switched the mode using the K3's front panel from Data to CW and 
the problem did not occur. (I listened to the monitor output.) 
The UI for the program still showed RTTY, so I don't think it 
noticed my change and changed its behavior.

There may be a problem handling the Control-D character in the 
K3. This character is ignored in CW, but it tells the K3 to stop 
sending RTTY when processed in RTTY. My guess is that RUMlogNG 
appends it to all KY sends. If another KY command's data is 
added to existing data in the buffer, The Control-D at the end 
of the first set of data may cause the second KY's data to lose 
the first character.

What should happen if the last character in the buffer is a 
Control-D, and more data is added, is to remove the Control-D so 
the two sets of data are merged for transmission.

Now I'm getting tempted to haul the KX3 up next to the K3 and 
decode what actually goes out over the air. Another interesting 
question is what happens if the first character of the second 
part of a chain is a "W"?

BTW, I worked on similar software systems when writing the 
Tymnet interface for Tymshare's IBM/370 VM systems.

73 & GL Bill AE6JV

On 7/19/20 at 6:50 PM, n6tv at arrl.net (Bob Wilson, N6TV) wrote:

>Bill,
>
>Before it can be "fixed" in the K4, the logging software has to be fixed to
>send the proper KY command.  If it is sending KY<blank>*somes-string*;,
>then the messages are not going to be chained.  If it is sending KYW
>*some-string*;, then the messages should be properly chained, perhaps with
>a very brief pause in between if 0x04 (Ctrl-D, ^D or EOT -- ASCII End of
>Transmission character) is appended at the very end of a each chained
>message, before the terminating semicolon.  The "W" means "wait for message
>completion," as documented in the K3 Programming Manual.
>
>However, once a message sent via KYW starts, you will not be able to
>interrupt the transmission by pressing "Escape" or sending an "RX;"
>command.  The RX; won't be processed until the message completes, which
>isn't very helpful.
>
>Maybe *that* will be addressed (somehow) in the K4.
>
>In sum, if you need chaining more than you need message interrupt
>capability, use KYW in your macros.  If you need message interrupt
>capability more than you need chaining, use KY<blank>.  If you need both,
>maybe you'll have to "wait" (sorry) to see if the K4 team comes up with
>some way to interrupt chained messages already in progress via a special
>"high priority" software command or key tap.
>
>73,
>Bob, N6TV
>
>On Sat, Jul 18, 2020 at 7:39 AM Bill Frantz <frantz at pwpconsult.com> wrote:
>
>>I'm getting ready for NAQP RTTY today, and I am reminded of an
>>old bug using the KY CAT command to send RTTY text. I am using
>>RUMlogNG on my MacBook Pro in contest mode which uses the CAT
>>interface to send and receive RTTY. (It also uses CAT with CW.)
>>
>>If I try to chain output, e.g. press the function key to send my
>>callsign several times, frequently the first parts of the
>>chained output are dropped, as shown by the text shown in the
>>VFO-B display.
>>
>>This does not occur on CW, so I think the CW to Data conversion
>>may be involved. The command is defined in the programmer's
>>Reference as:
>>
>>KY (CW or CW-to-DATA Keying from Text;
>>
>>If I chain by using a K3 memory and pressing the M1-4 button
>>several times, the VFO-B display shows "CHAIN" and things appear
>>to work correctly.
>>
>>I will admit, that while I can check what is being sent by
>>listening to the monitor tones with CW, but I can't quite be
>>sure about the RTTY.
>>
>>Will this problem be fixed on the K4?
>>
>>73 Bill AE6JV

-----------------------------------------------------------------------
Bill Frantz        | Since the IBM Selectric, keyboards have gotten
408-348-7900       | steadily worse. Now we have touchscreen keyboards.
www.pwpconsult.com | Can we make something even worse?