date:20170102

Re: [wsjt-devel] Ideas for Development

2017-01-02 Thread Bill ND0B

Joe,

Thank you for your response, sorry to have wasted your time.

Comments inserted below. 

73 de Bill ND0B



-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: Monday, January 2, 2017 1:57 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] Ideas for Development

Hi Bill (ND0B) and all,

I've been away most of the time since your post, and just now finding time
to respond.  You gave us a long list of ideas, with no evident
prioritization.  You mentioned to me that you were "in the process of
learning C++ and QT by immersion".  Of course you're the best judge of your
status in that respect, but keep in mind that it may take some time to get
up to speed.

I am well aware of that, in fact I was pretty much quoting back what you
suggested I do a couple of years ago when my efforts were focused on WSJT
and you suggested I might want to move over to WSJTx.   I pointed out that
while I do a lot of C I would be new to C++ and to QT.   You suggested I do
what you did and just start doing it.   While that email is archived I would
be happy to dig it up.   

I deliberately did not put priorities on these as they are self imposed
tasks and as such would be tackled as I feel comfortable doing them and as
such represent a range of difficulties.   

A few specific comments:

> 1. Add situational awareness to the auto sequencer. Currently if the 
> auto sequencer detects any message it will move to the next one in the 
> sequence even if it does not make sense to do so. I plan to add logic 
> (which is in the one I added to ISCAT in WSJT) so if you are currently 
> sending TX1 you will move forward if RXing a TX1 or a TX2, etc.

Many have been using the auto-sequencing with MSK144 and have not found it
to do things that "do not make sense".  A couple of things that I might look
at (but do not consider to be extremely important) are these:

I brought this one up because I have seen a couple of times where the other
station was not well behaved and jumped ahead in the sequence.   When this
happens, and it could well have been fixed by now, the auto sequencer does
not ignore the message but rather jumps ahead to the next one in the
sequence.   

K1JT ND0B EN07
ND0B K1JT +02
K1JT ND0B RRR   // Bad behavior on my behalf.
ND0B K1JT 73 //  At least in the past the auto sequencer
responded to the message, not the situation.

ND0B K1JT +02  // What the auto sequencer should respond with to an
out of sequence message.

a) If already sending a report, i.e. Tx2 or Tx3, allow it to replace the
numerical report by a higher number but not with a lower one.

b) If already sending 73, do not allow a "genStdMsgs()" call to overwrite an
entered-by-hand message that I have typed into one of the Tx# fields.

I concur both of these would be good fixes.  

> 2. Include MSK144 in the logic for "send 5 73's after last RRR 
> received" logic. This appears to be in place for some (one, ISCAT??) 
> of the other protocols and it makes sense for it to be on MSK. I find 
> myself clicking enable TX several times to make sure this effectively 
> happens. I believe this should be enabled by the Disable TX after 
> sending 73 click box.

> 3. Make the number of 73s sent after last RRR received configurable. 
> It is currently the magic number 5 for the protocol(s) it is 
> implemented for.

Motivation for these two seems weak to me.  Why are you "clicking enable TX
several times"?  I never do that.  I don't want the program to determine for
me how many times to send 73; I'm quite capable of doing that myself.

We're not attempting to make an automated QSO machine.

I concur but an automated QSO machine implies much more than what I am
suggesting here.I am not talking about automated responses to CQs and
automatic logging, I am simply suggesting an improvement in how a QSO ends
under the auto sequencer.   Currently there are two choices, send 73 once
and stop or send 73 until stopped.   I put a lot of thought and work based
on operational experience with this end game into the ISCAT auto sequencer I
put in WSJT and had it working what most considered fairly well.   It is a
situation that does not have an ideal solution regardless if it is fully
under human control or if it is automated.   My suggestion is to allow an in
between of the two current scenarios that would allow the auto sequencer to
end most contacts gracefully. 

> 4. Implement Hamlib rotor control for Az and Hot A: / B: A left click 
> on either of these would move the rotor to that direction a. Side 
> project: Add Idiom Press and Green Heron controllers into Hamlib. Both 
> of these are popular and an offshoot of the Hygain controller protocol 
> that inexplicably did not have a facility for getting the current 
> position from the controller. Both of these controllers added commands 
> to position query but unfortunately is a subtly different manner.

> 5. Add a toggle (on right

Re: [wsjt-devel] MSK144 Timing Flag?

2017-01-02 Thread Joe Taylor

On 1/2/2017 1:33 PM, Gordon Higgins wrote:
> What is the meaning of the tail nombers in msk155
> ie g3pxt dk9wi +01 1 8 -0.8 

The first number is described in the WSJT-X User Guide, in a table found 
here:

http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.7.0.html#_decoded_lines

Evidently you are using an unreleased WSJT-X built from a code revision 
later than r7405.  As stated here many times, this is generally unwise 
unless you have a specific reason to do so.  The additional end-of line 
numbers are diagnostic aids to our development process.

-- 73, Joe, K1JT

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Bill Somerville


On 02/01/2017 19:54, Black Michael wrote:

Here it is with the radius zeroed.
The radius did look a bit strange just being on the bottom.


Hi Mike,

that rather misses the point. The non-customized native windows control 
(somewhat version dependent) for a progress bar doesn't have radii at 
the corners, it looks like this:


with your patch it, like the Mac OS X version gets custom drawn by Qt 
like this:


so just as bad as on Mac.

73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Ideas for Development

2017-01-02 Thread Joe Taylor

Hi Bill (ND0B) and all,

I've been away most of the time since your post, and just now finding 
time to respond.  You gave us a long list of ideas, with no evident 
prioritization.  You mentioned to me that you were "in the process of 
learning C++ and QT by immersion".  Of course you're the best judge of 
your status in that respect, but keep in mind that it may take some time 
to get up to speed.

A few specific comments:

> 1. Add situational awareness to the auto sequencer. Currently
> if the auto sequencer detects any message it will move to the next one
> in the sequence even if it does not make sense to do so. I plan to
> add logic (which is in the one I added to ISCAT in WSJT) so if you are
> currently sending TX1 you will move forward if RXing a TX1 or a TX2, etc.

Many have been using the auto-sequencing with MSK144 and have not found 
it to do things that "do not make sense".  A couple of things that I 
might look at (but do not consider to be extremely important) are these:

a) If already sending a report, i.e. Tx2 or Tx3, allow it to replace the 
numerical report by a higher number but not with a lower one.

b) If already sending 73, do not allow a "genStdMsgs()" call to 
overwrite an entered-by-hand message that I have typed into one of the 
Tx# fields.

> 2. Include MSK144 in the logic for “send 5 73’s after last RRR
> received” logic. This appears to be in place for some (one, ISCAT??)
> of the other protocols and it makes sense for it to be on MSK. I find
> myself clicking enable TX several times to make sure this effectively
> happens. I believe this should be enabled by the Disable TX after
> sending 73 click box.

> 3. Make the number of 73s sent after last RRR received
> configurable. It is currently the magic number 5 for the protocol(s)
> it is implemented for.

Motivation for these two seems weak to me.  Why are you "clicking enable 
TX several times"?  I never do that.  I don't want the program to 
determine for me how many times to send 73; I'm quite capable of doing 
that myself.

We're not attempting to make an automated QSO machine.

> 4. Implement Hamlib rotor control for Az and Hot A: / B: A left
> click on either of these would move the rotor to that direction
> a. Side project: Add Idiom Press and Green Heron controllers
> into Hamlib. Both of these are popular and an offshoot of the Hygain
> controller protocol that inexplicably did not have a facility for
> getting the current position from the controller. Both of these
> controllers added commands to position query but unfortunately is a
> subtly different manner.

> 5. Add a toggle (on right mouse click) between Hot A: and Hot B
> While it usually displays the right one to use sometimes the radiant is
> obviously on the other side. While the mental gymnastics is easy
> enough to convert it would be nice to just click… and then click again
> to move the rotor.

OK, I guess, but again the motivation for adding rotor control to WSJT-X 
seems pretty weak to me.  Few users have an antenna for 6 or 2 meters 
with beamwidth small enough to be able to tell the difference between 
pointing at Hot A, Hot B, or the direct path.  It a tough call for me to 
see any difference, even with my wide-spaced 4 x 2MXP28 array on 2m.

> 6. Make entry of DX Grid so it is not so persnickety. This is a
> simple one trimming leading or trailing white space off. I find that
> my usual way of getting ahold of the grid, copying it out of PJClient,
> often has a leading or lagging space, the entry box does not like this.

I've never found grid entry to be difficult.  By all means, make it 
better if you see how.

> 7. Add 60s sequences to the fast modes. I know you have had a
> discussion with Ged W8BYA about this, he would like it so he can
> operate diametrically opposed to some local high power EME stations,
> I find that
> a reasonable request. I would like it because I am planning some long
> term (24+ hour) runs and would like to increase the active time. With
> 15 second sequences approximately 4 seconds out of 60 are spent in
> changeover, with 30 second sequences 2 out of 60 and with 60 second
> sequences this is 1 second out of 60. This small but appreciable
> difference help up the chances of success on a long term run that is
> dependent on low probability events. Not by much but enough to make
> the effort worthwhile.

Nearly everyone uses 15s sequences, and it's a big advantage to have a 
standard.  We allowed for longer and shorter ones, mainly for testing 
and specialty purposes.

One minute sequences?  Surely the difference between a "sequencing time 
loss" of 1/60 or 2/60 is not worth a big programming effort.  For your 
special 24-hour run, why not just extend it by another few minutes, to 
make up the difference?

