Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

[Gary McDuffie]

> On May 19, 2020, at 10:05, Neil Zampella  wrote:
> 
>  .. someone sending an RR73 does not expect a reply, the last 73 is a 
> courtesy from you the answering station. 

I certainly do, in order to let him know I got his RR73 and he needs to sen 
nothing else.  If I don’t send 73, I expect him to repeat it because I 
obviously didn’t get his RR73 in the first place.  When he gets my 73, he stops 
sending RR73, telling me that we are done!

Gary - AG0N

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

Re: [wsjt-devel] Configurations

[Joe Taylor]

Hi Ed,

On 5/19/2020 8:49 PM, j...@comcast.net N4II wrote:


Exactly.  The difficulty is, at present there's no way for the new user to
know what you've just written -- other than by receiving an email from you,
or one of the other cognoscenti -- since it's not documented anywhere.  (I
learned about Configuration operation from a WSJT-X beta tester -- a local
club member.)

Note that "There is no need to re-enter most of your setup details" is
exactly opposite the instruction given in the User Manual:  "Rename it as
desired, and then make all desired settings for that configuration."


I must disagree.  Good use of the Configuration capability is certainly 
not "exactly opposite the instruction given in the User Manual". 
Thousands of WSJT-X users have used what's in the User Guide, together 
with the on-screen menu options, to make effective and convenient use of 
Configurations.


If you find something in the User Guide instructions that is confusing 
or hard to follow, by all means tell us!  How else will we know?  At the 
time we wrote it, we thought is was clear enough.


-- 73, Joe, K1JT


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

Re: [wsjt-devel] Configurations

[jan0]

Joe,

Exactly.  The difficulty is, at present there's no way for the new user to
know what you've just written -- other than by receiving an email from you,
or one of the other cognoscenti -- since it's not documented anywhere.  (I
learned about Configuration operation from a WSJT-X beta tester -- a local
club member.)

Note that "There is no need to re-enter most of your setup details" is
exactly opposite the instruction given in the User Manual:  "Rename it as
desired, and then make all desired settings for that configuration."

If you need help with the writing or editing, I'd be happy to pitch in.

Ed N4II.

-Original Message-
From: Joe Taylor  
Sent: Tuesday, May 19, 2020 7:03 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] Configurations

Hi Ed,

Thanks for your comments, they are much appreciated.  A few comments inline
below.

On 5/19/2020 4:59 PM, j...@comcast.net N4II wrote:
> I sense a bit of, er, annoyance on behalf of WSJT-X developers with 
> the fact that relatively few users seem to be using Configurations -- 
> at least, the solution proposed to a fair number of user interface 
> issues raised here recently seems to be the same:  "Use Configurations".
> 
> When I first used the software, years ago, I didn't use configurations 
> for three reasons:
> 
> (1)  I couldn't find a list anywhere in the manual of just what "settings"
> were being "configured" (the File/Settings... settings?  To include 
> the main window check boxes?  Frequencies?  I still don't know the 
> complete list, even today);

Configurations save all settings that are normally restored after a program
restart, including which of the defined configurations is currently active.

