[WT-support] CW Speed variations - K1EL V22 Chip now available

Bob Wilson, N6TV n6tv at arrl.net
Wed May 21 20:37:06 CEST 2008


OK, I think we are all saying the same thing, but in different ways.

If you have a standalone WinKey chip (not inside a microHAM box router), you
communicate with it by sending bytes to a real serial port like COM2:, at
1200 baud.  Bytes are also echoed back from the WinKey.  That's where
Win-Test seems to have a problem.  More about that later.

If you have a WinKey chip inside a microHAM USB box, you must have the
microHAM "Router" program up and running at all times.  This program defines
a *virtual *serial port for the WinKey, like COM10:.  Win-Test doesn't know
the difference.  It just reads and writes bytes to this COM port, and the
router program takes care of getting this data to the internal WinKey, and
vice versa.  All of the data is flowing over a single USB line, but Win-Test
still thinks it is talking to an ordinary serial port.  WinKey parameters
set via Options, WinKey are also sent to the device this way, through the
WinKey virtual COM port.

Now, I believe Win-Test has a problem with all WinKey devices, no matter how
they are connected.

Looking at the data traces, it seems like Win-Test is not reading and
responding properly to all the bytes being returned from the WinKey.  For
example, when you get into a certain state by pressing a Win-Test message
key like [F4] *immediately* (too soon) after sending with the paddles,
Win-Test seems to get confused.  See Bug Report
#162<http://flyspray.win-test.com/index.php?id=162&do=details>for the
details.  Can we please change this bug from"Medium" to "High"
severity?

When Win-Test gets into this state, it refuses to send any more CW messages
until you press [Escape], and it ignores all movement of the speed pot
(despite tons of messages from the WinKey).

Speculation:  My guess is that when I press [F4], Win-Test writes an "N"
character to the serial port (first letter of my call), then waits for an
"N" to be echoed back from the WinKey.  Instead it sees a blank and some
status bytes (0x20 0xC4 0xC0) written back, so it gets into a loop, waiting
forever for the "N", ignoring everything else. The "N" doesn't ever get
echoed back because the Win-Key was in a "busy" state, ignoring all serial
input, when it was written to the port.  At this point, Win-test appears to
be "locked up"; it won't send any more CW.

As to the other issue, the $MK2R= macro lets you send specific microHAM
commands to the microHAM "control" port (like virtual com port COM9), but
not to the WinKey port (COM10 in this example).  None of the documented
microHAM commands seem to have anything to do with the WinKey device.
microHAM commands go to COM9 and WinKey commands to COM10.  They speak two
different languages (kind of like us).

In sum, we need a $WINKEY= macro to communicate directly with the WinKey
serial port (for adjusting things like "WinKey PTT tail" that are missing
from the WinKey dialog box), especially if you have a standalone WinKey,
without a microHAM box.

And we also need Win-Test to handle the situation better when the WinKey is
in "Busy" state (which happens for a full word space after sending anything
with the paddles).  It should probably resend the un-echoed character
whenever it reads a blank echoed back instead, after waiting for the two
bytes that indicate the transition from "busy" to "not busy" state.

FYI, Writelog handles this differently.  It appears to "chop" the first
character or two and send whatever comes afterwards (not a good solution).

73,
Bob, N6TV

On Wed, May 21, 2008 at 3:27 AM, Laurent HAAS - F6FVY <f6fvy at free.fr> wrote:

> Hi Bob
>
> Bob Wilson, N6TV a écrit :
>
> > On Tue, May 20, 2008 at 12:33 PM, Laurent HAAS - F6FVY <f6fvy at free.fr
> > <mailto:f6fvy at free.fr>> wrote:
> >
> >     AFAIK, the microHam router monitors the serial stream and dumps all
> WK
> >     commands that can be set by using the router.
> >
> >
> > According to the release notes "The WinKey and PTT/CW events of the
> > Win-Test integrated keyers are not handled by the protocol."  In other
> > words, you have to send commands to the WinKey virtual serial port,
> > rather than the MK2R control port, and there's no way to do that with
> > the $MK2R=/cmd/ macro.
>
> Actually, no.
>
> *I* wrote this release note, so I think I know what I'm talking about ;-)
>
> The Win-Test WinKey options (Options / WinKey configuration) are sent
> thru the WK virtual (or real) serial port. And the microHam router
> intercepts them.
>
> Jozef OM7ZZ confirmed me this behaviour by email before leaving to Dayton :
>
> > Router 5.x has "Winkey mastering" as we are calling it. In practice it
> means that the all settings which are shown on Router Winkey tab are
> exclusivelly controlled by Router WK Mastering. Commands from logger are
> online "patched" to meet Router settings, but without harmfull behaviour for
> the logger. Logger don't know that the settings are changed, because WK
> Mastering in Router also "patching" WK responses to the logger.
>
> *Maybe* you can change these settings by the MK2R protocol itself (I
> don't know, and I don't have to the possibility to check), but I doubt
> it will work.
>
> 73
>
> Larry - F6FVY
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.f5mzn.org/pipermail/support/attachments/20080521/26da347c/attachment.htm 


More information about the Support mailing list