> 8. If it will fit add a “what the heck I am doing” letter to the
> CQ message for MSK144. This would be a single letter representing the
> T/R period, SH status and Contest Mode status. Clicking on this in an
> RXed

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Black Michael

Here it is with the radius zeroed.The radius did look a bit strange just being 
on the bottom.
https://www.dropbox.com/s/q7t70yxdvrouyms/progressbar2.patch?dl=1

de Mike W9MDB

  From: Bill Somerville 
 To: wsjt-devel@lists.sourceforge.net 
 Sent: Monday, January 2, 2017 1:38 PM
 Subject: Re: [wsjt-devel] Disable Tx after RRR/73

 On 02/01/2017 18:15, Bill Somerville wrote:

Not just the images but the public functions, nothing to change color. 
Thanks for the correction, much appreciated,,
 HI Bill, you can certainly change the rendering of any Qt widget either by 
using a sytle sheet or delegate if supported or a custom paint function but as 
soon as you do that you disallow the use of the native version. This then ends 
up looking quite nasty when you end up with a combination of native and custom 
widgets. It works better with some than others but progress bars are definitely 
ones that look bad in custom form. 
 Hi again Bill, just to reiterate, here is an example of what happens when the 
native control is not able to be used due to customizations on Mac OS X:  The 
"Monitor" button is coloured using a style sheet which is enough to cause a 
switch to  Qt drawn custom widget rather than the standard Mac OS X controls 
that get used if the defaults are left alone. Here is the rendering of progress 
bar using the standard control:  and here it is as per Mike's patch below:  
maybe not too bad but it is too big to fit in the height of the status bar so 
is a bit mangled. Other examples where custom controls do not work well are 
these TxN buttons that fail to scale with the caption font size:  By far the 
best rule for UI portability is let the standard layouts do their job and only 
customize when absolutely necessary.
  73
 Bill
 G4WJS.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

   --
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] MSK144 Timing Flag?

2017-01-02 Thread Bill ND0B

Bill,

 

Got it.   I know where to look now for the exact how of what I want to do.


 

Much appreciated!

 

73 de Bill ND0B

 

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Monday, January 2, 2017 12:20 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] MSK144 Timing Flag?

 

On 02/01/2017 17:57, Bill ND0B wrote:

I suspected something like this but am still looking into it / getting up to
speed.This was why I specifically suggest this apply only to the CQ
message as being the shortest, it might, take on something like this and did
coach it with "if it will fit"   This will be an excellent opportunity for
me to learn the ins and outs of packing in this new protocol. 

HI Bill,

the CQ message does have an obvious set of permutations that are not used.
Joe recently added the interpretations of E9AA thru E9ZZ as CQ AA thru CQ ZZ
on the assumption that the E9 prefix will never be issued. I think this
leaves E9AAA thru E9ZZZ still spare and available for interpretation, which
is 26x26x26 permutations. The only thing I am not sure of is if that is
still true if the caller has a type 2 or type 3 compound callsign.

>From the above you should see that the CQ message is just a "
 " message with special meanings being applied to certain
 and  combinations. "  " messages
use "  " with spare space in the  component
encoding to signify reports etc.

I hope I am right here but I think I have the general principles correct.

73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Bill Somerville


On 02/01/2017 18:05, Bill ND0B wrote:
Not just the images but the public functions, nothing to change color. 
Thanks for the correction, much appreciated,,


HI Bill,

you can certainly change the rendering of any Qt widget either by using 
a sytle sheet or delegate if supported or a custom paint function but as 
soon as you do that you disallow the use of the native version. This 
then ends up looking quite nasty when you end up with a combination of 
native and custom widgets. It works better with some than others but 
progress bars are definitely ones that look bad in custom form.


73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread ANDY DURBIN

" You are trying to force your view of usage which seems  unreasonable given 
there is a valid alternative."


I'm not trying to force anything.   The user interface is misleading because of 
the nomenclature that is used on the button, in the option, and in the tool 
tips.  The functionality  is correctly described in the help file.  It that is 
considered satisfactory there is nothing more to be said.


73,

Andy k3wyc



From: wsjt-devel-requ...@lists.sourceforge.net 

Sent: Monday, January 2, 2017 10:41 AM
To: wsjt-devel@lists.sourceforge.net
Subject: wsjt-devel Digest, Vol 35, Issue 15

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
wsjt-devel Info Page - 
SourceForge
lists.sourceforge.net
Your email address: Your name (optional): You may enter a privacy password 
below. This provides only mild security, but should prevent others from messing 
with ...



or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."


Today's Topics:

   1. Re: Disable Tx after RRR/73 (Bill Somerville)
   2. Re: Disable Tx after RRR/73 (Black Michael)


--

Message: 1
Date: Mon, 2 Jan 2017 17:39:43 +
From: Bill Somerville 
Subject: Re: [wsjt-devel] Disable Tx after RRR/73
To: wsjt-devel@lists.sourceforge.net
Message-ID: <7843a265-ec44-83d5-5c15-a5559eaa0...@classdesign.com>
Content-Type: text/plain; charset="windows-1252"

Hi Andy,

comments in line below.

On 02/01/2017 17:22, ANDY DURBIN wrote:
>
> There was always a Halt TX button but, with the r3673 functionality of
> Enable TX, I don't think it was needed.  Removing it would not be
>  reversion.
>
The internal implementation is an auto transmit enable, having it also
halt transmit immediately has to be an add on to that. Having a halt tx
immediately avoids overloading the function of the buttons, that is a
good thing because it allows different operators to use the interface as
they wish. You are trying to force your view of usage which seems
unreasonable given there is a valid alternative. Client "Halt Tx" if you
want immediate stop and click "Enable Tx" if you wish to complete the
message that is currently running.
>
>
> The first step would be to understand why the change from "TX Enable"
> to "Next Enable" was made.  I see no advantage but I only use JT9 and
> JT65 on HF and 6m.   I assume there was some advantage in other
> operating environments.
>
No such change has happened. What has happened is that the overloaded
feature of having "Enable Tx" turn off auto transmission *and* having
"Enable Tx" stop immediately has been simplified - without any loss of
functionality *because the "Halt Tx" button already does the latter"*.
>
>
> If the arguments for the change are still valid then, obviously, it
> won't be changed back to the simple TX Enable that it used to be in
> r3673 and earlier.  If that is the case then I hope the description
> inconsistencies that I listed earlier will be addressed.
>
The arguments were for simplification without loss of functionality. Joe
has already cited the documentation that clearly states the current
functionality is for "Enable Tx" OFF only disables auto transmit, it
does not discard the current message if transmission has started, "Halt
Tx" does that.
>
>
> Moving to brainstorming mode - The color red seems inappropriate for
> the indicator for either functionality.   If tri-state is an option
> I'd suggest no fill for no TX possible (no change),  Green for auto
> enable -  this message and the next one will be sent, and Amber for
> this message is the last one that will be sent.  Colors would change
>  at the end of the TX period or when this button or Halt TX was pressed.
>
Statefull push buttons are generally considered as bad design, the other
button types like radio buttons and check boxes are designed for exactly
that purpose. Having said that most UI widget tool kits offer checkable
push buttons and they can be useful where they are used a lot and a
check box might be considered too small for quick operation. The
overriding design criteria should reflect the chosen button semantics
and in that respect we have it wrong as push button controls are meant
to mimic momentary push buttons that immediately start something. Going
to tri-state semantics is moving way too far from that behaviour IMHO.

73
Bill
G4WJS.

-- next part --
An HTML attachment was scrubbed...

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Bill ND0B

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Monday, January 2, 2017 12:00 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Disable Tx after RRR/73

On 02/01/2017 17:55, Bill ND0B wrote:

Even just color? 

Hi Bill,

Yes I'm afraid so. See the images here for examples:
http://doc.qt.io/qt-5/qprogressbar.html#details

73
Bill
G4WJS.

Not just the images but the public functions, nothing to change color.
Thanks for the correction, much appreciated,,

73 de Bill ND0B

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Bill ND0B

Mike,

 

I am kind of the “red” means transmit school.   That seems to show up a lot of 
places other than WSJT.

 

While it is “wicked awesome” and someone probably spent some time figuring out 
how to do it I find the flashing aspect of it a bit annoying too.  

 

Maybe a less redder red?   One of the changes (from setup) I immediately made 
was to my My Call In Message a duller red.

 

73 de Bill ND0B

 

 

From: Black Michael [mailto:mdblac...@yahoo.com] 
Sent: Monday, January 2, 2017 11:48 AM
To: n...@ockert.us; 'WSJT software development' 

Subject: Re: [wsjt-devel] Disable Tx after RRR/73

 

I kinda' like that ideathat flashing bar should have more meaningit's 
really a bit annoying but giving it some more meaning would make it more 
tolerable.

 

But should it go red or yellow?  I can see it either way.  Yellow matches all 
the other Tx indicators...but red says "hey dude...you're transmitting!"  Red 
might be a bit too visually stimulating for that flashing bar.

 

de Mike W9MDB

 

 

  _  

From: Bill ND0B  >
To: 'Black Michael'  >; 'WSJT 
software development'  > 
Sent: Monday, January 2, 2017 11:40 AM
Subject: RE: [wsjt-devel] Disable Tx after RRR/73

 

Or alternately the progress bar for the current sequence could be colored red 
or green depending on “progress” of TX or RX respectively.

 

73 de Bill ND0B

 

 