> (2)  The manual didn't explain that I could avoid a lot of UI 
> annoyances by doing so, just that "[m]any users prefer to create and 
> use entries on the Configurations menu for switching between modes," 
> without saying why they have that preference; and
> 
> (3)  The Configurations menu picks didn't seem to do what I *thought* 
> I would want to do to start, which was to CREATE a configuration for 
> the settings I already had, followed by SAVE a configuration.  (I knew 
> I didn't want to CLONE anything . . . .)  If one has the manual at 
> hand, one has the single-sentence instruction to "Simply Clone the 
> Default entry, Rename it as desired, and then make all desired 
> settings for that configuration."  But even then, one has to make an 
> assumption on how the settings are saved, since the manual says 
> nothing about what one has to do to save a configuration (change modes or
bands?  Switch to a different configuration?
> Exit the program?).  Without an EDIT menu pick, it's also not at all 
> clear how one might modify a configuration to correct an error, which 
> makes experimenting with the feature a high-risk endeavor for new users.

CLONE is a much better description than CREATE for what happens.  You should
start with a working setup, configured the way you like it for some mode.
(If the only entry on your Configuration menu is "Default", you might want
to rename it as, say FT8.  Or Clone it, and rename the copy to FT8.)  There
is no need to re-enter most of your setup details.

After making clone, rename it to something sensible, switch to it, and then
change anything you want to be different in the new configuration.

Modifying a configuration requires nothing more than changing whatever you
want changed.  The active configuration is saved whenever you terminate the
program.  The next program restart will put you back where you were.

> Note that, when the user has finally found a collection of settings he 
> likes, as currently implemented the configurations feature requires 
> the user to go back to the default settings and then change the 
> settings back to the values he likes, *again*, in order to create the 
> configuration.  For most new users, all this does is break the 
> software, since they likely have not made a list in advance of all the
changes they've made from the default.

If you follow the instructions above, nonw of this is true.

> All of these points discourage the new user from experimenting with, 
> and eventually using, the Configuration feature, which eventually 
> leads to a lot of threads on this reflector that end with someone 
> writing, "Use configurations".
> 
> Anyway, if I'm wrong, and the user email load has not become annoying, 
> well, then, never mind, and I apologize for the bandwidth.  However, 
> if it has become annoying, I have two possible remedies, both leading 
> to increased usage of Configurations over time:
> 
> (1)  Change the UI of the Configurations menu to the more intuitive 
> CREATE / SAVE / EDIT model; or

See above.

> (2)  Add a few sentences to the WSJT-X documentation, at least 
> describing the benefits of using Configurations; how changes are 
> saved; the importance of using Configurations/Default/Clone **before** 
> changing settings; what 

Re: [wsjt-devel] Configurations

[Al]

"*One feature I never understood is the "Clone Into" "
Me neither...
But it would make more sense to me if it allowed entering a new name 
thus  "Clone" and "Rename" in one step ( "Clone to new name" ). Sort of 
like "create new using existing settings".


AL, K0VM

*
On 5/19/2020 6:30 PM, Hasan al-Basri wrote:
I use configurations for every mode as well as DXpeditions. They work 
great.


*One feature I never understood is the "Clone Into"*
*
*
I guessed that it might be a simultaneous Clone and Rename, but I've 
never used it.


The way I make new configurations is to start from a known perfectly 
working configuration (in my case FT8).


Start with FT8 Config
Configuration > FT8 > Clone
Cursor to: Configuration > FT8 - Copy
> Rename  (Test for my example)
Configuration > Test > Switch To

Now make all the changes for the configuration you are wanting to 
"save" or "create"the changes are applied immediately without any 
save command. Each change is applied as it is made. e.g. Mode, Radio , 
Audio, etc. etc.


Select the mode and any other settings you want "remembered" in the 
new configuration.


To use the new config: in this example MSK144.

Configuration > MSK144 > Switch To

I have separate configurations for:

FT8
160M JA   (no longer needed)
Default
F+H 9J2LA (Fox and Hound mode with only their known frequencies)
F+H EX0QR (ditto)
F+H TO7DL (ditto)
FT4
FreqCal
MSK144
WSPR

One can add or delete configs as they are no longer useful, as in the 
Fox and Hound DXpeditions shown above.


If there is a better or faster way to do this, let me know and I'll 
write all this up as a simple guide and post it to the main list.


73, N0AN
Hasan


On Tue, May 19, 2020 at 6:08 PM Joe Taylor > wrote:


Hi Ed,

Thanks for your comments, they are much appreciated.  A few comments
inline below.

On 5/19/2020 4:59 PM, j...@comcast.net 
N4II wrote:
> I sense a bit of, er, annoyance on behalf of WSJT-X developers
with the fact
> that relatively few users seem to be using Configurations -- at
least, the
> solution proposed to a fair number of user interface issues
raised here
> recently seems to be the same:  "Use Configurations".
>
> When I first used the software, years ago, I didn't use
configurations for
> three reasons:
>
> (1)  I couldn't find a list anywhere in the manual of just what
"settings"
> were being "configured" (the File/Settings... settings? To
include the main
> window check boxes?  Frequencies?  I still don't know the
complete list,
> even today);

Configurations save all settings that are normally restored after a
program restart, including which of the defined configurations is
currently active.

> (2)  The manual didn't explain that I could avoid a lot of UI
annoyances by
> doing so, just that "[m]any users prefer to create and use
entries on the
> Configurations menu for switching between modes," without saying
why they
> have that preference; and
>
> (3)  The Configurations menu picks didn't seem to do what I
*thought* I
> would want to do to start, which was to CREATE a configuration
for the
> settings I already had, followed by SAVE a configuration.  (I
knew I didn't
> want to CLONE anything . . . .)  If one has the manual at hand,
one has the
> single-sentence instruction to "Simply Clone the Default entry,
Rename it as
> desired, and then make all desired settings for that
configuration."  But
> even then, one has to make an assumption on how the settings are
saved,
> since the manual says nothing about what one has to do to save a
> configuration (change modes or bands?  Switch to a different
configuration?
> Exit the program?).  Without an EDIT menu pick, it's also not at
all clear
> how one might modify a configuration to correct an error, which
makes
> experimenting with the feature a high-risk endeavor for new users.

CLONE is a much better description than CREATE for what happens.  You
should start with a working setup, configured the way you like it for
some mode.  (If the only entry on your Configuration menu is
"Default",
you might want to rename it as, say FT8.  Or Clone it, and rename the
copy to FT8.)  There is no need to re-enter most of your setup
details.

After making clone, rename it to something sensible, switch to it,
and
then change anything you want to be different in the new
configuration.

Modifying a configuration requires nothing more than changing
whatever
you want changed.  The active configuration is saved whenever you
terminate the program.  The next program restart will put you back
where
you were.

> Note that, when the user has finally found a collection of
settings he
> likes, as currently 

Re: [wsjt-devel] Configurations

[Hasan al-Basri]

I use configurations for every mode as well as DXpeditions. They work
great.

*One feature I never understood is the "Clone Into"*

I guessed that it might be a simultaneous Clone and Rename, but I've never
used it.

The way I make new configurations is to start from a known perfectly
working configuration (in my case FT8).

Start with FT8 Config
Configuration > FT8 > Clone
Cursor to: Configuration > FT8 - Copy
> Rename  (Test for my example)
Configuration > Test > Switch To

Now make all the changes for the configuration you are wanting to "save" or
"create"the changes are applied immediately without any save command.
Each change is applied as it is made. e.g. Mode, Radio , Audio, etc. etc.

Select the mode and any other settings you want "remembered" in the new
configuration.

To use the new config: in this example MSK144.

Configuration > MSK144 > Switch To

I have separate configurations for:

FT8
160M JA   (no longer needed)
Default
F+H 9J2LA  (Fox and Hound mode with only their known frequencies)
F+H EX0QR (ditto)
F+H TO7DL (ditto)
FT4
FreqCal
MSK144
WSPR

One can add or delete configs as they are no longer useful, as in the Fox
and Hound DXpeditions shown above.

If there is a better or faster way to do this, let me know and I'll write
all this up as a simple guide and post it to the main list.

73, N0AN

Hasan


On Tue, May 19, 2020 at 6:08 PM Joe Taylor  wrote:

> Hi Ed,
>
> Thanks for your comments, they are much appreciated.  A few comments
> inline below.
>
> On 5/19/2020 4:59 PM, j...@comcast.net N4II wrote:
> > I sense a bit of, er, annoyance on behalf of WSJT-X developers with the
> fact
> > that relatively few users seem to be using Configurations -- at least,
> the
> > solution proposed to a fair number of user interface issues raised here
> > recently seems to be the same:  "Use Configurations".
> >
> > When I first used the software, years ago, I didn't use configurations
> for
> > three reasons:
> >
> > (1)  I couldn't find a list anywhere in the manual of just what
> "settings"
> > were being "configured" (the File/Settings... settings?  To include the
> main
> > window check boxes?  Frequencies?  I still don't know the complete list,
> > even today);
>
> Configurations save all settings that are normally restored after a
> program restart, including which of the defined configurations is
> currently active.
>
> > (2)  The manual didn't explain that I could avoid a lot of UI annoyances
> by
> > doing so, just that "[m]any users prefer to create and use entries on the
> > Configurations menu for switching between modes," without saying why they
> > have that preference; and
> >
> > (3)  The Configurations menu picks didn't seem to do what I *thought* I
> > would want to do to start, which was to CREATE a configuration for the
> > settings I already had, followed by SAVE a configuration.  (I knew I
> didn't
> > want to CLONE anything . . . .)  If one has the manual at hand, one has
> the
> > single-sentence instruction to "Simply Clone the Default entry, Rename
> it as
> > desired, and then make all desired settings for that configuration."  But
> > even then, one has to make an assumption on how the settings are saved,
> > since the manual says nothing about what one has to do to save a
> > configuration (change modes or bands?  Switch to a different
> configuration?
> > Exit the program?).  Without an EDIT menu pick, it's also not at all
> clear
> > how one might modify a configuration to correct an error, which makes
> > experimenting with the feature a high-risk endeavor for new users.
>
> CLONE is a much better description than CREATE for what happens.  You
> should start with a working setup, configured the way you like it for
> some mode.  (If the only entry on your Configuration menu is "Default",
> you might want to rename it as, say FT8.  Or Clone it, and rename the
> copy to FT8.)  There is no need to re-enter most of your setup details.
>
> After making clone, rename it to something sensible, switch to it, and
> then change anything you want to be different in the new configuration.
>
> Modifying a configuration requires nothing more than changing whatever
> you want changed.  The active configuration is saved whenever you
> terminate the program.  The next program restart will put you back where
> you were.
>
> > Note that, when the user has finally found a collection of settings he
> > likes, as currently implemented the configurations feature requires the
> user
> > to go back to the default settings and then change the settings back to
> the
> > values he likes, *again*, in order to create the configuration.  For most
> > new users, all this does is break the software, since they likely have
> not
> > made a list in advance of all the changes they've made from the default.
>
> If you follow the instructions above, nonw of this is true.
>
> > All of these points discourage the new user from experimenting with, and
> > eventually using, the Configuration feature, which 

Re: [wsjt-devel] Configurations

[Joe Taylor]

Hi Ed,

Thanks for your comments, they are much appreciated.  A few comments 
inline below.


On 5/19/2020 4:59 PM, j...@comcast.net N4II wrote:

I sense a bit of, er, annoyance on behalf of WSJT-X developers with the fact
that relatively few users seem to be using Configurations -- at least, the
solution proposed to a fair number of user interface issues raised here
recently seems to be the same:  "Use Configurations".

When I first used the software, years ago, I didn't use configurations for
three reasons:

(1)  I couldn't find a list anywhere in the manual of just what "settings"
were being "configured" (the File/Settings... settings?  To include the main
window check boxes?  Frequencies?  I still don't know the complete list,
even today);


Configurations save all settings that are normally restored after a 
program restart, including which of the defined configurations is 
currently active.



(2)  The manual didn't explain that I could avoid a lot of UI annoyances by
doing so, just that "[m]any users prefer to create and use entries on the
Configurations menu for switching between modes," without saying why they
have that preference; and

(3)  The Configurations menu picks didn't seem to do what I *thought* I
would want to do to start, which was to CREATE a configuration for the
settings I already had, followed by SAVE a configuration.  (I knew I didn't
want to CLONE anything . . . .)  If one has the manual at hand, one has the
single-sentence instruction to "Simply Clone the Default entry, Rename it as
desired, and then make all desired settings for that configuration."  But
even then, one has to make an assumption on how the settings are saved,
since the manual says nothing about what one has to do to save a
configuration (change modes or bands?  Switch to a different configuration?
Exit the program?).  Without an EDIT menu pick, it's also not at all clear
how one might modify a configuration to correct an error, which makes
experimenting with the feature a high-risk endeavor for new users.


CLONE is a much better description than CREATE for what happens.  You 
should start with a working setup, configured the way you like it for 
some mode.  (If the only entry on your Configuration menu is "Default", 
you might want to rename it as, say FT8.  Or Clone it, and rename the 
copy to FT8.)  There is no need to re-enter most of your setup details.


After making clone, rename it to something sensible, switch to it, and 
then change anything you want to be different in the new configuration.


Modifying a configuration requires nothing more than changing whatever 
you want changed.  The active configuration is saved whenever you 
terminate the program.  The next program restart will put you back where 
you were.



Note that, when the user has finally found a collection of settings he
likes, as currently implemented the configurations feature requires the user
to go back to the default settings and then change the settings back to the
values he likes, *again*, in order to create the configuration.  For most
new users, all this does is break the software, since they likely have not
made a list in advance of all the changes they've made from the default.


If you follow the instructions above, nonw of this is true.


All of these points discourage the new user from experimenting with, and
eventually using, the Configuration feature, which eventually leads to a lot
of threads on this reflector that end with someone writing, "Use
configurations".

Anyway, if I'm wrong, and the user email load has not become annoying, well,
then, never mind, and I apologize for the bandwidth.  However, if it has
become annoying, I have two possible remedies, both leading to increased
usage of Configurations over time:

(1)  Change the UI of the Configurations menu to the more intuitive CREATE /
SAVE / EDIT model; or


See above.


(2)  Add a few sentences to the WSJT-X documentation, at least describing
the benefits of using Configurations; how changes are saved; the importance
of using Configurations/Default/Clone **before** changing settings; what
functions the "Clone Into . . ." and "Reset" undocumented menu picks
perform; and providing a list of the parameters controlled by the
Configurations feature.


We'll try to make the User Guide instructions more detailed and more 
specific.


-- Joe, K1JT



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

[wsjt-devel] Configurations

[jan0]

I sense a bit of, er, annoyance on behalf of WSJT-X developers with the fact
that relatively few users seem to be using Configurations -- at least, the
solution proposed to a fair number of user interface issues raised here
recently seems to be the same:  "Use Configurations".

When I first used the software, years ago, I didn't use configurations for
three reasons:  

(1)  I couldn't find a list anywhere in the manual of just what "settings"
were being "configured" (the File/Settings... settings?  To include the main
window check boxes?  Frequencies?  I still don't know the complete list,
even today); 

(2)  The manual didn't explain that I could avoid a lot of UI annoyances by
doing so, just that "[m]any users prefer to create and use entries on the
Configurations menu for switching between modes," without saying why they
have that preference; and 

(3)  The Configurations menu picks didn't seem to do what I *thought* I
would want to do to start, which was to CREATE a configuration for the
settings I already had, followed by SAVE a configuration.  (I knew I didn't
want to CLONE anything . . . .)  If one has the manual at hand, one has the
single-sentence instruction to "Simply Clone the Default entry, Rename it as
desired, and then make all desired settings for that configuration."  But
even then, one has to make an assumption on how the settings are saved,
since the manual says nothing about what one has to do to save a
configuration (change modes or bands?  Switch to a different configuration?
Exit the program?).  Without an EDIT menu pick, it's also not at all clear
how one might modify a configuration to correct an error, which makes
experimenting with the feature a high-risk endeavor for new users.  

Note that, when the user has finally found a collection of settings he
likes, as currently implemented the configurations feature requires the user
to go back to the default settings and then change the settings back to the
values he likes, *again*, in order to create the configuration.  For most
new users, all this does is break the software, since they likely have not
made a list in advance of all the changes they've made from the default.  

All of these points discourage the new user from experimenting with, and
eventually using, the Configuration feature, which eventually leads to a lot
of threads on this reflector that end with someone writing, "Use
configurations".

Anyway, if I'm wrong, and the user email load has not become annoying, well,
then, never mind, and I apologize for the bandwidth.  However, if it has
become annoying, I have two possible remedies, both leading to increased
usage of Configurations over time:

(1)  Change the UI of the Configurations menu to the more intuitive CREATE /
SAVE / EDIT model; or

(2)  Add a few sentences to the WSJT-X documentation, at least describing
the benefits of using Configurations; how changes are saved; the importance
of using Configurations/Default/Clone **before** changing settings; what
functions the "Clone Into . . ." and "Reset" undocumented menu picks
perform; and providing a list of the parameters controlled by the
Configurations feature.

73,

Ed Callaway, N4II.

-Original Message-
From: Reino Talarmo  
Sent: Tuesday, May 19, 2020 2:04 PM
To: k...@arrl.net; 'WSJT software development'

Subject: Re: [wsjt-devel] Hold TX Frequency Default

>From: Jim Brown [mailto:k...@audiosystemsgroup.com] 
Sent: 19. toukokuuta 2020 20:25

>On 5/19/2020 6:35 AM, Joe Taylor wrote:
>> I operate on 6m a lot, using FT8, MSK144, and recently also FT4.  I 
> >never have the problem you describe.

>Can you please tell me how your setup prevents the problem I've described?
Is there a reason that you cannot >change the behavior I've described?

Jim,
>From User Guide: " Simply Clone the Default entry, Rename it as desired, and
then make all desired settings for that configuration. These settings will
be restored whenever you select that configuration. "
Each configuration behaves as if you have never used any other mode and so
none of the mode dependent defaults will not affect to other configurations.
It should implement your wish and need, just in another fully working
manner. 

73, Reino OH3mA


___
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] 2.2.0 rc1 - Allow Tx Frequency Changes While Transmitting

