Master Keyer 1, incomplete WK emulation

[Nate Bargmann]

I think I've figured out that the reason I can't stop the CW sending is
because my MK1 is not sending a status byte. I used a software shim
(interceptty found as a source archive) to look at the data sent to/from
the MK1. I see the commands sent from SO2SDR to the MK1, but all the
MK1 ever sends back is the echo of the characters to be sent.

Tor, I presume you have a K1EL Winkeyer. Have you looked at its
responses? I've looked over the various WK datasheets and can't tell if
the WK is supposed to send a status byte indicating that it is sending
when it starts to send and then another saying it has stopped when the
message is complete or what, exactly? The documentation isn't too clear
on that point.

If I had a more exact example of the WK behavior, I could bring that to
the attention of N0XAS and see if he could add that capability to the
MK1.

73, de Nate >>

--

"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

[R. Torsten Clay]

Yes, I have a Winkey 2, serial version. It is not the latest firmware version, maybe
one or two releases behind the most current.

I don't see why that would affect the cancel command however. The cancel is very simple
(see cancelcw in winkey.cpp), it is just sending the command 0x0a (Clear Buffer):

"Clear Buffer can be sent at any time to abort a message, abort a command, or to clear the serial buffer. It
will cancel any Morse character in progress immediately ending it in midstream if necessary."
 
I don't check for anything returned.

The only returned information I capture is:

  1. status byte, used to tell if winkey is sending. This is only used to pause the peak detection
     in the bandmap while you are transmitting. At least my winkey does send this consistently
    when it starts/stops sending.

  2. changes in speed pot setting. I don't currently use this for anything however.

Even at the slow 1200 baud, cw cancel and the status byte are really fast on my hardware. Is
the 0x0a getting sent in your case?

Tor

[Nate Bargmann]

* On 2012 01 Jun 10:34 -0500, R. Torsten Clay wrote:
> Yes, I have a Winkey 2, serial version. It is not the latest firmware
> version, maybe one or two releases behind the most current.
>
> I don't see why that would affect the cancel command however. The
> cancel is very simple (see cancelcw in winkey.cpp), it is just sending
> the command 0x0a (Clear Buffer):

Following the code for the ESC key, it tests the return (bool) of
winkey->isSending() which returns the bool variable sending which is set
by the receive() function. Since my MK1 never sends a status byte that
I can see, sending is always set to false so ESC jumps straight to
clearing the call and exchange fields.

I don't disagree with the SO2SDR logic, in fact that is how I
think it should be done. I think the MK1 needs to be fixed and I can
take it up with Dale, N0XAS.

> Even at the slow 1200 baud, cw cancel and the status byte are really fast
> on my hardware. Is the 0x0a getting sent in your case?

I have not seen it sent when I tested for a few minutes yesterday due to
the logic of SO2SDR. I know that CQRlog is written to *always* require
two presses of ESC to clear the entry fields as the first always cancels
CW.

Mostly, I am curious how and when the genuine WK sends the status byte
without being polled so I can ask that the MK1 be modified to do the
same.

[R. Torsten Clay]

On Fri, Jun 1, 2012 at 12:37 PM, Nate Bargmann <n0...@n0nb.us> wrote:

* On 2012 01 Jun 10:34 -0500, R. Torsten Clay wrote:
> Yes, I have a Winkey 2, serial version. It is not the latest firmware
> version, maybe one or two releases behind the most current.
>
> I don't see why that would affect the cancel command however. The
> cancel is very simple (see cancelcw in winkey.cpp), it is just sending
> the command 0x0a (Clear Buffer):

Following the code for the ESC key, it tests the return (bool) of
winkey->isSending() which returns the bool variable sending which is set
by the receive() function.  Since my MK1 never sends a status byte that
I can see, sending is always set to false so ESC jumps straight to
clearing the call and exchange fields.

Yes, you are right- I forgot about that.


 

I don't disagree with the SO2SDR logic, in fact that is how I
think it should be done.  I think the MK1 needs to be fixed and I can
take it up with Dale, N0XAS.

> Even at the slow 1200 baud, cw cancel and the status byte are really fast
> on my hardware. Is the 0x0a getting sent in your case?

I have not seen it sent when I tested for a few minutes yesterday due to
the logic of SO2SDR.  I know that CQRlog is written to *always* require
two presses of ESC to clear the entry fields as the first always cancels
CW.

Mostly, I am curious how and when the genuine WK sends the status byte
without being polled so I can ask that the MK1 be modified to do the
same.

My WK always sends the status byte at the start and finish of a cw message. The host
does not have to poll for them:

