[WT-support] Feature request: PARTNER WINDOW

[Tõnno Vähk]

The first line should read could = could not

From: support-bounces at win-test.com [mailto:support-bounces at win-test.com] On Behalf Of Tõnno Vähk
Sent: Thursday, June 03, 2010 10:31 AM
To: support at win-test.com
Cc: k5zd at charter.net
Subject: Re: [WT-support] Feature request: PARTNER WINDOW

I could agree less with you Bob,

We have been there and this argument is finished and it has been very clearly communicated and agreed that there is no limit to physical stations/receivers/transmitters/computers as long as there is ONE SIGNAL IN THE AIR AT A TIME (in this case). Or two signals in M2 case.

Every serious MS participant (at least in EU) has more than one transmitter (3 to 6 as a rule at least). This is 100% coherent with the rules and accusing anyone in violating the rules is wrong, unjust and shortsighted.

What I am doing is to try to make WT help stations to fulfill the rules. Improve WT to support correct ONE SIGNAL AT A TIME management. I am afraid there are stations who are not following TX blocking requirement and that is a real problem.

So those enhancements I am asking would encourage following the rules not opposite! I am amazed you have got it upside down.

If WPX wanted to limit number of transceivers in use in station it could do so. IOTA contest has done it. WPX has not.

I CC Randy here because it is really sad that this argument is coming up. The same as SOAB operators "accused" in using SO2R (exactly the same wording in the rules - one transmitted signal at a time). Come on!

Tonno


From: support-bounces at win-test.com [mailto:support-bounces at win-test.com] On Behalf Of Bob Wilson, N6TV
Sent: Thursday, June 03, 2010 1:26 AM
To: support at win-test.com
Subject: Re: [WT-support] Feature request: PARTNER WINDOW

Using multiple transmitters in an "octopus" arrangement while competing as Multi-Single would be against the spirit of the new WPX Rules.  This is clearly spelled out in this blog entry by WPX contest director K5ZD.  Please read it all:

http://www.cqwpx.com/blog/?m=200912

The new MS rules are clearly designed to discourage the use of an octopus in the multi-single category.  Such stations are encouraged to enter as Multi-Two or Multi-Multi.

I don't think Win-Test should make any enhancements that would encourage further violation of the spirit of the rules, such as the enhancements described below, at least not for WPX.

73,
Bob, N6TV
On Wed, Jun 2, 2010 at 1:24 PM, Tõnno Vähk <Tonno.Vahk at gafm.ee<mailto:Tonno.Vahk at gafm.ee>> wrote:
I have been trying to solve the communication problems in Multi Op between ops. Especially hard it is now in WPX MS where only one signal is allowed at a time and one serial number sequence. Well, you might say 5 stations in that category is a bit overdone but that is what it takes to compete with E7DX and RU1A:)

So the problem is that while S&P stations have TX priority over RUN (they need to be able to cut CQ message) they don't always know when RUN is TXing and what it is sending. That makes the work unefficient.

PARNTER window shows content of callsign field, that is good. Is it possible to upgrade PARTNER window to show:

- content of the EXCHANGE RECEIVED window
- TX/RX status (I know you don't know abt footswitch, let's talk about button generated TX only)
- BUTTON THAT ACTIVATED MESSAGE BEING SENT (this is most important. When F1 is shown - CQ, when INSERT or F2 is show - EXCHANGE)

Another thing:

It is possible to have more than 1 RUN station (for example in M/2 or M/S with alternate CQ). Now the Support stations are displaying only one RUN station window. This is VERY bad because the two RUN stations conflict and PARTNER window is not correct.

What we need is two more options under Real time->

1. As Runner send to 1st, 2nd or 3rd slot
2. As Support display 1, 2 or 3 slots

Can you comment please! This would really take the communication and efficiency of multi op work to a new level.

73
Es5tv

p.s. when can we expect the new WRCT release? Restoring the ITU.DTB is very important!  We really need some time to test it as well..

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.f5mzn.org/pipermail/support/attachments/20100603/d7408bd9/attachment-0001.htm