[Joe Taylor]

Steve --

On 5/19/2020 4:23 PM, Stephen VK3SIR wrote:


Are changes to the frequency of any audio stream than can be adjusted through the 
"Audio Tx Widget" also blocked during a Tx cycle?


As you could easily discover for yourself, such changes are not allowed 
during a transmission unless "Allow Tx freequency changes while 
transmitting" is checked.



[ If not, perhaps then they should be? I could foresee the simplest way to overcome this could be 
disabling the "Audio Tx Widget" for input during a Tx and while "Allow Tx Frequency 
Changes..." is not checked ]


Did you try??  That spin control IS disabled when you are transmitting.

-- Joe, K1JT


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

Re: [wsjt-devel] 2.2.0 rc1 - Allow Tx Frequency Changes While Transmitting

[Stephen VK3SIR]

Joe,

Thanks for the clarification. Also thanks for the notification for us all in 
posts to others that rc2 is imminent.

Thanks also for the reminder to everyone participating that we should head to 
the documentation before posting. I was aware of the documentation having been 
there first before posting (as all should do).

There is a subsequent possible observation and hence question that is thrown 
up; I'll try to put this as simply as possible as you have considerably more 
important tasks to perform:

Behaviours that I have observed do not necessarily relate solely to CAT-code 
sending - more the "offset" of the transmitted audio stream and its frequency 
to the transceiver.

Are changes to the frequency of any audio stream than can be adjusted through 
the "Audio Tx Widget" also blocked during a Tx cycle?

[ If not, perhaps then they should be? I could foresee the simplest way to 
overcome this could be disabling the "Audio Tx Widget" for input during a Tx 
and while "Allow Tx Frequency Changes..." is not checked ]

Thanks Joe to you and the core development team; GREAT work. RC candidate 
software release time can be soul destroying but is highly necessary ...

73 

Steve I
VK3VM / VK3SIR


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

Re: [wsjt-devel] Hold TX Frequency Default

[Reino Talarmo]

>From: Jim Brown [mailto:k...@audiosystemsgroup.com] 
Sent: 19. toukokuuta 2020 20:25

>On 5/19/2020 6:35 AM, Joe Taylor wrote:
>> I operate on 6m a lot, using FT8, MSK144, and recently also FT4.  I 
> >never have the problem you describe.

>Can you please tell me how your setup prevents the problem I've described? Is 
>there a reason that you cannot >change the behavior I've described?

Jim,
>From User Guide: " Simply Clone the Default entry, Rename it as desired, and 
>then make all desired settings for that configuration. These settings will be 
>restored whenever you select that configuration. "
Each configuration behaves as if you have never used any other mode and so none 
of the mode dependent defaults will not affect to other configurations. It 
should implement your wish and need, just in another fully working manner. 

73, Reino OH3mA


___
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] Incorrect decodes