"Notice that unless Winkeyer2 has something for the host to read, the host continues to process outgoing
commands and other tasks. Also note that speed pot and status bytes can be unsolicited, in other words
Winkeyer2 can send these at any time a state change occurs inside Winkeyer2. Echo back bytes are also
unsolicited as they are based on asynchronous Morse sending. The host has to be able to handle these as
they occur. If host processing is slow, a serial input buffer on the host side is required to make sure no
returned bytes are missed."

Tor


 

[Nate Bargmann]

* On 2012 01 Jun 13:47 -0500, R. Torsten Clay wrote:
> My WK always sends the status byte at the start and finish of a cw
> message. The host does not have to poll for them:

After more testing and following along with the winkey.cpp source, I
have a better handle on things. Clearly, the bug is in the MK1.

> "Notice that unless Winkeyer2 has something for the host to read, the
> host continues to process outgoing commands and other tasks. Also note
> that speed pot and status bytes can be unsolicited, in other words
> Winkeyer2 can send these at any time a state change occurs inside
> Winkeyer2. Echo back bytes are also unsolicited as they are based on
> asynchronous Morse sending. The host has to be able to handle these as
> they occur. If host processing is slow, a serial input buffer on the
> host side is required to make sure no returned bytes are missed."

I've read that a few times in the Winkeyer manuals and still find it
lacking some detail. ;-) I suppose, "state change occurs" covers the
situation...

FYI, here is what I'm seeing to/from the MK1 when starting SO2SDR and
then pressing F1 once the FD contest is selected:

< 0x13
< 0x13
< 0x13
< 0x00
< 0x04
< 0x55 (U)
> 0x55 (U)
< 0x00
< 0x02
> 0x16
< 0x01
< 0x87
< 0x0e
< 0x00
< 0x05
< 0x0a
< 0x50 (P)
< 0x00
< 0x02
< 0x14
< 0x09
< 0x07
> 0xa1
> 0xa0
> 0xa1
> 0xa0
> 0xa1
> 0xa0
> 0xa1
> 0xa0
> 0xa1
> 0xa0
> 0xa1
< 0x02
< 0x14
< 0x09
< 0x07
< 0x43 (C)
< 0x51 (Q)
< 0x46 (F)
< 0x44 (D)
< 0x20
< 0x4e (N)
< 0x30 (0)
< 0x4e (N)
< 0x42 (B)
< 0x20
< 0x4e (N)
< 0x30 (0)
< 0x4e (N)
< 0x42 (B)
< 0x1e
> 0xc0


Now, what, exactly, those 0xa1 and 0xa0 bytes signify, I don't know.
The MK1 manual carries this statement, "Complete documentation of
emulation mode commands and status will be included in a separate
document.", except that I don't see it anywhere on the Web site!

Note that it does send the 0xc0 byte once sending is complete, but no
0xc4 as expected. I'll get ahold of N0XAS and work on this with him.

Interestingly, the MK1 manual carries this notice, "A note regarding
speed settings: Setting speeds above 63 WPM while in Winkeyer emulation
mode can cause problems with host mode software. At 64 WPM and above,
the keyer's speed update byte will appear to be a status byte. This is
the case with the MK-1 or any Winkeyer-based device. To avoid this
issue, keep the operating speed below 64 WPM when in Winkeyer emulation
mode." Indeed, with the current default speed pot range setting of 0x80
plus 0x10 minimum WPM, the top end is 144 WPM! Perhaps a range of 25
combined with a minimum of 15 would be reasonable defaults? Spinning
the speed knob did send values back to the host in the status byte range
so seeing to it that the max speed pot WPM value is 63 WPM and less is a
good idea.

[Nate Bargmann]

* On 2012 01 Jun 20:36 -0500, Nate Bargmann wrote:
> Indeed, with the current default speed pot range setting of 0x80
> plus 0x10 minimum WPM, the top end is 144 WPM!

My reading comprehension is off kilter here. The values in winkey.cpp
here are in *decimal* so the defaults are a minimum of 10, range of 80,
and maximum of 90 WPM. Plenty fast for my poor fist.

[Nate Bargmann]

* On 2012 31 May 22:10 -0500, Nate Bargmann wrote:
> I think I've figured out that the reason I can't stop the CW sending is
> because my MK1 is not sending a status byte. I used a software shim
> (interceptty found as a source archive) to look at the data sent to/from
> the MK1. I see the commands sent from SO2SDR to the MK1, but all the
> MK1 ever sends back is the echo of the characters to be sent.

I received a firmware update from Dale yesterday. From my testing of a
few simulated QSOs and such, it appears to work as SO2SDR expects now.
Just in time for Field Day. Yay!