[Elecraft] K4 and RTTY question

Bill Frantz frantz at pwpconsult.com
Tue Jul 21 10:27:20 EDT 2020


Apologies to the list. The message quoted below was meant just 
for N6TV.

[I have BCCed the author of RUMlogNG.]

By way of explanation, After my last post on this thread, I got 
a telephone call from TV Bob, N5TV. We discussed the problem and 
narrowed it down quite a bit.

We assume that RUMlogNG is sending RTTY data using the KY CAT 
command(*). We also assume that is isn't using using the W 
(wait) feature. We also assume that it is ending every string 
with EOT to quickly stop transmission.

The UI of RUMlogNG is basically a standard contest logger. It 
has function keys, with basically the same definition of those 
in N1MM. You can also send free text by typing it into a window 
and using buttons to send and stop sending.

What I observe: If I try to chain sends by pressing a function 
key before the entire previous function key message has been 
sent, frequently the first character of the chained message is 
dropped. My usual use case is to press F4 several times to send 
my call multiple times. I first noticed that the "A" in my call, 
AE6JV, was being dropped.

When TV Bob and I discussed the issue, one of our theories was 
that the problem was only in the K3's logic that displayed the 
output of the send. We decided to set up a test using the 
Reverse Beacon Network (RBN) to discover what was actually being 
sent on the air.

I set up F1 to be a bunch of CQs followed by DE, "CQ CQ CQ CQ CQ 
DE". I then started transmitting the CQ message by pressing F1 
followed by 2 presses of F4. I observed the problem on the K3's display.

My message to TV Bob was the results of looking at the RBM 
spots. I will note that while E6JV can be a valid call (from 
Niue, DXCC Entity #188), the RBN did not report any spots before 
I started my experiment. The spot generated from my experiment 
is the right time and frequency to be one of my transmissions.

73 Bill AE6JV

On 7/20/20 at 11:09 PM, frantz at pwpconsult.com (Bill Frantz) wrote:

>I got spotted 3 times with AE6JV and once with E6JV. ??!!??
>
>Headed back to Rivermead after watching the comet. TTYL
>
>73 Bill AE6JV

* The (edited and abridged) description of the KY command from 
the Programmer's Reference:

KY (CW or CW-to-DATA Keying from Text; GET/SET)

SET format: KY*[text]; where * is normally a BLANK and [text] is 
0 to 24 characters. If * is a W (for “wait”), processing of 
any following host commands will be delayed until the current 
message has been sent. This is useful when a KY command is 
followed by other commands that may have side-effects, e.g., KS 
(keyer speed).
Basic RSP format: KYn; where n is 0 (CW text buffer not full) or 
1 (buffer full). Also see TB command.

The following keyboard characters are mapped to CW "prosigns":
    ( KN    + AR    = BT    % AS    * SK    ! VE

In addition to these prosigns, these special characters can be 
inserted anywhere in the KY command text:

    <  Puts the K3 into TX TEST mode, until a '>' character is received
    >  Returns the K3 to TX NORM mode
    @  In CW mode, this character normally terminates any CW 
message (via KY or manual send), emulating the K2. However, 
tapping 2 in CONFIG:CW WGHT changes ‘@’ to a prosign: the 
‘at’ sign as used in e-mail addresses. This is the newest 
Morse Code character; it can be remembered as the prosign 
‘AC’ (as in “the At Character”).

   ^D  (EOT, ASCII 04) Quickly terminates transmission; use with CW-to-DATA.



-------------------------------------------------------------------------
Bill Frantz        | When it comes to the world     | Periwinkle
(408)348-7900      | around us, is there any choice | 150 
Rivermead Rd #235
www.pwpconsult.com | but to explore? - Lisa Randall | 
Peterborough, NH 03458



More information about the Elecraft mailing list