From: Black Michael [mailto:mdblac...@yahoo.com] 
Sent: Monday, January 2, 2017 11:36 AM
To: WSJT software development  >
Subject: Re: [wsjt-devel] Disable Tx after RRR/73

 

That Green/Yellow makes sense to me...that coloring matches the rx/tx mode and 
the colors on the Rx Frequency list plus the status line.  All would show green 
on Rx and yellow on Tx.

 

The main advantage in the red is that it does stand out letting you know you 
will be transmitting which is an important distinction.  Kind of a "warning" 
in-your-face.  I must say that I think I'd miss that color

 

de Mike W9MDB

 

  _  

From: ANDY DURBIN  >
To: "wsjt-devel@lists.sourceforge.net  
"  > 
Sent: Monday, January 2, 2017 11:22 AM
Subject: Re: [wsjt-devel] Disable Tx after RRR/73

 

"so are you saying that you want to revert to having no "Halt Tx" 
button and have the "Enable Tx" button have two functions that cannot be 
separated?"

 

There was always a Halt TX button but, with the r3673 functionality of Enable 
TX, I don't think it was needed.  Removing it would not be  reversion.

 

The first step would be to understand why the change from "TX Enable" to "Next 
Enable" was made.  I see no advantage but I only use JT9 and JT65 on HF and 6m. 
  I assume there was some advantage in other operating environments.

 

If the arguments for the change are still valid then, obviously, it won't be 
changed back to the simple TX Enable that it used to be in r3673 and earlier.  
If that is the case then I hope the description inconsistencies that I listed 
earlier will be addressed. 

 

Moving to brainstorming mode - The color red seems inappropriate for the 
indicator for either functionality.   If tri-state is an option I'd suggest no 
fill for no TX possible (no change),  Green for auto enable -  this message and 
the next one will be sent, and Amber for this message is the last one that will 
be sent.  Colors would change  at the end of the TX period or when this button 
or Halt TX was pressed.

 

73,

Andy k3wyc

 

  _  

From: wsjt-devel-requ...@lists.sourceforge.net 
  
 >
Sent: Monday, January 2, 2017 9:50 AM
To: wsjt-devel@lists.sourceforge.net  
Subject: wsjt-devel Digest, Vol 35, Issue 11 

 

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net 
 

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel 


  wsjt-devel Info Page 
- SourceForge

lists.sourceforge.net

Your email address: Your name (optional): You may enter a privacy password 
below. This provides only mild security, but should prevent others from messing 
with ...



or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net 
 

You can reach the person managing the list at

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Bill Somerville


On 02/01/2017 17:47, Black Michael wrote:
I kinda' like that ideathat flashing bar should have more 
meaningit's really a bit annoying but giving it some more meaning 
would make it more tolerable.


But should it go red or yellow?  I can see it either way.  Yellow 
matches all the other Tx indicators...but red says "hey dude...you're 
transmitting!"  Red might be a bit too visually stimulating for that 
flashing bar.


Changing the rendering of a progress bar is not portable, for example on 
Mac Qt uses native progress bars which are fixed format because Apple 
closely controls the look and feel of the user interface. Windows 
progress bars are also most efficient if not customized as they too use 
native renderings where possible.


73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread ANDY DURBIN

Joe,

"Of course you're welcome to use good-old-r3673 as long as you like. But you'll 
then do without three years worth of very significant program enhancements and 
improvements "

Yes, of course I understand that. I only referenced r3673 to show that what 
Bill stated was untrue. 3 years ago is not "never". The decoder enhancements 
have made it advantageous to use 1.7.0 even for HF.

73,

Andy k3wyc

From: wsjt-devel-requ...@lists.sourceforge.net 

Sent: Monday, January 2, 2017 10:22 AM
To: wsjt-devel@lists.sourceforge.net
Subject: wsjt-devel Digest, Vol 35, Issue 12

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
wsjt-devel Info Page - 
SourceForge
lists.sourceforge.net
Your email address: Your name (optional): You may enter a privacy password 
below. This provides only mild security, but should prevent others from messing 
with ...

or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."

Today's Topics:

   1. Re: Disable Tx after RRR/73 (Bill Somerville)
   2. MSK144 Timing Flag? (George J Molnar)
   3. Re: Disable Tx after RRR/73 (Joe Taylor)
   4. Re: Disable Tx after RRR/73 (Black Michael)
   5. Re: Disable Tx after RRR/73 (ANDY DURBIN)

--

Message: 1
Date: Mon, 2 Jan 2017 16:55:43 +
From: Bill Somerville 
Subject: Re: [wsjt-devel] Disable Tx after RRR/73
To: wsjt-devel@lists.sourceforge.net
Message-ID: <2126fb3b-c133-ab79-c532-81ace5650...@classdesign.com>
Content-Type: text/plain; charset="windows-1252"

On 02/01/2017 16:50, Black Michael wrote:
> I think it's a case of semantics.  If you push "Tx" button on rig it
> starts Tx"Enable Tx" sounds a lot like that.
>
> "Enable Tx Next" might be more appropos.  Even then if you Enable
> during a Tx period it starts but at least that still meets the "Next"
> behavior I think.  Or "Tx Allowed".

Hi Mike,

that is a bit rich given all the comments about reducing the UI width!
One could also argue that the button caption should be "Tx" so as not to
contribute to the UI minimum width. Maybe it should be changed to a
check box option which has semantics of "Tick now to affect things
later" rather than the push button semantic of "Do it now".

73
Bill
G4WJS.

-- next part --
An HTML attachment was scrubbed...

--

Message: 2
Date: Mon, 2 Jan 2017 09:02:05 -0800
From: George J Molnar 
Subject: [wsjt-devel] MSK144 Timing Flag?
To: WSJT software development 
Message-ID: <65141be4-659b-4264-87d1-256d9b1ca...@molnar.com>
Content-Type: text/plain; charset="utf-8"

Is there room in the MSK144 protocol to include a ?duration? flag, indicating 
the sequence length selected by the transmitting station? In meteor scatter 
use, length isn?t usually obvious by listening, and mismatched sequence times 
could create undesired interference and longer times to complete.

I would suspect that MSK144 short sequences will find use during Es season, 
too. Having the software able to match sequences would be handy.

73/HNY

George J Molnar
Nevada, USA
KF2T  @GJMolnar

-- next part --
An HTML attachment was scrubbed...

--

Message: 3
Date: Mon, 2 Jan 2017 12:06:01 -0500
From: Joe Taylor 
Subject: Re: [wsjt-devel] Disable Tx after RRR/73
To: WSJT software development 
Message-ID: <205166bd-1ed2-4a4f-3b8d-9fd0f0d12...@princeton.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed

Andy --

K3WYC wrote:
> That assertion is simply not true. I keep v1.3 r3673 on my computer so I
> can check things like this. In r3673 pressing the lit "Enable Tx" button
> while transmitting a message does stop the message transmission!

WSJT-X v1.3 (r3673) was made more than three years ago.  At that time
the program was simple: it offered two modes, JT9 and JT65, and it was
useful only at HF.

WSJT-X Version 1.7 offers nine modes and is used from LF and MF through
24 GHz.  Yes, some user-interface behavior has evolved over time.  But
the program is still nearly 100% compatible with older versions, even
for users who still use only the original supported modes.  When we make
behavioral changes we generally have good reasons for doing so.

The WSJT-X User Guide makes it very clear what "Enable Tx" means, and
what it does:

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Black Michael

I kinda' like that ideathat flashing bar should have more meaningit's 
really a bit annoying but giving it some more meaning would make it more 
tolerable.
But should it go red or yellow?  I can see it either way.  Yellow matches all 
the other Tx indicators...but red says "hey dude...you're transmitting!"  Red 
might be a bit too visually stimulating for that flashing bar.

de Mike W9MDB


  From: Bill ND0B 
 To: 'Black Michael' ; 'WSJT software development' 
 
 Sent: Monday, January 2, 2017 11:40 AM
 Subject: RE: [wsjt-devel] Disable Tx after RRR/73
   
#yiv4780127622 #yiv4780127622 -- _filtered #yiv4780127622 
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv4780127622 
{panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv4780127622 
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv4780127622 
#yiv4780127622 p.yiv4780127622MsoNormal, #yiv4780127622 
li.yiv4780127622MsoNormal, #yiv4780127622 div.yiv4780127622MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv4780127622 a:link, 
#yiv4780127622 span.yiv4780127622MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv4780127622 a:visited, #yiv4780127622 
span.yiv4780127622MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv4780127622 
p.yiv4780127622msonormal0, #yiv4780127622 li.yiv4780127622msonormal0, 
#yiv4780127622 div.yiv4780127622msonormal0 
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv4780127622 
span.yiv4780127622EmailStyle19 {color:windowtext;}#yiv4780127622 
.yiv4780127622MsoChpDefault {font-size:10.0pt;} _filtered #yiv4780127622 
{margin:1.0in 1.0in 1.0in 1.0in;}#yiv4780127622 div.yiv4780127622WordSection1 
{}#yiv4780127622 Or alternately the progress bar for the current sequence could 
be colored red or green depending on “progress” of TX or RX respectively.  73 
de Bill ND0B    From: Black Michael [mailto:mdblac...@yahoo.com] 
Sent: Monday, January 2, 2017 11:36 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] Disable Tx after RRR/73  That Green/Yellow makes 
sense to me...that coloring matches the rx/tx mode and the colors on the Rx 
Frequency list plus the status line.  All would show green on Rx and yellow on 
Tx.  The main advantage in the red is that it does stand out letting you know 
you will be transmitting which is an important distinction.  Kind of a 
"warning" in-your-face.  I must say that I think I'd miss that color  de 
Mike W9MDB  From: ANDY DURBIN 
To: "wsjt-devel@lists.sourceforge.net"  
Sent: Monday, January 2, 2017 11:22 AM
Subject: Re: [wsjt-devel] Disable Tx after RRR/73  "so are you saying that you 
want to revert to having no "Halt Tx" 
button and have the "Enable Tx" button have two functions that cannot be 
separated?"  There was always a Halt TX button but, with the r3673 
functionality of Enable TX, I don't think it was needed.  Removing it would not 
be  reversion.  The first step would be to understand why the change from "TX 
Enable" to "Next Enable" was made.  I see no advantage but I only use JT9 and 
JT65 on HF and 6m.   I assume there was some advantage in other operating 
environments.  If the arguments for the change are still valid then, obviously, 
it won't be changed back to the simple TX Enable that it used to be in r3673 
and earlier.  If that is the case then I hope the description inconsistencies 
that I listed earlier will be addressed.   Moving to brainstorming mode - The 
color red seems inappropriate for the indicator for either functionality.   If 
tri-state is an option I'd suggest no fill for no TX possible (no change),  
Green for auto enable -  this message and the next one will be sent, and Amber 
for this message is the last one that will be sent.  Colors would change  at 
the end of the TX period or when this button or Halt TX was pressed.  73,Andy 
k3wyc  From: wsjt-devel-requ...@lists.sourceforge.net 