[Reino Talarmo]

The third line is an EU VHF report message with target call, sender's call,
both hashed and not know in your decoder, report with serial number and six
digit locator. Well, it is a false positive in any case.

73, Reino OH3mA

 

From: K2DBK-WSJT [mailto:k2dbk+w...@k2dbk.com] 
Sent: 18. toukokuuta 2020 1:08
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Incorrect decodes

 

I've seen some odd decodes in the new version, and I'm attaching a couple of
.wav files from a few minutes ago that when replayed reproduce what I saw.

 



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

Re: [wsjt-devel] Hold TX Frequency Default

[Jim Brown]

On 5/19/2020 6:35 AM, Joe Taylor wrote:
I operate on 6m a lot, using FT8, MSK144, and recently also FT4.  I 
never have the problem you describe.


Can you please tell me how your setup prevents the problem I've 
described? Is there a reason that you cannot change the behavior I've 
described?


73, Jim K9YC


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

Re: [wsjt-devel] wsjt-devel Digest, Vol 75, Issue 95

[Al Pawlowski]

If so, maybe WSJTx should only do the tx5 message atuomatically when it is not 
set to the default .


Al Pawlowski, K6AVP
Los Osos, CA USA



> On May 19, 2020, at 09:11, wsjt-devel-requ...@lists.sourceforge.net wrote:
> 
> Date: Tue, 19 May 2020 12:05:27 -0400
> From: Neil Zampella mailto:ne...@techie.com>>
> To: wsjt-devel@lists.sourceforge.net 
> Subject: Re: [wsjt-devel] Clicking on RR73 produced wrong TX response
>   msg
> 
> FWIW .. someone sending an RR73 does not expect a reply…..

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

