<div class="gmail_quote">On Wed, Oct 19, 2011 at 6:15 PM, Peter Stuge <span dir="ltr"><<a href="mailto:peter@stuge.se">peter@stuge.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">Can you provide some details about the device and the protocol? From</div>
cursory surfing on <a href="http://www.microham.com/index1.html" target="_blank">http://www.microham.com/index1.html</a> it seems that<br>
the device falls into the trap of COM port emulation over USB,<br>
instead of using a more efficient, tailor made, protocol.<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">But please, if some details are known about the protocol failues with<br>


this device, I would be happy to help come up with a solution.<br></blockquote><div><br></div><div>The problems are related to Winkey PTT acknowledgment when using a microHAM device, so there is yet another software layer involved.</div>

<div><br></div><div>See</div><div><br></div><div><a href="http://lists.f5mzn.org/pipermail/support/2011-August/081447.html">http://lists.f5mzn.org/pipermail/support/2011-August/081447.html</a> </div><div><br></div><div>and the reply below (forwarded, because it does not appear in Win-Test Archives for some reason), and the follow-up</div>

<div><br></div><div><a href="http://lists.f5mzn.org/pipermail/support/2011-August/081448.html">http://lists.f5mzn.org/pipermail/support/2011-August/081448.html</a></div><div><br></div><div>and subsequent posts to that long thread.</div>

<div><br></div><div>Other programs like N1MM Software do not write to the Winkey one character at a time like Win-Test, so the problem doesn't happen with those, as far as I understand.  This convinces the microHAM folks that it is strictly a Win-Test bug.  I don't agree.</div>

<div><br></div><div>It's been easier to work around the problem by <i>not</i> using a Winkey with Win-Test than to try to get all the developers (F5MZN, F6FVY, K1EL, and OM7ZZ) to work out the proper fix.</div><div><br>

</div><div>73,</div><div>Bob, N6TV</div><div><br></div><div>---------- Forwarded message ----------<br>From: <b class="gmail_sendername">microHAM America - W4TV</b> <span dir="ltr"><<a href="mailto:support@microham.com">support@microham.com</a>></span><br>

Date: Mon, Aug 8, 2011 at 12:57 PM<br>Subject: Re: microHAM u2R (micro2R) CW delays and headphone switching problems with Win-Test<br>To: "Bob Wilson, N6TV" <<a href="mailto:n6tv@arrl.net">n6tv@arrl.net</a>><br>

Cc: Win-Test Reflector <<a href="mailto:support@win-test.com">support@win-test.com</a>><br><br><br><br>Bob,<br><br>Please direct e-mail related to microHAM products to the microHAM<br>support e-mail and not my personal mailbox.<br>

<br>> As reported here --- and here and by many others, unacceptable delay<div class="im"><br>> problems are immediately noticed when trying to send CW messages via<br>> the built-in WinKey.<br><br></div>Looking at the control log segments provided, the delay is strictly<br>

within Win-Test (Win-Test delays the FR command and the start of the<br>message).<div class="im"><br><br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

This was once explained in this reflector as a failure of the<br>microHAM box or WinKey to properly echo back a "PTT event" to the<br>program<br></blockquote><br></div>Waiting on PTT events before switching receive focus is not wise or appropriate.<div class="im">

<br><br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

I understand from K5RC that Writelog has a similar CW delay issue<br>when using the u2R. The 1 or 2 second delays are apparently caused by<br>a "wait state" timeout in the contest software.<br></blockquote><br>
</div>
If WriteLog has a wait state, that should be reported to the developer<br>and eliminated.<div class="im"><br><br>> I was using:<br>><br>>     WT 4.7 (nothing in the 4.8 Release notes related to microHAM)<br>>     Router 7.7.1 (attempting to Update Router via the menu reported<br>

>     "You are already using the latest available")<br><br></div>Correct, Router 7.7.1 is the latest released version.<div class="im"><br><br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

The only way I could make CW message timing work acceptably with the<br>u2R was to bypass the WinKey completely, except for hand keying, and<br>select COM port CW keying only, with Classic Auto Control on the SO2R<br>tab.<br>

</blockquote><br></div>Win-Test *must* eliminate the unnecessary wait states in switching.<br><br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

<div class="im">The other major problem I had, unique to the u2R, was that it<br></div>/insisted/ on controlling all the headphone switching for me, based<div class="im"><br>on the status of the radio, rather than letting the contest software<br>

be in control of the headphones.<br></div></blockquote><br>micro2R does not *insist* on controlling the headphone switching, it<br>does not provide the same level of *macro based* control as MK2R+.<br><br>micro2R only provides control of RX Focus and Stereo (Receive on R1, Receive on R2 and Stereo).  This results in six possible states:<br>

RX on 1, RX on 2, TX from computer (CW/DVK) on R1, TX from computer<br>(CW/DVK) on R2, Manual TX (PTT/Paddles) on R1, and Manual TX<br>(PTT/Paddles) on R2, with stereo override.  A future version of Router<br>will permit independent selection of the transmit audio states with<br>

Stereo On/Stereo Off (e.g. stereo can be retained in transmit or<br>not) but that is a Router configuration, and not controllable in the<br>microHAM Control Protocol.<div class="im"><br><br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

In sum, multiple changes to Win-Test, microHAM Router, and perhaps<br>the WinKey may be required before you can use the WinKey in the u2R<br>with Win-Test using a "normal" configuration.<br></blockquote><br></div>

The only change needed is to remove the gratuitous wait states in<br>the logging software.  Advanced audio switching is only available<br>in MK2R and MK2R+ ... micro2R is designed as a basic SO2R controller<br>and does not contain a protocol driven N x N audio crosspoint switch.<br>

<br><br>73,<br><br> ... Joe Subich, W4TV<br>     microHAM America<br>     <a href="http://www.microham-usa.com/" target="_blank">http://www.microHAM-USA.com</a><br>     <a href="http://groups.yahoo.com/group/microHAM" target="_blank">http://groups.yahoo.com/group/<u></u>microHAM</a><br>

<br>     support e-mail: <a href="mailto:support@microham.com" target="_blank">support@microham.com</a><div class="im"><br></div></div></div>