[WT-support] WT experiences at ZL8X

[Christian Janssen]

Hi Bob,

> First, keep in mind that Win-Test is primarily contest software, not
> DXpedition software, though it has been used very successfully by many
> DXpeditions, including over 183,000 QSOs logged by VP6DX.  Please
> exchange notes with K3NA regarding some of the issues you describe
> below.  He may have other solutions.

I will be excited if he really has solutions for these problems. In my 
opinion DXpedition is still a contest (only lasting a little bit longer 
than a normal contest). Therefore you have similar needs. You will not 
use standard logging programs to log several 10,000 QSOs.

>     - We again experienced the lack of user profiles. Everytime when
>     operators changed their shifts the first workload was to reorganize
>     windows, messages, colours in WT.
>
>
> It would be nice, even for contesters, if Options | Windows could be
> enhanced to save and name Window position profiles as easily as you can
> save and name various addresses and callsigns in the Contest
> Configuration dialog.
>
> Today, Win-Test saves window positions, colors, and messages in two
> places:  wt.ini and the log itself.  Did you use Options | CW | Custom
> Variables or Options | CW | Additional Messages?  These are saved in the
> ini file, not the log, and can be helpful to DXpeditions.
>
> Each operator could be assigned their own personal wt.ini file and log
> file, and those files could be chosen when Win-Test restarts via a
> special icon or batch file, one per operator.
>
> wt -i DL1MGB.wt.ini DL1MGB_ZL8X.wt4
>
> Of course this would create a lot of network traffic as the log would
> have to be resynchronized in background every time it is opened, so that
> may not work well.

That's right. That's a no go.

> An alternative is to use the File | Merge dialog to merge an /empty/ log
> containing each operator's window preferences and messages with the
> current log.  The first log listed in the dialog will be used as the
> "master" for messages and window positions.  It's not easily automated,
> however.

And I will have 14 logs at each station, times 8 makes 112 logs in total 
to merge at the end? Or how would you do it?

>     If such a feature is about to get into WT one should consider that
>     it only makes sense when the log has
>     not to be reloaded when changing the user profile. With a loading time
>     of estimated 30 seconds with a log over 100k QSOs nobody will change the
>     user profile then.
>
>
> Well, there's no quick fix for that problem in the current version of
> Win-Test.  A way to save and restore a "Window profile" in wt.ini should
> be nice and fast though.

As stated above it is not.

>     - We also missed the possibility to use separate messages for CW and
>     RTTY. The described workaround with Ctrl-Tab doesn't work in such a
>     setup. Too many operators who get too confused by this.
>
>
> It would be nice to keep separate CW and RTTY messages.  A workaround
> for now is to assign a Lua script to every message key, and code the CW
> messages in the scripts, and the RTTY messages in the standard messages
> dialog.
>
> For example, in a LUA script assigned to F1, you could have:
>
> F1.wts:
>
> -- Get mode of current QSO
> local mode = wtQso:GetModeID()
>
> if mode == WT_MODE_CW then
>     wtKeyer:Play("CQ $MYCALL $MYCALL")
>
>     -- No further keystroke processing
>     return -1
> else
>     -- Else, not CW, so do normal keystroke processing to play RTTY or
> DVK message
>     return 0
> end
>
> Do this for F1 to F7, INSERT and PLUS.

I see. Also nothing for DXpedition. So we have to wait if there will be 
a better solution.

>     Also for example the repeat function of the F1 doesn't work in S&P
>     mode so people started
>     to throw away the workaround and went back to re-editing the standard
>     messages when switching from CW and RTTY and back.
>
>
> For a DXpedition using the suggested scripts, you probably would never
> need to switch between RUN and S&P modes, so you could disable Ctrl-TAB
> via the text command NORUNSP [Enter].
>
>     - Why did file export last so long? The log with nearly 150k QSOs needed
>     some minutes to export a normal text file with the columns CALLSIGN,
>     DATE, TIME, BAND, MODE. A bug or a feature?
>
>
> A known problem, perhaps a side effect of the encrypted V4 WT.EXE file.
>   I don't know if this can be fixed.

Hopefully, we won't make less QSOs the next time because of that ;-)

>     - Gab was sometimes missing some messages (computer visible in the Alt-J
>     windows, messages from computer A to B are possible but not the other
>     way). I guess that is due to the network protocol. Any ideas?
>
>
> Sounds like the wireless network was dropping packets.  I've never seen
> this happen on a wired network once intialized.  Maybe unlike QSO data,
> if there is a collision when a GAB message is sent, maybe Win-Test
> doesn't retry?  If it did, when a computer came back online, all of the
> missed Gab messages would show up, which would be very distracting.

It does definitely not retry to send the missing gabs. It was very 
interesting to see a computer in the Alt-J, you can see how this 
computer is logging QSOs (which are distributed over the network), you 
can send gab messages from any other computer to this computer , but 
when one enters a message into this computer to send it to the network 
nothing is shown. I know this is hard to rebuild here in civilization.