Sent: Monday, January 2, 2017 9:50 AM
To: wsjt-devel@lists.sourceforge.net
Subject: wsjt-devel Digest, Vol 35, Issue 11  Send wsjt-devel mailing list 
submissions to
    wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
| wsjt-devel Info Page - SourceForgelists.sourceforge.netYour email address: 
Your name (optional): You may enter a privacy password below. This provides 
only mild security, but should prevent others from messing with ... |



or, via email, send a message with subject or body 'help' to
    wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
    wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."


Today's Topics:

   1. Re: Disable Tx

Re: [wsjt-devel] MSK144 Timing Flag?

2017-01-02 Thread Bill Somerville

On 02/01/2017 17:12, Bill ND0B wrote:

I posted a few things I am working on a couple of days ago. This is 
one of them and I believe there is room for a single character in the 
CQ message to indicate this and a few other operational items.   Here 
were my comments on what I propose to develop…

> 8.   If it will fit add a “what the heck I am doing” letter to the

> CQ message for MSK144.   This would be a single letter representing the

> T/R period, SH status and Contest Mode status.   Clicking on this in an

> RXed CQ would change things to match.   Because space is limited this

> would be done by convention using a table.  A first draft of what 
this table

Might look like:

Standard/SH Off   Standard/ SH On Contest/SH 
Off Contest/SH On

60s 0 7 E L

30s 1 8 F  M

15s 2 9 G N

10s 3 A H O

5s 4 B I   P

Reserved 5 C J  Q

Reserved 6 D K R

Comments welcome.

Hi Bill,

Joe and Steve can confirm but I think this will be hard to shoehorn in. 
The encoding of callsigns and grids along with the substitution of type 
3 compound callsigns for grid data may not leave enough code space for 
28 new permutations of code word. For sure trying to map it by using a 
whole letter in the plain text space is not optimal and working in the 
codeword space is more likely to be successful. For example can 28 grid 
locator values be freed and is there equivalent space in the 
prefix/suffix encodings?

73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Bill ND0B

Mike,

 

Of course LOL!!   This is the second time in as many weeks I have been caught 
shooting my mouth off about something that got fixed one version ago from where 
I am at.

 

Thank you for the correction!!

 

73 de Bill ND0B

 

 

From: Black Michael [mailto:mdblac...@yahoo.com] 
Sent: Monday, January 2, 2017 11:41 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] Disable Tx after RRR/73

 

It was removed in 7442

 

de Mike W9MDB

 

 

  _  

From: Bill ND0B  >
To: 'WSJT software development'  > 
Sent: Monday, January 2, 2017 11:17 AM
Subject: Re: [wsjt-devel] Disable Tx after RRR/73

 

Good morning,

 

I just noticed this morning using r7441 that TX Enable is disabled (and the log 
prompt pops up) at the start of a TX4 transmission.   This is new behavior in 
one of the recent versions and I agree with those asserting it appears to be in 
error.   The contact can be considered over when one of the stations RECEIVES 
RRR, not when one of the stations transmits it.

 

Enable Tx and Halt Tx appear to operate as they always have, this is a change 
in how “Disable TX after sending 73” is interpreted.   I do not believe it to 
be correct to interpret this as disabling TX after sending an RRR.   This does 
not make sense either semantically or operationally.

 

73 de Bill ND0B

 

 

From: ANDY DURBIN [mailto:a.dur...@msn.com] 
Sent: Monday, January 2, 2017 8:54 AM
To: wsjt-devel@lists.sourceforge.net  
Subject: Re: [wsjt-devel] Disable Tx after RRR/73

 

"I figured out my issue with the auto sequencing stopping at RRR. It does not 
have anything to do with with prompt to log pop up. I had Disable TX after 
sending 73 checkmarked in Settings/General tab. For some reason, it is 
disabling TX after sending RRR instead."

 

You have been caught by what I think is a very misleading user interface!

 

In earlier versions of wsjt-x if "Enable TX" was not red you could not 
transmit.  The name was consistent with the behaviour.

 

The function was then changed to enable auto sequencing  (or something 
similar).  Now the Enable TX light extinguishes at the start of 73 but the 73 
continues to be sent.

 

I don't know why this behaviour was changed but I don't like it.  The current 
interface is misleading because several items were not changed to reflect the 
new behaviour.   

 

1. The button is still called "Enable TX" but TX is still enabled when it is 
not lit

2. The behaviour option is called "Disable TX after sending 73"  but this 
selection actually disables auto sequencing at start of 73

3.  The tool tip for the behaviour option does not describe what the option 
actually does

4. The tool tip for the Enable Tx button does not describe what the 
button/light does/indicates.

 

Either the behaviour needs to be changed back to how it used to be or the 
function names need to match what the system actually does.  My preference 
would be to go back to it being an Enable TX function.   If the Enable Tx 
button really did what is was labeled as,  there would be no need for the Halt 
TX button.

 

73,

Andy k3wyc

 

 

 

 

 

  _  

From: wsjt-devel-requ...@lists.sourceforge.net 
  
 >
Sent: Monday, January 2, 2017 6:53 AM
To: wsjt-devel@lists.sourceforge.net  
Subject: wsjt-devel Digest, Vol 35, Issue 9 

 

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net 
 

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel 


  wsjt-devel Info Page 
- SourceForge

lists.sourceforge.net

Your email address: Your name (optional): You may enter a privacy password 
below. This provides only mild security, but should prevent others from messing 
with ...



or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net 
 

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net 
 

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."


Today's Topics:

   1. Re: Prompt to log QSO when either RRR or 73 is sent (Jay Hainline)
   2. Re: Prompt to log QSO when either RRR or 73 is sent
  (Bill Somerville)


--

Message: 1
Date: Mon, 2 Jan 2017 13:40:47 -
From: "Jay Hainline"

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Black Michael

It was removed in 7442
de Mike W9MDB

  From: Bill ND0B 
 To: 'WSJT software development'  
 Sent: Monday, January 2, 2017 11:17 AM
 Subject: Re: [wsjt-devel] Disable Tx after RRR/73

#yiv0617045516 #yiv0617045516 -- _filtered #yiv0617045516 {panose-1:2 4 5 3 5 4 
6 3 2 4;} _filtered #yiv0617045516 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 
3 2 4;} _filtered #yiv0617045516 {panose-1:2 11 5 2 4 2 4 2 2 3;} _filtered 
#yiv0617045516 {panose-1:2 11 5 2 4 2 4 2 2 3;}#yiv0617045516 #yiv0617045516 
p.yiv0617045516MsoNormal, #yiv0617045516 li.yiv0617045516MsoNormal, 
#yiv0617045516 div.yiv0617045516MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0617045516 a:link, 
#yiv0617045516 span.yiv0617045516MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv0617045516 a:visited, #yiv0617045516 
span.yiv0617045516MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv0617045516 
p.yiv0617045516msonormal0, #yiv0617045516 li.yiv0617045516msonormal0, 
#yiv0617045516 div.yiv0617045516msonormal0 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0617045516 
span.yiv0617045516EmailStyle19 {color:windowtext;}#yiv0617045516 
.yiv0617045516MsoChpDefault {font-size:10.0pt;} _filtered #yiv0617045516 
{margin:1.0in 1.0in 1.0in 1.0in;}#yiv0617045516 div.yiv0617045516WordSection1 
{}#yiv0617045516 Good morning,  I just noticed this morning using r7441 that TX 
Enable is disabled (and the log prompt pops up) at the start of a TX4 
transmission.   This is new behavior in one of the recent versions and I agree 
with those asserting it appears to be in error.   The contact can be considered 
over when one of the stations RECEIVES RRR, not when one of the stations 
transmits it.  Enable Tx and Halt Tx appear to operate as they always have, 
this is a change in how “Disable TX after sending 73” is interpreted.   I do 
not believe it to be correct to interpret this as disabling TX after sending an 
RRR.   This does not make sense either semantically or operationally.  73 de 
Bill ND0B    From: ANDY DURBIN [mailto:a.dur...@msn.com] 
Sent: Monday, January 2, 2017 8:54 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Disable Tx after RRR/73  "I figured out my issue with 
the auto sequencing stopping at RRR. It does not have anything to do with with 
prompt to log pop up. I had Disable TX after sending 73 checkmarked in 
Settings/General tab. For some reason, it is disabling TX after sending RRR 
instead."  You have been caught by what I think is a very misleading user 
interface!  In earlier versions of wsjt-x if "Enable TX" was not red you could 
not transmit.  The name was consistent with the behaviour.  The function was 
then changed to enable auto sequencing  (or something similar).  Now the Enable 
TX light extinguishes at the start of 73 but the 73 continues to be sent.  I 
don't know why this behaviour was changed but I don't like it.  The current 
interface is misleading because several items were not changed to reflect the 
new behaviour.     1. The button is still called "Enable TX" but TX is still 
enabled when it is not lit2. The behaviour option is called "Disable TX after 
sending 73"  but this selection actually disables auto sequencing at start of 
733.  The tool tip for the behaviour option does not describe what the option 
actually does4. The tool tip for the Enable Tx button does not describe what 
the button/light does/indicates.  Either the behaviour needs to be changed back 
to how it used to be or the function names need to match what the system 
actually does.  My preference would be to go back to it being an Enable TX 
function.   If the Enable Tx button really did what is was labeled as,  there 
would be no need for the Halt TX button.  73,Andy k3wyc          From: 
wsjt-devel-requ...@lists.sourceforge.net 

