Re: [wsjt-devel] SUGGESTION

2022-03-10 Thread Conrad PA5Y via wsjt-devel
This is a none invasive solution and practical, there are times when I require 
a continuous carrier. So my vote would be to adopt Mike’s suggestion.

Conrad PA5Y

From: Black Michael via wsjt-devel 
Sent: 06 March 2022 14:05
To: 'WSJT software development' 
Cc: Black Michael 
Subject: Re: [wsjt-devel] SUGGESTION

My suggestion would be to default the Tune to 30 seconds (some tuners are slow) 
and then have CTRL-Click make it stick.

Mike W9MDB




On Sunday, March 6, 2022, 06:10:13 AM CST, Reino Talarmo via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:


I also belong to the continuous carrier lot. Already now there is the TX
watch dog that can be set from 1 min
to 99 min or disabled. I assume that the 1 min value could be good enough
in most cases for those who don't want boil their rig..
The 1 min value seems to be maximum 1 min time depending when the Tune is
activated. The watch god hit at 0, 15, 30 or 45 s of a minute.

73, Reino OH3mA

On 3/6/22 04:39, Claude Frantz via wsjt-devel wrote:
>
> On 3/6/22 10:28, Charles Suckling via wsjt-devel wrote:
>
> Hi Charly & all,
>
>> I personally find it useful to be able to generate a continuous
>> carrier with WSJT-X using the Tune button.
>
> I share this opinion, it's an important feature because many XCVR's do
> not offer this function in a simple manner.
>
> Best wishes,
> Claude (DJ0OT)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-07 Thread DG2YCB, Uwe via wsjt-devel
Hi Reino,

Before I answer your questions, a few general comments. WSJTX has internally 
several timers that keep all processes clean and prevent unwanted effects. The 
normal user doesn't even notice all this, and that's intended. This is exactly 
how it should be with the new Tune watchdog. If you use the Tune button for 
what it is intended for, you will not notice the Tune watchdog.

Another important point is that it has always been our policy to keep the WSJTX 
code as simple and robust as possible. This was very important to Bill (sk) as 
well! Therefore it would be too much of a good thing to make a tune watchdog 
adjustable. It is only there to protect your transceiver (and the bands) from 
unintended long term transmissions.

But since there are obviously users who use the Tune button for other purposes 
and need continuous transmissions, I reprogrammed it this morning so that you 
can disable the Tune watchdog with a checkbox “Disable Tune watchdog” (see the 
screen shot of my current development version). The checkbox is not set by 
default, because only in this way users, who are not even aware that there is 
such a thing, get the protection. The others need only ONCE to activate the 
checkbox and everything is as before (of course WSJTX remembers the status of 
the checkbox).

 



 

To answer your questions:

1. The new Tune watchdog and the existing Tx watchdog work independent of each 
other.  

2. and 3. No, see my comment above about this. (I have now set the Tune 
watchdog to 90 seconds. This should not damage any transceiver and the time 
should also be sufficient for any ATU.)

4. The Tx watchdog remains unchanged. This means that if you have e.g. the Tx 
watchdog on 6 minutes, your normal transmissions will stop after 6 minutes, but 
the Tune watchdog would disable the Tune button after 90 seconds. If you set 
the Tx watchdog to 1 minute, then Tune would also be turned off after 1 minute, 
or to be more precise: exactly at the next full minute. As before. But if you 
set the Tx watchdog to let’s say 30 minutes and have "Disable Tune watchdog" 
activated, then you could theoretically transmit continuously for 30 minutes 
with the help of the Tune button. As it was before.

 

I hope it has now become clear. No one needs to be afraid of the new Tune 
watchdog, but it will help thousands to protect their transceivers from 
unintentional continuous transmissions. The function has worked well for my own 
WSJTX fork for 1.5 years now. It is based on repeated user requests. And I have 
also received several "thank you" emails from other OMs who had sometimes 
accidentally sent 1 hour or so in the past.

 

73 de Uwe DG2YCB 

 

Von: Reino Talarmo via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Gesendet: Montag, 7. März 2022 06:03
An: 'WSJT software development'
Cc: Reino Talarmo
Betreff: Re: [wsjt-devel] SUGGESTION

 

>Then let's make it switchable.The majority of users will certainly find a Tune 
>watchdog useful and want to have it activated, but those who don't like it can 
>then simply switch it off. Good solution.

 

Hi Uwe, 

How that new Tune watchdog will interact with the current Tx watchdog? 
1. Would it be totally independent?

2. Would there be a selectable tuning time in some range, say up to a minute or 
even 99 minutes?

3. If tuning time will be selectable, will it be selected at “Hit time” or in 
the same manner as Tx watch dog by a menu setting in General window?

4. If tuning time is not activated, will TX be on for even or will Tx watchdog 
still cut the transmission as it does in current version?

 

And of course you may Halt transmission at any time. Would that happen with 
Tune button as today or only with the Halt Tx button?

 

Sorry for too many questions on a simple issue, hi!

 

73, Reino OH3mA

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Reino Talarmo via wsjt-devel
>Then let's make it switchable.The majority of users will certainly find a Tune 
>watchdog useful and want to have it activated, but those who don't like it can 
>then simply switch it off. Good solution.

 

Hi Uwe, 

How that new Tune watchdog will interact with the current Tx watchdog? 
1. Would it be totally independent?

2. Would there be a selectable tuning time in some range, say up to a minute or 
even 99 minutes?

3. If tuning time will be selectable, will it be selected at “Hit time” or in 
the same manner as Tx watch dog by a menu setting in General window?

4. If tuning time is not activated, will TX be on for even or will Tx watchdog 
still cut the transmission as it does in current version?

 

And of course you may Halt transmission at any time. Would that happen with 
Tune button as today or only with the Halt Tx button?

 

Sorry for too many questions on a simple issue, hi!

 

73, Reino OH3mA

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Megan Woods via wsjt-devel
Hi,

How about some sort of split button where the primary option is for 30
seconds and via the secondary option folks can select to have it on until
they switch it off.

MW - VK3TIN, AJ6EI



On Mon, Mar 7, 2022 at 8:11 AM Gary McDuffie via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

>
>
> > On Mar 6, 2022, at 02:56, Alan via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
> >
> >  it's an important feature because many XCVR's do not offer this
> function in a simple manner.
>
> Put the radio in CW mode and lock the key.  Simple.
>
> Gary - AG0N
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread DG2YCB via wsjt-devel

Then let's make it switchable.The majority of users will certainly find a
Tune watchdog useful and want to have it activated, but those who don't
like it can then simply switch it off. Good solution.

73 de Uwe, DG2YCB

Am 6. März 2022 21:41:23 schrieb Charles Suckling via wsjt-devel
:

Uwe