Re: [wsjt-devel] wsjt-devel Digest, Vol 75, Issue 94

[Al Pawlowski]

Would it not be good if double clicking any received message sent the next 
sequenced message?

What I do (pretty automatically) now when I get to the end of a QSO cycle is 
select RR73, or 73 (as appropriate), enable tx and wait with my mouse cursor 
over the disable tx button to kill a second ending tx if the other person does 
not repeat his.

BTW, I like that WSJTx will now (since v2.1.2, I think) delay disabling tx of 
this ending repeat for three times automatically.

Al Pawlowski, K6AVP
Los Osos, CA USA



> On May 19, 2020, at 08:07, wsjt-devel-requ...@lists.sourceforge.net wrote:
> 
> Date: Tue, 19 May 2020 14:06:51 + (UTC)
> From: Black Michael mailto:mdblac...@yahoo.com>>
> To: WSJT software development  >,
>   Rich Zwirko - K1HTV mailto:k1...@comcast.net>>
> Subject: Re: [wsjt-devel] Clicking on RR73 produced wrong TX response
>   msg
> 
> What he's describing has happened to me numerous times...
> You send 73 and move on to another QSO...then the last QSO sends RR73 again 
> so you have to double-click it.
> Seems to me double-clicking an RR73 that has your callsign in it should 
> automatically go to Tx 5 instead of TX3.
> de Mike W9MDB

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

