[WT-support] Issues from ES9C

[Tõnno Vähk]

I need to go to my QTH to try to test those things to be able to answer most of the questions. Maybe this CORRECT bug can be reproduced when the TU message is aborted in the middle first time (but QSO entered) and then pressed again...

I was running 4.6 on all computers. And now it seems that the difference in score was till due to CTY files because the QSO count seems to be the same and the scores are the same when I run the log files on one specific computer.

From: support-bounces at win-test.com [mailto:support-bounces at win-test.com] On Behalf Of Bob Wilson, N6TV
Sent: Wednesday, December 01, 2010 12:24 AM
To: support at win-test.com
Subject: Re: [WT-support] Issues from ES9C

On Tue, Nov 30, 2010 at 12:10 PM, Tõnno Vähk <Tonno.Vahk at gafm.ee<mailto:Tonno.Vahk at gafm.ee>> wrote:
2. Confirm speed jump issues with MK2R+/MKII and WT with Winkey keying. We use +++/--- stuff a lot and also separate speeds for WT and paddle. So asking for trouble as I understand. Also, I guess, when message is aborted after ++++ has been run but ---- not yet the speed might stay high? I did not actually test it again now.

Could using the paddle to halt CW cause this problem if it happens at just the right moment, between the "++" and the "--" perhaps?

3. A serious issue with $CORRECT. It seems that when the callsign field is empty at the time when e.g. a message of $CORRECT TU ES9C is run the $CORRECT send some totally wrong old callsign.

I have seen this issue with WT 3, but I have not been seeing it in the newer versions of WT 4.  It certainly behaves as if a memory overwrite somewhere in Win-Test is writing random characters to the $CORRECT message buffer at unpredictable times, perhaps if callsigns are being rapidly entered and corrected by other computers in the network.  As a single op with one computer, I thought it was fixed.

Maybe a code change could clear this buffer every time the call is unchanged, even the code thinks thinks that the $CORRECT buffer should already be clear.

Sometimes a call worked tens of QSOs ago.

Yes, or part of one.  It is really hard to reproduce, which is why I think it is a random memory overwrite.  It may also have something to do with network activity, really not sure.
4. I tried the Download Files through the Network command for the first time after the contest to pull all the logs to one computer. It does not work. Did not matter which networked PC I tried the message came up: "transfer canceled. Reason: Unzip: can't open file 'C\Doc.\Temp\WT_EA.tmp'". What is wrong?

Does the file actually exist?  Is there anything new in that directory?  Is the full name of the file:
C:\Documents and Settings\userid\Local Settings\Temp\WT_EA.tmp

or does it display as C:\Doc.\Temp\WT_EA.tmp" in the message?  Can you send a screen shot?

Do you have a program or batch file called Unzip on your PC that you can run from the command line?
5. I had 6 computers in network and the scores were different on all of them by the end!! That is real strange. WT has been usually very good on this and we don't delete QSOs.

Were the QSO counts off, or perhaps did some computers use CTY_WT.DAT and others CTY_WT_MOD.DAT, or maybe different versions of these files?  This is the first report I have seen.  It is extremely rare for Win-Test to have missing QSOs accross the network, even if a computer is temporarily down or rebooted.  What are the QSO totals on each computer, including dupes?

What version of Win-Test was running on all computers, 4.6 ?

7. Another very small but strange issue: We had INSERT message programmed as: ++ $LOGGEDCALL--^^$SPACEBAR $GUESSEXCH $F2. In order to get the speed change for LOGGEDCALL to work a SPACE had to be entered before it!! Otherwise the ++ and -- had no effect. This is really akward. It took a while for us to figure this out. This is not the case with other messages and for example ++$CORRECT-- syntax.

I can't replicate this problem using LPT keying.  Have not tried it with a Winkey.  Maybe there was something in the $F1 message or PLUS message or $F2 message?  Did your F1 message end with ++TEST-- or a script call like #CLEARRIT?

I assume you were not using the secondary radio window at all.
8. Another small issue. $GRABPARTNER does not trigger AUTOSEND but ALT-SPACE does. One pulls the callsign from the first line in the Stack in the Partner window, the other from the real time field in the Partner window. Can you make them the same so that inserting call with ALT-SPACE would also not trigger AUTOSEND? Because when it does then it is not possible to create a Tail End script/message which would allow toggling AUTOSEND ON/OFF during the contest like it is possible with GRABPARTNER.

I agree that calls grabbed from the real time partner window with Alt-Space, or the activation of $SPACEBAR, should not trigger autosending.

73,
Bob, N6TV
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.f5mzn.org/pipermail/support/attachments/20101201/94195c6f/attachment.htm