As others have stated, there are occasions when one wants to use WSJT-X to
generate a carrier for a long, non-fixed time.  For example, someone on
10GHz EME was doing exactly that (to look for drift in a TWT over time.
Having a time limited Tune would be a new feature that a number of folks
won't like, as expressed here in other messages.

If a 'watchdog' is to be added to Tune, then please allow those of us who
don't want it to be able to revert to its historic behaviour.

73

Charlie DL3WDG


On Sun, 6 Mar 2022 at 19:55, DG2YCB, Uwe via wsjt-devel
 wrote:


Well, basically it is no problem to make a checkbox to deactivate such a
TUNE watchdog, but tell me: What do you need it for?



73 de Uwe DG2YCB



Von: Carey Fisher via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
Gesendet: Sonntag, 6. März 2022 19:29
An: WSJT software development
Cc: Carey Fisher
Betreff: Re: [wsjt-devel] SUGGESTION



Make it a programmable (up to 10 minutes)  time, default to 2 minutes.



On Sun, Mar 6, 2022 at 12:19 PM DG2YCB, Uwe via wsjt-devel
 wrote:

Hi all,



Since I had similar requests for such a function in the past, I already
programmed a time limit for the TUNE button a few weeks ago. This will be
included in the next WSJTX release. 10 seconds is of course much too short,
but I think 2 minutes is reasonable. This should be long enough to tune
your antenna, but it effectively prevents unwanted continuous transmissions.



73 de Uwe, DG2YCB



Von: Carey Fisher via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
Gesendet: Sonntag, 6. März 2022 14:26
An: WSJT software development
Cc: Carey Fisher
Betreff: Re: [wsjt-devel] SUGGESTION



Uh, no!



On Sat, Mar 5, 2022 at 11:51 PM Gavin ZL3GAV via wsjt-devel
 wrote:

Hello



Not a huge priority, but one of those nice to have please…



With the TUNE button, can this be limited to timeout at 10 seconds maximum
please?



From experience, we all make silly mistakes, whilst tuning my FT-991A I got
distracted, with the result, I nuked the radio (since fixed) running on
full power on TUNE. It is not a pleasant experience the acrid smell of
burning electronic components!



73



Gavin

ZL3GAV







___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--

Carey Fisher

careyfis...@gmail.com



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel






--

Carey Fisher

careyfis...@gmail.com



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Gary trock via wsjt-devel
Thanks for the suggestions.
Gary N8GT

Sent from my iPhone

> On Mar 6, 2022, at 1:09 PM, Gary McDuffie via wsjt-devel 
>  wrote:
> 
> 
> 
>> On Mar 5, 2022, at 21:19, Gavin ZL3GAV via wsjt-devel 
>>  wrote:
>> 
>> With the TUNE button, can this be limited to timeout at 10 seconds maximum 
>> please?
>> 
>> From experience, we all make silly mistakes, whilst tuning my FT-991A I got 
>> distracted, with the result, I nuked the radio (since fixed)running on full 
>> power on TUNE. It is not a pleasant experience the acrid smell of burning 
>> electronic components!
> 
> A much simpler way to get around it is to be sure you always have MONITOR 
> turned on.  You should be monitoring your output audio quality anyway.  It 
> will give you immediate notification when it is either locked on or 
> forgotten.  It doesn’t need to be loud, but if you can hear it, it will let 
> you know it is still on.  Also, most radios these days have a timeout timer 
> that you can set for maximum transmit time.  Set that to save the transmitter 
> from destroying itself, or QRMing the rest of the people on the band.
> 
> Gary - AG0N
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=04%7C01%7C%7C4a7d375e44694a9598cf08d9ffb59b25%7C84df9e7fe9f640afb435%7C1%7C0%7C637821977733852714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=tLm1%2FPkKRhJQvuBrzSNiRt%2BpgiGwEs1ccw7YO1SXNWo%3Dreserved=0

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Gary McDuffie via wsjt-devel



> On Mar 6, 2022, at 02:56, Alan via wsjt-devel 
>  wrote:
> 
>  it's an important feature because many XCVR's do not offer this function in 
> a simple manner.

Put the radio in CW mode and lock the key.  Simple.

Gary - AG0N

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Gary McDuffie via wsjt-devel


> On Mar 5, 2022, at 21:19, Gavin ZL3GAV via wsjt-devel 
>  wrote:
> 
> With the TUNE button, can this be limited to timeout at 10 seconds maximum 
> please?
>  
> From experience, we all make silly mistakes, whilst tuning my FT-991A I got 
> distracted, with the result, I nuked the radio (since fixed)running on full 
> power on TUNE. It is not a pleasant experience the acrid smell of burning 
> electronic components!

A much simpler way to get around it is to be sure you always have MONITOR 
turned on.  You should be monitoring your output audio quality anyway.  It will 
give you immediate notification when it is either locked on or forgotten.  It 
doesn’t need to be loud, but if you can hear it, it will let you know it is 
still on.  Also, most radios these days have a timeout timer that you can set 
for maximum transmit time.  Set that to save the transmitter from destroying 
itself, or QRMing the rest of the people on the band.

Gary - AG0N

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Charles Suckling via wsjt-devel
Uwe

As others have stated, there are occasions when one wants to use WSJT-X to
generate a carrier for a long, non-fixed time.  For example, someone on
10GHz EME was doing exactly that (to look for drift in a TWT over time.
Having a time limited Tune would be a new feature that a number of folks
won't like, as expressed here in other messages.

If a 'watchdog' is to be added to Tune, then please allow those of us who
don't want it to be able to revert to its historic behaviour.

73

Charlie DL3WDG

On Sun, 6 Mar 2022 at 19:55, DG2YCB, Uwe via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Well, basically it is no problem to make a checkbox to deactivate such a
> TUNE watchdog, but tell me: What do you need it for?
>
>
>
> 73 de Uwe DG2YCB
>
>
>
> *Von:* Carey Fisher via wsjt-devel [mailto:
> wsjt-devel@lists.sourceforge.net]
> *Gesendet:* Sonntag, 6. März 2022 19:29
> *An:* WSJT software development
> *Cc:* Carey Fisher
> *Betreff:* Re: [wsjt-devel] SUGGESTION
>
>
>
> Make it a programmable (up to 10 minutes)  time, default to 2 minutes.
>
>
>
> On Sun, Mar 6, 2022 at 12:19 PM DG2YCB, Uwe via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> Hi all,
>
>
>
> Since I had similar requests for such a function in the past, I already
> programmed a time limit for the TUNE button a few weeks ago. This will be
> included in the next WSJTX release. 10 seconds is of course much too short,
> but I think 2 minutes is reasonable. This should be long enough to tune
> your antenna, but it effectively prevents unwanted continuous transmissions.
>
>
>
> 73 de Uwe, DG2YCB
>
>
>
> *Von:* Carey Fisher via wsjt-devel [mailto:
> wsjt-devel@lists.sourceforge.net]
> *Gesendet:* Sonntag, 6. März 2022 14:26
> *An:* WSJT software development
> *Cc:* Carey Fisher
> *Betreff:* Re: [wsjt-devel] SUGGESTION
>
>
>
> Uh, no!
>
>
>
> On Sat, Mar 5, 2022 at 11:51 PM Gavin ZL3GAV via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> Hello
>
>
>
> Not a huge priority, but one of those nice to have please…
>
>
>
> With the TUNE button, can this be limited to timeout at 10 seconds maximum
> please?
>
>
>
> From experience, we all make silly mistakes, whilst tuning my FT-991A I
> got distracted, with the result, I nuked the radio *(since fixed)*
> running on full power on TUNE. It is not a pleasant experience the acrid
> smell of burning electronic components!
>
>
>
> 73
>
>
>
> Gavin
>
> ZL3GAV
>
>
>
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> --
>
> Carey Fisher
>
> careyfis...@gmail.com
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
>
> --
>
> Carey Fisher
>
> careyfis...@gmail.com
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Gavin ZL3GAV via wsjt-devel
Daniel

 

Two different requirements, the watch dog I usually set for say 15 minutes for 
FT8 operation, which is off/on TX/RX cycles. If in the case where I left the 
Tune feature running, 15 minutes continuous was more than sufficient to 
overheat the radio.

 

Regards

 

Gavin

ZL3GAV

 

From: Daniel Delaplain via wsjt-devel  
Sent: Monday, 7 March 2022 07:46
To: careyfis...@gmail.com; WSJT software development 

Cc: Daniel Delaplain 
Subject: Re: [wsjt-devel] SUGGESTION

 

The tune time out is programmable.  Go to file/settings/general. At the bottom 
of the screen is Tx watchdog. It works for both the Enable Tx button, and the 
Tune button. Mine is set for 4 minutes. 

Sent from AT 
<https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature_web_dp=https://more.att.com/currently/imap>
  Yahoo Mail on Android

 

On Sun, Mar 6, 2022 at 10:30 AM, Carey Fisher via wsjt-devel

mailto:wsjt-devel@lists.sourceforge.net> > 
wrote:

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Bruce Bohannon via wsjt-devel
My thought is if you need that much time to tune the radio to the 
antenna, fix the antenna and feed line to it.


Bruce WA1YZN

On 3/6/2022 13:45, Daniel Delaplain via wsjt-devel wrote:
The tune time out is programmable.  Go to file/settings/general. At 
the bottom of the screen is Tx watchdog. It works for both the Enable 
Tx button, and the Tune button. Mine is set for 4 minutes.


Sent from AT Yahoo Mail on Android 



On Sun, Mar 6, 2022 at 10:30 AM, Carey Fisher via wsjt-devel
 wrote:
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Daniel Delaplain via wsjt-devel
The tune time out is programmable.  Go to file/settings/general. At the bottom 
of the screen is Tx watchdog. It works for both the Enable Tx button, and the 
Tune button. Mine is set for 4 minutes. 

Sent from AT Yahoo Mail on Android 
 
  On Sun, Mar 6, 2022 at 10:30 AM, Carey Fisher via 
wsjt-devel wrote:   
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Daniel Delaplain via wsjt-devel
The tune time out is programmable.  Go to file/settings/general. At the bottom 
of the screen is Tx watchdog. It works for both the Enable Tx button, and the 
Tune button. Mine is set for 4 minutes. 

Sent from AT Yahoo Mail on Android 
 
  On Sun, Mar 6, 2022 at 5:06 AM, Black Michael via 
wsjt-devel wrote:   
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread DG2YCB, Uwe via wsjt-devel
Well, basically it is no problem to make a checkbox to deactivate such a TUNE 
watchdog, but tell me: What do you need it for?

 

73 de Uwe DG2YCB 

 

Von: Carey Fisher via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Gesendet: Sonntag, 6. März 2022 19:29
An: WSJT software development
Cc: Carey Fisher
Betreff: Re: [wsjt-devel] SUGGESTION

 

Make it a programmable (up to 10 minutes)  time, default to 2 minutes.

 

On Sun, Mar 6, 2022 at 12:19 PM DG2YCB, Uwe via wsjt-devel 
 wrote:

Hi all,

 

Since I had similar requests for such a function in the past, I already 
programmed a time limit for the TUNE button a few weeks ago. This will be 
included in the next WSJTX release. 10 seconds is of course much too short, but 
I think 2 minutes is reasonable. This should be long enough to tune your 
antenna, but it effectively prevents unwanted continuous transmissions.

 

73 de Uwe, DG2YCB

 

Von: Carey Fisher via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Gesendet: Sonntag, 6. März 2022 14:26
An: WSJT software development
Cc: Carey Fisher
Betreff: Re: [wsjt-devel] SUGGESTION

 

Uh, no!

 

On Sat, Mar 5, 2022 at 11:51 PM Gavin ZL3GAV via wsjt-devel 
 wrote:

Hello

 

Not a huge priority, but one of those nice to have please…

 

With the TUNE button, can this be limited to timeout at 10 seconds maximum 
please?

 

>From experience, we all make silly mistakes, whilst tuning my FT-991A I got 
>distracted, with the result, I nuked the radio (since fixed) running on full 
>power on TUNE. It is not a pleasant experience the acrid smell of burning 
>electronic components!

 

73

 

Gavin

ZL3GAV

 

 

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

-- 

Carey Fisher

careyfis...@gmail.com

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




 

-- 

Carey Fisher

careyfis...@gmail.com

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Carey Fisher via wsjt-devel
Make it a programmable (up to 10 minutes)  time, default to 2 minutes.

On Sun, Mar 6, 2022 at 12:19 PM DG2YCB, Uwe via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hi all,
>
>
>
> Since I had similar requests for such a function in the past, I already
> programmed a time limit for the TUNE button a few weeks ago. This will be
> included in the next WSJTX release. 10 seconds is of course much too short,
> but I think 2 minutes is reasonable. This should be long enough to tune
> your antenna, but it effectively prevents unwanted continuous transmissions.
>
>
>
> 73 de Uwe, DG2YCB
>
>
>
> *Von:* Carey Fisher via wsjt-devel [mailto:
> wsjt-devel@lists.sourceforge.net]
> *Gesendet:* Sonntag, 6. März 2022 14:26
> *An:* WSJT software development
> *Cc:* Carey Fisher
> *Betreff:* Re: [wsjt-devel] SUGGESTION
>
>
>
> Uh, no!
>
>
>
> On Sat, Mar 5, 2022 at 11:51 PM Gavin ZL3GAV via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> Hello
>
>
>
> Not a huge priority, but one of those nice to have please…
>
>
>
> With the TUNE button, can this be limited to timeout at 10 seconds maximum
> please?
>
>
>
> From experience, we all make silly mistakes, whilst tuning my FT-991A I
> got distracted, with the result, I nuked the radio *(since fixed)*
> running on full power on TUNE. It is not a pleasant experience the acrid
> smell of burning electronic components!
>
>
>
> 73
>
>
>
> Gavin
>
> ZL3GAV
>
>
>
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> --
>
> Carey Fisher
>
> careyfis...@gmail.com
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


-- 
Carey Fisher
careyfis...@gmail.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Charles Suckling via wsjt-devel
Good suggestion, Mike.  I would like an easy to use method of keeping it
continuous.

Charlie DL3WDG

On Sun, 6 Mar 2022 at 18:33, Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> And can you make CTRL-click keep it on please?
> There are use cases for it.
>
> Mike W9MDB
>
>
>
>
> On Sunday, March 6, 2022, 11:20:58 AM CST, DG2YCB, Uwe via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>
> Hi all,
>
>
>
> Since I had similar requests for such a function in the past, I already
> programmed a time limit for the TUNE button a few weeks ago. This will be
> included in the next WSJTX release. 10 seconds is of course much too short,
> but I think 2 minutes is reasonable. This should be long enough to tune
> your antenna, but it effectively prevents unwanted continuous transmissions.
>
>
>
> 73 de Uwe, DG2YCB
>
>
>
> *Von:* Carey Fisher via wsjt-devel [mailto:
> wsjt-devel@lists.sourceforge.net]
> *Gesendet:* Sonntag, 6. März 2022 14:26
> *An:* WSJT software development
> *Cc:* Carey Fisher
> *Betreff:* Re: [wsjt-devel] SUGGESTION
>
>
>
> Uh, no!
>
>
>
> On Sat, Mar 5, 2022 at 11:51 PM Gavin ZL3GAV via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> Hello
>
>
>
> Not a huge priority, but one of those nice to have please…
>
>
>
> With the TUNE button, can this be limited to timeout at 10 seconds maximum
> please?
>
>
>
> From experience, we all make silly mistakes, whilst tuning my FT-991A I
> got distracted, with the result, I nuked the radio *(since fixed)*
> running on full power on TUNE. It is not a pleasant experience the acrid
> smell of burning electronic components!
>
>
>
> 73
>
>
>
> Gavin
>
> ZL3GAV
>
>
>
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> --
>
> Carey Fisher
>
> careyfis...@gmail.com
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Black Michael via wsjt-devel
And can you make CTRL-click keep it on please?There are use cases for it.
Mike W9MDB

 

On Sunday, March 6, 2022, 11:20:58 AM CST, DG2YCB, Uwe via wsjt-devel 
 wrote:  
 
 
Hi all,

  

Since I had similar requests for such a function in the past, I already 
programmed a time limit for the TUNE button a few weeks ago. This will be 
included in the next WSJTX release. 10 seconds is of course much too short, but 
I think 2 minutes is reasonable. This should be long enough to tune your 
antenna, but it effectively prevents unwanted continuous transmissions.

  

73 de Uwe, DG2YCB

  

Von: Carey Fisher via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Gesendet: Sonntag, 6. März 2022 14:26
An: WSJT software development
Cc: Carey Fisher
Betreff: Re: [wsjt-devel] SUGGESTION

  

Uh, no!

  

On Sat, Mar 5, 2022 at 11:51 PM Gavin ZL3GAV via wsjt-devel 
 wrote:


Hello

 

Not a huge priority, but one of those nice to have please…

 

With the TUNE button, can this be limited to timeout at 10 seconds maximum 
please?

 

>From experience, we all make silly mistakes, whilst tuning my FT-991A I got 
>distracted, with the result, I nuked the radio (since fixed) running on full 
>power on TUNE. It is not a pleasant experience the acrid smell of burning 
>electronic components!

 

73

 

Gavin

ZL3GAV

 

 

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


-- 

Carey Fisher

careyfis...@gmail.com

  
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread DG2YCB, Uwe via wsjt-devel
Hi all,

 

Since I had similar requests for such a function in the past, I already 
programmed a time limit for the TUNE button a few weeks ago. This will be 
included in the next WSJTX release. 10 seconds is of course much too short, but 
I think 2 minutes is reasonable. This should be long enough to tune your 
antenna, but it effectively prevents unwanted continuous transmissions.

 

73 de Uwe, DG2YCB

 

Von: Carey Fisher via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Gesendet: Sonntag, 6. März 2022 14:26
An: WSJT software development
Cc: Carey Fisher
Betreff: Re: [wsjt-devel] SUGGESTION

 

Uh, no!

 

On Sat, Mar 5, 2022 at 11:51 PM Gavin ZL3GAV via wsjt-devel 
 wrote:

Hello

 

Not a huge priority, but one of those nice to have please…

 

With the TUNE button, can this be limited to timeout at 10 seconds maximum 
please?

 

>From experience, we all make silly mistakes, whilst tuning my FT-991A I got 
>distracted, with the result, I nuked the radio (since fixed) running on full 
>power on TUNE. It is not a pleasant experience the acrid smell of burning 
>electronic components!

 

73

 

Gavin

ZL3GAV

 

 

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

-- 

Carey Fisher

careyfis...@gmail.com

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Carey Fisher via wsjt-devel
Uh, no!

On Sat, Mar 5, 2022 at 11:51 PM Gavin ZL3GAV via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hello
>
>
>
> Not a huge priority, but one of those nice to have please…
>
>
>
> With the TUNE button, can this be limited to timeout at 10 seconds maximum
> please?
>
>
>
> From experience, we all make silly mistakes, whilst tuning my FT-991A I
> got distracted, with the result, I nuked the radio *(since fixed)*
> running on full power on TUNE. It is not a pleasant experience the acrid
> smell of burning electronic components!
>
>
>
> 73
>
>
>
> Gavin
>
> ZL3GAV
>
>
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
-- 
Carey Fisher
careyfis...@gmail.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Black Michael via wsjt-devel
My suggestion would be to default the Tune to 30 seconds (some tuners are slow) 
and then have CTRL-Click make it stick.
Mike W9MDB

 

On Sunday, March 6, 2022, 06:10:13 AM CST, Reino Talarmo via wsjt-devel 
 wrote:  
 
 I also belong to the continuous carrier lot. Already now there is the TX
watch dog that can be set from 1 min
 to 99 min or disabled. I assume that the 1 min value could be good enough
in most cases for those who don't want boil their rig..
The 1 min value seems to be maximum 1 min time depending when the Tune is
activated. The watch god hit at 0, 15, 30 or 45 s of a minute.

73, Reino OH3mA

On 3/6/22 04:39, Claude Frantz via wsjt-devel wrote:
>  
> On 3/6/22 10:28, Charles Suckling via wsjt-devel wrote:
> 
> Hi Charly & all,
> 
>> I personally find it useful to be able to generate a continuous 
>> carrier with WSJT-X using the Tune button.
> 
> I share this opinion, it's an important feature because many XCVR's do 
> not offer this function in a simple manner.
> 
> Best wishes,
> Claude (DJ0OT)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Reino Talarmo via wsjt-devel
I also belong to the continuous carrier lot. Already now there is the TX
watch dog that can be set from 1 min
 to 99 min or disabled. I assume that the 1 min value could be good enough
in most cases for those who don't want boil their rig..
The 1 min value seems to be maximum 1 min time depending when the Tune is
activated. The watch god hit at 0, 15, 30 or 45 s of a minute.

73, Reino OH3mA

On 3/6/22 04:39, Claude Frantz via wsjt-devel wrote:
>  
> On 3/6/22 10:28, Charles Suckling via wsjt-devel wrote:
> 
> Hi Charly & all,
> 
>> I personally find it useful to be able to generate a continuous 
>> carrier with WSJT-X using the Tune button.
> 
> I share this opinion, it's an important feature because many XCVR's do 
> not offer this function in a simple manner.
> 
> Best wishes,
> Claude (DJ0OT)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread N1BUG via wsjt-devel
I also share the opinion that continuous tune is useful. I used it to 
provide a steady signal for adjusting my LF phasing exciter to balance 
out the opposite sidebands. That process can take several minutes and 
should be rechecked occasionally.


73,
Paul N1BUG


On 3/6/22 04:39, Claude Frantz via wsjt-devel wrote:


On 3/6/22 10:28, Charles Suckling via wsjt-devel wrote:

Hi Charly & all,


I personally find it useful to be able to generate a continuous carrier
with WSJT-X using the Tune button.


I share this opinion, it's an important feature because many XCVR's do 
not offer this function in a simple manner.


Best wishes,
Claude (DJ0OT)



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Alan via wsjt-devel
I agree that a continuous carrier ability is useful for testing, and also 
agree that a timeout would be a good idea in case of distractions etc - it 
unfortunately happens.


Maybe a small selection of timeout periods in program settings, including 
no timeout, with a default at say 1 minute might be good?


Alan G0TLK, sent from my mobile device
On 6 March 2022 09:31:50 Charles Suckling via wsjt-devel 
 wrote:

Gavin, Tony et al

I personally find it useful to be able to generate a continuous carrier 
with WSJT-X using the Tune button.


73

Charlie DL3WDG

On Sun, 6 Mar 2022 at 10:13, Tony ZL3HAM via wsjt-devel 
 wrote:
A good idea Gavin and I don't think it would be too difficult to do, we're 
keep our fingers crossed.


A very warm day today.

73 Tony



On 6/03/2022 5:29 pm, Gavin ZL3GAV via wsjt-devel wrote:


Not a huge priority, but one of those nice to have please…

With the TUNE button, can this be limited to timeout at 10 seconds maximum 
please?


From experience, we all make silly mistakes, whilst tuning my FT-991A I got 
distracted, with the result, I nuked the radio (since fixed) running on 
full power on TUNE. It is not a pleasant experience the acrid smell of 
burning electronic components!


73

Gavin
ZL3GAV



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Claude Frantz via wsjt-devel



On 3/6/22 10:28, Charles Suckling via wsjt-devel wrote:

Hi Charly & all,


I personally find it useful to be able to generate a continuous carrier
with WSJT-X using the Tune button.


I share this opinion, it's an important feature because many XCVR's do 
not offer this function in a simple manner.


Best wishes,
Claude (DJ0OT)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Charles Suckling via wsjt-devel
Gavin, Tony et al

I personally find it useful to be able to generate a continuous carrier
with WSJT-X using the Tune button.

73

Charlie DL3WDG

On Sun, 6 Mar 2022 at 10:13, Tony ZL3HAM via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> A good idea Gavin and I don't think it would be too difficult to do, we're
> keep our fingers crossed.
>
> A very warm day today.
>
> 73 Tony
>
>
> On 6/03/2022 5:29 pm, Gavin ZL3GAV via wsjt-devel wrote:
>
>
>
> Not a huge priority, but one of those nice to have please…
>
>
>
> With the TUNE button, can this be limited to timeout at 10 seconds maximum
> please?
>
>
>
> From experience, we all make silly mistakes, whilst tuning my FT-991A I
> got distracted, with the result, I nuked the radio *(since fixed)*
> running on full power on TUNE. It is not a pleasant experience the acrid
> smell of burning electronic components!
>
>
>
> 73
>
>
>
> Gavin
>
> ZL3GAV
>
>
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] SUGGESTION

2022-03-06 Thread Tony ZL3HAM via wsjt-devel
A good idea Gavin and I don't think it would be too difficult to do, 
we're keep our fingers crossed.


A very warm day today.

73 Tony


On 6/03/2022 5:29 pm, Gavin ZL3GAV via wsjt-devel wrote:


Not a huge priority, but one of those nice to have please…

With the TUNE button, can this be limited to timeout at 10 seconds 
maximum please?


From experience, we all make silly mistakes, whilst tuning my FT-991A 
I got distracted, with the result, I nuked the radio /(since fixed)/ 
running on full power on TUNE. It is not a pleasant experience the 
acrid smell of burning electronic components!


73

Gavin

ZL3GAV



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] SUGGESTION

2022-03-05 Thread Gavin ZL3GAV via wsjt-devel
 

Not a huge priority, but one of those nice to have please…

 

With the TUNE button, can this be limited to timeout at 10 seconds maximum 
please?

 

>From experience, we all make silly mistakes, whilst tuning my FT-991A I got 
>distracted, with the result, I nuked the radio (since fixed) running on full 
>power on TUNE. It is not a pleasant experience the acrid smell of burning 
>electronic components!

 

73

 

Gavin

ZL3GAV

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] SUGGESTION

2022-03-05 Thread Gavin ZL3GAV via wsjt-devel
Hello

 

Not a huge priority, but one of those nice to have please.

 

With the TUNE button, can this be limited to timeout at 10 seconds maximum
please?

 

>From experience, we all make silly mistakes, whilst tuning my FT-991A I got
distracted, with the result, I nuked the radio (since fixed) running on full
power on TUNE. It is not a pleasant experience the acrid smell of burning
electronic components!

 

73

 

Gavin

ZL3GAV

 

 

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Q65 Astronomical Data table

2021-10-19 Thread Joe Taylor via wsjt-devel

Hi Lance,

On 10/17/2021 12:05 AM, Lance Collister, W7GJ via wsjt-devel wrote:
As I am currently on an EME DXpedition without any access to internet or 
a reliable GPS puck that runs on Windows 10, it occurred to me that it 
should be very easy to add a very helpful item to the Astronomical Data 
table. If the correct DT were shown, I could make computer clock 
adjustments using W9MDB's TimeFudge ;-)  MNI TNX for your kind 
consideration!!  VY 73, Lance


I don't understand what you think could be usefully placed on the 
Astronomical Data window.


As OH3MA has suggested, if you have no other access to accurate time 
your best solution may be to receive FT8 signals on 14.074 for a few 
minutes.  Use "TimeFudge" to adjust the O/S clock so that the DT for 
most FT8 signals is close to 0.1 s.


If you have email access while in FO, pleasecontact me off list!

-- 73, Joe, K1JT


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Q65 Astronomical Data table

2021-10-19 Thread Lance Collister, W7GJ via wsjt-devel


On 10/19/2021 09:10, Reino Talarmo via wsjt-devel wrote:


Its there already, labelled as Delay.

Hi Charlie,

You may talk about totally different issue. User Guide states: delay 
of your own EME echoes in seconds


The problem is accurate time. A correct DT is only possible, when a 
time reference is available in some form. One less accurate method is 
to listen some active FT8 frequency and note DT values of the received 
message. Some average or mean value could be close to actual time 
inaccuracy.


73, Reino OH3mA



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR, 
5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ, 
FO/W7GJ, TX7MB)
P.O. Box 73
Frenchtown, MT   59834-0073
USA
TEL: (406) 626-5728
QTH: DN27ub
URL:http://www.bigskyspaces.com/w7gj
Skype: lanceW7GJ
2m DXCC #11/6m DXCC #815

Interested in 6m EME?  Ask me about subscribing to the Magic Band EME
email group, or just fill in the request box at the bottom of my web
page (above)!
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Q65 Astronomical Data table

