<div dir="ltr">Thanks for the screen grabs.  I think having both a WinKey PTT lead of 30 ms and a PA PTT lead of 30 ms is too much.  Most modern amplifiers require no more than 10-12 ms PTT lead time.  However, it sounds like the delay was on the order of 1000 ms so this is probably not the cause.<div><br></div><div>Was the PTT closure itself delayed, or the CW after the PTT was closed?<div><br></div><div><div><b>Did you disable "Incoming spot logging" in the Alt-A window and "Stream logging" in the Alt-O window as recommended for RBN connections?  </b>Right click and uncheck those if selected.  Please re-run your SH/DX test.  Do things improve?<br></div><div><br></div><div>From Release.txt:</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><div><div><font face="monospace">- DX Spots window (Alt-A) : New option to enable/disable logging of</font></div></div></div></div></div><div><div><div><font face="monospace">  the incoming spots in the .dxc file. It is enabled by default. Under</font></div></div></div><div><div><div><font face="monospace">  some circumstances (slow antivirus inspection, slow HDD, etc.),</font></div></div></div><div><div><div><font face="monospace">  saving every spot (especially when using the RBN) was making Win-Test</font></div></div></div><div><div><div><font face="monospace">  less responsive. The op-entered spots are always saved to allow their</font></div></div></div><div><div><div><font face="monospace">  restoration on log startup. Tnx HA1AG @ ED9M.</font></div></div></div><div><div><div><font face="monospace"><br></font></div></div></div><div><div><div><font face="monospace">- Packet window (Alt-O) : New option to enable/disable logging of</font></div></div></div><div><div><div><font face="monospace">  the packet stream in the .pkt file. It is enabled by default. Under</font></div></div></div><div><div><div><font face="monospace">  some circumstances (slow antivirus inspection, slow HDD, etc.),</font></div></div></div><div><div><div><font face="monospace">  saving the packet data stream (especially when using the RBN) was</font></div></div></div><div><div><div><font face="monospace">  making Win-Test less responsive. Tnx HA1AG @ ED9M.</font></div></div></div></blockquote><div><div><div><br></div><div><br></div></div><div>Excessive disk I/O may cause interrupt overloads, even on a fast computer, and that may slow down serial communications with the WinKey.  It's only a guess.</div><div><br></div><div>Also, we you using a WiFi LAN, or all hard-wired, or a combination?   A 100% hard-wired LAN will be much more reliable and require less overhead.</div><div><br></div><div>Which RBN server and port were you connecting to?</div><div><br></div><div>wtDxTelnet only needs to run on a single computer.  You should only have one copy of wtDxTelnet running on the entire LAN (or two if you want to connect one to a local skimmer and a second to a remote DX Cluster node), though it's hard to understand why heavy wtDxTelnet activity would slow down WinKey serial port I/O.<br></div><div><br></div><div>Win-Test communication with the WinKey maxes out at 1200 baud.  I guess it's possible that such communication is delayed when there is heavy LAN traffic, though I can't understand why a leading dot would get truncated unless PTT lead delay was 0 ms.</div><div><br></div><div>73,<br></div><div class="gmail_extra"><div><div class="gmail_signature"><div>Bob, N6TV</div></div></div>
<br><div class="gmail_quote">On Tue, Dec 2, 2014 at 9:43 AM, Don Beattie <span dir="ltr"><<a href="mailto:g3ozf@btinternet.com" target="_blank">g3ozf@btinternet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif">Hi Bob,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif">Here’s my answers, Bob:<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif">The delay was random – sometimes it was zero but (when it mattered !) it would be up to about a second.  PTT lead set to 30ms. It was an embedded WinKey in both the Microham and the EZMaster. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif">However, I do think I am beginning to get a sniff of the solution. The machines were each running cluster links via WTDX Telnet. The load of spots was considerable at the weekend, and so I tried today to simulate that with an extensive “SH/DX” commend. Up till I sent that command,  the keying had been perfect. When the spots arrived the delay was there for a while. I am beginning to think this is the Telnet app + the processing of the spots in WT which together loads things so that the CW gets a back seat. Might that be possible? The fact that I get the same effect on EZMaster and Microham suggests it is not the basic installation of the hardware/firmware/interface, but a processing issue.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif">I’ll send you the relevant screen grabs directly (I’ll just to the Microham) as I don’t think the reflector handles attachments.  If you have any ideas, they would be very appreciated.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif">73<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif">Don, G3BJ / G5W <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><b><span lang="EN-US" style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span lang="EN-US" style="font-size:10pt;font-family:Tahoma,sans-serif"> <a href="mailto:support-bounces@f5mzn.org" target="_blank">support-bounces@f5mzn.org</a> [mailto:<a href="mailto:support-bounces@f5mzn.org" target="_blank">support-bounces@f5mzn.org</a>] <b>On Behalf Of </b>Bob Wilson, N6TV<br><b>Sent:</b> 02 December 2014 17:02<br><b>To:</b> Win-Test Reflector<br><b>Subject:</b> Re: [WT-support] KEYING DELAY<u></u><u></u></span></p><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Was it a consistent delay, or variable?  How long was the delay?  What was the PTT Lead time set to in the WinKey (WKSETUP) dialog?  Were you using WinKey PTT or any other type of PTT port?  Was the "PA PTT" box checked and was "PA PTT lead" set to some value other than 0 in the PTT tab?  You really need to send me a screen shot of every Win-Test dialog and every Router tab on the problem computer before I can do much more.<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">There at at least 3 different places where PTT lead time can be set in Win-Test and the Router. <u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">If it works for a while, then the delay shows up, sometimes I've had to type SETUP [Enter] [Enter] in Win-Test to reopen all COM ports, including the WinKey.  Did you try that?<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Any leading blanks in CW messages programmed by mistake?<u></u><u></u></p><div><p class="MsoNormal"><br clear="all"><u></u><u></u></p><div><div><p class="MsoNormal">73,<u></u><u></u></p><div><p class="MsoNormal">Bob, N6TV<u></u><u></u></p></div></div></div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Tue, Dec 2, 2014 at 7:24 AM, Pablo - EA4TX <<a href="mailto:ea4tx@ea4tx.com" target="_blank">ea4tx@ea4tx.com</a>> wrote:<u></u><u></u></p><p class="MsoNormal">In ED1R we also noticed the same problem but only in one of our computers.<br>Our entry was M/2 and we used 5 computers (2 x RUN + 2 x INBAND + MULTI).<br>All the computers are similar (same Dell desktop computer) and we used<br>microHAM microKeyer II. The problem was detected ONLY in the "MULTI"<br>Station, the rest of computers (4) worked without delay in the CW starting.<br><br>We checked all possible options (MicroHam Router and WT) but it didn't help<br>to fix it. We also entered the same setup of another computer (without<br>delay) into this Multi station and it didn't work.<br><br>After a lot of time spent in this issue, we couldn't solve. After a lot of<br>years running WT and microham, I think I do not consider myself a newbie is<br>these settings.<br><br>We thought that the problem was due to this computer (some strange case),<br>but now after reading your email, you describe the same problem we found in<br>this station.<br><br>Regards, Pablo EA4TX (ED1R Team)</p></div></div></div></div></div></div></div></div></div></blockquote></div></div></div></div>