Sent: Monday, January 2, 2017 6:53 AM
To: wsjt-devel@lists.sourceforge.net
Subject: wsjt-devel Digest, Vol 35, Issue 9  Send wsjt-devel mailing list 
submissions to
    wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
| wsjt-devel Info Page - SourceForgelists.sourceforge.netYour email address: 
Your name (optional): You may enter a privacy password below. This provides 
only mild security, but should prevent others from messing with ... |

or, via email, send a message with subject or body 'help' to
    wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
    wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."

Today's Topics:

   1. Re: Prompt to log QSO when either RRR or 73 is sent (Jay Hainline)
   2. Re: Prompt to log QSO when either RRR or 73 is sent
  (Bill Somerville)

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Bill ND0B

Or alternately the progress bar for the current sequence could be colored red 
or green depending on “progress” of TX or RX respectively.

73 de Bill ND0B

From: Black Michael [mailto:mdblac...@yahoo.com] 
Sent: Monday, January 2, 2017 11:36 AM
To: WSJT software development 
Subject: Re: [wsjt-devel] Disable Tx after RRR/73

That Green/Yellow makes sense to me...that coloring matches the rx/tx mode and 
the colors on the Rx Frequency list plus the status line.  All would show green 
on Rx and yellow on Tx.

The main advantage in the red is that it does stand out letting you know you 
will be transmitting which is an important distinction.  Kind of a "warning" 
in-your-face.  I must say that I think I'd miss that color

de Mike W9MDB

  _  

From: ANDY DURBIN  >
To: "wsjt-devel@lists.sourceforge.net  
"  > 
Sent: Monday, January 2, 2017 11:22 AM
Subject: Re: [wsjt-devel] Disable Tx after RRR/73

"so are you saying that you want to revert to having no "Halt Tx" 
button and have the "Enable Tx" button have two functions that cannot be 
separated?"

There was always a Halt TX button but, with the r3673 functionality of Enable 
TX, I don't think it was needed.  Removing it would not be  reversion.

The first step would be to understand why the change from "TX Enable" to "Next 
Enable" was made.  I see no advantage but I only use JT9 and JT65 on HF and 6m. 
  I assume there was some advantage in other operating environments.

If the arguments for the change are still valid then, obviously, it won't be 
changed back to the simple TX Enable that it used to be in r3673 and earlier.  
If that is the case then I hope the description inconsistencies that I listed 
earlier will be addressed. 

Moving to brainstorming mode - The color red seems inappropriate for the 
indicator for either functionality.   If tri-state is an option I'd suggest no 
fill for no TX possible (no change),  Green for auto enable -  this message and 
the next one will be sent, and Amber for this message is the last one that will 
be sent.  Colors would change  at the end of the TX period or when this button 
or Halt TX was pressed.

73,

Andy k3wyc

  _  

From: wsjt-devel-requ...@lists.sourceforge.net 

 >
Sent: Monday, January 2, 2017 9:50 AM
To: wsjt-devel@lists.sourceforge.net  
Subject: wsjt-devel Digest, Vol 35, Issue 11 

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net 

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel 

  wsjt-devel Info Page 
- SourceForge

lists.sourceforge.net

Your email address: Your name (optional): You may enter a privacy password 
below. This provides only mild security, but should prevent others from messing 
with ...

or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net 

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net 

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."

Today's Topics:

   1. Re: Disable Tx after RRR/73 (Bill Somerville)
   2. Re: Disable Tx after RRR/73 (ANDY DURBIN)
   3. Re: Disable Tx after RRR/73 (Bill Somerville)
   4. Re: Disable Tx after RRR/73 (Black Michael)

--

Message: 1
Date: Mon, 2 Jan 2017 15:07:33 +
From: Bill Somerville  >
Subject: Re: [wsjt-devel] Disable Tx after RRR/73
To: wsjt-devel@lists.sourceforge.net  
Message-ID:  >
Content-Type: text/plain; charset="windows-1252"

On 02/01/2017 14:54, ANDY DURBIN wrote:
> My preference would be to go back to it being an Enable TX function. 

Hi Andy,

the "Enable Tx" button has always been "Enable auto Tx", in fact the 
underlying variable name is autoButton and it always has been.

Because the message protocols restrict you to transmitting in only the 
first or second period of the sequence the only interpretation of that 
button is transmit when it is next possible to do so. That may be now or 
at the start of the next suitable period. The "Halt Tx" button

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Bill Somerville


Hi Andy,

comments in line below.

On 02/01/2017 17:22, ANDY DURBIN wrote:


There was always a Halt TX button but, with the r3673 functionality of 
Enable TX, I don't think it was needed.  Removing it would not be 
 reversion.


The internal implementation is an auto transmit enable, having it also 
halt transmit immediately has to be an add on to that. Having a halt tx 
immediately avoids overloading the function of the buttons, that is a 
good thing because it allows different operators to use the interface as 
they wish. You are trying to force your view of usage which seems 
unreasonable given there is a valid alternative. Client "Halt Tx" if you 
want immediate stop and click "Enable Tx" if you wish to complete the 
message that is currently running.



The first step would be to understand why the change from "TX Enable" 
to "Next Enable" was made.  I see no advantage but I only use JT9 and 
JT65 on HF and 6m.   I assume there was some advantage in other 
operating environments.


No such change has happened. What has happened is that the overloaded 
feature of having "Enable Tx" turn off auto transmission *and* having 
"Enable Tx" stop immediately has been simplified - without any loss of 
functionality *because the "Halt Tx" button already does the latter"*.



If the arguments for the change are still valid then, obviously, it 
won't be changed back to the simple TX Enable that it used to be in 
r3673 and earlier.  If that is the case then I hope the description 
inconsistencies that I listed earlier will be addressed.


The arguments were for simplification without loss of functionality. Joe 
has already cited the documentation that clearly states the current 
functionality is for "Enable Tx" OFF only disables auto transmit, it 
does not discard the current message if transmission has started, "Halt 
Tx" does that.



Moving to brainstorming mode - The color red seems inappropriate for 
the indicator for either functionality.   If tri-state is an option 
I'd suggest no fill for no TX possible (no change),  Green for auto 
enable -  this message and the next one will be sent, and Amber for 
this message is the last one that will be sent.  Colors would change 
 at the end of the TX period or when this button or Halt TX was pressed.


Statefull push buttons are generally considered as bad design, the other 
button types like radio buttons and check boxes are designed for exactly 
that purpose. Having said that most UI widget tool kits offer checkable 
push buttons and they can be useful where they are used a lot and a 
check box might be considered too small for quick operation. The 
overriding design criteria should reflect the chosen button semantics 
and in that respect we have it wrong as push button controls are meant 
to mimic momentary push buttons that immediately start something. Going 
to tri-state semantics is moving way too far from that behaviour IMHO.


73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Bill ND0B

Good morning,

 

I just noticed this morning using r7441 that TX Enable is disabled (and the
log prompt pops up) at the start of a TX4 transmission.   This is new
behavior in one of the recent versions and I agree with those asserting it
appears to be in error.   The contact can be considered over when one of the
stations RECEIVES RRR, not when one of the stations transmits it.

 

Enable Tx and Halt Tx appear to operate as they always have, this is a
change in how "Disable TX after sending 73" is interpreted.   I do not
believe it to be correct to interpret this as disabling TX after sending an
RRR.   This does not make sense either semantically or operationally.

 

73 de Bill ND0B

 

 

From: ANDY DURBIN [mailto:a.dur...@msn.com] 
Sent: Monday, January 2, 2017 8:54 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Disable Tx after RRR/73

 

"I figured out my issue with the auto sequencing stopping at RRR. It does
not have anything to do with with prompt to log pop up. I had Disable TX
after sending 73 checkmarked in Settings/General tab. For some reason, it is
disabling TX after sending RRR instead."

 

You have been caught by what I think is a very misleading user interface!

 

In earlier versions of wsjt-x if "Enable TX" was not red you could not
transmit.  The name was consistent with the behaviour.

 

The function was then changed to enable auto sequencing  (or something
similar).  Now the Enable TX light extinguishes at the start of 73 but the
73 continues to be sent.

 