2021-10-19 Thread Lance Collister, W7GJ via wsjt-devel

MNI TNX!

On 10/19/2021 09:10, Reino Talarmo via wsjt-devel wrote:


Its there already, labelled as Delay.

Hi Charlie,

You may talk about totally different issue. User Guide states: delay 
of your own EME echoes in seconds


The problem is accurate time. A correct DT is only possible, when a 
time reference is available in some form. One less accurate method is 
to listen some active FT8 frequency and note DT values of the received 
message. Some average or mean value could be close to actual time 
inaccuracy.


73, Reino OH3mA



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR, 
5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ, 
FO/W7GJ, TX7MB)
P.O. Box 73
Frenchtown, MT   59834-0073
USA
TEL: (406) 626-5728
QTH: DN27ub
URL:http://www.bigskyspaces.com/w7gj
Skype: lanceW7GJ
2m DXCC #11/6m DXCC #815

Interested in 6m EME?  Ask me about subscribing to the Magic Band EME
email group, or just fill in the request box at the bottom of my web
page (above)!
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Q65 Astronomical Data table

2021-10-19 Thread Reino Talarmo via wsjt-devel
Its there already, labelled as Delay.

  

Hi Charlie,

You may talk about totally different issue. User Guide states: delay of your 
own EME echoes in seconds

The problem is accurate time. A correct DT is only possible, when a time 
reference is available in some form. One less accurate method is to listen some 
active FT8 frequency and note DT values of the received message. Some average 
or mean value could be close to actual time inaccuracy.

73, Reino OH3mA

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Q65 Astronomical Data table

2021-10-18 Thread Charles Suckling via wsjt-devel
Hi Lance

Its there already, labelled as Delay.

73

Charlie DL3WDG

On Tue, 19 Oct 2021 at 00:30, Lance Collister, W7GJ via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> As I am currently on an EME DXpedition without any access to internet or
> a reliable GPS puck that runs on Windows 10, it occurred to me that it
> should be very easy to add a very helpful item to the Astronomical Data
> table. If the correct DT were shown, I could make computer clock
> adjustments using W9MDB's TimeFudge ;-)  MNI TNX for your kind
> consideration!!  VY 73, Lance
>
> --
> Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX,
> 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ,
> S79GJ, FO/W7GJ, TX7MB)
> P.O. Box 73
> Frenchtown, MT   59834-0073
> USA
> TEL: (406) 626-5728
> QTH: DN27ub
> URL: http://www.bigskyspaces.com/w7gj
> Skype: lanceW7GJ
> 2m DXCC #11/6m DXCC #815
>
> Interested in 6m EME?  Ask me about subscribing to the Magic Band EME
> email group, or just fill in the request box at the bottom of my web
> page (above)!
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Suggestion for Q65 Astronomical Data table

2021-10-18 Thread Lance Collister, W7GJ via wsjt-devel
As I am currently on an EME DXpedition without any access to internet or 
a reliable GPS puck that runs on Windows 10, it occurred to me that it 
should be very easy to add a very helpful item to the Astronomical Data 
table. If the correct DT were shown, I could make computer clock 
adjustments using W9MDB's TimeFudge ;-)  MNI TNX for your kind 
consideration!!  VY 73, Lance


--
Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR, 
5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ, 
FO/W7GJ, TX7MB)
P.O. Box 73
Frenchtown, MT   59834-0073
USA
TEL: (406) 626-5728
QTH: DN27ub
URL: http://www.bigskyspaces.com/w7gj
Skype: lanceW7GJ
2m DXCC #11/6m DXCC #815

Interested in 6m EME?  Ask me about subscribing to the Magic Band EME
email group, or just fill in the request box at the bottom of my web
page (above)!



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion re OpenSSL

2020-05-17 Thread Bill Somerville

Steve,

that's not possible, the OpenSSL libraries are controlled by US state 
and federal export restrictions on strong cryptography. The end user 
must obtain them themselves and take note if the restrictions apply to 
them. We do not, nor wish to, restrict the ability of international 
Amateur Radio operators everywhere from installing WSJT-X.


73
Bill
G4WJS.

On 17/05/2020 22:34, Stephen VK3SIR wrote:

Hi Gents,

As a suggestion is it possible to direct the installer scripts on a Windows 
build to auto-deploy the Appropriate Win32 or Win64 OpenSSL Lite package?

Should the SDK's and package requirements be looked at with regards to 
providing access to these libraries available for the future?

I can only foresee utility for this package set increasing in the future.

Thanks and 73.

Steve I
VK3VM / VK3SIR



-Original Message-
From: Ari Paananen  
Sent: Monday, 18 May 2020 5:36 AM

To:wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc1 - Waterfall Palette

Hi Jim,

I've noticed the same thing and it happens when the focus is in the WSJT-X 
waterfall window and you press enter twice while thinking the focus is in some 
other window.


73 de Ari OH2ECG


On 17.5.2020 22:14, Jim Brown wrote:

I use the ZL1FZ palette. Running FT8, the setting occasionally changes
to User Defined with no "trigger" that I've been able to identify as
the cause. I know it's happened because the traces change to white
from the multi-color ZL1FZ palette. This has happened several times in
the 6 days I've been running the beta.

73, Jim K9YC



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Suggestion re OpenSSL

2020-05-17 Thread Stephen VK3SIR
Hi Gents,

As a suggestion is it possible to direct the installer scripts on a Windows 
build to auto-deploy the Appropriate Win32 or Win64 OpenSSL Lite package?

Should the SDK's and package requirements be looked at with regards to 
providing access to these libraries available for the future?

I can only foresee utility for this package set increasing in the future.

Thanks and 73.

Steve I
VK3VM / VK3SIR



-Original Message-
From: Ari Paananen  
Sent: Monday, 18 May 2020 5:36 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc1 - Waterfall Palette

Hi Jim,

I've noticed the same thing and it happens when the focus is in the WSJT-X 
waterfall window and you press enter twice while thinking the focus is in some 
other window.


73 de Ari OH2ECG


On 17.5.2020 22:14, Jim Brown wrote:
> I use the ZL1FZ palette. Running FT8, the setting occasionally changes 
> to User Defined with no "trigger" that I've been able to identify as 
> the cause. I know it's happened because the traces change to white 
> from the multi-color ZL1FZ palette. This has happened several times in 
> the 6 days I've been running the beta.
> 
> 73, Jim K9YC
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion: Have Rx following Tx on CQ option?

2020-05-12 Thread Stephen Ireland
Ps: I meant "previous contact" not "precious contact" ! Typnoing is bbbaaaddd 
and too much coffee this morning here !

-Original Message-
From: Stephen Ireland  
Sent: Wednesday, 13 May 2020 11:00 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] Suggestion: Have Rx following Tx on CQ option?

Bill,

No ! I have not assumed that and that is not what this report focusses on. 

What I am suggesting is that if a QSO has finished, and you are presented with 
the "Confirm QSO" box, press it, and then start calling CQ again that TX and Rx 
frequencies separated - left in the previous form that they were in for the 
PREVIOUS  contact. This may be necessary to receive a "73" from a 
station that has just been logged ... accepted. More thought on this is 
required.

Also if one has to abort an attempt the Tx and Rx "frames" (that indicate 
processing "sweet spots") are equally left in the original positions.

