[WT-support] Version 4 Feature Requests

[Tõnno Vähk]

good ideas.

Especially the TX lockout! Would be great if possible to implement! I was proposing earlier to indicate a TX/RX indicator to status window to show when the other radio is in TX but this network enfourced TX lockout would be simply perfect for Multi Op! That means you can link to each other in this lockout scheme any two (or more) stations in network. Say you have 4 stations and Station 1 and 3 have a First TX wins between themselves and Station 2 and 4 have Last TX wins between them.

Programming F8 to F12 for extra messages is also something I have wished for a while. There is a semi-solution now in the form of ByebyeCT prgram that lets you activate Additional messages from those keys.

73
es5tv

-----Original Message-----
From: support-bounces at win-test.com [mailto:support-bounces at win-test.com] On Behalf Of Ed Muns
Sent: Friday, June 13, 2008 6:31 AM
To: support at win-test.com
Subject: [WT-support] Version 4 Feature Requests

I propose the following features and enhancements be included in the next
major Win-Test release:

1.  SO2R Two-Computer Configuration - Provide TX Lockout configuration
between networked computers.  Allow the user to choose between:
	a. First TX wins.  Initiating a transmission on another radio is
inhibited until the current transmission is complete.  This insures that the
current transmission is not interrupted with the undesired consequence of
having to resend it, e.g., an exchange.  However, this option will not
likely be used much.
	b. Last TX wins.  A transmission initiated on one radio will first
stop any ongoing transmission on another radio.  This is the most common
option and the one currently implemented for one-radio SO2R in Win-Test.
	c. Linked TX.  A transmission on one radio will be queued up to
begin upon completion of an ongoing transmission on another radio.

2.  Frequency Grab Variable - Add a message variable that inserts the
frequency of any specified radio on the network, including multiple radios
on one computer, i.e., one-computer SO2R.  The frequency should be resolved
to 100 Hz, e.g., '14032.6'.  This allows SO2R and multi-op operators to set
up QSY messages where the frequency dynamically tracks the VFO on the
specified radio.  The operator can simply find a clear frequency and
initiate the QSY message rather than having to send, or type, the frequency.
If the QSY frequency is already a run frequency, then this frees the
operator of having to either send the QSY message manually or stop and
insert it into a QSY message.

3.  Multiple RTTY Windows per Radio - Provide for multiple RTTY windows so
that parallel decoding can be done with different decoders, e.g., hardware
TNC and software decoder, as well as multiple instances of the same decoder
with different decoder algorithms configured.  An example of the latter
would be three MMTTY decoder windows running off the same soundcard audio
input but each with a different FFT profile: Standard, Flutter and
Multi-path.  The reason for this is that sometimes one decoder or profile
will copy in marginal conditions where others will not.  Too much time is
lost manually switching between profiles while receiving.  Only one of the
decoders or instances should be the RTTY TX encoder, while all the others
are read only (decode).

4.  I think the following three are already captured on the request list:

	a. F8-F12 Messages - Allow F8-F12 to be arbitrarily programmed by
the user like F1-F7, although the defaults can be the current CT
definitions.

	b. Clear RIT Message Variable - Add a $CLEARRIT message variable.

	c. CQP Support - Add support for this state QSO party, by far the
largest QSO party in the US.

Thanks,
Ed - W0YK
	

_______________________________________________
Support mailing list
Support at win-test.com
http://www.f5mzn.org/cgi-bin/mailman/listinfo/support