I don't know why this behaviour was changed but I don't like it.  The
current interface is misleading because several items were not changed to
reflect the new behaviour.   

 

1. The button is still called "Enable TX" but TX is still enabled when it is
not lit

2. The behaviour option is called "Disable TX after sending 73"  but this
selection actually disables auto sequencing at start of 73

3.  The tool tip for the behaviour option does not describe what the option
actually does

4. The tool tip for the Enable Tx button does not describe what the
button/light does/indicates.

 

Either the behaviour needs to be changed back to how it used to be or the
function names need to match what the system actually does.  My preference
would be to go back to it being an Enable TX function.   If the Enable Tx
button really did what is was labeled as,  there would be no need for the
Halt TX button.

 

73,

Andy k3wyc

 

 

 

 

 

  _  

From: wsjt-devel-requ...@lists.sourceforge.net

 >
Sent: Monday, January 2, 2017 6:53 AM
To: wsjt-devel@lists.sourceforge.net
 
Subject: wsjt-devel Digest, Vol 35, Issue 9 

 

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net
 

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel 


  wsjt-devel Info
Page - SourceForge

lists.sourceforge.net

Your email address: Your name (optional): You may enter a privacy password
below. This provides only mild security, but should prevent others from
messing with ...



or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net
 

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net
 

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."


Today's Topics:

   1. Re: Prompt to log QSO when either RRR or 73 is sent (Jay Hainline)
   2. Re: Prompt to log QSO when either RRR or 73 is sent
  (Bill Somerville)


--

Message: 1
Date: Mon, 2 Jan 2017 13:40:47 -
From: "Jay Hainline"  >
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is
sent
To: "'WSJT software development'"  >
Message-ID: <004801d264fd$d3a2c8d0$7ae85a70$@mtcnow.net
 >
Content-Type: text/plain; charset="utf-8"

I figured out my issue with the auto sequencing stopping at RRR. It does not
have anything to do with with prompt to log pop up. I had Disable TX after
sending 73 checkmarked in Settings/General tab. For some reason, it is
disabling TX after sending RRR instead.

 

 

73 Jay KA9CFD

 

From: Jay Hainline [mailto:ka9...@mtcnow.net] 
Sent: January 1, 2017 22:08
To: 'Black Michael'  >;
'WSJT software development'

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Black Michael

That Green/Yellow makes sense to me...that coloring matches the rx/tx mode and 
the colors on the Rx Frequency list plus the status line.  All would show green 
on Rx and yellow on Tx.
The main advantage in the red is that it does stand out letting you know you 
will be transmitting which is an important distinction.  Kind of a "warning" 
in-your-face.  I must say that I think I'd miss that color

de Mike W9MDB


  From: ANDY DURBIN 
 To: "wsjt-devel@lists.sourceforge.net"  
 Sent: Monday, January 2, 2017 11:22 AM
 Subject: Re: [wsjt-devel] Disable Tx after RRR/73
   
 "so are you saying that 
you want to revert to having no "Halt Tx" 
button and have the "Enable Tx" button have two functions that cannot be 
separated?"
There was always a Halt TX button but, with the r3673 functionality of Enable 
TX, I don't think it was needed.  Removing it would not be  reversion.
The first step would be to understand why the change from "TX Enable" to "Next 
Enable" was made.  I see no advantage but I only use JT9 and JT65 on HF and 6m. 
  I assume there was some advantage in other operating environments.
If the arguments for the change are still valid then, obviously, it won't be 
changed back to the simple TX Enable that it used to be in r3673 and earlier.  
If that is the case then I hope the description inconsistencies that I listed 
earlier will be addressed. 
Moving to brainstorming mode - The color red seems inappropriate for the 
indicator for either functionality.   If tri-state is an option I'd suggest no 
fill for no TX possible (no change),  Green for auto enable -  this message and 
the next one will be sent, and Amber for this message is the last one that will 
be sent.  Colors would change  at the end of the TX period or when this button 
or Halt TX was pressed.
73,Andy k3wyc
From: wsjt-devel-requ...@lists.sourceforge.net 

Sent: Monday, January 2, 2017 9:50 AM
To: wsjt-devel@lists.sourceforge.net
Subject: wsjt-devel Digest, Vol 35, Issue 11 Send wsjt-devel mailing list 
submissions to
    wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.sourceforge.net/lists/listinfo/wsjt-devel
| wsjt-devel Info Page - SourceForgelists.sourceforge.netYour email address: 
Your name (optional): You may enter a privacy password below. This provides 
only mild security, but should prevent others from messing with ... |



or, via email, send a message with subject or body 'help' to
    wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
    wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."


Today's Topics:

   1. Re: Disable Tx after RRR/73 (Bill Somerville)
   2. Re: Disable Tx after RRR/73 (ANDY DURBIN)
   3. Re: Disable Tx after RRR/73 (Bill Somerville)
   4. Re: Disable Tx after RRR/73 (Black Michael)


--

Message: 1
Date: Mon, 2 Jan 2017 15:07:33 +
From: Bill Somerville 
Subject: Re: [wsjt-devel] Disable Tx after RRR/73
To: wsjt-devel@lists.sourceforge.net
Message-ID: 
Content-Type: text/plain; charset="windows-1252"

On 02/01/2017 14:54, ANDY DURBIN wrote:
> My preference would be to go back to it being an Enable TX function. 

Hi Andy,

the "Enable Tx" button has always been "Enable auto Tx", in fact the 
underlying variable name is autoButton and it always has been.

Because the message protocols restrict you to transmitting in only the 
first or second period of the sequence the only interpretation of that 
button is transmit when it is next possible to do so. That may be now or 
at the start of the next suitable period. The "Halt Tx" button is not 
the antithesis of "Enable Tx" but it does happen to toggle it off, this 
is because it makes sense to not transmit again after a request to "Halt 
Tx". Once a transmission is started the "Halt Tx" button is the way to 
stop it, toggling "Enable Tx" to off does not do that, it never has.

73
Bill
G4WJS.

-- next part --
An HTML attachment was scrubbed...

--

Message: 2
Date: Mon, 2 Jan 2017 16:40:20 +
From: ANDY DURBIN 
Subject: Re: [wsjt-devel] Disable Tx after RRR/73
To: "wsjt-devel@lists.sourceforge.net"
    
Message-ID:
    

    
Content-Type: text/plain; charset="iso-8859-1"

"Once a transmission is started the "Halt Tx" button is the way to stop it, 
toggling "Enable Tx" to off does not do that, it never has."


Bill,


That assertion is simply not true. I keep v1.3 r3673 on my computer so I can 
check

Re: [wsjt-devel] MSK144 Timing Flag?

2017-01-02 Thread Bill ND0B

Good morning George,

 

I posted a few things I am working on a couple of days ago.   This is one of 
them and I believe there is room for a single character in the CQ message to 
indicate this and a few other operational items.   Here were my comments on 
what I propose to develop…

 

> 8.   If it will fit add a “what the heck I am doing” letter to the

> CQ message for MSK144.   This would be a single letter representing the

> T/R period, SH status and Contest Mode status.   Clicking on this in an

> RXed CQ would change things to match.   Because space is limited this

> would be done by convention using a table.  A first draft of what this table 

Might look like:

 

 

Standard/SH Off   Standard/ SH On   
Contest/SH Off Contest/SH On

60s 0   
   7  E 
 L  

30s 1   
   8  F 
 M

15s 2   
   9  G 
N

10s 3   
   A H  
   O

5s4 
 B I
   P

Reserved 5  
C J 
 Q

Reserved 6  
D K 
R

 

Comments welcome.

 

73 de Bill ND0B

 

 

From: George J Molnar [mailto:geo...@molnar.com] 
Sent: Monday, January 2, 2017 11:02 AM
To: WSJT software development 
Subject: [wsjt-devel] MSK144 Timing Flag?

 

Is there room in the MSK144 protocol to include a “duration” flag, indicating 
the sequence length selected by the transmitting station? In meteor scatter 
use, length isn’t usually obvious by listening, and mismatched sequence times 
could create undesired interference and longer times to complete.

 

I would suspect that MSK144 short sequences will find use during Es season, 
too. Having the software able to match sequences would be handy.

 

73/HNY

 

 

George J Molnar

Nevada, USA
KF2T  @GJMolnar

 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread ANDY DURBIN

"so are you saying that you want to revert to having no "Halt Tx"
button and have the "Enable Tx" button have two functions that cannot be
separated?"


There was always a Halt TX button but, with the r3673 functionality of Enable 
TX, I don't think it was needed.  Removing it would not be  reversion.


The first step would be to understand why the change from "TX Enable" to "Next 
Enable" was made.  I see no advantage but I only use JT9 and JT65 on HF and 6m. 
  I assume there was some advantage in other operating environments.


If the arguments for the change are still valid then, obviously, it won't be 
changed back to the simple TX Enable that it used to be in r3673 and earlier.  
If that is the case then I hope the description inconsistencies that I listed 
earlier will be addressed.


Moving to brainstorming mode - The color red seems inappropriate for the 
indicator for either functionality.   If tri-state is an option I'd suggest no 
fill for no TX possible (no change),  Green for auto enable -  this message and 
the next one will be sent, and Amber for this message is the last one that will 
be sent.  Colors would change  at the end of the TX period or when this button 
or Halt TX was pressed.


73,

Andy k3wyc


From: wsjt-devel-requ...@lists.sourceforge.net 

