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, fra...@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

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com 

Reply via email to