OK, I think we are all saying the same thing, but in different ways.<br><br>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.<br>
<br>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 <i>virtual </i>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.<br>
<br>Now, I believe Win-Test has a problem with all WinKey devices, no matter how they are connected.<br><br>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] <i>immediately</i> (too soon) after sending with the paddles, Win-Test seems to get confused. See <a href="http://flyspray.win-test.com/index.php?id=162&do=details">Bug Report #162</a> for the details. Can we please change this bug from"Medium" to "High" severity?<br>
<br>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).<br><br>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.<br>
<br>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).<br>
<br>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.<br>
<br>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.<br>
<br>FYI, Writelog handles this differently. It appears to "chop" the first character or two and send whatever comes afterwards (not a good solution).<br><br>73,<br>Bob, N6TV<br><br><div class="gmail_quote">On Wed, May 21, 2008 at 3:27 AM, Laurent HAAS - F6FVY <<a href="mailto:f6fvy@free.fr">f6fvy@free.fr</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">Hi Bob<br>
<br>
Bob Wilson, N6TV a écrit :<br>
<br>
</div><div class="Ih2E3d">> On Tue, May 20, 2008 at 12:33 PM, Laurent HAAS - F6FVY <<a href="mailto:f6fvy@free.fr">f6fvy@free.fr</a><br>
</div><div class="Ih2E3d">> <mailto:<a href="mailto:f6fvy@free.fr">f6fvy@free.fr</a>>> wrote:<br>
><br>
> AFAIK, the microHam router monitors the serial stream and dumps all WK<br>
> commands that can be set by using the router.<br>
><br>
><br>
> According to the release notes "The WinKey and PTT/CW events of the<br>
> Win-Test integrated keyers are not handled by the protocol." In other<br>
> words, you have to send commands to the WinKey virtual serial port,<br>
> rather than the MK2R control port, and there's no way to do that with<br>
> the $MK2R=/cmd/ macro.<br>
<br>
</div>Actually, no.<br>
<br>
*I* wrote this release note, so I think I know what I'm talking about ;-)<br>
<br>
The Win-Test WinKey options (Options / WinKey configuration) are sent<br>
thru the WK virtual (or real) serial port. And the microHam router<br>
intercepts them.<br>
<br>
Jozef OM7ZZ confirmed me this behaviour by email before leaving to Dayton :<br>
<br>
> 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.<br>
<br>
*Maybe* you can change these settings by the MK2R protocol itself (I<br>
don't know, and I don't have to the possibility to check), but I doubt<br>
it will work.<br>
<div><div></div><div class="Wj3C7c"><br>
73<br>
<br>
Larry - F6FVY</div></div></blockquote></div><br>