Sent: Monday, January 2, 2017 9:50 AM
To: wsjt-devel@lists.sourceforge.net
Subject: wsjt-devel Digest, Vol 35, Issue 11

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
wsjt-devel Info Page - 
SourceForge
lists.sourceforge.net
Your email address: Your name (optional): You may enter a privacy password 
below. This provides only mild security, but should prevent others from messing 
with ...



or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."


Today's Topics:

   1. Re: Disable Tx after RRR/73 (Bill Somerville)
   2. Re: Disable Tx after RRR/73 (ANDY DURBIN)
   3. Re: Disable Tx after RRR/73 (Bill Somerville)
   4. Re: Disable Tx after RRR/73 (Black Michael)


--

Message: 1
Date: Mon, 2 Jan 2017 15:07:33 +
From: Bill Somerville 
Subject: Re: [wsjt-devel] Disable Tx after RRR/73
To: wsjt-devel@lists.sourceforge.net
Message-ID: 
Content-Type: text/plain; charset="windows-1252"

On 02/01/2017 14:54, ANDY DURBIN wrote:
> My preference would be to go back to it being an Enable TX function.

Hi Andy,

the "Enable Tx" button has always been "Enable auto Tx", in fact the
underlying variable name is autoButton and it always has been.

Because the message protocols restrict you to transmitting in only the
first or second period of the sequence the only interpretation of that
button is transmit when it is next possible to do so. That may be now or
at the start of the next suitable period. The "Halt Tx" button is not
the antithesis of "Enable Tx" but it does happen to toggle it off, this
is because it makes sense to not transmit again after a request to "Halt
Tx". Once a transmission is started the "Halt Tx" button is the way to
stop it, toggling "Enable Tx" to off does not do that, it never has.

73
Bill
G4WJS.

-- next part --
An HTML attachment was scrubbed...

--

Message: 2
Date: Mon, 2 Jan 2017 16:40:20 +
From: ANDY DURBIN 
Subject: Re: [wsjt-devel] Disable Tx after RRR/73
To: "wsjt-devel@lists.sourceforge.net"

Message-ID:



Content-Type: text/plain; charset="iso-8859-1"

"Once a transmission is started the "Halt Tx" button is the way to stop it, 
toggling "Enable Tx" to off does not do that, it never has."


Bill,


That assertion is simply not true. I keep v1.3 r3673 on my computer so I can 
check things like this. In r3673 pressing the lit "Enable Tx" button while 
transmitting a message does stop the message transmission!


"Enable TX" used to be just that - Enable TX - and if it was not lit then no TX 
was possible.


73,

Andy k3wyc
-- next part --
An HTML attachment was scrubbed...

--

Message: 3
Date: Mon, 2 Jan 2017 16:43:38 +
From: Bill Somerville 
Subject: Re: [wsjt-devel] Disable Tx after RRR/73
To: wsjt-devel@lists.sourceforge.net
Message-ID:

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Black Michael

Maybe it should be Yellow when enabled and not transmitting?Red when 
transmitting?  A bit like the status line?

Just throwing out ideas for consideration.  I think those of us who have been 
operating this for a while may not be able to perceive the new user experience.
de Mike W9MDB



  From: Bill Somerville 
 To: wsjt-devel@lists.sourceforge.net 
 Sent: Monday, January 2, 2017 10:55 AM
 Subject: Re: [wsjt-devel] Disable Tx after RRR/73
   
 On 02/01/2017 16:50, Black Michael wrote:
  
 I think it's a case of semantics.  If you push "Tx" button on rig it starts 
Tx"Enable Tx" sounds a lot like that. 
  "Enable Tx Next" might be more appropos.  Even then if you Enable during a Tx 
period it starts but at least that still meets the "Next" behavior I think.  Or 
"Tx Allowed". 
 Hi Mike, that is a bit rich given all the comments about reducing the UI 
width! One could also argue that the button caption should be "Tx" so as not to 
contribute to the UI minimum width. Maybe it should be changed to a check box 
option which has semantics of "Tick now to affect things later" rather than the 
push button semantic of "Do it now".
  73
 Bill
 G4WJS.
  
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


   --
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Joe Taylor

Andy --

K3WYC wrote:
> That assertion is simply not true. I keep v1.3 r3673 on my computer so I
> can check things like this. In r3673 pressing the lit "Enable Tx" button
> while transmitting a message does stop the message transmission!

WSJT-X v1.3 (r3673) was made more than three years ago.  At that time 
the program was simple: it offered two modes, JT9 and JT65, and it was 
useful only at HF.

WSJT-X Version 1.7 offers nine modes and is used from LF and MF through 
24 GHz.  Yes, some user-interface behavior has evolved over time.  But 
the program is still nearly 100% compatible with older versions, even 
for users who still use only the original supported modes.  When we make 
behavioral changes we generally have good reasons for doing so.

The WSJT-X User Guide makes it very clear what "Enable Tx" means, and 
what it does:

"Enable Tx toggles automatic T/R sequencing mode on or off and 
highlights the button in red when ON. A transmission will start at the 
beginning of the selected (odd or even) sequence, or immediately if 
appropriate. Toggling the button to OFF during a transmission allows the 
current transmission to finish."

Of course you're welcome to use good-old-r3673 as long as you like.  But 
you'll then do without three years worth of very significant program 
enhancements and improvements -- even if you never use anything but JT9 
and JT65.

-- Joe, K1JT

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] MSK144 Timing Flag?

2017-01-02 Thread George J Molnar

Is there room in the MSK144 protocol to include a “duration” flag, indicating 
the sequence length selected by the transmitting station? In meteor scatter 
use, length isn’t usually obvious by listening, and mismatched sequence times 
could create undesired interference and longer times to complete.

I would suspect that MSK144 short sequences will find use during Es season, 
too. Having the software able to match sequences would be handy.

73/HNY


George J Molnar
Nevada, USA
KF2T  @GJMolnar

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Bill Somerville


On 02/01/2017 16:50, Black Michael wrote:
I think it's a case of semantics.  If you push "Tx" button on rig it 
starts Tx"Enable Tx" sounds a lot like that.


"Enable Tx Next" might be more appropos.  Even then if you Enable 
during a Tx period it starts but at least that still meets the "Next" 
behavior I think.  Or "Tx Allowed".


Hi Mike,

that is a bit rich given all the comments about reducing the UI width! 
One could also argue that the button caption should be "Tx" so as not to 
contribute to the UI minimum width. Maybe it should be changed to a 
check box option which has semantics of "Tick now to affect things 
later" rather than the push button semantic of "Do it now".


73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Black Michael

I think it's a case of semantics.  If you push "Tx" button on rig it starts 
Tx"Enable Tx" sounds a lot like that.
"Enable Tx Next" might be more appropos.  Even then if you Enable during a Tx 
period it starts but at least that still meets the "Next" behavior I think.  Or 
"Tx Allowed".

de Mike W9MDB


  From: Bill Somerville 
 To: wsjt-devel@lists.sourceforge.net 
 Sent: Monday, January 2, 2017 10:43 AM
 Subject: Re: [wsjt-devel] Disable Tx after RRR/73
   
 On 02/01/2017 16:40, ANDY DURBIN wrote:
  
 That assertion is simply not true. I keep v1.3 r3673 on my computer so I can 
check things like this. In r3673 pressing the lit "Enable Tx" button while 
transmitting a message does stop the message transmission!  "Enable TX" used to 
be just that - Enable TX - and if it was not lit then no TX was possible. 
 Hi Andy, ok, so are you saying that you want to revert to having no "Halt Tx" 
button and have the "Enable Tx" button have two functions that cannot be 
separated? 73
 Bill
 G4WJS.
  
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


   --
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Bill Somerville


On 02/01/2017 16:40, ANDY DURBIN wrote:


That assertion is simply not true. I keep v1.3 r3673 on my computer so 
I can check things like this. In r3673 pressing the lit "Enable Tx" 
button while transmitting a message does stop the message transmission!


"Enable TX" used to be just that - Enable TX - and if it was not lit 
then no TX was possible.



Hi Andy,

ok, so are you saying that you want to revert to having no "Halt Tx" 
button and have the "Enable Tx" button have two functions that cannot be 
separated?


73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread ANDY DURBIN

"Once a transmission is started the "Halt Tx" button is the way to stop it, 
toggling "Enable Tx" to off does not do that, it never has."


Bill,


That assertion is simply not true. I keep v1.3 r3673 on my computer so I can 
check things like this. In r3673 pressing the lit "Enable Tx" button while 
transmitting a message does stop the message transmission!


"Enable TX" used to be just that - Enable TX - and if it was not lit then no TX 
was possible.


73,

Andy k3wyc
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread Bill Somerville


On 02/01/2017 14:54, ANDY DURBIN wrote:
My preference would be to go back to it being an Enable TX function. 


Hi Andy,

the "Enable Tx" button has always been "Enable auto Tx", in fact the 
underlying variable name is autoButton and it always has been.


Because the message protocols restrict you to transmitting in only the 
first or second period of the sequence the only interpretation of that 
button is transmit when it is next possible to do so. That may be now or 
at the start of the next suitable period. The "Halt Tx" button is not 
the antithesis of "Enable Tx" but it does happen to toggle it off, this 
is because it makes sense to not transmit again after a request to "Halt 
Tx". Once a transmission is started the "Halt Tx" button is the way to 
stop it, toggling "Enable Tx" to off does not do that, it never has.


73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Disable Tx after RRR/73

2017-01-02 Thread ANDY DURBIN