>     - When a QSO is corrected after it was logged on one computer this
>     information is not distributed correctly to all other computers. Is
>     there a special setting needed that also the corrections are
>     synchronized?
>
>
> If log SYNC is enabled, all QSO updates/edits should almost immediately
> propagate to every log in the network if using default networking
> options and every computer is using the same broadcast address.  Make
> sure Options | Disable Log Synchronization on Network is /not/ checked
> on any computer.  An unreliable wireless network could also cause
> problems, perhaps due to lack of retries as well?

It does definitely not. Or I don't know how many weeks the computers 
have to be in the network to get all synchronized. After 18 days there 
was a different count on each computer. Maybe the log gets too big for 
synch?

> Did anyone change the "Network Protocol Advanced Settings" on any of
> these computers or were all using the defaults?

I am not sure. BTW that's also a feature which should be password 
protected (see below)

>     - OPON function: This is a widely spread problem that operators don't
>     want to OPON because you can follow what they did wrong (that's my only
>     explanation why this is done). And of course you just forgot to OPON.
>     Maybe there is a possibility to ask the operator immediately (if there
>     is currently no OPON) or after a certain OFF time (i.e. 15 minutes) to
>     enter (or choose from a list) his callsign. Also ask for an operator
>     callsign when WT is started.
>
>
> Sounds reasonable for DXpedition and M/M logs to prompt for an operator
> when Win-Test is restarted, and it could default to the last operator
> that was logged on, so you can just hit Enter.  Of course Win-Test has
> no easy way to detect an operator change.
>
> Did you try using Tools | Correcting Op. over a QSO Range?  If you saved
> an "operator schedule" that was reasonably accurate (on paper or in a
> spreadsheet), you could note the QSO numbers that correlated to the
> ON/OFF times on every band/mode and get this operator data added to the
> log afterwards.

Yes, we try to rebuild the shift plans.

>     - We had the situation at some stations that the audio recording
>     function was also stopped (either because WT was re-started or somebody
>     didn't want his audio to be recorded or the audio recording was stopped
>     to find a reason if this or that didn't work). How can the audio
>     recording be started when WT is started without any possibility to
>     stop it?
>
>
> When you start a recording, you get a pop-up window with a check box
> that asks if you want the audio recordings to automatically restart the
> next time that Win-Test is launched.  It sounds likes like someone
> forgot to check that box in the pop-up window before pressing [OK].

And that's the problem. At the beginning I can check this box, but also 
everybody has the right to stop recording and everybody has the 
possibility to forget it. So it is nice to have, but you need someone to 
control it every some hours if it is still working. Unnecessary workload.

>     - That leads us to an administrator mode of WT :-) Those who installed
>     the stations at ZL8X had very often the wish to have an administrator
>     password to make certain settings impossible to change for the normal
>     user (configuration, network, audio,...).
>
>
> The REMOTE command (Commands | Remote commands...) can be used by WT
> administrators to send text commands to every computer on the LAN at the
> same time, or a selected computer.  But you can't "lock" anything.  What
> settings were changed that caused problems?

In my opinion following settings should/could be password locked:

- configure interfaces
- microham configuration
- MP3 configuration
- MP3 recording
- delete all QSO
- delete QSO

>     - Is it possible to view in the log who (station name) made changes to
>     the log? Or is there a plan to implement it to WT?
>
>
> There is no separate file kept to track every update made to the log.
>   The station name is recorded when a QSO is logged, then it never
> changes.  Even if this information was available, would it be useful?
> "Why did you change that QSO?" "I don't remember, I was tired." ...

Even if you know the operator who was sitting at the station at that 
time he doesn't remember all QSOs he changed. It would be just a feature 
to follow changes when merging all the logs.

>     - Having big logs synchronization needs a long time. Is it possible to
>     get the info out of WT about the synch status (how many QSOs need to be
>     synchronized, how long it will approximately take,...)? I think in
>     Writelog you can see this status.
>
>
> Not that I know of.  On a reliable network, logs nicely synchronize in
> the background while you are operating, so there's no real concern about
> "waiting" for it to "complete."

See above.

>     - Additional to Cabrillo import an ADIF import? Cabrillo doesn't accept
>     WARC bands at all :-((
>
>
> ADIF doesn't record contest exchanges well, hence ADIF /import/ is not
> supported by Win-Test.  Since a DXPedition is not a contest, there is no
> Cabrillo format for a DXpedition.

Time to introduce the change of the ADIF format :-)

> Why did you want to import an ADIF into Win-Test?  Did you need to make
> mass updates offline?

Because we have a DXpedition log and a contest log (CQWW CW) we want to 
merge.

>     - F9 window and Alt-S window should be configurable which modes should
>     be shown. Who runs HELL or SSTV on a serious DXpedition? It would save
>     alot of space on the desktop.
>
>
> Sounds very reasonable, but only needed by DXpeditions?
>
> On the Contest Configuration dialog, if you change mode from "All Modes"
> to "Mixed", it only displays CW and SSB.  Maybe a new mode option
> "CW/SSB/RTTY only" is needed.

The CW/SSB/RTTY would also help in this case.

73s Chris DL1MGB