[WT-support] Version 4 Feature Requests

Tõnno Vähk Tonno.Vahk at gildbankers.com
Sun Jun 15 17:21:01 CEST 2008


correct Fabio, I have also put that in my wish list a few times as it is greyed out now in Status window but would be very useful between networked stations.

es5tv

-----Original Message-----
From: support-bounces at win-test.com [mailto:support-bounces at win-test.com] On Behalf Of I4UFH HRS
Sent: Sunday, June 15, 2008 6:11 PM
To: support at win-test.com
Subject: [WT-support] Version 4 Feature Requests

Fine Analyse of the SO2R needs !!

I can suggest to swap freq above the network, not only between the two local 
radios, useful when u have 2nd RX ( support ) station am same band and move 
quickly the Runner to the new freq.

73 de Fabio I4UFH


----- Original Message ----- 
From: "Tõnno Vähk" <Tonno.Vahk at gildbankers.com>
To: <support at win-test.com>; <w0yk at msn.com>
Sent: Friday, June 13, 2008 10:57 AM
Subject: Re: [WT-support] Version 4 Feature Requests


> 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
> _______________________________________________
> Support mailing list
> Support at win-test.com
> http://www.f5mzn.org/cgi-bin/mailman/listinfo/support
> 

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


More information about the Support mailing list