[WT-support] Win-Test and contest numbers, proposal

Mark Bailey kd4d at comcast.net
Tue May 29 14:52:28 CEST 2012


I think this would work fine!  Thanks, Tono.

73,

Mark, KD4D

On 5/29/2012 8:29 AM, Rick Dougherty NQ4I wrote:
> Hi Tono and others...this is the best sounding solution I have heard 
> yet...
> de Rick NQ4I
>
> On Tue, May 29, 2012 at 7:41 AM, Wolfgang -DK9VZ- <ws at dk9vz.com 
> <mailto:ws at dk9vz.com>> wrote:
>
>     Hey Tönno
>
>     yes you're right, I didn´t consider that there is another mode
>     called SSB,
>     which I normally don´t use and don´t like ;-))
>
>     So your proposal to increment SN only the callsign fileld is empty
>     would be a very good solution in my view also.
>
>     It could lead to having sent the same number twice, but when both QSOs
>     are logged with that same number and could be cross checked it
>     wouldn´t be a problem.
>     A gap (a number without an assigned QSO) would not appear.
>
>     When can we have it? ;-))
>
>     /*73 de*/
>     /*Wolfgang DK9VZ*/
>     ws at dk9vz.com <mailto:ws at dk9vz.com> <mailto:ws at dk9vz.com
>     <mailto:ws at dk9vz.com>>
>
>
>     Am 29.05.2012 13:25, schrieb Tõnno Vähk:
>
>
>         I see a very interesting and needed discussion here. We just
>         completed another MS operation in WPX which now has one
>         numbering sequence only and running with 5 stations you need
>         all them to coordinate numbers. It is a mess as often the
>         number is stolen from the RUN station or another station after
>         it has given it out but before he has pressed Enter and then
>         the wrong sent number gets into the log. We do use
>         $NEXTSERIAL, etc... But a lot of human mistakes happen. And
>         unfortunately it is the innocent caller who gets punished as
>         he will lose the QSO because "wrongly copied" exchange.
>
>         I have seen the opinion of WT guys and solutions proposed and
>         arguments presented to protect the current system. Well,
>         obviously a critical mass of people have huge problems with
>         this thing and we would need at least some optional solution.
>         It is clear that none of the contest organizers require
>         perfect line of numbers and what is important is that the
>         numbers match in logs. So preserving a clean sequence is not
>         an argument.
>
>         Reserving the number somehow when it is sent does not quite
>         work as in SSB it won't work and even in CW some guys send
>         with paddle, etc.. Bob's idea abut the program checking what
>         was sent and logging it is interesting but again not universal.
>
>         It seems to me that the best option is to have a following
>         tickable option in WT:
>
>         ONLY INCREMENT SERIAL NUMBER WHEN CALLSIGN FIELD IS EMPTY
>
>         That's it. Let the station who has something on the callsign
>         field keep the number. This way it can never happen that you
>         log a different number from what is sent! If the QSO does not
>         happen and you clear the callsign field the number gets
>         immidiately synchronized again! Can someone point out when
>         this solution would not work?
>
>         If only it would not require rewriting the whole code of the
>         program! Does it??
>
>         73
>
>         Es5tv
>
>
>
>         _______________________________________________
>         Support mailing list
>         support at win-test.com <mailto:support at win-test.com>
>         http://lists.f5mzn.org/cgi-bin/mailman/listinfo/support
>
>
>     _______________________________________________
>     Support mailing list
>     support at win-test.com <mailto:support at win-test.com>
>     http://lists.f5mzn.org/cgi-bin/mailman/listinfo/support
>
>
>
>
> _______________________________________________
> Support mailing list
> support at win-test.com
> http://lists.f5mzn.org/cgi-bin/mailman/listinfo/support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.f5mzn.org/pipermail/support/attachments/20120529/1531f9da/attachment.html>


More information about the Support mailing list