"I figured out my issue with the auto sequencing stopping at RRR. It does not 
have anything to do with with prompt to log pop up. I had Disable TX after 
sending 73 checkmarked in Settings/General tab. For some reason, it is 
disabling TX after sending RRR instead."


You have been caught by what I think is a very misleading user interface!


In earlier versions of wsjt-x if "Enable TX" was not red you could not 
transmit.  The name was consistent with the behaviour.


The function was then changed to enable auto sequencing  (or something 
similar).  Now the Enable TX light extinguishes at the start of 73 but the 73 
continues to be sent.


I don't know why this behaviour was changed but I don't like it.  The current 
interface is misleading because several items were not changed to reflect the 
new behaviour.


1. The button is still called "Enable TX" but TX is still enabled when it is 
not lit

2. The behaviour option is called "Disable TX after sending 73"  but this 
selection actually disables auto sequencing at start of 73

3.  The tool tip for the behaviour option does not describe what the option 
actually does

4. The tool tip for the Enable Tx button does not describe what the 
button/light does/indicates.


Either the behaviour needs to be changed back to how it used to be or the 
function names need to match what the system actually does.  My preference 
would be to go back to it being an Enable TX function.   If the Enable Tx 
button really did what is was labeled as,  there would be no need for the Halt 
TX button.


73,

Andy k3wyc







From: wsjt-devel-requ...@lists.sourceforge.net 

Sent: Monday, January 2, 2017 6:53 AM
To: wsjt-devel@lists.sourceforge.net
Subject: wsjt-devel Digest, Vol 35, Issue 9

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
wsjt-devel Info Page - 
SourceForge
lists.sourceforge.net
Your email address: Your name (optional): You may enter a privacy password 
below. This provides only mild security, but should prevent others from messing 
with ...



or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."


Today's Topics:

   1. Re: Prompt to log QSO when either RRR or 73 is sent (Jay Hainline)
   2. Re: Prompt to log QSO when either RRR or 73 is sent
  (Bill Somerville)


--

Message: 1
Date: Mon, 2 Jan 2017 13:40:47 -
From: "Jay Hainline" 
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is
sent
To: "'WSJT software development'" 
Message-ID: <004801d264fd$d3a2c8d0$7ae85a70$@mtcnow.net>
Content-Type: text/plain; charset="utf-8"

I figured out my issue with the auto sequencing stopping at RRR. It does not 
have anything to do with with prompt to log pop up. I had Disable TX after 
sending 73 checkmarked in Settings/General tab. For some reason, it is 
disabling TX after sending RRR instead.





73 Jay KA9CFD



From: Jay Hainline [mailto:ka9...@mtcnow.net]
Sent: January 1, 2017 22:08
To: 'Black Michael'  >; 'WSJT 
software development'  >
Subject: RE: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent



I don?t know for certain why this was changed in the first place except the 
JT65 HF crowd is always looking for a way to sidestep a sequence to shorten the 
time for a QSO. This does not work in the meteor scatter VHF world where you 
are relying on random data bits to fly in on a meteor for less than 1 second 
and you are trying to decode just what the guy on the other end has received. 
If it aint broke, don?t fix it.



I hope I don?t get black balled for being negative like the Ham Radio Deluxe 
people do to users of their software. Lol ;-)



73 Jay KA9CFD



From: Black Michael [  mailto:mdblac...@yahoo.com]
Sent: Sunday, January 1, 2017 3:39 PM
To: WSJT software development <  
wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent



I think the consensus solution would be to make it a user option.

Seems the meteor scatter people have the most problems with it since they were 
quick to speak up.



I had proposed at one time to make the "Prompt me to log QSO" a tri-state box 
so one could check 73, 73+RRR, or

Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

2017-01-02 Thread Jay Hainline

Hello Bill. I did not uncheck "Auto Seq". Just the "Disable TX after sending
73" box in the Settings. I still have "Prompt me to log QSO" checkmarked but
the program does not stop TX after sending RRR now. It continues on to TX5
sending the 73 message. I have to click on the "Enable TX" button to make it
stop now as it stays red. Hope that make sense.

 

73 Jay KA9CFD

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: January 2, 2017 13:54
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

 

On 02/01/2017 13:40, Jay Hainline wrote:

I figured out my issue with the auto sequencing stopping at RRR. It does not
have anything to do with with prompt to log pop up. I had Disable TX after
sending 73 checkmarked in Settings/General tab. For some reason, it is
disabling TX after sending RRR instead.

Hi Jay,

the disabling of auto Tx and the automatic pop up of the logging dialog are
currenty linked. I believe the thinking was that if you are able to log then
you should stop sending. IMHO this is only true for the caller as the
station running the frequency is obliged to keep sending RRR until they are
sure that the caller has seen it, even though their end of the QSO is
compete and they can log it. This made sense when the logging reminder only
came up for 73 messages, now it also does for RRR messages and that is
causing the problem here.

Maybe we should pop up the log QSO dialog but only disable auto Tx once the
Ok has been clicked. Another option might be to split the setting into two
options like "Prompt to Log QSO" and "Disable auto Tx *after* logging", the
latter maybe only applying if the message that prompted logging was a 73
message.

There must be a way of doing this that satisfies all modes and operating
methods.

73 & HNY
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

2017-01-02 Thread Bill Somerville


On 02/01/2017 13:40, Jay Hainline wrote:
I figured out my issue with the auto sequencing stopping at RRR. It 
does not have anything to do with with prompt to log pop up. I had 
Disable TX after sending 73 checkmarked in Settings/General tab. For 
some reason, it is disabling TX after sending RRR instead.


Hi Jay,

the disabling of auto Tx and the automatic pop up of the logging dialog 
are currenty linked. I believe the thinking was that if you are able to 
log then you should stop sending. IMHO this is only true for the caller 
as the station running the frequency is obliged to keep sending RRR 
until they are sure that the caller has seen it, even though their end 
of the QSO is compete and they can log it. This made sense when the 
logging reminder only came up for 73 messages, now it also does for RRR 
messages and that is causing the problem here.


Maybe we should pop up the log QSO dialog but only disable auto Tx once 
the Ok has been clicked. Another option might be to split the setting 
into two options like "Prompt to Log QSO" and "Disable auto Tx *after* 
logging", the latter maybe only applying if the message that prompted 
logging was a 73 message.


There must be a way of doing this that satisfies all modes and operating 
methods.


73 & HNY
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

2017-01-02 Thread Jay Hainline

I figured out my issue with the auto sequencing stopping at RRR. It does not 
have anything to do with with prompt to log pop up. I had Disable TX after 
sending 73 checkmarked in Settings/General tab. For some reason, it is 
disabling TX after sending RRR instead.

 

 

73 Jay KA9CFD

 

From: Jay Hainline [mailto:ka9...@mtcnow.net] 
Sent: January 1, 2017 22:08
To: 'Black Michael'  >; 'WSJT 
software development'  >
Subject: RE: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

 

I don’t know for certain why this was changed in the first place except the 
JT65 HF crowd is always looking for a way to sidestep a sequence to shorten the 
time for a QSO. This does not work in the meteor scatter VHF world where you 
are relying on random data bits to fly in on a meteor for less than 1 second 
and you are trying to decode just what the guy on the other end has received. 
If it aint broke, don’t fix it.

 

I hope I don’t get black balled for being negative like the Ham Radio Deluxe 
people do to users of their software. Lol ;-)

 

73 Jay KA9CFD

 

From: Black Michael [  mailto:mdblac...@yahoo.com] 
Sent: Sunday, January 1, 2017 3:39 PM
To: WSJT software development <  
wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

 

I think the consensus solution would be to make it a user option.

Seems the meteor scatter people have the most problems with it since they were 
quick to speak up.

 

I had proposed at one time to make the "Prompt me to log QSO" a tri-state box 
so one could check 73, 73+RRR, or none.  But seems the binary choice is clearer 
and there are no other tri-state checkboxes in WSJT-X.

 

So this patch makes it optional with an added option line below the current 
prompt option.  All worlds should be happy with this.

 

  
https://www.dropbox.com/s/s5xwpc39bubmzxx/rrr_option.patch?dl=1

 

 

de Mike W9MDB

 

 

  _  

From: Seb <  w...@miamisky.com>
To: WSJT software development <  
wsjt-devel@lists.sourceforge.net> 
Sent: Sunday, January 1, 2017 1:26 PM
Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

 

IMHO the introduction of the log QSO prompt when you are sending RRR does not 
solve or help anything.  

 

It is useless when you are doing meteor scatter. If I’m sending Tx3 and the 
other station hears that and sends Tx4 and then logs the contact, it is not a 
valid QSO because I have no idea if the other station has heard my report.  I 
will end up sending Tx3 several times until I just give up on the contact.

 

73 de Sebastian, W4AS



 

On Jan 1, 2017, at 9:38 AM, Jay Hainline <  
ka9...@mtcnow.net> wrote:

 

This was introduced in r7431. I think its bad form to get a prompt to log the 
QSO when you are sending RRR. How do you know if your QSO partner has received 
it if he does not send 73 back to you??

 

Jay Hainline KA9CFD

Colchester, IL  EN40om

 

 

 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org!   
http://sdm.link/slashdot

 

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

 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Ideas for Development

Re: [wsjt-devel] MSK144 Timing Flag?

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Ideas for Development

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] MSK144 Timing Flag?

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] MSK144 Timing Flag?

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] MSK144 Timing Flag?

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

[wsjt-devel] MSK144 Timing Flag?

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Disable Tx after RRR/73

Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

34 matches

Site Navigation

Mail list logo

Footer information