Re: [wsjt-devel] Clicking on RR73 produced wrong TX response msg

[Black Michael via wsjt-devel]

Yeah, I know, but a good number do it anyways...
Mike

 

On Tuesday, May 19, 2020, 11:09:47 AM CDT, Neil Zampella  
wrote:  
 
  
FWIW .. someone sending an RR73 does not expect a reply, the last 73 is a 
courtesy from you the answering station.    If someone keeps sending RR73, they 
don't understand the use of that response.
 
 Neil, KN3ILZ
 
 On 5/19/2020 10:06 AM, Black Michael wrote:
  
 
  What he's describing has happened to me numerous times... 
  You send 73 and move on to another QSO...then the last QSO sends RR73 again 
so you have to double-click it. 
  Seems to me double-clicking an RR73 that has your callsign in it should 
automatically go to Tx 5 instead of TX3. 
  de Mike W9MDB  

  
  On Tuesday, May 19, 2020, 09:02:07 AM CDT, Joe Taylor 
 wrote:  
  
   Hi Rich,
 
 On 5/18/2020 20:16, Rich Zwirko - K1HTV wrote:
 
 > *Using 2.2.0-rc1, when completing an FT8 QSO and an RR73 is received I 
 > send a 73. However if the station doesn't receive my '73' message, he 
 > re-sends his TX4 RR73 message. When I double click on his first RR73 
 > line, instead of sending me sending the correct Tx5 '73' message,  
 > WSJT-X sends the incorrect response of a  'Tx3' message of calls and 
 > roger report. *
 > *
 > *Is this a bug or a 'feature' to keep us on our toes?*
 
 Think of it as a 'feature'.  The program's logic is that you sent 73, so 
 the QSO is over as far as you're concerned.  If you want the program to 
 send 73 again upon receipt of another RR73 from the same QSO partner, 
 toggle *Enable Tx* to red, again, during the Rx interval after you send 73.
 
     -- Joe, K1JT 
 
 
 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  

|  | Virus-free. 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] Clicking on RR73 produced wrong TX response msg

