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, [email protected] (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 <[email protected]> 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?
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[email protected]
This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [email protected]