What I am suggesting is that once a 73 has been received OR if you have aborted 
communication attempts manually by changing to Tx6, and If Hold Tx Freq is 
checked, that there should be an option that can be globally switched on or off 
that if on resynchronises the Tx and RX markers (and "sweet spots) to each 
other (i.e. calls the "Set Tx Frequence to Tx Frequency". Many ops do not work 
as I do (i.e. stay omn the same Tx frequency and wander to another station that 
you are contacting's frequency); Instead they do not check "Hold Tx Freq" and 
move to the "back side" (alternate time interval) of your Tx offset to 
communicate.

Just this very second I have had an instance where I am transmitting on 20m 
offset 700 Hz station VK8JG (on offset 1507) has called me 3 times (i.e. VK3VM 
VK8JG PM57) . I have responded to each "Tx1 sequence call" with R11 (i.e. VK8JG 
VK3VM -11) but the station has been unable to resolve my attempts at returning 
their call. 

Therefore I have had to manually abort by clicking the TX6 button... The Rx 
marker remains at 1507 Hz. 

There are good utilitarian reasons sometimes for this behaviour to be valid. 
Yet the most common behaviour should be that the Rx marker should move back to 
the Tx marker at 700 Hz. I am suggesting that a configuration switch to enable 
this to occur should be available.

I have another issue (an OLD issue) that has also arisen that a fork has dealt 
with. Later on that as I am awaiting a phone call !!!

73, and Great work Bill. This is very slick !

Steve I
VK3VM / VK3SIR

Ps: I am on 20m now ( 0056z 13th May 2020 )




What I am suggesting is that o

-Original Message-
From: Bill Somerville  
Sent: Wednesday, 13 May 2020 8:39 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Suggestion: Have Rx following Tx on CQ option?

On 12/05/2020 23:24, Stephen Ireland wrote:
> Folks,
>
> One minor suggestion for future RC candidates... I have been calling a 
> station XQ1KN that cannot see me ... so I have aborted attempts and clicked 
> on Tx6 to return to calling CQ.
>
> I have Hold Tx Frequency set ... but the Rx has not returned with me to the 
> frequency that I am calling on.
>
> I can appreciate that this behaviour is in play just in case that last 
> station did respond. Yet typical behaviour, I believe, should be for the "RX 
> Marker" to move back synchronised under these circumstances to be 
> synchronised to the Tx frequency (where it originally was).
>
> Perhaps a switch under "Behaviour" to have "Rx Frequency Following Tx on CQ" 
> may be in order (and I think that that will fit on the File / Settings / 
> General tab) ?
>
> 73, and as I reiterate this is GREAT work !
>
> Steve I
> VK3VM / VK3SIR

Steve,

you seem to be assuming that replies to your general calls will be at your Tx 
frequency, with normal FT8/FT4 operating practice that is unlikely because most 
operators will wisely have their "Hold Tx Frequency" options checked.

73
bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion: Have Rx following Tx on CQ option?

2020-05-12 Thread Stephen Ireland
Bill,

No ! I have not assumed that and that is not what this report focusses on. 

What I am suggesting is that if a QSO has finished, and you are presented with 
the "Confirm QSO" box, press it, and then start calling CQ again that TX and Rx 
frequencies separated - left in the previous form that they were in for the 
precious contact. This may be necessary to receive a "73" from a station that 
has just been logged ... accepted. More thought on this is required.

Also if one has to abort an attempt the Tx and Rx "frames" (that indicate 
processing "sweet spots") are equally left in the original positions.

What I am suggesting is that once a 73 has been received OR if you have aborted 
communication attempts manually by changing to Tx6, and If Hold Tx Freq is 
checked, that there should be an option that can be globally switched on or off 
that if on resynchronises the Tx and RX markers (and "sweet spots) to each 
other (i.e. calls the "Set Tx Frequence to Tx Frequency". Many ops do not work 
as I do (i.e. stay omn the same Tx frequency and wander to another station that 
you are contacting's frequency); Instead they do not check "Hold Tx Freq" and 
move to the "back side" (alternate time interval) of your Tx offset to 
communicate.

Just this very second I have had an instance where I am transmitting on 20m 
offset 700 Hz station VK8JG (on offset 1507) has called me 3 times (i.e. VK3VM 
VK8JG PM57) . I have responded to each "Tx1 sequence call" with R11 (i.e. VK8JG 
VK3VM -11) but the station has been unable to resolve my attempts at returning 
their call. 

Therefore I have had to manually abort by clicking the TX6 button... The Rx 
marker remains at 1507 Hz. 

There are good utilitarian reasons sometimes for this behaviour to be valid. 
Yet the most common behaviour should be that the Rx marker should move back to 
the Tx marker at 700 Hz. I am suggesting that a configuration switch to enable 
this to occur should be available.

I have another issue (an OLD issue) that has also arisen that a fork has dealt 
with. Later on that as I am awaiting a phone call !!!

73, and Great work Bill. This is very slick !

Steve I
VK3VM / VK3SIR

Ps: I am on 20m now ( 0056z 13th May 2020 )




What I am suggesting is that o

-Original Message-
From: Bill Somerville  
Sent: Wednesday, 13 May 2020 8:39 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Suggestion: Have Rx following Tx on CQ option?

On 12/05/2020 23:24, Stephen Ireland wrote:
> Folks,
>
> One minor suggestion for future RC candidates... I have been calling a 
> station XQ1KN that cannot see me ... so I have aborted attempts and clicked 
> on Tx6 to return to calling CQ.
>
> I have Hold Tx Frequency set ... but the Rx has not returned with me to the 
> frequency that I am calling on.
>
> I can appreciate that this behaviour is in play just in case that last 
> station did respond. Yet typical behaviour, I believe, should be for the "RX 
> Marker" to move back synchronised under these circumstances to be 
> synchronised to the Tx frequency (where it originally was).
>
> Perhaps a switch under "Behaviour" to have "Rx Frequency Following Tx on CQ" 
> may be in order (and I think that that will fit on the File / Settings / 
> General tab) ?
>
> 73, and as I reiterate this is GREAT work !
>
> Steve I
> VK3VM / VK3SIR

Steve,

you seem to be assuming that replies to your general calls will be at your Tx 
frequency, with normal FT8/FT4 operating practice that is unlikely because most 
operators will wisely have their "Hold Tx Frequency" options checked.

73
bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion: Have Rx following Tx on CQ option?

2020-05-12 Thread Neil Zampella

Um ... all I do is click on the DOWN ARROW next to the Tx location which
sets the Rx to the same location.  One click.

Neil, KN3ILZ

On 5/12/2020 6:24 PM, Stephen Ireland wrote:

Folks,

One minor suggestion for future RC candidates... I have been calling a station 
XQ1KN that cannot see me ... so I have aborted attempts and clicked on Tx6 to 
return to calling CQ.

I have Hold Tx Frequency set ... but the Rx has not returned with me to the 
frequency that I am calling on.

I can appreciate that this behaviour is in play just in case that last station did 
respond. Yet typical behaviour, I believe, should be for the "RX Marker" to 
move back synchronised under these circumstances to be synchronised to the Tx frequency 
(where it originally was).

Perhaps a switch under "Behaviour" to have "Rx Frequency Following Tx on CQ" 
may be in order (and I think that that will fit on the File / Settings / General tab) ?

73, and as I reiterate this is GREAT work !

Steve I
VK3VM / VK3SIR





--
This email has been checked for viruses by AVG.
https://www.avg.com



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion: Have Rx following Tx on CQ option?

2020-05-12 Thread Bill Somerville

On 12/05/2020 23:24, Stephen Ireland wrote:

Folks,

One minor suggestion for future RC candidates... I have been calling a station 
XQ1KN that cannot see me ... so I have aborted attempts and clicked on Tx6 to 
return to calling CQ.

I have Hold Tx Frequency set ... but the Rx has not returned with me to the 
frequency that I am calling on.

I can appreciate that this behaviour is in play just in case that last station did 
respond. Yet typical behaviour, I believe, should be for the "RX Marker" to 
move back synchronised under these circumstances to be synchronised to the Tx frequency 
(where it originally was).

Perhaps a switch under "Behaviour" to have "Rx Frequency Following Tx on CQ" 
may be in order (and I think that that will fit on the File / Settings / General tab) ?

73, and as I reiterate this is GREAT work !

Steve I
VK3VM / VK3SIR


Steve,

you seem to be assuming that replies to your general calls will be at 
your Tx frequency, with normal FT8/FT4 operating practice that is 
unlikely because most operators will wisely have their "Hold Tx 
Frequency" options checked.


73
bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Suggestion: Have Rx following Tx on CQ option?

2020-05-12 Thread Stephen Ireland
Folks,

One minor suggestion for future RC candidates... I have been calling a station 
XQ1KN that cannot see me ... so I have aborted attempts and clicked on Tx6 to 
return to calling CQ.

I have Hold Tx Frequency set ... but the Rx has not returned with me to the 
frequency that I am calling on.

I can appreciate that this behaviour is in play just in case that last station 
did respond. Yet typical behaviour, I believe, should be for the "RX Marker" to 
move back synchronised under these circumstances to be synchronised to the Tx 
frequency (where it originally was).

Perhaps a switch under "Behaviour" to have "Rx Frequency Following Tx on CQ" 
may be in order (and I think that that will fit on the File / Settings / 
General tab) ?

73, and as I reiterate this is GREAT work !

Steve I
VK3VM / VK3SIR



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion: CW ID callsign

2019-10-21 Thread David Gilbert


Agree on all.  When running in a contest I never go more than three 
contacts without giving my call, but usually go at least two unless 
conditions are dicey and I don't want anyone on the other end to have to 
wait through a couple of contacts before deciding whether they want to 
work me or not.  I don't presume that they are using a spotting cluster.


When just chatting I always try to adhere to the ten minute rule, but I 
can't remember the last time I ever heard about the FCC citing anyone 
for going longer.


73,
Dave   AB7E



On 10/21/2019 1:21 AM, Jim Brown wrote:

On 10/20/2019 2:44 PM, David Gilbert wrote:
As best I know, you don't need to ID every contact, and I suspect you 
wouldn't even if moving around within a bandwidth as narrow as is 
typical for FT8.


Far too much attention to identification is paid by those who don't 
operate much, and/or aren't very good operators. In a typical contest 
or DX QSO, one operator IDs when he calls CQ (or finishes a QSO), and 
the caller calls by dropping his callsign (thus, an ID). The CQer IDs 
with TU callsign or TU and someone else calls his/her. Whether TU or 
TU callsign is up to the judgement of the CQing op, which is 
appropriate boils down to making a lot of QSOs  in a short time, 
holding a frequency, and being courteous to potential callers. The FCC 
minimum is an ID in 10 minutes of a series of transmssions. Courtesy 
of a running station in a contest DEMANDS every 2-3 QSOs.


Too many IDs is slows down communications, and is a real PITA. In a 
contest or DX QSO, re-sending your call when the running (DX) station 
has it right is a LIDISM. When someone calls me in a contest or as a 
DXpedition, all I want is their call, and I never want to hear it (or 
mine) unless I've gotten their call WRONG. I know who they are both 
from timing and their CW note.


73, Jim K9YC




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel





___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion: CW ID callsign

2019-10-21 Thread Jim Brown

On 10/20/2019 2:44 PM, David Gilbert wrote:
As best I know, you don't need to ID every contact, and I suspect you 
wouldn't even if moving around within a bandwidth as narrow as is 
typical for FT8.


Far too much attention to identification is paid by those who don't 
operate much, and/or aren't very good operators. In a typical contest or 
DX QSO, one operator IDs when he calls CQ (or finishes a QSO), and the 
caller calls by dropping his callsign (thus, an ID). The CQer IDs with 
TU callsign or TU and someone else calls his/her. Whether TU or TU 
callsign is up to the judgement of the CQing op, which is appropriate 
boils down to making a lot of QSOs  in a short time, holding a 
frequency, and being courteous to potential callers. The FCC minimum is 
an ID in 10 minutes of a series of transmssions. Courtesy of a running 
station in a contest DEMANDS every 2-3 QSOs.


Too many IDs is slows down communications, and is a real PITA. In a 
contest or DX QSO, re-sending your call when the running (DX) station 
has it right is a LIDISM. When someone calls me in a contest or as a 
DXpedition, all I want is their call, and I never want to hear it (or 
mine) unless I've gotten their call WRONG. I know who they are both from 
timing and their CW note.


73, Jim K9YC




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion: CW ID callsign

2019-10-21 Thread David A. Behar
Hi Dave,

Thanks for the response.

If a call sign is specified in Settings which is not compliant with the
requirements of the 28-bit encoding scheme, my recollection is that with
WSPR the non-compliant callsign will code into some kind of nonsense in the
*digital* message. In any case, a non-compliant callsign will never encode
properly.

I don't clearly recall whether the non-compliant callsign does or does not
transmit properly on CW, but my recollection is that the non-compliant
callsign *did not* transmit properly on CW.

The ideal solution that would work across the various modes that WSJT-X
supports would be to permit an optional *CW ID* callsign that can be
anything reasonable -- e.g., an arbitrary string of up to 16 characters,
where any letter, digit, and the fraction-bar character would be permitted.
When a station has been legally assigned a non-compliant callsign the
operator could choose something reasonable and compliant for the callsign
to be encoded, and then the operator could separately specify the actual
assigned callsign for the CW ID.

For example, Denmark has issued a special callsign series 5P0WARD/x, where
apparently the x is a one- or two-digit suffix. An actual station spotted
is 5P0WARD/7. "5P0WARD" can't be encoded in the 28-bit encoding scheme used
by WSPR (not as a standard Type 1 message, but also not as the Type 2 or
Type 3 variants).

So in this situation the operator might choose to use a "Type 2" message --
e.g., "5P0WAR/7" --  or even a "Type 1" message -- e.g., "Q07WAR" (as the
ITU regulations don't use a Q callsign for any country), but then in CW
transmit the actual assigned legal callsign of "5P0WARD/7".

It seems to me that callsigns that don't comply with the WSJT-X model are
becoming more common, so it would be nice if any station -- regardless of
the particular station ID requirements of the competent jurisdiction -- can
always legally ID the station in Morse CW.

David / K7DB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion: CW ID callsign

2019-10-20 Thread David Gilbert


Yes, that's what is says, and the FCC has continually interpreted 
"communication" very broadly.  Broadly enough that in the past they have 
several times informally said that they weren't going to require it 
every contact.


Thousands of contesters have for decades made several contacts between 
identifications and the FCC doesn't care in the least.


Dave   AB7E


On 10/20/2019 3:06 PM, David Beauchesne wrote:


You do need to ID with every contact.  See Part 97.119 (a) “Each 
amateur station, except a space station or telecommand station, must 
transmit its assigned call sign on its transmitting channel at the end 
of each communication…”


AK2L

*From:*David Gilbert 
*Sent:* Sunday, October 20, 2019 14:44
*To:* wsjt-devel@lists.sourceforge.net
*Subject:* Re: [wsjt-devel] Suggestion: CW ID callsign


As best I know, you don't need to ID every contact, and I suspect you 
wouldn't even if moving around within a bandwidth as narrow as is 
typical for FT8.  So why not simply use the freeform 13-character TX5 
message to periodically ID?  I've played around with it a bit and it 
will even accept a few non-alphanumeric symbols like -, ?, and +.  It 
certainly will accept four character suffixes ... even four characters 
after a "/".  It shouldn't even matter whether any other amateur 
station realizes that it was you who sent it.


I've seen several FT8 stations with long callsigns using TX5 to 
periodically identify their grid when it won't fit within the normal 
message exchange.


What don't I understand?

73,
Dave   AB7E

On 10/20/2019 12:48 PM, David A. Behar wrote:

Hi friends, I am writing to share an idea...

WSJT callsign encoding generally accommodates most amateur radio
callsigns, but some callsigns -- e.g., some special-event
callsigns, and callsigns which might use a _four character
suffix_ as provided at ITU RR19-7 §30
<http://life.itu.int/radioclub/rr/art19.pdf#page=7> -- can't be
accommodated by the coding scheme. There has been plenty of
previous discussion about that, and I think no more is necessary.

WSPR-X provides for the user's specification of a single callsign;
that callsign is used for encoding into messages, and also for use
in optional CW Morse identification.

I think it would be nice if a user could optionally specify a
free-form CW identification callsign which is not subject to the
restrictions of the callsign encoding scheme. This would enable
stations to comply with regulatory station identification
requirements in cases of callsigns which are not accommodated by
the callsign coding scheme.

David/ K7DB



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion: CW ID callsign

2019-10-20 Thread David Gilbert


Ahh ... OK.

Well, I don't normally use WSPR but I just switched to it and it let me 
enter a rather length string of gibberish for a callsign.  And at the 
bottom right of the Settings - General page it lets me set an interval 
for a periodic CW ID ... which I assume would be the same gibberish 
callsign I entered as a test.  If so, would that not do the job for you?


Or is there some other constraint in WSPR that doesn't allow that? As I 
said, I'm not really very well versed in it.


73,
Dave   AB7E



On 10/20/2019 3:07 PM, David A. Behar wrote:
Hi Dave, the specific actual situation I have encountered involves 
using WSJT-X for WSPR (not FT8).


Your thoughts?

David / K7DB

On Sun, Oct 20, 2019, 2:50 PM David Gilbert > wrote:



As best I know, you don't need to ID every contact, and I suspect
you wouldn't even if moving around within a bandwidth as narrow as
is typical for FT8.  So why not simply use the freeform
13-character TX5 message to periodically ID?  I've played around
with it a bit and it will even accept a few non-alphanumeric
symbols like -, ?, and +.  It certainly will accept four character
suffixes ... even four characters after a "/".  It shouldn't even
matter whether any other amateur station realizes that it was you
who sent it.

I've seen several FT8 stations with long callsigns using TX5 to
periodically identify their grid when it won't fit within the
normal message exchange.

What don't I understand?

73,
Dave   AB7E


On 10/20/2019 12:48 PM, David A. Behar wrote:

Hi friends, I am writing to share an idea...

WSJT callsign encoding generally accommodates most amateur radio
callsigns, but some callsigns -- e.g., some special-event
callsigns, and callsigns which might use a _four character
suffix_ as provided at ITU RR19-7 §30
 -- can't be
accommodated by the coding scheme. There has been plenty of
previous discussion about that, and I think no more is necessary.

WSPR-X provides for the user's specification of a single
callsign; that callsign is used for encoding into messages, and
also for use in optional CW Morse identification.

I think it would be nice if a user could optionally specify a
free-form CW identification callsign which is not subject to the
restrictions of the callsign encoding scheme. This would enable
stations to comply with regulatory station identification
requirements in cases of callsigns which are not accommodated by
the callsign coding scheme.

David/ K7DB


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion: CW ID callsign

2019-10-20 Thread David A. Behar
And I think this would also be an issue for FT8 and other modes in
jurisdictions (not those administered by the United States Federal
Communications Commission) where station identification using the digital
mode is not compliant and CW Morse identification is required.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion: CW ID callsign

2019-10-20 Thread David Beauchesne
You do need to ID with every contact.  See Part 97.119 (a) “Each amateur 
station, except a space station or telecommand station, must transmit its 
assigned call sign on its transmitting channel at the end of each 
communication…”

 

AK2L

 

 

From: David Gilbert  
Sent: Sunday, October 20, 2019 14:44
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Suggestion: CW ID callsign

 


As best I know, you don't need to ID every contact, and I suspect you wouldn't 
even if moving around within a bandwidth as narrow as is typical for FT8.  So 
why not simply use the freeform 13-character TX5 message to periodically ID?  
I've played around with it a bit and it will even accept a few non-alphanumeric 
symbols like -, ?, and +.  It certainly will accept four character suffixes ... 
even four characters after a "/".  It shouldn't even matter whether any other 
amateur station realizes that it was you who sent it.

I've seen several FT8 stations with long callsigns using TX5 to periodically 
identify their grid when it won't fit within the normal message exchange.

What don't I understand?

73,
Dave   AB7E



On 10/20/2019 12:48 PM, David A. Behar wrote:

Hi friends, I am writing to share an idea...

 

WSJT callsign encoding generally accommodates most amateur radio callsigns, but 
some callsigns -- e.g., some special-event callsigns, and callsigns which might 
use a four character suffix as provided at ITU RR19-7 
<http://life.itu.int/radioclub/rr/art19.pdf#page=7>  §30 -- can't be 
accommodated by the coding scheme. There has been plenty of previous discussion 
about that, and I think no more is necessary.

 

WSPR-X provides for the user's specification of a single callsign; that 
callsign is used for encoding into messages, and also for use in optional CW 
Morse identification.

 

I think it would be nice if a user could optionally specify a free-form CW 
identification callsign which is not subject to the restrictions of the 
callsign encoding scheme. This would enable stations to comply with regulatory 
station identification requirements in cases of callsigns which are not 
accommodated by the callsign coding scheme.

 

David / K7DB

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion: CW ID callsign

2019-10-20 Thread David A. Behar
Hi Dave, the specific actual situation I have encountered involves using
WSJT-X for WSPR (not FT8).

Your thoughts?

David / K7DB

On Sun, Oct 20, 2019, 2:50 PM David Gilbert 
wrote:

>
> As best I know, you don't need to ID every contact, and I suspect you
> wouldn't even if moving around within a bandwidth as narrow as is typical
> for FT8.  So why not simply use the freeform 13-character TX5 message to
> periodically ID?  I've played around with it a bit and it will even accept
> a few non-alphanumeric symbols like -, ?, and +.  It certainly will accept
> four character suffixes ... even four characters after a "/".  It shouldn't
> even matter whether any other amateur station realizes that it was you who
> sent it.
>
> I've seen several FT8 stations with long callsigns using TX5 to
> periodically identify their grid when it won't fit within the normal
> message exchange.
>
> What don't I understand?
>
> 73,
> Dave   AB7E
>
>
> On 10/20/2019 12:48 PM, David A. Behar wrote:
>
> Hi friends, I am writing to share an idea...
>
> WSJT callsign encoding generally accommodates most amateur radio
> callsigns, but some callsigns -- e.g., some special-event callsigns, and
> callsigns which might use a *four character suffix* as provided at ITU
> RR19-7 §30  -- can't
> be accommodated by the coding scheme. There has been plenty of previous
> discussion about that, and I think no more is necessary.
>
> WSPR-X provides for the user's specification of a single callsign; that
> callsign is used for encoding into messages, and also for use in optional
> CW Morse identification.
>
> I think it would be nice if a user could optionally specify a free-form CW
> identification callsign which is not subject to the restrictions of the
> callsign encoding scheme. This would enable stations to comply with
> regulatory station identification requirements in cases of callsigns which
> are not accommodated by the callsign coding scheme.
>
> David / K7DB
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion: CW ID callsign

2019-10-20 Thread David Gilbert


As best I know, you don't need to ID every contact, and I suspect you 
wouldn't even if moving around within a bandwidth as narrow as is 
typical for FT8.  So why not simply use the freeform 13-character TX5 
message to periodically ID?  I've played around with it a bit and it 
will even accept a few non-alphanumeric symbols like -, ?, and +.  It 
certainly will accept four character suffixes ... even four characters 
after a "/".  It shouldn't even matter whether any other amateur station 
realizes that it was you who sent it.


I've seen several FT8 stations with long callsigns using TX5 to 
periodically identify their grid when it won't fit within the normal 
message exchange.


What don't I understand?

73,
Dave   AB7E


On 10/20/2019 12:48 PM, David A. Behar wrote:

Hi friends, I am writing to share an idea...

WSJT callsign encoding generally accommodates most amateur radio 
callsigns, but some callsigns -- e.g., some special-event callsigns, 
and callsigns which might use a _four character suffix_ as provided at 
ITU RR19-7 §30  -- 
can't be accommodated by the coding scheme. There has been plenty of 
previous discussion about that, and I think no more is necessary.


WSPR-X provides for the user's specification of a single callsign; 
that callsign is used for encoding into messages, and also for use in 
optional CW Morse identification.


I think it would be nice if a user could optionally specify a 
free-form CW identification callsign which is not subject to the 
restrictions of the callsign encoding scheme. This would enable 
stations to comply with regulatory station identification requirements 
in cases of callsigns which are not accommodated by the callsign 
coding scheme.


David/ K7DB


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Suggestion: CW ID callsign

2019-10-20 Thread David A. Behar
Hi friends, I am writing to share an idea...

WSJT callsign encoding generally accommodates most amateur radio callsigns,
but some callsigns -- e.g., some special-event callsigns, and callsigns
which might use a *four character suffix* as provided at ITU RR19-7 §30
 -- can't be
accommodated by the coding scheme. There has been plenty of previous
discussion about that, and I think no more is necessary.

WSPR-X provides for the user's specification of a single callsign; that
callsign is used for encoding into messages, and also for use in optional
CW Morse identification.

I think it would be nice if a user could optionally specify a free-form CW
identification callsign which is not subject to the restrictions of the
callsign encoding scheme. This would enable stations to comply with
regulatory station identification requirements in cases of callsigns which
are not accommodated by the callsign coding scheme.

David / K7DB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion

2019-08-12 Thread Sergio Yes UT9LI
Hi! Yes, I agree with the usefulness of combining a switch for the FT4 / FT8. I 
find in this addition the usefulness of the function! Unfortunately, there may 
be an inconvenience in synchronization: the RX FT8 may be different from the RX 
FT4 (i it had such an RX-SWL). This fact should be noted in Help to FT4 / FT8.
My 73! TNX!

9 августа 2019, 09:53:19, от "F6BHK" < f6...@f6bhk.org >:

Hi Joe,

Thank you for your answer.

Cheers

Serge


On 09/08/2019 00:36, Joe Taylor wrote:
> Hi Serge,
>
> On 8/8/2019 17:31, Serge F6BHK wrote:
>> at the dawn of WSJT-X we had the choice to decode JT65+JT9 under the 
>> same combo value. I remember I found it very useful. When I 
>> double-clicked a JT65 signal then I was sending using JT65, same for 
>> JT9.
>>
>> would'nt it be nice to have a FT8+FT4 combo value that decode both of 
>> the protocols and set the Xmit side of WSJT-X accordingly?
>
> Because their T/R sequence lengths are different, FT4 and FT8 are not 
> amenable to the convenient dual-mode decoding scheme that was useful 
> for JT65 and JT9.
>
> -- 73, Joe, K1JT
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

-- 

73, de Serge
F6BHK, ex-VR2LL, G5BHT, FM5GC
DEYRAS, JN24IX, ARDECHE



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Good Luck! Best DX's! 73!
de Sergio fm Kharkov BYE-Poka!
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion

2019-08-09 Thread F6BHK

Hi Joe,

Thank you for your answer.

Cheers

Serge


On 09/08/2019 00:36, Joe Taylor wrote:

Hi Serge,

On 8/8/2019 17:31, Serge F6BHK wrote:
at the dawn of WSJT-X we had the choice to decode JT65+JT9 under the 
same combo value. I remember I found it very useful. When I 
double-clicked a JT65 signal then I was sending using JT65, same for 
JT9.


would'nt it be nice to have a FT8+FT4 combo value that decode both of 
the protocols and set the Xmit side of WSJT-X accordingly?


Because their T/R sequence lengths are different, FT4 and FT8 are not 
amenable to the convenient dual-mode decoding scheme that was useful 
for JT65 and JT9.


-- 73, Joe, K1JT


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--

73, de Serge
F6BHK, ex-VR2LL, G5BHT, FM5GC
DEYRAS, JN24IX, ARDECHE



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion

2019-08-08 Thread Joe Taylor

Hi Serge,

On 8/8/2019 17:31, Serge F6BHK wrote:
at the dawn of WSJT-X we had the choice to decode JT65+JT9 under the 
same combo value. I remember I found it very useful. When I 
double-clicked a JT65 signal then I was sending using JT65, same for JT9.


would'nt it be nice to have a FT8+FT4 combo value that decode both of 
the protocols and set the Xmit side of WSJT-X accordingly?


Because their T/R sequence lengths are different, FT4 and FT8 are not 
amenable to the convenient dual-mode decoding scheme that was useful for 
JT65 and JT9.


-- 73, Joe, K1JT


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Suggestion

2019-08-08 Thread F6BHK

Hi all!

at the dawn of WSJT-X we had the choice to decode JT65+JT9 under the 
same combo value. I remember I found it very useful. When I 
double-clicked a JT65 signal then I was sending using JT65, same for JT9.


would'nt it be nice to have a FT8+FT4 combo value that decode both of 
the protocols and set the Xmit side of WSJT-X accordingly?


Just a suggestion

Cheers

Serge


--

73, de Serge
F6BHK, ex-VR2LL, G5BHT, FM5GC
DEYRAS, JN24IX, ARDECHE



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] SUGGESTION: Display or not, confirmed QSOs

2019-07-30 Thread Gene Marsh via wsjt-devel
Joe (and the team),

First, the last (new) rev of WSJT-X is WAY FASTER to decode a busy band.  THANK 
YOU!

My suggestion: Because I made thousands of FT8 contacts (especially on 20m, 30m 
and 40m), a huge amount of the CQ decodes on a busy band are GREEN (confirmed 
QSO for call/band/etc). Even if I check CQ Only, I have 2 pages of CQs.  

Can you change (maybe in settings, or a check box on the main screen) to  
filter out decodes for confirmed calls? Only for CQs.  Easy to do - you have 
the logic for parsing.

If I missed it, and the program has this logic, please explain how and reply to 
me with a “DOH!”

;)

73 de W8NET Miles / “Gene”
Secretary, Portage County Amateur Radio Service (PCARS)
3905 Century Club - Master #47
DV2/W8NET in the Philippines
Licensed since 1974___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-26 Thread Martin Davies G0HDB
On 25 Apr 2019 at 14:30, Bill Somerville wrote:

> Frank,
> 
> WSJT-X tries to prevent *Fox* FT8 DXpedition mode stations from 
> operating on the "usual" FT8 frequencies. Clearly we cannot stop use of 
> Fox mode if the DX does not use CAT control. Other programs like MSHV 
> allow a mode similar to Fox mode on normal FT8 frequencies but AFAIK you 
> do not need to select WSJT-X Hound mode to work DX using that 
> application. This causes considerable confusion and when the so-called 
> multi-threaded mode on MSHV is enabled on normal FT8 frequencies it 
> causes QRM to other users by using more bandwidth than other stations, 
> but TBH that's what happens with DXpeditions anyway. WSJT-X Fox & Hound 
> DXpedition mode was designed to facilitate the larger DXpeditions, i.e. 
> in the top 100 most wanted lists and able to operate 24/7 for most of 
> the DXpedition operation. This warrants using a separate pre-published 
> frequency schedule and there using multiple QSOs in parallel is quite 
> acceptable for maximum throughput, thereby allowing as many users as 
> possible to get in the DXpedition log without having to use high gain 
> aerials and high power levels.

Hello Bill, thanks for your email above which has certainly helped me, and 
hopefully others, 
understand a bit better the operating-frequency constraints of FT8's (and 
presumably FT4's) 
Fox & Hound DXpedition mode.

I don't know if others, like me, had gained the impression from various 
postings to this email 
list and on the Yahoo group that the WSJT-X s/ware was intended to prevent any 
station 
operating in *either* Fox *or* Hound mode from transmitting in the standard FT8 
band 
segments, but your email certainly seems to indicate that it's only a Fox 
that's so-constrained; 
if my interpretation is correct then it begs the question of whether Hounds 
should also be 
prevented from Tx'ing in the standard segments.

Perhaps the software could apply a Hound-mode stop-band around each of the 
standard FT8 
frequencies; for example if Hound mode is enabled and the rig is tuned to 
anywhere within 
say 14070 to 14078kHz then transmission would be prevented.  Of course this 
would only 
function if the rig was being CAT-controlled so that the dial frequency was 
known to the 
software; it wouldn't prevent a Hound station not using CAT from Tx'ing in the 
standard 
segments.  The desirability or otherwise of using CAT is open to ongoing 
discussion...  :-)

In your email you mention stations using the MSHV software; I (and I expect 
many others) 
can confirm that it's not necessary to use Hound mode to work such stations - 
the standard 
FT8 mode works just fine in such scenarios.  As you've pointed out, the use of 
the MSHV 
multi-threaded mode in the standard band segments can be (and probably is) a 
cause of 
significant confusion, and no doubt the desirability of such multi-threaded 
operating in the 
standard segments will continue to be a topic for sometimes heated debate...

--
73, Martin G0HDB


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-25 Thread Jim Shorney


Bravo!

73

-Jim
NU0C

On Thu, 25 Apr 2019 18:02:35 -0400
James Shaver  wrote:

> No CAT control with this old rig (picture attached) and it holds its own ;)
> 



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-25 Thread James Shaver
No CAT control with this old rig (picture attached) and it holds its own ;)



> On Apr 25, 2019, at 5:07 PM, Jim Shorney  wrote:
> 
> 
> The point was that CAT is not essential in any case. The notion that CAT is 
> *required* to use FT/JT modes is a myth propagated by those who don't know 
> any better. There are those of us who do not use CAT for whatever reason and 
> we appreciate the ability to operate this way. To successfully to so requires 
> a level of knowledge and skill a bit above the plug-and-play appliance level. 
> Try it sometime. :D
> 
> 73
> 
> -Jim
> NU0C
> 
> 
> On Thu, 25 Apr 2019 09:19:16 -0400
> Frank Kirschner  wrote:
> 
>>> Actually, no it (rig split via CAT) is not at all essential. However,
>>> using the software without CAT control requires actual radio knowledge.
>>> 
>> Actually, it's pretty easy if you have the right equipment. The Flex Radio  
>> 6600 and Maestro combination allow control without the usual CAT
>> functionality. They communicate via TCP ports. There is a CAT program
>> provided, but I don't even run it when using the Maestro to control the rig.
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-25 Thread Jim Shorney


The point was that CAT is not essential in any case. The notion that CAT is 
*required* to use FT/JT modes is a myth propagated by those who don't know any 
better. There are those of us who do not use CAT for whatever reason and we 
appreciate the ability to operate this way. To successfully to so requires a 
level of knowledge and skill a bit above the plug-and-play appliance level. Try 
it sometime. :D

73

-Jim
NU0C


On Thu, 25 Apr 2019 09:19:16 -0400
Frank Kirschner  wrote:

> > Actually, no it (rig split via CAT) is not at all essential. However,
> > using the software without CAT control requires actual radio knowledge.
> >
> Actually, it's pretty easy if you have the right equipment. The Flex Radio  
> 6600 and Maestro combination allow control without the usual CAT
> functionality. They communicate via TCP ports. There is a CAT program
> provided, but I don't even run it when using the Maestro to control the rig.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-25 Thread Frank Kirschner
Bill,

Thanks for the info. I'm an old CW op at heart, and even with a PhD in EE,
I sometimes scratch my head trying to figure out why the software works the
way it does.

73,
Frank
KF6E

On Thu, Apr 25, 2019 at 9:54 AM Bill Somerville 
wrote:

> On 25/04/2019 14:15, Frank Kirschner wrote:
> > Someone wrote that the software prevented using Hound mode in the
> > regular band segments. I was just demonstrating that this was not the
> > case. I didn't actually transmit, since I saw no stations in Fox mode.
>
> Frank,
>
> WSJT-X tries to prevent *Fox* FT8 DXpedition mode stations from
> operating on the "usual" FT8 frequencies. Clearly we cannot stop use of
> Fox mode if the DX does not use CAT control. Other programs like MSHV
> allow a mode similar to Fox mode on normal FT8 frequencies but AFAIK you
> do not need to select WSJT-X Hound mode to work DX using that
> application. This causes considerable confusion and when the so-called
> multi-threaded mode on MSHV is enabled on normal FT8 frequencies it
> causes QRM to other users by using more bandwidth than other stations,
> but TBH that's what happens with DXpeditions anyway. WSJT-X Fox & Hound
> DXpedition mode was designed to facilitate the larger DXpeditions, i.e.
> in the top 100 most wanted lists and able to operate 24/7 for most of
> the DXpedition operation. This warrants using a separate pre-published
> frequency schedule and there using multiple QSOs in parallel is quite
> acceptable for maximum throughput, thereby allowing as many users as
> possible to get in the DXpedition log without having to use high gain
> aerials and high power levels.
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-25 Thread Bill Somerville

On 25/04/2019 14:15, Frank Kirschner wrote:
Someone wrote that the software prevented using Hound mode in the 
regular band segments. I was just demonstrating that this was not the 
case. I didn't actually transmit, since I saw no stations in Fox mode. 


Frank,

WSJT-X tries to prevent *Fox* FT8 DXpedition mode stations from 
operating on the "usual" FT8 frequencies. Clearly we cannot stop use of 
Fox mode if the DX does not use CAT control. Other programs like MSHV 
allow a mode similar to Fox mode on normal FT8 frequencies but AFAIK you 
do not need to select WSJT-X Hound mode to work DX using that 
application. This causes considerable confusion and when the so-called 
multi-threaded mode on MSHV is enabled on normal FT8 frequencies it 
causes QRM to other users by using more bandwidth than other stations, 
but TBH that's what happens with DXpeditions anyway. WSJT-X Fox & Hound 
DXpedition mode was designed to facilitate the larger DXpeditions, i.e. 
in the top 100 most wanted lists and able to operate 24/7 for most of 
the DXpedition operation. This warrants using a separate pre-published 
frequency schedule and there using multiple QSOs in parallel is quite 
acceptable for maximum throughput, thereby allowing as many users as 
possible to get in the DXpedition log without having to use high gain 
aerials and high power levels.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-25 Thread Frank Kirschner
On Tue, Apr 23, 2019 at 10:49 PM Jim Shorney  wrote:

> On Tue, 23 Apr 2019 14:11:19 +0100
> "Martin Davies G0HDB"  wrote:
>
> > The use of Split is all-but essential for slick operation in Hound mode,
> which is presumably
> > why the software complained if you changed to a Hound configuration
> without one or other of
> > the Split options being selected.
>
> Actually, no it (rig split via CAT) is not at all essential. However,
> using the software without CAT control requires actual radio knowledge.
>
> Actually, it's pretty easy if you have the right equipment. The Flex Radio
6600 and Maestro combination allow control without the usual CAT
functionality. They communicate via TCP ports. There is a CAT program
provided, but I don't even run it when using the Maestro to control the rig.

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-25 Thread Frank Kirschner
Martin,

Thanks for you complete reply. I appreciate your taking the time. My
comments are below.

On Tue, Apr 23, 2019 at 9:20 AM Martin Davies G0HDB 
wrote:

>
> Frank:
>
> If the station you want to work is concurrently transmitting multiple
> (typically 3) signals 60Hz
> apart, and conducting multiple simultaneous QSOs, within a 'standard' FT8
> band segment
> then it'll be almost certain that the station is NOT operating in true F/H
> DXpedition mode but
> is instead using one of the derivative apps such as MSHV.
>
> To work such a station, should you wish to do so (although some people
> discourage it), it's
> NOT NECESSARY to switch your mode to Hound; you can work them using the
> standard
> FT8 mode.


 OK. Then a few of the stations I worked who were transmitting
other-than-normal messages were of the derivative type. However, often, the
program puts up a screen that says I should switch to F/H mode. I assume
these are genuine F/H signals.

Indeed, I'm puzzled as to why you feel it's necessary to toggle seemingly
> quite
> often between standard and Hound mode; the latter should only ever be
> necessary when
> you're trying to work a DXpedition, most (if not all) of which will have
> declared in advance
> which frequencies away from the standard segments they will be using for
> F/H mode.  There
> should never really be a need to change your system to Hound mode when
> you're operating
> in the standard band segments - it doesn't matter if you're trying to work
> a local or some
> exotic DX.
>

I don't believe I ever stated anything about the frequency of toggling F/H
ON or OFF. It's just that when a F/H signal appears, it would be convenient
to get into that mode as quickly as possible, since they are often weak,
and QSB takes them below the useful signal strength.

A DXpedition is usually active for a week or more. When one is coming in on
FT8, I switch to that band and frequency, toggle the F/H mode from OFF to
ON, and try to work them. Once I work them (or they fade out and I lose
patience), I again toggle the F/H mode from ON to OFF, and look for less
exotic DX. With ten bands of interest, this means that in two weeks, I
could toggle the F/H mode between OFF and ON many times. When there are no
DXpeditions active, of course I don't need to toggle it at all.

I don't believe that most people toggle F/H mode to ON when there is a
DXpedition active and leave it there for the duration.

>
> You stated in another email:
>
> > I have responded to stations in F/H mode in the regular band segment on
> > numerous occasions with no interference from the software. This
> screen-grab
> > shows Hound mode in the regular band segment.
>
> There's nothing in your screen-grab to indicate that any of the stations
> are operating in either
> true F/H mode or even in a derivative multi-channel mode such as MSHV, so
> why are you in
> Hound mode?
>

Someone wrote that the software prevented using Hound mode in the regular
band segments. I was just demonstrating that this was not the case. I
didn't actually transmit, since I saw no stations in Fox mode.

>
> If you've been switching to Hound mode whenever you want to try to work a
> DX station


I have not. The large majority of DX stations I have worked have been in
the normal mode. However, with 265 DXCC entities and 1233 band-entities
confirmed on LOTW, and band conditions as bad as they are, working new
entities without the benefit of a DXpedition at the distant end is getting
harder. Since I mostly hunt new band-entities, I don't generally work DX
that already have confirmed on that band. So the ratio of F/H contacts to
regular contacts is going up.


> With regard to being able to use Hound mode in the standard band segments,
> I've
> discovered that if I select my specific Hound configuration which excludes
> all the standard
> frequency segments (my frequency list for Hound mode only includes the
> declared
> DXpedition frequencies, eg. 14095kHz), then there's nothing to prevent me
> from manually
> retuning the rig down to 14074kHz and then transmitting within the
> standard segment.
> Perhaps the software developers could take a look at explicitly preventing
> transmissions in
> the standard segments whenever Hound mode is selected, irrespective of how
> the frequency
> is set.
>

That was my point, above. So it would also be true that a DX station (or
anybody, really) could switch to Fox mode in the regular band segment.

>
> You also stated, in another email:
>
> > I tried that, and it worked fine, switching between F/H and normal mode,
> > and switching Split between Rig and None. Until I closed and restarted
> the
> > program. The first time I switched configurations, the S/W complained
> that
> > I needed to use Rig or Fake It for the Split parameter. Once I reset it,
> it
> > worked fine again.
>
> Does this mean that you only select 'Split' operation when you change to
> Hound mode?  Why
> would you not use 'Split' when operating in normal FT8 

Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-23 Thread Jim Shorney
On Tue, 23 Apr 2019 14:11:19 +0100
"Martin Davies G0HDB"  wrote:

> The use of Split is all-but essential for slick operation in Hound mode, 
> which is presumably 
> why the software complained if you changed to a Hound configuration without 
> one or other of 
> the Split options being selected.

Actually, no it (rig split via CAT) is not at all essential. However, using the 
software without CAT control requires actual radio knowledge.

73

-Jim
NU0C

--
"Life is too short for QRP" - ETO Alpha

"DeciBels were invented to give QRPers a false sense of smugness" - NU0C
"QRO is a public service" - NU0C




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-23 Thread Martin Davies G0HDB
On 22 Apr 2019 at 17:22, Frank Kirschner wrote:

> OK. How do I tell whether it's a F/H mode station or a "derivative"
> program? Most of the time, when I switch to F/H mode to work DX, I am able
> to work them. Does that indicate the DX station is, indeed, running F/H?

Frank:

If the station you want to work is concurrently transmitting multiple 
(typically 3) signals 60Hz 
apart, and conducting multiple simultaneous QSOs, within a 'standard' FT8 band 
segment 
then it'll be almost certain that the station is NOT operating in true F/H 
DXpedition mode but 
is instead using one of the derivative apps such as MSHV.

To work such a station, should you wish to do so (although some people 
discourage it), it's 
NOT NECESSARY to switch your mode to Hound; you can work them using the 
standard 
FT8 mode.  Indeed, I'm puzzled as to why you feel it's necessary to toggle 
seemingly quite 
often between standard and Hound mode; the latter should only ever be necessary 
when 
you're trying to work a DXpedition, most (if not all) of which will have 
declared in advance 
which frequencies away from the standard segments they will be using for F/H 
mode.  There 
should never really be a need to change your system to Hound mode when you're 
operating 
in the standard band segments - it doesn't matter if you're trying to work a 
local or some 
exotic DX.

You stated in another email:

> I have responded to stations in F/H mode in the regular band segment on
> numerous occasions with no interference from the software. This screen-grab
> shows Hound mode in the regular band segment.

There's nothing in your screen-grab to indicate that any of the stations are 
operating in either 
true F/H mode or even in a derivative multi-channel mode such as MSHV, so why 
are you in 
Hound mode?

If you've been switching to Hound mode whenever you want to try to work a DX 
station then 
it's possible (or even likely) that your transmit frequency will have been 
hopping around the 
band in response to you being called by the DX station - when you're called by 
the DX station 
the 'Hound-mode' software will have changed your Tx frequency to match that of 
the DX 
station (in the range of 300 to 540Hz) and then, if your transmission isn't 
received by the DX 
station (perhaps because others were also calling him on his frequency), your 
Tx frequency 
will be shifted either up or down by 300Hz.  Such frequency agility on your 
part might not be 
appreciated by other users on the band!!

With regard to being able to use Hound mode in the standard band segments, I've 
discovered that if I select my specific Hound configuration which excludes all 
the standard 
frequency segments (my frequency list for Hound mode only includes the declared 
DXpedition frequencies, eg. 14095kHz), then there's nothing to prevent me from 
manually 
retuning the rig down to 14074kHz and then transmitting within the standard 
segment.  
Perhaps the software developers could take a look at explicitly preventing 
transmissions in 
the standard segments whenever Hound mode is selected, irrespective of how the 
frequency 
is set.

You also stated, in another email:

> I tried that, and it worked fine, switching between F/H and normal mode,
> and switching Split between Rig and None. Until I closed and restarted the
> program. The first time I switched configurations, the S/W complained that
> I needed to use Rig or Fake It for the Split parameter. Once I reset it, it
> worked fine again.

Does this mean that you only select 'Split' operation when you change to Hound 
mode?  Why 
would you not use 'Split' when operating in normal FT8 mode?  There's no 
earthly reason not 
to, especially as it provides the benefit of ensuring that your audio tones are 
always in the 
'sweet' range between 1500 and 2000Hz, thereby helping to minimise the 
potential for 'bad 
audio'.

The use of Split is all-but essential for slick operation in Hound mode, which 
is presumably 
why the software complained if you changed to a Hound configuration without one 
or other of 
the Split options being selected.

-- 
Martin G0HDB

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-22 Thread Neil Zampella

If you're answering on the normal FT8 frequencies, its not the WSJT-X
DXPedition mode which specifically locks out the standard FT8 frequencies.

They are using a third-party software that I referred to previously.

Neil, KN3ILZ

On 4/22/2019 5:22 PM, Frank Kirschner wrote:

Grant,

On Sun, Apr 21, 2019 at 6:40 PM Grant VK5GR mailto:vk5gr.ra...@gmail.com>> wrote:

Frank,

Fox and Hound was never in the main FT8 channels – indeed I
believe Bill, Frank Joe and the team coded the system to not let
you run F/H mode on the main FT8 channels.


Interesting. If that's the case, that function isn't working:



image.png

I have responded to stations in F/H mode in the regular band segment
on numerous occasions with no interference from the software. This
screen-grab shows Hound mode in the regular band segment.

There have been non WSJT based “derivatives” that unfortunately
did not give due consideration to the problems of mixing F/H mode
with standard FT8 traffic.


OK. How do I tell whether it's a F/H mode station or a "derivative"
program? Most of the time, when I switch to F/H mode to work DX, I am
able to work them. Does that indicate the DX station is, indeed,
running F/H?

Thanks.

73,
Frank
KF6E

Regards,

Grant VK5GR





---
This email has been checked for viruses by AVG.
https://www.avg.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-22 Thread Neil Zampella

I don't know of many people who 'toggle' F/H mode.   As has been pointed
out, if you're using F/H mode, you're chasing a DXPedition that has
normally announced what frequencies it will be using, and would not be
on the normal FT8 locations.

Whoever is using a F/H look-alike on the normal frequencies is doing a
disservice to the rest of the community.

Neil, KN3ILZ

On 4/22/2019 5:14 PM, Frank Kirschner wrote:



On Sun, Apr 21, 2019 at 5:51 PM Martin Davies G0HDB
mailto:marting0...@gmail.com>> wrote:

On 21 Apr 2019 at 13:47, Frank Kirschner wrote:


I've been a user of FT8 F/H mode since its inception and I can't
recall any instances where
*genuine* F/H signals have appeared in the standard FT8 band
segments; can anyone
confirm any instances of this?  However, there have been (and
still are) numerous stations
using the MSHV multi-thread mode in the standard band segments;
such stations
superficially appear to be using F/H mode because of the multiple
concurrent QSOs but
they're most definitely not.


 Here's a DX cluster report of a station using F/H in the regular band
segment:

image.png

I can't receive him (low-band antenna blew down), and I wouldn't know
if he was or wasn't, but I have worked several stations using F/H mode
in the regular band segment.


I use a specific, separate configuration for F/H mode and see no
need to have a main-screen
check-box to select the mode; as has already been pointed out
selecting that, and any other,
configuration can already be quickly and easily selected via a
couple of clicks.


 Yes, that's one work-around, probably the one I will use. But since
toggling F/H mode is done more often than toggling Hold Tx Freq or
Call 1st, it seems like that should be quicker to get to. A good UI
has the most-used features closest to the user.

73,
Frank
KF6E


--
73, Martin G0HDB




---
This email has been checked for viruses by AVG.
https://www.avg.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-22 Thread Frank Kirschner
Just found my reading glasses and noticed that it is 10.131, not 10.136, so
that's not an example.

But that has noting to do with the point of improving the user interface.

I created hundreds of databases for industry and government, and found that
they were best-received when the most used functions were easiest to access.

73,
Frank
KF6E

On Mon, Apr 22, 2019 at 5:14 PM Frank Kirschner 
wrote:

>
>
> On Sun, Apr 21, 2019 at 5:51 PM Martin Davies G0HDB 
> wrote:
>
>> On 21 Apr 2019 at 13:47, Frank Kirschner wrote:
>>
>>
>> I've been a user of FT8 F/H mode since its inception and I can't recall
>> any instances where
>> *genuine* F/H signals have appeared in the standard FT8 band segments;
>> can anyone
>> confirm any instances of this?  However, there have been (and still are)
>> numerous stations
>> using the MSHV multi-thread mode in the standard band segments; such
>> stations
>> superficially appear to be using F/H mode because of the multiple
>> concurrent QSOs but
>> they're most definitely not.
>>
>
>  Here's a DX cluster report of a station using F/H in the regular band
> segment:
>
> [image: image.png]
>
> I can't receive him (low-band antenna blew down), and I wouldn't know if
> he was or wasn't, but I have worked several stations using F/H mode in the
> regular band segment.
>
>>
>> I use a specific, separate configuration for F/H mode and see no need to
>> have a main-screen
>> check-box to select the mode; as has already been pointed out selecting
>> that, and any other,
>> configuration can already be quickly and easily selected via a couple of
>> clicks.
>>
>
>  Yes, that's one work-around, probably the one I will use. But since
> toggling F/H mode is done more often than toggling Hold Tx Freq or Call
> 1st, it seems like that should be quicker to get to. A good UI has the
> most-used features closest to the user.
>
> 73,
> Frank
> KF6E
>
>>
>> --
>> 73, Martin G0HDB
>>
>>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-22 Thread Frank Kirschner
On Sun, Apr 21, 2019 at 5:51 PM Martin Davies G0HDB 
wrote:

> On 21 Apr 2019 at 13:47, Frank Kirschner wrote:
>
> I use a specific, separate configuration for F/H mode and see no need to
> have a main-screen
> check-box to select the mode; as has already been pointed out selecting
> that, and any other,
> configuration can already be quickly and easily selected via a couple of
> clicks.
>

I tried that, and it worked fine, switching between F/H and normal mode,
and switching Split between Rig and None. Until I closed and restarted the
program. The first time I switched configurations, the S/W complained that
I needed to use Rig or Fake It for the Split parameter. Once I reset it, it
worked fine again.

Why does the program lose that setting when I close it?

73,
Frank
KF6E

>
> --
> 73, Martin G0HDB
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-22 Thread Enrique Scheuer
Hello Frank  coming in..

May I ask where to download the FT4 beta version?

73 de Enrique PY2CP

Em seg, 22 de abr de 2019 às 18:05, Frank Kirschner <
frank.kirsch...@gmail.com> escreveu:

> Gary,
>
> Thanks; very helpful.
>
> It is interesting to see that the F/H choice was on the main page early
> on. It is toggled much more often than Hold Tx Freq or Call 1st.
>
> 73,
> Frank
> KIF6E
>
> On Sun, Apr 21, 2019 at 3:03 PM Gary Hinson  wrote:
>
>> Here’s a different suggestion, Frank: take a look at JTDX which has a
>> hound button on the main screen.  Click the button to turn on hound mode’s
>> short QSO sequence, then right click it to also enable the automatic
>> frequency control thing that moves us below 1000 to the DX frequency when
>> (if!) he calls us.
>>
>>
>>
>> Also, by the way, click the waterfall to set the green marker, or right
>> click to set the red marker – simple, intuitive and easy.
>>
>>
>>
>> 73 GL
>>
>> Gary   ZL2iFB
>>
>>
>>
>> *From:* Frank Kirschner 
>> *Sent:* 22 April 2019 05:38
>> *To:* WSJT software development 
>> *Subject:* Re: [wsjt-devel] Suggestion for Additional Checkbox
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Apr 20, 2019 at 10:53 PM WB5JJJ  wrote:
>>
>> F/H is not something you would normally select on a frequent basis,
>>
>>
>>
>> Yes it is. I mostly do DX hunting, and around 10 to 15% of my QSOs have
>> been in F/H mode. Normally, I never respond to CQs from band-entities that
>> I already have confirmed on LoTW. If someone calls me while I'm working DX,
>> I will respond, but that requires turning off F/H mode before doing so. A
>> checkbox would make that easier. I certainly select or unselect F/H mode
>> more often than Hold Tx Freq or Call 1st, and there are checkboxes for
>> those.
>>
>> so a check box cluttering the main screen is not necessary.
>>
>>
>>
>> As I pointed out, it wouldn't clutter the screen. There is ample room for
>> several more checkboxes.
>>
>>
>>
>> As previously suggested setting a Configuration for that mode (and
>> others) are just 2 clicks away and totally customizable.  This procedure is
>> outlined in the User Manual.  It's simple and effective.
>>
>>
>>
>> Yes, that's an adequate workaround. But there are several selections
>> available on the screen that I don't normally change, and these could be
>> accessed through different configurations. Yet, they are on the main
>> screen. It's just a difference in operating style.
>>
>>
>>
>> WB5JJJ - George
>>
>>
>>
>> It was just a suggestion. Some people are not open to suggestions.
>>
>>
>>
>> Thanks for your input.
>>
>>
>>
>> 73,
>>
>> Frank
>>
>> KF6E
>>
>>
>>
>> On Sat, Apr 20, 2019 at 7:44 PM Frank Kirschner 
>> wrote:
>>
>> Good idea. I'm not familiar enough with the program to have thought of
>> that. Thanks.
>>
>>
>>
>> 73,
>>
>> Frank
>>
>> KF6E
>>
>>
>>
>> On Sat, Apr 20, 2019 at 6:16 PM N3SL  wrote:
>>
>> Just a suggestion - works for me:  Create a F/H "configuration" and
>> toggle to it.  Two mouse clicks.
>>
>>
>>
>> On Sat, Apr 20, 2019 at 4:50 PM Frank Kirschner <
>> frank.kirsch...@gmail.com> wrote:
>>
>> Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is
>> room for several more checkboxes. One I would suggest is Fox/Hound mode. I
>> would also suggest this automatically set Split to either Rig or Fake It,
>> which could be selected somewhere else.
>>
>>
>>
>> If the menus are turned off, it takes a while to turn them on and
>> navigate to the correct spot to set fox/hound and split mode. This
>> sometimes is long enough to miss a weak one. A checkbox would not only make
>> it faster, but it would encourage using that mode for those who are still
>> learning FT8 operation.
>>
>>
>>
>> 73,
>>
>> Frank
>>
>> KF6E
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-22 Thread Frank Kirschner
On Sun, Apr 21, 2019 at 7:08 PM Jim Shorney  wrote:

> On Mon, 22 Apr 2019 08:06:26 +0930
> "Grant VK5GR"  wrote:
>
> > Fox and Hound was never in the main FT8 channels – indeed I believe
> Bill, Frank Joe and the team coded the system to not let you run F/H mode
> on the main FT8 channels.
>
>
> which can easily be subverted by not using CAT control of frequency.
>

Here is the program set to F/H mode in the regular band segment:


[image: image.png]

I'm using DAX with my Flex 6600, and Split is set to "Rig." Am I missing
something? There doesn't seem to be anything to prevent this.

73,
Frank
KF6E

>
> Not that anyone would do that.
>
> 73
>
> -Jim
> NU0C
>
> --
> “There’s something out of place – let’s go and poke it with a stick.” –
> The Doctor, "Amy’s Choice"
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-22 Thread Frank Kirschner
Grant,

On Sun, Apr 21, 2019 at 6:40 PM Grant VK5GR  wrote:

> Frank,
>
>
>
> Fox and Hound was never in the main FT8 channels – indeed I believe Bill,
> Frank Joe and the team coded the system to not let you run F/H mode on the
> main FT8 channels.
>

Interesting. If that's the case, that function isn't working:



[image: image.png]

>
>
I have responded to stations in F/H mode in the regular band segment on
numerous occasions with no interference from the software. This screen-grab
shows Hound mode in the regular band segment.


> There have been non WSJT based “derivatives” that unfortunately did not
> give due consideration to the problems of mixing F/H mode with standard FT8
> traffic.
>

OK. How do I tell whether it's a F/H mode station or a "derivative"
program? Most of the time, when I switch to F/H mode to work DX, I am able
to work them. Does that indicate the DX station is, indeed, running F/H?

Thanks.

73,
Frank
KF6E

>
>
> Regards,
>
> Grant VK5GR
>
>
>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-22 Thread Frank Kirschner
On Sun, Apr 21, 2019 at 5:51 PM Martin Davies G0HDB 
wrote:

> On 21 Apr 2019 at 13:47, Frank Kirschner wrote:
>
>
> I've been a user of FT8 F/H mode since its inception and I can't recall
> any instances where
> *genuine* F/H signals have appeared in the standard FT8 band segments; can
> anyone
> confirm any instances of this?  However, there have been (and still are)
> numerous stations
> using the MSHV multi-thread mode in the standard band segments; such
> stations
> superficially appear to be using F/H mode because of the multiple
> concurrent QSOs but
> they're most definitely not.
>

 Here's a DX cluster report of a station using F/H in the regular band
segment:

[image: image.png]

I can't receive him (low-band antenna blew down), and I wouldn't know if he
was or wasn't, but I have worked several stations using F/H mode in the
regular band segment.

>
> I use a specific, separate configuration for F/H mode and see no need to
> have a main-screen
> check-box to select the mode; as has already been pointed out selecting
> that, and any other,
> configuration can already be quickly and easily selected via a couple of
> clicks.
>

 Yes, that's one work-around, probably the one I will use. But since
toggling F/H mode is done more often than toggling Hold Tx Freq or Call
1st, it seems like that should be quicker to get to. A good UI has the
most-used features closest to the user.

73,
Frank
KF6E

>
> --
> 73, Martin G0HDB
>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-22 Thread Frank Kirschner
Gary,

Thanks; very helpful.

It is interesting to see that the F/H choice was on the main page early on.
It is toggled much more often than Hold Tx Freq or Call 1st.

73,
Frank
KIF6E

On Sun, Apr 21, 2019 at 3:03 PM Gary Hinson  wrote:

> Here’s a different suggestion, Frank: take a look at JTDX which has a
> hound button on the main screen.  Click the button to turn on hound mode’s
> short QSO sequence, then right click it to also enable the automatic
> frequency control thing that moves us below 1000 to the DX frequency when
> (if!) he calls us.
>
>
>
> Also, by the way, click the waterfall to set the green marker, or right
> click to set the red marker – simple, intuitive and easy.
>
>
>
> 73 GL
>
> Gary   ZL2iFB
>
>
>
> *From:* Frank Kirschner 
> *Sent:* 22 April 2019 05:38
> *To:* WSJT software development 
> *Subject:* Re: [wsjt-devel] Suggestion for Additional Checkbox
>
>
>
>
>
>
>
> On Sat, Apr 20, 2019 at 10:53 PM WB5JJJ  wrote:
>
> F/H is not something you would normally select on a frequent basis,
>
>
>
> Yes it is. I mostly do DX hunting, and around 10 to 15% of my QSOs have
> been in F/H mode. Normally, I never respond to CQs from band-entities that
> I already have confirmed on LoTW. If someone calls me while I'm working DX,
> I will respond, but that requires turning off F/H mode before doing so. A
> checkbox would make that easier. I certainly select or unselect F/H mode
> more often than Hold Tx Freq or Call 1st, and there are checkboxes for
> those.
>
> so a check box cluttering the main screen is not necessary.
>
>
>
> As I pointed out, it wouldn't clutter the screen. There is ample room for
> several more checkboxes.
>
>
>
> As previously suggested setting a Configuration for that mode (and others)
> are just 2 clicks away and totally customizable.  This procedure is
> outlined in the User Manual.  It's simple and effective.
>
>
>
> Yes, that's an adequate workaround. But there are several selections
> available on the screen that I don't normally change, and these could be
> accessed through different configurations. Yet, they are on the main
> screen. It's just a difference in operating style.
>
>
>
> WB5JJJ - George
>
>
>
> It was just a suggestion. Some people are not open to suggestions.
>
>
>
> Thanks for your input.
>
>
>
> 73,
>
> Frank
>
> KF6E
>
>
>
> On Sat, Apr 20, 2019 at 7:44 PM Frank Kirschner 
> wrote:
>
> Good idea. I'm not familiar enough with the program to have thought of
> that. Thanks.
>
>
>
> 73,
>
> Frank
>
> KF6E
>
>
>
> On Sat, Apr 20, 2019 at 6:16 PM N3SL  wrote:
>
> Just a suggestion - works for me:  Create a F/H "configuration" and toggle
> to it.  Two mouse clicks.
>
>
>
> On Sat, Apr 20, 2019 at 4:50 PM Frank Kirschner 
> wrote:
>
> Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is room
> for several more checkboxes. One I would suggest is Fox/Hound mode. I would
> also suggest this automatically set Split to either Rig or Fake It, which
> could be selected somewhere else.
>
>
>
> If the menus are turned off, it takes a while to turn them on and navigate
> to the correct spot to set fox/hound and split mode. This sometimes is long
> enough to miss a weak one. A checkbox would not only make it faster, but it
> would encourage using that mode for those who are still learning FT8
> operation.
>
>
>
> 73,
>
> Frank
>
> KF6E
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-21 Thread Jim Shorney
On Mon, 22 Apr 2019 08:06:26 +0930
"Grant VK5GR"  wrote:

> Fox and Hound was never in the main FT8 channels – indeed I believe Bill, 
> Frank Joe and the team coded the system to not let you run F/H mode on the 
> main FT8 channels. 


which can easily be subverted by not using CAT control of frequency.

Not that anyone would do that. 

73

-Jim
NU0C

--
“There’s something out of place – let’s go and poke it with a stick.” – The 
Doctor, "Amy’s Choice"


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-21 Thread Grant VK5GR
Frank,

 

Fox and Hound was never in the main FT8 channels – indeed I believe Bill, Frank 
Joe and the team coded the system to not let you run F/H mode on the main FT8 
channels. 

 

There have been non WSJT based “derivatives” that unfortunately did not give 
due consideration to the problems of mixing F/H mode with standard FT8 traffic.

 

Regards,

Grant VK5GR

 

 

From: Frank Kirschner [mailto:frank.kirsch...@gmail.com] 
Sent: Monday, 22 April 2019 3:18 AM
To: WSJT software development
Subject: Re: [wsjt-devel] Suggestion for Additional Checkbox

 

 

 

On Sat, Apr 20, 2019 at 11:19 PM Neil Zampella  wrote:

There is already a F/H mode, safely placed where it can't be
accidentally checked as the old VHF contest box (at least I believe it
was the VHF contest) was at one point.

The suggestion has been to clone your current FT8 configuration, and set
up the frequencies in that clone to the DXPedition frequencies.All
you have to do is switch to that configuration, and you're already set
to go.

However, if you're talking about being able to switch because you see
what looks like F/H in the standard FT8 frequencies, its not WSJT-X
DXPedition mode, but another program using the FT8 sources for
encode/decode but a different 'multi-thread' mode that does NOT block
out the standard frequencies.

 

That's not completely accurate. Initially, most F/H operation was in the 
regular band segment, but as those segments filled up, DX stations moved to the 
alternate frequencies. I have worked DX stations in F/H mode in the regular 
band segments. That's becoming less frequent, though.

 

Since I mostly hunt DX, I don't just look for DX on the band activity window in 
WSJT-X. I use a DX cluster and jump to the indicated frequency directly. Since 
clusters now indicate the transmitted frequency instead of the QRG, I have to 
manually change the VFO frequency to the correct one. Then I look for the DX 
station, and decide if it's using F/H mode. It would be convenient to switch to 
F/H with one click.

 

73,

Frank

KF6E


I would not want to see such a change as it then rewards bad behavior
(IMHO).

Neil, KN3ILZ

On 4/20/2019 5:46 PM, Frank Kirschner wrote:
> Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is
> room for several more checkboxes. One I would suggest is Fox/Hound
> mode. I would also suggest this automatically set Split to either Rig
> or Fake It, which could be selected somewhere else.
>
> If the menus are turned off, it takes a while to turn them on and
> navigate to the correct spot to set fox/hound and split mode. This
> sometimes is long enough to miss a weak one. A checkbox would not only
> make it faster, but it would encourage using that mode for those who
> are still learning FT8 operation.
>
> 73,
> Frank
> KF6E

---
This email has been checked for viruses by AVG.
https://www.avg.com



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-21 Thread James Shaver
At one point the controls for F/H were on the main part of the GUI and the 
group was flooded with questions asking why they were receiving and 
transmitting “funny” because they were inadvertently checking the box when it 
was on the main page. That went away when the box was moved into the settings. 

> On Apr 21, 2019, at 3:31 PM, Jim Shorney  wrote:
> 
> 
> F2 is your friend. If 'Advanced" was the last active tab you you will be 
> right there. That's a single key stroke! What's so hard about that?
> 
> 73
> 
> -Jim
> NU0C
> 
> 
> On Sun, 21 Apr 2019 13:38:24 -0400
> Frank Kirschner  wrote:
> 
>>> On Sat, Apr 20, 2019 at 10:53 PM WB5JJJ  wrote:
>>> 
>>> F/H is not something you would normally select on a frequent basis,
>>> 
>> 
>> Yes it is. I mostly do DX hunting, and around 10 to 15% of my QSOs have
>> been in F/H mode. Normally, I never respond to CQs from band-entities that
>> I already have confirmed on LoTW. If someone calls me while I'm working DX,
>> I will respond, but that requires turning off F/H mode before doing so. A
>> checkbox would make that easier. I certainly select or unselect F/H mode
>> more often than Hold Tx Freq or Call 1st, and there are checkboxes for
>> those.
>> 
>>> so a check box cluttering the main screen is not necessary.
>>> 
>> 
>> As I pointed out, it wouldn't clutter the screen. There is ample room for
>> several more checkboxes.
>> 
>>> 
>>> As previously suggested setting a Configuration for that mode (and others)
>>> are just 2 clicks away and totally customizable.  This procedure is
>>> outlined in the User Manual.  It's simple and effective.
>>> 
>>> Yes, that's an adequate workaround. But there are several selections  
>> available on the screen that I don't normally change, and these could be
>> accessed through different configurations. Yet, they are on the main
>> screen. It's just a difference in operating style.
>> 
>> 
>>> WB5JJJ - George
>>> 
>> 
>> It was just a suggestion. Some people are not open to suggestions.
>> 
>> Thanks for your input.
>> 
>> 73,
>> Frank
>> KF6E
>> 
>>> 
>>> On Sat, Apr 20, 2019 at 7:44 PM Frank Kirschner 
>>> wrote:
>>> 
 Good idea. I'm not familiar enough with the program to have thought of
 that. Thanks.
 
 73,
 Frank
 KF6E
 
> On Sat, Apr 20, 2019 at 6:16 PM N3SL  wrote:
> 
> Just a suggestion - works for me:  Create a F/H "configuration" and
> toggle to it.  Two mouse clicks.
> 
> On Sat, Apr 20, 2019 at 4:50 PM Frank Kirschner <  
> frank.kirsch...@gmail.com> wrote:  
> 
>> Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is
>> room for several more checkboxes. One I would suggest is Fox/Hound mode. 
>> I
>> would also suggest this automatically set Split to either Rig or Fake It,
>> which could be selected somewhere else.
>> 
>> If the menus are turned off, it takes a while to turn them on and
>> navigate to the correct spot to set fox/hound and split mode. This
>> sometimes is long enough to miss a weak one. A checkbox would not only 
>> make
>> it faster, but it would encourage using that mode for those who are still
>> learning FT8 operation.
>> 
>> 73,
>> Frank
>> KF6E
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> 
> ___  
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel
 
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>> 
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-21 Thread Martin Davies G0HDB
On 21 Apr 2019 at 13:47, Frank Kirschner wrote:

> That's not completely accurate. Initially, most F/H operation was in the
> regular band segment, but as those segments filled up, DX stations moved to
> the alternate frequencies. I have worked DX stations in F/H mode in the
> regular band segments. That's becoming less frequent, though.

I've been a user of FT8 F/H mode since its inception and I can't recall any 
instances where 
*genuine* F/H signals have appeared in the standard FT8 band segments; can 
anyone 
confirm any instances of this?  However, there have been (and still are) 
numerous stations 
using the MSHV multi-thread mode in the standard band segments; such stations 
superficially appear to be using F/H mode because of the multiple concurrent 
QSOs but 
they're most definitely not.

I use a specific, separate configuration for F/H mode and see no need to have a 
main-screen 
check-box to select the mode; as has already been pointed out selecting that, 
and any other, 
configuration can already be quickly and easily selected via a couple of clicks.

--
73, Martin G0HDB


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-21 Thread Jim Shorney


F2 is your friend. If 'Advanced" was the last active tab you you will be right 
there. That's a single key stroke! What's so hard about that?

73

-Jim
NU0C


On Sun, 21 Apr 2019 13:38:24 -0400
Frank Kirschner  wrote:

> On Sat, Apr 20, 2019 at 10:53 PM WB5JJJ  wrote:
> 
> > F/H is not something you would normally select on a frequent basis,
> >  
> 
> Yes it is. I mostly do DX hunting, and around 10 to 15% of my QSOs have
> been in F/H mode. Normally, I never respond to CQs from band-entities that
> I already have confirmed on LoTW. If someone calls me while I'm working DX,
> I will respond, but that requires turning off F/H mode before doing so. A
> checkbox would make that easier. I certainly select or unselect F/H mode
> more often than Hold Tx Freq or Call 1st, and there are checkboxes for
> those.
> 
> > so a check box cluttering the main screen is not necessary.
> >  
> 
> As I pointed out, it wouldn't clutter the screen. There is ample room for
> several more checkboxes.
> 
> >
> > As previously suggested setting a Configuration for that mode (and others)
> > are just 2 clicks away and totally customizable.  This procedure is
> > outlined in the User Manual.  It's simple and effective.
> >
> > Yes, that's an adequate workaround. But there are several selections  
> available on the screen that I don't normally change, and these could be
> accessed through different configurations. Yet, they are on the main
> screen. It's just a difference in operating style.
> 
> 
> > WB5JJJ - George
> >  
> 
> It was just a suggestion. Some people are not open to suggestions.
> 
> Thanks for your input.
> 
> 73,
> Frank
> KF6E
> 
> >
> > On Sat, Apr 20, 2019 at 7:44 PM Frank Kirschner 
> > wrote:
> >  
> >> Good idea. I'm not familiar enough with the program to have thought of
> >> that. Thanks.
> >>
> >> 73,
> >> Frank
> >> KF6E
> >>
> >> On Sat, Apr 20, 2019 at 6:16 PM N3SL  wrote:
> >>  
> >>> Just a suggestion - works for me:  Create a F/H "configuration" and
> >>> toggle to it.  Two mouse clicks.
> >>>
> >>> On Sat, Apr 20, 2019 at 4:50 PM Frank Kirschner <  
> >>> frank.kirsch...@gmail.com> wrote:  
> >>>  
>  Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is
>  room for several more checkboxes. One I would suggest is Fox/Hound mode. 
>  I
>  would also suggest this automatically set Split to either Rig or Fake It,
>  which could be selected somewhere else.
> 
>  If the menus are turned off, it takes a while to turn them on and
>  navigate to the correct spot to set fox/hound and split mode. This
>  sometimes is long enough to miss a weak one. A checkbox would not only 
>  make
>  it faster, but it would encourage using that mode for those who are still
>  learning FT8 operation.
> 
>  73,
>  Frank
>  KF6E
>  ___
>  wsjt-devel mailing list
>  wsjt-devel@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>   
> >>> ___  
> >> wsjt-devel mailing list
> >> wsjt-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >>  
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >  



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-21 Thread Gary Hinson
Here’s a different suggestion, Frank: take a look at JTDX which has a hound 
button on the main screen.  Click the button to turn on hound mode’s short QSO 
sequence, then right click it to also enable the automatic frequency control 
thing that moves us below 1000 to the DX frequency when (if!) he calls us.

 

Also, by the way, click the waterfall to set the green marker, or right click 
to set the red marker – simple, intuitive and easy.

 

73 GL

Gary   ZL2iFB

 

From: Frank Kirschner  
Sent: 22 April 2019 05:38
To: WSJT software development 
Subject: Re: [wsjt-devel] Suggestion for Additional Checkbox

 

 

 

On Sat, Apr 20, 2019 at 10:53 PM WB5JJJ mailto:wb5...@gmail.com> > wrote:

F/H is not something you would normally select on a frequent basis, 

 

Yes it is. I mostly do DX hunting, and around 10 to 15% of my QSOs have been in 
F/H mode. Normally, I never respond to CQs from band-entities that I already 
have confirmed on LoTW. If someone calls me while I'm working DX, I will 
respond, but that requires turning off F/H mode before doing so. A checkbox 
would make that easier. I certainly select or unselect F/H mode more often than 
Hold Tx Freq or Call 1st, and there are checkboxes for those. 

so a check box cluttering the main screen is not necessary.  

 

As I pointed out, it wouldn't clutter the screen. There is ample room for 
several more checkboxes. 

 

As previously suggested setting a Configuration for that mode (and others) are 
just 2 clicks away and totally customizable.  This procedure is outlined in the 
User Manual.  It's simple and effective.  

 

Yes, that's an adequate workaround. But there are several selections available 
on the screen that I don't normally change, and these could be accessed through 
different configurations. Yet, they are on the main screen. It's just a 
difference in operating style.

 

WB5JJJ - George

 

It was just a suggestion. Some people are not open to suggestions.

 

Thanks for your input.

 

73,

Frank

KF6E

 

On Sat, Apr 20, 2019 at 7:44 PM Frank Kirschner mailto:fr...@fkirschner.net> > wrote:

Good idea. I'm not familiar enough with the program to have thought of that. 
Thanks.

 

73,

Frank

KF6E

 

On Sat, Apr 20, 2019 at 6:16 PM N3SL mailto:n3sl.d...@gmail.com> > wrote:

Just a suggestion - works for me:  Create a F/H "configuration" and toggle to 
it.  Two mouse clicks.

 

On Sat, Apr 20, 2019 at 4:50 PM Frank Kirschner mailto:frank.kirsch...@gmail.com> > wrote:

Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is room for 
several more checkboxes. One I would suggest is Fox/Hound mode. I would also 
suggest this automatically set Split to either Rig or Fake It, which could be 
selected somewhere else.

 

If the menus are turned off, it takes a while to turn them on and navigate to 
the correct spot to set fox/hound and split mode. This sometimes is long enough 
to miss a weak one. A checkbox would not only make it faster, but it would 
encourage using that mode for those who are still learning FT8 operation.

 

73,

Frank

KF6E

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> 
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-21 Thread Frank Kirschner
On Sat, Apr 20, 2019 at 11:19 PM Neil Zampella  wrote:

> There is already a F/H mode, safely placed where it can't be
> accidentally checked as the old VHF contest box (at least I believe it
> was the VHF contest) was at one point.
>
> The suggestion has been to clone your current FT8 configuration, and set
> up the frequencies in that clone to the DXPedition frequencies.All
> you have to do is switch to that configuration, and you're already set
> to go.
>
> However, if you're talking about being able to switch because you see
> what looks like F/H in the standard FT8 frequencies, its not WSJT-X
> DXPedition mode, but another program using the FT8 sources for
> encode/decode but a different 'multi-thread' mode that does NOT block
> out the standard frequencies.
>

That's not completely accurate. Initially, most F/H operation was in the
regular band segment, but as those segments filled up, DX stations moved to
the alternate frequencies. I have worked DX stations in F/H mode in the
regular band segments. That's becoming less frequent, though.

Since I mostly hunt DX, I don't just look for DX on the band activity
window in WSJT-X. I use a DX cluster and jump to the indicated frequency
directly. Since clusters now indicate the transmitted frequency instead of
the QRG, I have to manually change the VFO frequency to the correct one.
Then I look for the DX station, and decide if it's using F/H mode. It would
be convenient to switch to F/H with one click.

73,
Frank
KF6E

>
> I would not want to see such a change as it then rewards bad behavior
> (IMHO).
>
> Neil, KN3ILZ
>
> On 4/20/2019 5:46 PM, Frank Kirschner wrote:
> > Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is
> > room for several more checkboxes. One I would suggest is Fox/Hound
> > mode. I would also suggest this automatically set Split to either Rig
> > or Fake It, which could be selected somewhere else.
> >
> > If the menus are turned off, it takes a while to turn them on and
> > navigate to the correct spot to set fox/hound and split mode. This
> > sometimes is long enough to miss a weak one. A checkbox would not only
> > make it faster, but it would encourage using that mode for those who
> > are still learning FT8 operation.
> >
> > 73,
> > Frank
> > KF6E
>
> ---
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-21 Thread Bill Somerville

On 21/04/2019 18:38, Frank Kirschner wrote:
As I pointed out, it wouldn't clutter the screen. There is ample room 
for several more checkboxes. 


Frank,

that is not correct, there are other controls that are not always 
visible. Here is a view of the UI design file that shows what is really 
there:


73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-21 Thread Frank Kirschner
On Sat, Apr 20, 2019 at 10:53 PM WB5JJJ  wrote:

> F/H is not something you would normally select on a frequent basis,
>

Yes it is. I mostly do DX hunting, and around 10 to 15% of my QSOs have
been in F/H mode. Normally, I never respond to CQs from band-entities that
I already have confirmed on LoTW. If someone calls me while I'm working DX,
I will respond, but that requires turning off F/H mode before doing so. A
checkbox would make that easier. I certainly select or unselect F/H mode
more often than Hold Tx Freq or Call 1st, and there are checkboxes for
those.

> so a check box cluttering the main screen is not necessary.
>

As I pointed out, it wouldn't clutter the screen. There is ample room for
several more checkboxes.

>
> As previously suggested setting a Configuration for that mode (and others)
> are just 2 clicks away and totally customizable.  This procedure is
> outlined in the User Manual.  It's simple and effective.
>
> Yes, that's an adequate workaround. But there are several selections
available on the screen that I don't normally change, and these could be
accessed through different configurations. Yet, they are on the main
screen. It's just a difference in operating style.


> WB5JJJ - George
>

It was just a suggestion. Some people are not open to suggestions.

Thanks for your input.

73,
Frank
KF6E

>
> On Sat, Apr 20, 2019 at 7:44 PM Frank Kirschner 
> wrote:
>
>> Good idea. I'm not familiar enough with the program to have thought of
>> that. Thanks.
>>
>> 73,
>> Frank
>> KF6E
>>
>> On Sat, Apr 20, 2019 at 6:16 PM N3SL  wrote:
>>
>>> Just a suggestion - works for me:  Create a F/H "configuration" and
>>> toggle to it.  Two mouse clicks.
>>>
>>> On Sat, Apr 20, 2019 at 4:50 PM Frank Kirschner <
>>> frank.kirsch...@gmail.com> wrote:
>>>
 Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is
 room for several more checkboxes. One I would suggest is Fox/Hound mode. I
 would also suggest this automatically set Split to either Rig or Fake It,
 which could be selected somewhere else.

 If the menus are turned off, it takes a while to turn them on and
 navigate to the correct spot to set fox/hound and split mode. This
 sometimes is long enough to miss a weak one. A checkbox would not only make
 it faster, but it would encourage using that mode for those who are still
 learning FT8 operation.

 73,
 Frank
 KF6E
 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel

>>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-21 Thread Gary McDuffie



> On Apr 20, 2019, at 15:46, Frank Kirschner  wrote:
> 
> Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is room 
> for several more checkboxes. One I would suggest is Fox/Hound mode. I would 
> also suggest this automatically set Split to either Rig or Fake It, which 
> could be selected somewhere else.

First, why turn menus off?  But, even if they are off, F2 brings up the config 
window immediately.  Re F/H mode, it should never come up because F/H, 
otherwise known as DXpedition mode, is NEVER supposed to be used in the same 
band segment as general QSOs.  If someone is using it in the normal segment, 
boycott them.  

You should have a configuration specifically for DXpedition mode so that 
everything normally used there is pre-set, including the frequency of the 
Expedition.

> If the menus are turned off, it takes a while to turn them on and navigate to 
> the correct spot to set fox/hound and split mode. This sometimes is long 
> enough to miss a weak one. A checkbox would not only make it faster, but it 
> would encourage using that mode for those who are still learning FT8 
> operation.

To have a simple check box on the main screen would make it make it even easier 
to abuse and use it for non-expeditions.

Gary - AG0N

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-21 Thread Jim Shorney


Or just hit F2 and you are one or two mouse clicks away...

73

-Jim
NU0C


On Sat, 20 Apr 2019 21:48:03 -0500
WB5JJJ  wrote:

> F/H is not something you would normally select on a frequent basis, so a
> check box cluttering the main screen is not necessary.
> 
> As previously suggested setting a Configuration for that mode (and others)
> are just 2 clicks away and totally customizable.  This procedure is
> outlined in the User Manual.  It's simple and effective.
> 
> WB5JJJ - George
> 
> On Sat, Apr 20, 2019 at 7:44 PM Frank Kirschner 
> wrote:
> 
> > Good idea. I'm not familiar enough with the program to have thought of
> > that. Thanks.
> >
> > 73,
> > Frank
> > KF6E
> >
> > On Sat, Apr 20, 2019 at 6:16 PM N3SL  wrote:
> >  
> >> Just a suggestion - works for me:  Create a F/H "configuration" and
> >> toggle to it.  Two mouse clicks.
> >>
> >> On Sat, Apr 20, 2019 at 4:50 PM Frank Kirschner <  
> >> frank.kirsch...@gmail.com> wrote:  
> >>  
> >>> Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is
> >>> room for several more checkboxes. One I would suggest is Fox/Hound mode. I
> >>> would also suggest this automatically set Split to either Rig or Fake It,
> >>> which could be selected somewhere else.
> >>>
> >>> If the menus are turned off, it takes a while to turn them on and
> >>> navigate to the correct spot to set fox/hound and split mode. This
> >>> sometimes is long enough to miss a weak one. A checkbox would not only 
> >>> make
> >>> it faster, but it would encourage using that mode for those who are still
> >>> learning FT8 operation.
> >>>
> >>> 73,
> >>> Frank
> >>> KF6E
> >>> ___
> >>> wsjt-devel mailing list
> >>> wsjt-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >>>  
> >> ___  
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >  



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-20 Thread Neil Zampella

There is already a F/H mode, safely placed where it can't be
accidentally checked as the old VHF contest box (at least I believe it
was the VHF contest) was at one point.

The suggestion has been to clone your current FT8 configuration, and set
up the frequencies in that clone to the DXPedition frequencies.    All
you have to do is switch to that configuration, and you're already set
to go.

However, if you're talking about being able to switch because you see
what looks like F/H in the standard FT8 frequencies, its not WSJT-X
DXPedition mode, but another program using the FT8 sources for
encode/decode but a different 'multi-thread' mode that does NOT block
out the standard frequencies.

I would not want to see such a change as it then rewards bad behavior
(IMHO).

Neil, KN3ILZ

On 4/20/2019 5:46 PM, Frank Kirschner wrote:

Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is
room for several more checkboxes. One I would suggest is Fox/Hound
mode. I would also suggest this automatically set Split to either Rig
or Fake It, which could be selected somewhere else.

If the menus are turned off, it takes a while to turn them on and
navigate to the correct spot to set fox/hound and split mode. This
sometimes is long enough to miss a weak one. A checkbox would not only
make it faster, but it would encourage using that mode for those who
are still learning FT8 operation.

73,
Frank
KF6E


---
This email has been checked for viruses by AVG.
https://www.avg.com



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-20 Thread WB5JJJ
F/H is not something you would normally select on a frequent basis, so a
check box cluttering the main screen is not necessary.

As previously suggested setting a Configuration for that mode (and others)
are just 2 clicks away and totally customizable.  This procedure is
outlined in the User Manual.  It's simple and effective.

WB5JJJ - George

On Sat, Apr 20, 2019 at 7:44 PM Frank Kirschner 
wrote:

> Good idea. I'm not familiar enough with the program to have thought of
> that. Thanks.
>
> 73,
> Frank
> KF6E
>
> On Sat, Apr 20, 2019 at 6:16 PM N3SL  wrote:
>
>> Just a suggestion - works for me:  Create a F/H "configuration" and
>> toggle to it.  Two mouse clicks.
>>
>> On Sat, Apr 20, 2019 at 4:50 PM Frank Kirschner <
>> frank.kirsch...@gmail.com> wrote:
>>
>>> Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is
>>> room for several more checkboxes. One I would suggest is Fox/Hound mode. I
>>> would also suggest this automatically set Split to either Rig or Fake It,
>>> which could be selected somewhere else.
>>>
>>> If the menus are turned off, it takes a while to turn them on and
>>> navigate to the correct spot to set fox/hound and split mode. This
>>> sometimes is long enough to miss a weak one. A checkbox would not only make
>>> it faster, but it would encourage using that mode for those who are still
>>> learning FT8 operation.
>>>
>>> 73,
>>> Frank
>>> KF6E
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion for Additional Checkbox

2019-04-20 Thread Frank Kirschner
Good idea. I'm not familiar enough with the program to have thought of
that. Thanks.

73,
Frank
KF6E

On Sat, Apr 20, 2019 at 6:16 PM N3SL  wrote:

> Just a suggestion - works for me:  Create a F/H "configuration" and toggle
> to it.  Two mouse clicks.
>
> On Sat, Apr 20, 2019 at 4:50 PM Frank Kirschner 
> wrote:
>
>> Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is
>> room for several more checkboxes. One I would suggest is Fox/Hound mode. I
>> would also suggest this automatically set Split to either Rig or Fake It,
>> which could be selected somewhere else.
>>
>> If the menus are turned off, it takes a while to turn them on and
>> navigate to the correct spot to set fox/hound and split mode. This
>> sometimes is long enough to miss a weak one. A checkbox would not only make
>> it faster, but it would encourage using that mode for those who are still
>> learning FT8 operation.
>>
>> 73,
>> Frank
>> KF6E
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Suggestion for Additional Checkbox

2019-04-20 Thread Frank Kirschner
Between the Hold Tx Freq checkbox and the Call 1st checkbox, there is room
for several more checkboxes. One I would suggest is Fox/Hound mode. I would
also suggest this automatically set Split to either Rig or Fake It, which
could be selected somewhere else.

If the menus are turned off, it takes a while to turn them on and navigate
to the correct spot to set fox/hound and split mode. This sometimes is long
enough to miss a weak one. A checkbox would not only make it faster, but it
would encourage using that mode for those who are still learning FT8
operation.

73,
Frank
KF6E
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion regarding colors

2018-12-22 Thread Robert Rearden
For MacOS, this is taken care by JT-Bridge. 

Robert Rearden 
AE5UV
_

On Dec 22, 2018, at 8:41 AM, Tom Ramberg via wsjt-devel 
 wrote:

May I suggest using JTAlert which has already taken care of this?

73 de Tom OH6VDA

> 22. des. 2018 kl. 00:17 skrev I Z :
> 
> Suggestion regarding colors.
> I really love what was done in 2.0. Finally a great logger, many thanks!
> I miss one enhancement though. When I see a message from one station to 
> another (without CQ or my call), it is in white. It will be very nice if the 
> second call in this message was highlighted, telling me if I worked this 
> station before or not on this band.
> Example: K1AA ZS1ABC -10. I don’t care about the first station, which I may 
> not ever copy. But since I am receiving ZS1ABC, it would be very nice to know 
> if I worked him before or not. If I did not, I will probably wait till he is 
> done with K1AA and then call him. Otherwise I have to open the adif file and 
> look there manually, which is a hassle.
> Most of the semi-rare stations hardly call CQ.
> 73, W0IZ “IZ”
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion regarding colors

2018-12-22 Thread Tom Ramberg via wsjt-devel
May I suggest using JTAlert which has already taken care of this?

73 de Tom OH6VDA

> 22. des. 2018 kl. 00:17 skrev I Z :
> 
> Suggestion regarding colors.
> I really love what was done in 2.0. Finally a great logger, many thanks!
> I miss one enhancement though. When I see a message from one station to 
> another (without CQ or my call), it is in white. It will be very nice if the 
> second call in this message was highlighted, telling me if I worked this 
> station before or not on this band.
> Example: K1AA ZS1ABC -10. I don’t care about the first station, which I may 
> not ever copy. But since I am receiving ZS1ABC, it would be very nice to know 
> if I worked him before or not. If I did not, I will probably wait till he is 
> done with K1AA and then call him. Otherwise I have to open the adif file and 
> look there manually, which is a hassle.
> Most of the semi-rare stations hardly call CQ.
> 73, W0IZ “IZ”
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Suggestion regarding colors

2018-12-21 Thread I Z
Suggestion regarding colors.

I really love what was done in 2.0. Finally a great logger, many thanks!

I miss one enhancement though. When I see a message from one station to another 
(without CQ or my call), it is in white. It will be very nice if the second 
call in this message was highlighted, telling me if I worked this station 
before or not on this band.

Example: K1AA ZS1ABC -10. I don’t care about the first station, which I may not 
ever copy. But since I am receiving ZS1ABC, it would be very nice to know if I 
worked him before or not. If I did not, I will probably wait till he is done 
with K1AA and then call him. Otherwise I have to open the adif file and look 
there manually, which is a hassle.

Most of the semi-rare stations hardly call CQ.

73, W0IZ “IZ”

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion Hold TX Freq sticky

2018-12-17 Thread WB5JJJ
I did and Laurie said the same thing.  I gave it a try just now and it DOES
work.  I guess there was just a glitch in my configurations when the FT8 RU
was in progress.  That was the last time I did a configuration change.
That weekend, I had to restart JTAlert every time I went back to normal
FT8.

On Mon, Dec 17, 2018 at 11:31 AM Bill Somerville 
wrote:

> On 17/12/2018 17:19, WB5JJJ wrote:
> > If I do a configuration change, I have to stop and restart JTAlert as
> > it doesn't connect again automatically to the new configuration.
>
> Hi George,
>
> that's not right, several versions ago changes were made to the WSJT-X
> UDP protocol and to JTAlert to make configuration switching seamless.
> Have you raised this issue on the JTAlert support forum?
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


-- 
George Cotton, WB5JJJ
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion Hold TX Freq sticky

2018-12-17 Thread WB5JJJ
Sorry.  It seems to be working now.  I just tried it.  However, it did not
function properly when I tried the FT8 Round Up a couple weekend back.
This could have just been a glitch that day in my computer.

Thanks.

On Mon, Dec 17, 2018 at 2:25 PM Laurie, VK3AMA <_vk3a...@vkdxer.net> wrote:

>
> On 18/12/2018 4:19 am, WB5JJJ wrote:
> > If I do a configuration change, I have to stop and restart JTAlert as
> > it doesn't connect again automatically to the new configuration.
> > That's OK when I go to DXP configuration since I will probably stay
> > there for several hours.
>
> That should not be the case.
>
> JTAlert will automatically detect changes in WSJT-X when it changes
> config and automatically readjusts itself ensuring docking and UDP
> traffic monitoring for that WSJT-X instance continue. This has been
> inplace since JTAlert version  2.10.0 (21-JUL-2017). There have been no
> reports since then that this is not working.
>
> de Laurie VK3AMA
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


-- 
George Cotton, WB5JJJ
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion Hold TX Freq sticky

2018-12-17 Thread Laurie, VK3AMA



On 18/12/2018 4:19 am, WB5JJJ wrote:
If I do a configuration change, I have to stop and restart JTAlert as 
it doesn't connect again automatically to the new configuration. 
That's OK when I go to DXP configuration since I will probably stay 
there for several hours. 


That should not be the case.

JTAlert will automatically detect changes in WSJT-X when it changes 
config and automatically readjusts itself ensuring docking and UDP 
traffic monitoring for that WSJT-X instance continue. This has been 
inplace since JTAlert version  2.10.0 (21-JUL-2017). There have been no 
reports since then that this is not working.


de Laurie VK3AMA



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion Hold TX Freq sticky

2018-12-17 Thread WB5JJJ
No, I haven't.  It's not that big of a deal to me when I go to/from DXP.
It's just become habit, like checking the Hold box when going from MSK144
to FT8 - most times.


On Mon, Dec 17, 2018 at 11:31 AM Bill Somerville 
wrote:

> On 17/12/2018 17:19, WB5JJJ wrote:
> > If I do a configuration change, I have to stop and restart JTAlert as
> > it doesn't connect again automatically to the new configuration.
>
> Hi George,
>
> that's not right, several versions ago changes were made to the WSJT-X
> UDP protocol and to JTAlert to make configuration switching seamless.
> Have you raised this issue on the JTAlert support forum?
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


-- 
George Cotton, WB5JJJ
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion Hold TX Freq sticky

2018-12-17 Thread Bill Somerville

On 17/12/2018 17:19, WB5JJJ wrote:
If I do a configuration change, I have to stop and restart JTAlert as 
it doesn't connect again automatically to the new configuration.


Hi George,

that's not right, several versions ago changes were made to the WSJT-X 
UDP protocol and to JTAlert to make configuration switching seamless. 
Have you raised this issue on the JTAlert support forum?


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion Hold TX Freq sticky

2018-12-17 Thread WB5JJJ
Yes, I do that for DXP and such that require several changes.  But just to
change modes, there is a drop down for that already that's just 2 clicks
and everything continues along just fine.  Plus the Auto Seq and Call 1st
are sticky already.

If I do a configuration change, I have to stop and restart JTAlert as it
doesn't connect again automatically to the new configuration.  That's OK
when I go to DXP configuration since I will probably stay there for several
hours.

On Mon, Dec 17, 2018 at 11:07 AM Bill Somerville 
wrote:

> On 17/12/2018 15:21, WB5JJJ wrote:
>
> As I change from MSK144 to FT8, the vast majority of the time I forget to
> check the Hold Tx Freq box until I've moved off my clear spot.
>
> Could this box be made a sticky for either choice?
>
> Hi George,
>
> one easy option is to create a separate configuration for each mode
> ("Menu->Configurations"). it is normally easier to switch configurations
> (two mouse clicks) than to switch modes (two mouse clicks plus several more
> to change other options and settings necessary for the new mode and
> intended use).
>
> 73
> Bill
> G4WJS.
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


-- 
George Cotton, WB5JJJ
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Suggestion Hold TX Freq sticky

2018-12-17 Thread Bill Somerville

On 17/12/2018 15:21, WB5JJJ wrote:
As I change from MSK144 to FT8, the vast majority of the time I forget 
to check the Hold Tx Freq box until I've moved off my clear spot.


Could this box be made a sticky for either choice?


Hi George,

one easy option is to create a separate configuration for each mode 
("Menu->Configurations"). it is normally easier to switch configurations 
(two mouse clicks) than to switch modes (two mouse clicks plus several 
more to change other options and settings necessary for the new mode and 
intended use).


73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


  1   2   >