[Neil Zampella]

FWIW .. someone sending an RR73 does not expect a reply, the last 73 is
a courtesy from you the answering station.    If someone keeps sending
RR73, they don't understand the use of that response.

Neil, KN3ILZ

On 5/19/2020 10:06 AM, Black Michael wrote:

What he's describing has happened to me numerous times...

You send 73 and move on to another QSO...then the last QSO sends RR73
again so you have to double-click it.

Seems to me double-clicking an RR73 that has your callsign in it
should automatically go to Tx 5 instead of TX3.

de Mike W9MDB



On Tuesday, May 19, 2020, 09:02:07 AM CDT, Joe Taylor
 wrote:


Hi Rich,

On 5/18/2020 20:16, Rich Zwirko - K1HTV wrote:

> *Using 2.2.0-rc1, when completing an FT8 QSO and an RR73 is received I
> send a 73. However if the station doesn't receive my '73' message, he
> re-sends his TX4 RR73 message. When I double click on his first RR73
> line, instead of sending me sending the correct Tx5 '73' message,
> WSJT-X sends the incorrect response of a  'Tx3' message of calls and
> roger report. *
> *
> *Is this a bug or a 'feature' to keep us on our toes?*

Think of it as a 'feature'.  The program's logic is that you sent 73, so
the QSO is over as far as you're concerned.  If you want the program to
send 73 again upon receipt of another RR73 from the same QSO partner,
toggle *Enable Tx* to red, again, during the Rx interval after you
send 73.

    -- Joe, K1JT



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



--
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] Clicking on RR73 produced wrong TX response msg

[Black Michael via wsjt-devel]

What he's describing has happened to me numerous times...
You send 73 and move on to another QSO...then the last QSO sends RR73 again so 
you have to double-click it.
Seems to me double-clicking an RR73 that has your callsign in it should 
automatically go to Tx 5 instead of TX3.
de Mike W9MDB
 

On Tuesday, May 19, 2020, 09:02:07 AM CDT, Joe Taylor  
wrote:  
 
 Hi Rich,

On 5/18/2020 20:16, Rich Zwirko - K1HTV wrote:

> *Using 2.2.0-rc1, when completing an FT8 QSO and an RR73 is received I 
> send a 73. However if the station doesn't receive my '73' message, he 
> re-sends his TX4 RR73 message. When I double click on his first RR73 
> line, instead of sending me sending the correct Tx5 '73' message,  
> WSJT-X sends the incorrect response of a  'Tx3' message of calls and 
> roger report. *
> *
> *Is this a bug or a 'feature' to keep us on our toes?*

Think of it as a 'feature'.  The program's logic is that you sent 73, so 
the QSO is over as far as you're concerned.  If you want the program to 
send 73 again upon receipt of another RR73 from the same QSO partner, 
toggle *Enable Tx* to red, again, during the Rx interval after you send 73.

    -- Joe, K1JT


___
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] Clicking on RR73 produced wrong TX response msg

[Joe Taylor]

Hi Rich,

On 5/18/2020 20:16, Rich Zwirko - K1HTV wrote:

*Using 2.2.0-rc1, when completing an FT8 QSO and an RR73 is received I 
send a 73. However if the station doesn't receive my '73' message, he 
re-sends his TX4 RR73 message. When I double click on his first RR73 
line, instead of sending me sending the correct Tx5 '73' message,  
WSJT-X sends the incorrect response of a  'Tx3' message of calls and 
roger report. *

*
*Is this a bug or a 'feature' to keep us on our toes?*


Think of it as a 'feature'.  The program's logic is that you sent 73, so 
the QSO is over as far as you're concerned.  If you want the program to 
send 73 again upon receipt of another RR73 from the same QSO partner, 
toggle *Enable Tx* to red, again, during the Rx interval after you send 73.


-- Joe, K1JT


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

Re: [wsjt-devel] 2.2.0 rc1 - Allow Tx Frequency Changes While Transmitting

[Joe Taylor]

Steve --

On 5/19/2020 00:15, Stephen VK3SIR wrote:


Does the "Allow Tx Frequency Changes While Transmitting" (File/Settings/General 
Tab) when not-checked function as intended?


Yes.  When this option is not checked, frequency-changing CAT commands 
will not be sent to your radio.



My expectation would be that if disabled that any frequency changes observed in 
the Tx spin-box widget on the Main Window should be delayed until the end of 
the cycle and should not be immediate (or perhaps these boxes disabled until 
the end of the cycle) under this circumstance.


Here's the User Guide statement about the option "Allow Tx frequency 
changes while transmitting".  You'll find it here, in Section 8.1:


http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.2.0-rc1.html#VHF_SETUP

