[WT-support] "after-contest" impressions from a newcomer

[pat_f6irf]

Salut Laurent

> Hi !
>
> f6irf at free.fr 
> <http://www.f5mzn.org/cgi-bin/mailman/listinfo/support> a écrit :
>
>> / - Hamcap (ctrlP) use to work on my machine before installation of 
>> ver 3 /
>
> Pretty strange. Nothing wrong here...
>  
>

Sorry for the QRM  - installed hamcap 1.4 and everything is working fine 
(was still using hamcap 1.01 !)

>
>> / - With my Pro2, experience abt 2s latency with CAT, when clicking 
>> on a spot, or
>
> />/ when changing band , even with baudrate set at 19200. Note: The 
> bandmap follows
> />/ the VFO changes accurately and without latency, but the opposite 
> is not true (I
> />/ use the microkeyer as CAT interface).
> /
> Maybe smth abt the CI-V transceive mode ? As I don't own an ICOM, it's 
> just a comment...
>  
>
This is specific to win-test - does not happen with other software I use 
here...
Assume CI-V transceive OFF is the right setup, quickly tried with 
ON-option but it slows down bandmap response. (bandmap updates only when 
VFO stops)
Tried again now- strange thing is that it is not systematic - ie 
pressing alt-f2 several times band change is sometimes instaneous, 
sometimes not...

>> / - Experienced many speed problems with winkey v.10 when speed 
>> changes (++/--)
>
> />/ are used within messages... (ie sometimes the serial is sent very 
> QRS, and
> />/ sometime at the same speed as 5NN...)  Also some latency sometimes 
> when a F-key
> />/ is pressed. Sometimes repeating the call or the serial is 
> impossible (pressing
> />/ F3 or F4 does nothing...).
> />/ It seems to work far better using RTS-CW and DTR-PTT on the CAT 
> com port of the
> />/ microham, but just tried quickly after the contest...
> /
> WinKey related. I know Olivier is working on it. Pretty thought job !
>  
>
To be honnest had similar problems with winkey V10 using other software, 
so may not be a win-test problem...  However, had the impression that it 
was working
better with earlier version of win-test (maybe just an impression..., 
maybe you just have to forget about speed change for sending 5NN)

>> / - databases: assuming that good reasons for not using standard 
>> databases exist
>
> />/ (?)
> /
> There _are_ good reasons : I don't consider the K5ZD files as 
> databases. It is just preprocessed callsigns lists. They do not 
> include any additional data (like the default exchange etc...). Most 
> of the Win-Test DTB files do.
>
>> / tools should be provided to allow users to customize their 
>> databases (ie
>
> />/ master.dta and "contest specific" historical data). A way to 
> download updated
> />/ databases from the software should be provided.
> /
> We are working on it.
>  
>
Good news...
But maybe for updates ease, it would be better to have a different 
database for exchange data and callsigns data (ie for US states in 
ARRL-DX).
Where I see the problem is that RTTY requires specific master.dta  (many 
contesters are RTTY only, many others are CW/SSB only)
One RTTY master.dta is maintained by AA5AU, but it very US-specific 
(many US domestic-contest calls never heard here) while many EU
casual contesters do not appear in his DTA (though they appear in my 
logs quite a few times...) so I like to maintain mine, using VE3NEA 
utility...
Another RTTY-specific feature is that you want to be able to send "op 
name" when you QSO someone you know... (may look stupid, but it is a TTY 
tradition...)
There is a  so called "friend.ini"  maintained by AF4Z, but it also 
requires some customisation/cleaning to be optimum...
(ie you don't want to send HELLO INTERNATIONAL AMATEUR RADIO CLUB when 
you contact 4U1ITU ! - while TNX BILL or GRACIAS JOSE is fine to end-up 
a QSO)
There is some other useful-data like Locator in Makrothen contest, or op 
age in JARTS which will be difficult to maintain by non motivated TTY 
operators, so it is
the reason why I think this part should be left to users... (like 
N1MM-logger does, with the coma separated "history file" that you can 
easily manipulate yourself
using excel, or some dedicated utility software ).


>> / - Having to press ctrl-enter to enter a call in bandmap is a waste 
>> of time - a
>
> />/ QSY should automaticaly enter the call in bandmap and wipe the 
> entry field.
> />/ Furthermore  calls cannot be transferred by mouse click from the 
> "check
> />/ partial" window to entry window, which slows down the S&P process.
> /
> Can you elaborate ? I don't see the connection between the check 
> partial window and the log entry field ??? In what case would it be 
> useful (I mean _really_ useful) and faster than typing ?
>
>  
>
Easy: you hear BUE, when QSY'ing - you just type BUE (or capture it with 
mouse in TTY), then SP1/DL3BUE appears in green in "check window" (you 
have worked him on another band).
The only thing you have to do is click on the call in "check windows" 
and full call pops up in entry windows...
Assuming SP1/DL3BUE  is not a multiplier and that you don't want to 
spend time with him now;  you just QSY and his call is recorded in bandmap,
and entry field wiped, without any keyboard press.
It may look useless for a CT user used to KB only, but it is very 
precious in TTY, especialy when running SO2R... one hand on the mouse, 
the other on the VFO...