[WT-support] Issues from ES9C

Tõnno Vähk Tonno.Vahk at gafm.ee
Tue Nov 30 21:10:11 CET 2010


That was our first MS in CQWW with WT. Some issues:

1. Confirm the need for 0 hz spot bandwith (I understand dev version provides it).

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.

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. Sometimes a call worked tens of QSOs ago. I can't test is now on my laptop (it does not produce CW sound for some reason) to systemize the bug but there is definitely a bug. I would say that $CORRECT needs to be ignored when callsign field is empty, right? This caused a lot of headaches for our RUN ops constantly when they had already entered a QSO but needed to send TU message. Bob, maybe you can test this bug to see what is the stuff that $CORRECT is sending when the callsign field is empty.

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?

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. I will try to see if I can find which QSOs did not propagate and why... Of course the Disable... was not flagged.

6. The Status window and QSY counters worked great. A small thing though: When a mult was worked on a Radio that was marked R for RUN and then the status of the QSO changed to M with ALT-Y then the Status window was properly updated in this particular computer but not on the other computers in the network. For them this QSO was left as RUN station QSO what regards STATUS window and counter was not reset. In the log window the status was correctly updated to M though on all computers. Maybe something that can be easily fixed...

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.

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.


All from me now:) Look forward to see if those things can be fixed.

73
Tonno
ES5TV



More information about the Support mailing list