"If you will use automatic Doppler tracking and your radio accepts 
frequency-setting commands while transmitting, check *Allow Tx frequency 
changes while transmitting*. Transceivers known to permit such changes 
include the IC-735, IC-756 Pro II, IC-910-H, FT-847, TS-590S, TS-590SG, 
TS-2000 (with Rev 9 or later firmware upgrade), Flex 1500 and 5000, 
HPSDR, Anan-10, Anan-100, and KX3. To gain full benefit of Doppler 
tracking your radio should allow frequency changes under CAT control in 
1 Hz steps."


-- 73, Joe, K1JT


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

Re: [wsjt-devel] Hold TX Frequency Default

[Joe Taylor]

Hi Jim,

On 5/19/2020 01:20, Jim Brown K9YC wrote:

I have made this "feature request before, and hoped to see it in this 
beta, but it's missing. My request is that either 1) WSJT-X remember my 
setting of Hold TX Frequency or 2) make Hold TX Frequency the default. I 
am continually bitten by this when I switch back and forth between the 
slow modes and fast modes on 6M. I ALWAYS want it ON, but when I return 
to FT8 from MSK144 or ISCAT, it's ALWAYS turned off and set to 1500 Hz.


I operate on 6m a lot, using FT8, MSK144, and recently also FT4.  I 
never have the problem you describe.


Is there a reason why you choose not to set up and use a different 
Configuration for each mode?  Configurations save all your settings. 
Switching modes from the Mode menu necessarily sets some parameters to 
the default for that mode.


I'm THRILLED with the three-stage decode process. It speeds up general 
operation a lot, because I now nearly always have time to make TX 
decisions in time to start at the beginning of the TX period.


I'm experiencing at least as many bad decodes as before, maybe more, and 
they seem to come from that last third decode operation. Not 
complaining, just observing.


You will soon find that RC2, the second release candidate for v2.2.0, 
produces far fewer false decodes than RC1.


-- 73, Joe, K1JT




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

Re: [wsjt-devel] 2.2.0 rc1 - Allow Tx Frequency Changes While Transmitting

[Bill Somerville]

On 19/05/2020 05:15, Stephen VK3SIR wrote:

Hi Folks,

Does the "Allow Tx Frequency Changes While Transmitting" (File/Settings/General 
Tab) when not-checked function as intended?

My expectation would be that if disabled that any frequency changes observed in 
the Tx spin-box widget on the Main Window should be delayed until the end of 
the cycle and should not be immediate (or perhaps these boxes disabled until 
the end of the cycle) under this circumstance.

I just performed a slight frequency change on 20m while transmitting and noted that in 
the "Rx Frequency Window" that a frequency change during the Tx cycle from 851 
to 899 to 900 Hz was noted.

035400  Tx   851 ~  CQ VK3VM QF11
035405  Tx   851 ~  CQ VK3VM QF11
035408  Tx   851 ~  CQ VK3VM QF11
035410  Tx   899 ~  CQ VK3VM QF11
035430  Tx   900 ~  CQ VK3VM QF11
035500  Tx   900 ~  CQ VK3VM QF11

I have also observed some frequency shifts on waterfalls that may or may not be 
related to this.

I cannot recall any inquiry on this so far and if I have missed it my apologies.

73

Steve I
VK3VM / VK3SIR


Hi Steve,

that option is intended for rigs that do not accept CAT QSY commands 
while transmitting, e.g. the Yaesu FT-817/857/897(D) and others. If no 
"Settings->Radio->Split Operating" options are selected then you can 
change the Tx audio offset at will since no QSY commands will be sent to 
the rig.


73
Bill
G4WJS.



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

Re: [wsjt-devel] Hold TX Frequency Default

[Peter Sumner]

Hi Jim,
 you should consider using different configurations for the modes and try
to not use the MODE selector when possible, using a Configuration for each
mode will return you to exactly where you were before on that mode.  I use
it exclusively on the three computers here (2 are PI's) and find it works a
treat.  It is just a small mind set change for changing modes to use the
Configuration menu, start with one sample setup like you use for FT8 and
Clone it, rename the clone to be MSK144, switch to that mode and alter the
settings to how you like it, even the waterfall changes are remembered.
You may be pleasantly surprised how well it works for you.

Regards,
Peter, vk5pj

On Tue, May 19, 2020 at 2:54 PM Jim Brown 
wrote:

> Joe, Bill, and Steve,
>
> I have made this "feature request before, and hoped to see it in this
> beta, but it's missing. My request is that either 1) WSJT-X remember my
> setting of Hold TX Frequency or 2) make Hold TX Frequency the default. I
> am continually bitten by this when I switch back and forth between the
> slow modes and fast modes on 6M. I ALWAYS want it ON, but when I return
> to FT8 from MSK144 or ISCAT, it's ALWAYS turned off and set to 1500 Hz.
>
> I'm THRILLED with the three-stage decode process. It speeds up general
> operation a lot, because I now nearly always have time to make TX
> decisions in time to start at the beginning of the TX period.
>
> I'm experiencing at least as many bad decodes as before, maybe more, and
> they seem to come from that last third decode operation. Not
> complaining, just observing.
>
> Thanks and 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