Re: [wsjt-devel] "NO RCV 75 BIT"

[Wolfgang]

Hello Gary,

I saw this in a QSO too. ??? It is like you are holding a printed
sign in front of a blind person and waiting for an reaction.

If you TX those texts in 77bit, only the ones with 77bits can read it
and "NO RCV 75 BIT" is like talking to yourself. For the ones using
RC4 or RC5 in 77bit mode, the messages are useless cycles and all
1.9.1 user will never ever see it, because 1.9.1 can not decode your
77bit messages.

73's de OE1MWW
Wolfgang

Thursday, November 29, 2018, 5:57:08 AM, you wrote:


> I have composed and compiled a motley collection of free text
> messages to send in sequence or sporadically between CQs e.g.
> “WSJTX2 RC5 HR”, “77 BITS ONLY”, “NO RCV 75 BIT” and (in desperation) “PLS TX 
> 77 BITS”.

> Hey, it’s only a hobby!  I’ve made about 10 shiny-new FT8+ QSOs
> today, and about 50 old-skool FT8s … all while working on the other screen.

> 73
> Gary  ZL2iFB


--
Amateur radio is the most expensive type of free-of-charge communication!
Amateurfunk ist die teuerste Art der kostenlosen Kommunikation!



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

[wsjt-devel] Just Dupes, or Autodupes?

[John Zantek]

While everything functioned normally at my end of the world during this
evening's FT8 RU mock, I was puzzled by the number of dupes directed my way.

I was playing the role of a RUN station, transmitting at :00 and :30, and
had 3 stations who worked me, then turned around immediately and called me
again after our exchange was complete. E.g, he sent RR73, I sent 73, and
they would start over with a W7CD W1AA 579 MA.  In this particular case, the
call and state are only an example, not one of the actual three stations.

I'd write it off to simple testing by one operator, maybe even 2, but three?
Did anyone else experience this?  Has there been a contest mode exchange
condition that would cause this?  

Was I hallucinating?  :-)

73 John W7CD




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

Re: [wsjt-devel] 2 more bug reports on RC5

[Gary Hinson]

Good on yer, Chuck!

 

I have composed and compiled a motley collection of free text messages to send 
in sequence or sporadically between CQs e.g. “WSJTX2 RC5 HR”, “77 BITS ONLY”, 
“NO RCV 75 BIT” and (in desperation) “PLS TX 77 BITS”.

 

Hey, it’s only a hobby!  I’ve made about 10 shiny-new FT8+ QSOs today, and 
about 50 old-skool FT8s … all while working on the other screen.

 

73
Gary  ZL2iFB

 

From: Chuck Furman  
Sent: 29 November 2018 15:51
To: WSJT software development 
Subject: Re: [wsjt-devel] 2 more bug reports on RC5

 

It certainly is frustrating. I'm calling CQ and getting responses that are very 
strong, but will not decode. I assume they are using 75 bit to respond to me. I 
just sent a free text message "USE 77BIT" to one person and suddenly his signal 
magically started decoding :). Oh well, in spite of all the stubborn ops who 
won't upgrade, I'm making plenty of contacts anyway.

 

Chuck

KG6PH

 

 

On Wed, 28 Nov 2018 at 20:43, Gary Hinson mailto:g...@isect.com> > wrote:

Prior release candidates were able to decode both 75 AND 77-bit messages but 
since there are many more 75s than 77s floating about, users mostly send 75 bit 
responses … unless prompted … and even then it’s like pushing string uphill 
some days …

Those of us using RC5 can ONLY transmit and receive 77 bit messages.  

We can’t send 75 bit messages.  

We can’t decode 75 bit messages.  

We do not have the capability, in that release candidate, to encode or decode 
75 bit messages.  

75 bit messages are merely unsightly smears on our waterfalls.

We are stuck with 77 bits, no more, no less.  

76 bits won’t cut it, nor 78.  77½ bits would be OK but might break the laws of 
physics.

It’s 77 bits or bust, basically - mostly bust at present until word gets out 
about the sexy new version of FT8.  

In other words, we’re using FT8+ not FT8, pushing back the front ears.

73
Gary  ZL2iFB

 

From: Chuck Furman mailto:chuck.fur...@gmail.com> > 
Sent: 29 November 2018 14:30
To: WSJT software development mailto:wsjt-devel@lists.sourceforge.net> >
Subject: Re: [wsjt-devel] 2 more bug reports on RC5

 

I’m confused. Why is CQ 77 helpful?  Only people who are already on 77 bit mode 
will decode you. Am I missing something? I am just curious. It seem more useful 
to TX on 75 bits with something like “PSE USE 77BIT”

 

On Wed, Nov 28, 2018 at 7:23 PM Al Pawlowski mailto:k6...@almont.com> > wrote:

I have used “CQ 77 …..” a few times for the same thing and it is not very 
sticky also. In fact, even saved free text messages revert to the standard 
after any attempt to answer a call.

 

In addition, it appears double-clicking a received message with , which 
is what other non-standard CQ messages I’ve seen decode as (probably my 77 
also, will not initiate a return/answer sequence on double click - you have to 
start one manually (type callsign, generate messages, select TX1, enable tx). 
So, I only send a couple of the CQ 77 messages and followed by a standard CQ, 
or CQ DX.

 

 

Al Pawlowski, K6AVP
Los Osos, CA USA

Date: Thu, 29 Nov 2018 12:36:29 +1300

From: "Gary Hinson" <  g...@isect.com>
To: "'WSJT software development'" <  
wsjt-devel@lists.sourceforge.net>
Subject: [wsjt-devel] 2 more bug reports on RC5

………. I've tried sending "CQ PLUS ZL2IFB RF80" and
little free text messages to give more of a clue that I'm using the new 77
bit version . but I've noticed that the "PLUS" in my CQ message is not very
sticky.

 

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

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

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

Re: [wsjt-devel] Color scheme: "on band" always highest priority?

[Paul Kube]

Bill,

(I'll put this comment in this thread instead of starting a new one, since
you are the "color" guy :)

Is there any way to control colors of a non-CQ message? There doesn't seem
to be, and I would like to do that.

For example:, I'd like to have a visual cue when someone not in the log is
finishing a QSO, so I know they're not a dupe and I can tailend without
waiting for their next CQ: highlight their "W1XYZ K0ABC 73" message. (This
came up a lot in this evening's mock contest.)

Possible?

Thanks,

Paul K6PO

On Wed, Nov 28, 2018 at 1:42 PM Bill Somerville 
wrote:

> On 28/11/2018 21:22, DG2YCB, Uwe wrote:
>
> Just one further question: N9BUB is a new call for me, but also a new call
> on band. Thus, background color is assigned to the darker green and
> foreground color is assigned to blue. Correct? But that means that
> currently I cannot use the foreground color for differentiation between
> “totally new” and “new…on Band”, because a new call is always also a new
> call on band. Is that right?
>
> Hi Uwe,
>
> sure you can, make the "on band" highlight the higher priority of the two.
>
> I would suggest that using foreground colour for an "all bands" highlight
> type and background colour for its "on band" partner is wasteful, you would
> be better to stick to pairs either using different foreground or different
> background.
>
> Hmmm, perhaps the default ordering should the "on band" variants as higher
> priority than their "all band" partners, I will switch them around.
>
> 73
> Bill
> G4WJS.
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Quick Start WSJT-X 2.0 Errata

[Larry Phelps]

On page 5, LoTW Download Errors:

Note that Win32 OpenSSL is now at revision "q"

The new release works OK on my Win7 Pro 64


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

[wsjt-devel] "contest log" window does not scroll to bottom

[John Nogatch]

When a new QSO is added to the bottom of the "Contest Log" window, and
the window is full, the window does not scroll down to show the last
QSO that was just added.

This is on Ubuntu 18.04 GNOME.

-John AC6SL


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

Re: [wsjt-devel] Contest: Problems with exchange info logging

[Dave J Barnes]

Ubuntu 18.04 AMD64

4 contacts - first two had to enter "rpt sent" and "exch sent" in log 
dialog box.


Exited and restarted wsjt-x.

Second two, still had to enter "rpt sent" and "exch sent".  Both fields 
blank.


Log looks OK so far.

djb



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

Re: [wsjt-devel] 2 more bug reports on RC5

[Gary Hinson]

Ezacerly!  We 

 

Most non-standard/custom CQ messages are unclickable i.e. double-clicking them 
doesn’t trigger an automated-response because the software doesn’t know who to 
respond to.  They are treated as free-text messages.  They are not 
automatically interpreted as CQs.

 

FT8 lets us insert up to 2 characters (letters only, I think) into our CQs to 
make directed calls e.g. “CQ DX ZL2IFB RF80” or “CQ NA ZL2IFB RF80”.  These 
messages ARE clickable. 

 

FT8+ gives us up to 4 letters to play with e.g. “CQ TEST ZL2IFB RF80” or “CQ 
IOTA ZL2IFB RF80” or “CQ BOB ZL2IFB RF80”.  Again, these ARE clickable.  

 

73
Gary  ZL2iFB

 

PS  I presume the message type is indicated by flags in the transmitted 
message, not by the payload itself.  However, I’m not clear whether the message 
type is initially determined by the message box we use, or by the content of 
the message.  For instance, if I type “CQ ZL2IFB RF80” into the Tx 5 free-text 
box, is that sent as a clickable CQ message or an unclickable free text 
message?   

 

From: Al Pawlowski  
Sent: 29 November 2018 15:05
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] 2 more bug reports on RC5

 

Actually, I have never seen one of my 77 messages as decoded - just assumed it 
would decode as the bottom of pane tx message being sent read. I think all of 
the non-standard messages I tried to answer by double-click had no numbers in 
them, and they still did not auto-start.

 

Al Pawlowski, K6AVP
Los Osos, CA USA







On Nov 28, 2018, at 17:39, wsjt-devel-requ...@lists.sourceforge.net 
  wrote:

 

Date: Thu, 29 Nov 2018 14:38:39 +1300
From: "Gary Hinson" <  g...@isect.com>
To: "'WSJT software development'" <  
wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] 2 more bug reports on RC5
Message-ID: <  
058b01d48784$433a8b10$c9afa130$@isect.com>
Content-Type: text/plain; charset="utf-8"

HI Al.

As I understand it, the zero to 4 characters we can insert into a standard CQ 
message must be letters only ? no numbers ? if the recipients are to be able to 
double-click and respond to them.  That?s why I?m using ?CQ PLUS?.  It?s a 
limitation of the message compression ? not enough bits to code letters AND 
numbers in that field.  If we use numbers, the message changes to a normal 
free-text message format ? with no indication to the user that it is 
unclickable at the far end ?…...

 

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

Re: [wsjt-devel] 2 more bug reports on RC5

[Gary Hinson]

Prior release candidates were able to decode both 75 AND 77-bit messages but 
since there are many more 75s than 77s floating about, users mostly send 75 bit 
responses … unless prompted … and even then it’s like pushing string uphill 
some days …

Those of us using RC5 can ONLY transmit and receive 77 bit messages.  

We can’t send 75 bit messages.  

We can’t decode 75 bit messages.  

We do not have the capability, in that release candidate, to encode or decode 
75 bit messages.  

75 bit messages are merely unsightly smears on our waterfalls.

We are stuck with 77 bits, no more, no less.  

76 bits won’t cut it, nor 78.  77½ bits would be OK but might break the laws of 
physics.

It’s 77 bits or bust, basically - mostly bust at present until word gets out 
about the sexy new version of FT8.  

In other words, we’re using FT8+ not FT8, pushing back the front ears.

73
Gary  ZL2iFB

 

From: Chuck Furman  
Sent: 29 November 2018 14:30
To: WSJT software development 
Subject: Re: [wsjt-devel] 2 more bug reports on RC5

 

I’m confused. Why is CQ 77 helpful?  Only people who are already on 77 bit mode 
will decode you. Am I missing something? I am just curious. It seem more useful 
to TX on 75 bits with something like “PSE USE 77BIT”

 

On Wed, Nov 28, 2018 at 7:23 PM Al Pawlowski mailto:k6...@almont.com> > wrote:

I have used “CQ 77 …..” a few times for the same thing and it is not very 
sticky also. In fact, even saved free text messages revert to the standard 
after any attempt to answer a call.

 

In addition, it appears double-clicking a received message with , which 
is what other non-standard CQ messages I’ve seen decode as (probably my 77 
also, will not initiate a return/answer sequence on double click - you have to 
start one manually (type callsign, generate messages, select TX1, enable tx). 
So, I only send a couple of the CQ 77 messages and followed by a standard CQ, 
or CQ DX.

 

 

Al Pawlowski, K6AVP
Los Osos, CA USA

Date: Thu, 29 Nov 2018 12:36:29 +1300

From: "Gary Hinson" <  g...@isect.com>
To: "'WSJT software development'" <  
wsjt-devel@lists.sourceforge.net>
Subject: [wsjt-devel] 2 more bug reports on RC5

………. I've tried sending "CQ PLUS ZL2IFB RF80" and
little free text messages to give more of a clue that I'm using the new 77
bit version . but I've noticed that the "PLUS" in my CQ message is not very
sticky.

 

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

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

Re: [wsjt-devel] Disable New Grid Colors before test

[Bill Somerville]

On 29/11/2018 01:58, SKI W4PPC wrote:
After two QSO were logged now receiving Invalid QSO Data Check all 
fields (attached) but nothing shows errors!?


Hi OM,

so I can see what happened, can you zip and send me the file db.sqlite 
from your WSJT-X log directory please.


73
Bill
G4WJS.



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

Re: [wsjt-devel] Contest: Problems with exchange info logging

[Bill Somerville]

On 29/11/2018 02:05, Mark James wrote:

I seem to have run into an issue with the contest mode.

Sometimes -- not always -- the "Exch sent" and "Rpt sent" fields in 
the log window are not getting populated, even though the QSO worked fine.


This is an example QSO from the "ALL.TXT" file, for which I had the 
logging issue (with other station decodes removed):


015600 -13  0.4 1795 ~  CQ RU N6EE CM97
181129_015615  Transmitting 7.08 MHz  FT8:  N6EE KC1GWX 539 MA
015630 -14  0.3 1795 ~  KC1GWX N6EE R 549 CA
181129_015645  Transmitting 7.08 MHz  FT8:  N6EE KC1GWX RR73
015700  -8  0.4 1795 ~  KC1GWX N6EE 73

Mark, KC1GWX


Hi Mark,

although that shouldn't happen, you should be able to fill in the 
missing fields in the "Log QSO" window, log the QSO and continue.


73
Bill
G4WJS.



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

Re: [wsjt-devel] 2 more bug reports on RC5

[Al Pawlowski]

Actually, I have never seen one of my 77 messages as decoded - just assumed it 
would decode as the bottom of pane tx message being sent read. I think all of 
the non-standard messages I tried to answer by double-click had no numbers in 
them, and they still did not auto-start.

Al Pawlowski, K6AVP
Los Osos, CA USA



> On Nov 28, 2018, at 17:39, wsjt-devel-requ...@lists.sourceforge.net wrote:
> 
> Date: Thu, 29 Nov 2018 14:38:39 +1300
> From: "Gary Hinson" mailto:g...@isect.com>>
> To: "'WSJT software development'"  >
> Subject: Re: [wsjt-devel] 2 more bug reports on RC5
> Message-ID: <058b01d48784$433a8b10$c9afa130$@isect.com 
> >
> Content-Type: text/plain; charset="utf-8"
> 
> HI Al.
> 
> As I understand it, the zero to 4 characters we can insert into a standard CQ 
> message must be letters only ? no numbers ? if the recipients are to be able 
> to double-click and respond to them.  That?s why I?m using ?CQ PLUS?.  It?s a 
> limitation of the message compression ? not enough bits to code letters AND 
> numbers in that field.  If we use numbers, the message changes to a normal 
> free-text message format ? with no indication to the user that it is 
> unclickable at the far end ?…...

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

[wsjt-devel] Contest: Problems with exchange info logging

[Mark James]

I seem to have run into an issue with the contest mode.

Sometimes -- not always -- the "Exch sent" and "Rpt sent" fields in the log
window are not getting populated, even though the QSO worked fine.

This is an example QSO from the "ALL.TXT" file, for which I had the logging
issue (with other station decodes removed):

015600 -13  0.4 1795 ~  CQ RU N6EE CM97
181129_015615  Transmitting 7.08 MHz  FT8:  N6EE KC1GWX 539 MA

015630 -14  0.3 1795 ~  KC1GWX N6EE R 549 CA
181129_015645  Transmitting 7.08 MHz  FT8:  N6EE KC1GWX RR73

015700  -8  0.4 1795 ~  KC1GWX N6EE 73

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

Re: [wsjt-devel] Disable New Grid Colors before test

[SKI W4PPC]

After two QSO were logged now receiving Invalid QSO Data Check all fields
(attached) but nothing shows errors!?

On Wed, Nov 28, 2018 at 7:54 PM Don Hill AA5AU  wrote:

> Stations worked in the Roundup practice session are showing as new grids
> after they are worked and logged. The solution is to uncheck "New Grid" and
> "New Grid on Band" on the Colors tab of Settings.
>
> Now, worked stations are shown in Green as they should.
>
> Don AA5AU
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Disable New Grid Colors before test

[Don Hill AA5AU]

Stations worked in the Roundup practice session are showing as new grids
after they are worked and logged. The solution is to uncheck "New Grid" and
"New Grid on Band" on the Colors tab of Settings.

Now, worked stations are shown in Green as they should.

Don AA5AU



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

Re: [wsjt-devel] 2 more bug reports on RC5

[Chuck Furman]

Thank you. I knew I was missing something.

On Wed, Nov 28, 2018 at 7:38 PM Bill Somerville 
wrote:

> On 29/11/2018 01:30, Chuck Furman wrote:
> > I’m confused. Why is CQ 77 helpful?
>
> Hi Chuck,
>
> the idea is a hint to v2.0.0 RC3 or RC4 users who probably will not have
> their "Force 77-bit Transmissions" option checked. They will decode
> 77-bit but reply in 75-bit. If they are still following the
> recommendations that came with the versions they are using then on 7074
> and 14074 they will have 77-bit Tx switched off, 77-bit QSOs were
> originally recommended to run on 7078 and 14078.
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2 more bug reports on RC5

[Gary Hinson]

HI Al.

 

As I understand it, the zero to 4 characters we can insert into a standard CQ 
message must be letters only – no numbers – if the recipients are to be able to 
double-click and respond to them.  That’s why I’m using “CQ PLUS”.  It’s a 
limitation of the message compression – not enough bits to code letters AND 
numbers in that field.  If we use numbers, the message changes to a normal 
free-text message format … with no indication to the user that it is 
unclickable at the far end …

 

Yes, the disappearing custom 73 messages can be a bit annoying at times.  Also, 
it would be nice if clicking the ‘Generate std messages’ button re-generated 
the complete set of standard messages on demand, for those occasions when we 
mess up our custom messages, typing ineptly against the clock!

73
Gary  ZL2iFB

 

From: Al Pawlowski  
Sent: 29 November 2018 14:19
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] 2 more bug reports on RC5

 

I have used “CQ 77 …..” a few times for the same thing and it is not very 
sticky also. In fact, even saved free text messages revert to the standard 
after any attempt to answer a call.

 

In addition, it appears double-clicking a received message with , which 
is what other non-standard CQ messages I’ve seen decode as (probably my 77 
also, will not initiate a return/answer sequence on double click - you have to 
start one manually (type callsign, generate messages, select TX1, enable tx). 
So, I only send a couple of the CQ 77 messages and followed by a standard CQ, 
or CQ DX.

 

 

Al Pawlowski, K6AVP
Los Osos, CA USA



Date: Thu, 29 Nov 2018 12:36:29 +1300

From: "Gary Hinson" <  g...@isect.com>
To: "'WSJT software development'" <  
wsjt-devel@lists.sourceforge.net>
Subject: [wsjt-devel] 2 more bug reports on RC5

………. I've tried sending "CQ PLUS ZL2IFB RF80" and
little free text messages to give more of a clue that I'm using the new 77
bit version . but I've noticed that the "PLUS" in my CQ message is not very
sticky.

 

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

Re: [wsjt-devel] 2 more bug reports on RC5

[Bill Somerville]

On 29/11/2018 01:30, Chuck Furman wrote:

I’m confused. Why is CQ 77 helpful?


Hi Chuck,

the idea is a hint to v2.0.0 RC3 or RC4 users who probably will not have 
their "Force 77-bit Transmissions" option checked. They will decode 
77-bit but reply in 75-bit. If they are still following the 
recommendations that came with the versions they are using then on 7074 
and 14074 they will have 77-bit Tx switched off, 77-bit QSOs were 
originally recommended to run on 7078 and 14078.


73
Bill
G4WJS.



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

Re: [wsjt-devel] 2 more bug reports on RC5

[Chuck Furman]

I’m confused. Why is CQ 77 helpful?  Only people who are already on 77 bit
mode will decode you. Am I missing something? I am just curious. It seem
more useful to TX on 75 bits with something like “PSE USE 77BIT”

On Wed, Nov 28, 2018 at 7:23 PM Al Pawlowski  wrote:

> I have used “CQ 77 …..” a few times for the same thing and it is not very
> sticky also. In fact, even saved free text messages revert to the standard
> after any attempt to answer a call.
>
> In addition, it appears double-clicking a received message with ,
> which is what other non-standard CQ messages I’ve seen decode as (probably
> my 77 also, will not initiate a return/answer sequence on double click -
> you have to start one manually (type callsign, generate messages, select
> TX1, enable tx). So, I only send a couple of the CQ 77 messages and
> followed by a standard CQ, or CQ DX.
>
>
> Al Pawlowski, K6AVP
> Los Osos, CA USA
>
>
> Date: Thu, 29 Nov 2018 12:36:29 +1300
> From: "Gary Hinson" 
> To: "'WSJT software development'" 
> Subject: [wsjt-devel] 2 more bug reports on RC5
>
> ………. I've tried sending "CQ PLUS ZL2IFB RF80" and
> little free text messages to give more of a clue that I'm using the new 77
> bit version . but I've noticed that the "PLUS" in my CQ message is not very
> sticky.
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2 more bug reports on RC5

[Al Pawlowski]

I have used “CQ 77 …..” a few times for the same thing and it is not very 
sticky also. In fact, even saved free text messages revert to the standard 
after any attempt to answer a call.

In addition, it appears double-clicking a received message with , which 
is what other non-standard CQ messages I’ve seen decode as (probably my 77 
also, will not initiate a return/answer sequence on double click - you have to 
start one manually (type callsign, generate messages, select TX1, enable tx). 
So, I only send a couple of the CQ 77 messages and followed by a standard CQ, 
or CQ DX.


Al Pawlowski, K6AVP
Los Osos, CA USA


> Date: Thu, 29 Nov 2018 12:36:29 +1300
> From: "Gary Hinson" mailto:g...@isect.com>>
> To: "'WSJT software development'"  >
> Subject: [wsjt-devel] 2 more bug reports on RC5
> 
> ………. I've tried sending "CQ PLUS ZL2IFB RF80" and
> little free text messages to give more of a clue that I'm using the new 77
> bit version . but I've noticed that the "PLUS" in my CQ message is not very
> sticky.

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

Re: [wsjt-devel] ISCAT Problem?

[k6cks01]

Thanks Joe!


Sent via the Samsung Galaxy S®6 active, an AT 4G LTE smartphone
 Original message From: Joe Taylor  Date: 
11/28/18  6:41 PM  (GMT-06:00) To: WSJT software development 
 Subject: Re: [wsjt-devel] ISCAT Problem? 
On 11/27/2018 10:20 AM, Rory Bowers K5CKS wrote:
> Is there a chance you will change that to a double click Joe?  

No.  ISCAT uses free-form messages.  It's totally unsuited to 
double-clicking or Auto-Sequencing logic.

> I think 
> ISCAT could be a LOT of fun.  I was amazed at the sensitivity!!

It can be a lot of fun.  But most QSOs you can make with ISCAT, you can 
also make with MSK144, probably even easier.  There is a fairly narrow 
range of circumstances in which ISCAT is, or should be, the preferred mode.
-- Joe, K1JT


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

Re: [wsjt-devel] ISCAT Problem?

[Joe Taylor]

On 11/27/2018 10:20 AM, Rory Bowers K5CKS wrote:
Is there a chance you will change that to a double click Joe?  


No.  ISCAT uses free-form messages.  It's totally unsuited to 
double-clicking or Auto-Sequencing logic.


I think 
ISCAT could be a LOT of fun.  I was amazed at the sensitivity!!


It can be a lot of fun.  But most QSOs you can make with ISCAT, you can 
also make with MSK144, probably even easier.  There is a fairly narrow 
range of circumstances in which ISCAT is, or should be, the preferred mode.

-- Joe, K1JT


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

[wsjt-devel] ISCAT question

[k6cks01]

Have you given any more thought to improvements to ISCAT Joe??
Rory, K5CKS 

Sent via the Samsung Galaxy S®6 active, an AT 4G LTE smartphone___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] 2 more bug reports on RC5

[Gary Hinson]

I'm running RC5 on the air for about an hour a day from NZ.   Aside from
transmitting above 2000 Hz, I've tried sending "CQ PLUS ZL2IFB RF80" and
little free text messages to give more of a clue that I'm using the new 77
bit version . but I've noticed that the "PLUS" in my CQ message is not very
sticky.  If I meddle with the F2 settings (or simply open F2 settings then
OK it, with no changes) or complete a QSO, the "PLUS" gets dropped from my
CQ message as it reverts to the default generated message "CQ ZL2IFB RF80".
If this still occurs when people are using those 4 characters 'for real' to
send CQ DX or CQ NONA or CQ TEST or whatever, this will be more of an
annoyance.

Also, by the way, I have seen RC5 transmit " ZL2IFB RF80" at least
once - presumably sending a hashed message?  This happened more often with
the previous release but something is still not quite right there.  I think
the button shows the message as "CQ plus ZL2IFB RF80" when it sends the
hashed version, so it looks like whatever updates it to all uppercase
prevents the hashing.

73
Gary  ZL2iFB

PS  The team's lack of response to my previous RC5 bug report suggests maybe
I'm whistling down the wind here . but I'm dutifully reporting bugs as
requested .  QSL?

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

[wsjt-devel] (no subject)

[Charlie Carlsson]

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

Re: [wsjt-devel] Color scheme: "on band" always highest priority?

[Bill Somerville]

On 28/11/2018 21:22, DG2YCB, Uwe wrote:
Just one further question: N9BUB is a new call for me, but also a new 
call on band. Thus, background color is assigned to the darker green 
and foreground color is assigned to blue. Correct? But that means that 
currently I cannot use the foreground color for differentiation 
between “totally new” and “new…on Band”, because a new call is always 
also a new call on band. Is that right?


Hi Uwe,

sure you can, make the "on band" highlight the higher priority of the two.

I would suggest that using foreground colour for an "all bands" 
highlight type and background colour for its "on band" partner is 
wasteful, you would be better to stick to pairs either using different 
foreground or different background.


Hmmm, perhaps the default ordering should the "on band" variants as 
higher priority than their "all band" partners, I will switch them around.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Color scheme: "on band" always highest priority?

[Bill Somerville]

On 28/11/2018 20:07, Paul Kube wrote:
This way of doing things does provide some nice flexibility as you 
point out. It is rather counterintuitive though; for example there is 
no way to tell by looking at the color settings whether a foreground 
color is set to black, or is not specified. I'm still not sure I 
really understand it, but I do have it working the way I want now. 
Thanks again.


Hi Paul,

I am working on some extra menu options to "unset" the colours so you 
can take full advantage of the fall-through facility. I agree it is 
complex but if users tale a step back and work out what their top 
priorities are for DX chasing then only enable highlighting for a couple 
of them; then they should get maximum value from the limited 
highlighting options. Just turning everything on is bound to lead to 
confusion.


73
Bill
G4WJS.



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

Re: [wsjt-devel] [RTTY] "FT8 Roundup" mock contest [Two Sessions]

[Joe Taylor]

Hi Phil and Ed,

Thanks for sharing your views.

We thought long and hard about backward-compatibility issues before 
concluding that a change in the FT8 protocol was highly desirable.


Among the most important motivations were these:

1. Message formats optimized for North American VHF contests, European 
VHF contests, RTTY contests, and ARRL Field Day have been frequently 
requested by users.


2. Nonstandard and compound callsigns were a perpetual nuisance with the 
older protocols.  The new capabilities make them a breeze.


Neither of these objectives could be met with the original FT8 and 
MSK144 message payloads.


Our planned changes were publicized well in advance.  We sent internal 
details and source code to developers of the derivative programs JTDX 
and MSHV well in advance.  These guys are fully on board with the changes.


A number of other relevant considerations were spelled out very 
effectively by Ed, W0YK, in a previous message.


Upgrading to WSJT-X 2.0 will not be a big imposition.  Download, click 
to install over your older version, read and pay attention to the 
Release Notes, and away you go.


-- 73, Joe, K1JT

On 11/28/2018 2:37 PM, Ed Muns wrote:

Hi Phil.

This question is really for the WSJT development team to address.  But, my
personal opinion as a user differs a bit from yours.  I'll offer it here as
another perspective.

In general, I agree with your stated principle of backward compatibility.
At the same time I tolerate breaking the principle for good reason.  And, in
this case, I believe there is good reason.

First of all, WSJT-X is not a commercial product and the developers aren't
compensated much (tongue-in-cheek) for their tremendous efforts.  Second,
this mode was invented 1-1/2 years ago and should rationally be considered
as still in development.  Third, the use cases for this wonderful mode are
very diverse so a lot of conflicting requirements are being juggled.
Fourth, the WSJT-X source code is fully open for others to use.  There is no
monopoly.

I am delighted to be able to participate as a user in this state-of-the-art
development and believe the developers try hard to maintain backward
compatibility when they can.  The exception we're traversing now is
acceptable to me, even though it is a bit inconvenient and perhaps even
annoying to some.

When I start using a mode that is still being actively developed, my
expectation is that there well could be migration bumps and other
inconveniences.  That's been my frequent experience when I choose to be an
early adopter.  My alternative would be to stick with a digital mode like
RTTY that is unlikely to have backward compatibility issues.

I think the FT8 backward compatibility issue is exacerbated by the explosive
popularity of the mode on HF.  I'm sure the WSJT-X developers understand
this reality and respect user convenience balanced with striving to make FT8
the best it can be.

Ed W0YK

-Original Message-
From: Phil Sussman [mailto:psuss...@pactor.com]
Sent: 28 November, 2018 03:09
To: Ed W0YK
Cc: 'WSJT software development'; r...@groups.io; 'NCCC Reflector'
Subject: Re: [RTTY] "FT8 Roundup" mock contest [Two Sessions]
Importance: High

I am concerned that transition to Ver. 2.0 without backwards compatibility
to
previous versions is a serious shortfall. I do NOT plan to change because of
the lack of compatibility. There is a principle involved.

Not everyone is going to make the transition and I've spoken to others who
feel WSJT software is trying to monopolize the mode. (Those using JTDX and
some others.) Personally I don't care; however, as I mentioned backwards
compatibility is a must. Complexities aside, it's a basic concept that
should
be respected.

As someone who works with commercial software (e.g. Motorola, Harris, etc.)
all can be upgraded, but is always backwards compatible. Of course, that
makes future software revisions more complex, the price of maintaining a
base
of satisfied users who rely on support.

Thanks for reading and understanding.

73 de Phil - N8PS

---

Quoting Ed W0YK :


In addition to this practice contest just prior to the actual FT8 Roundup
next weekend, there will be an identical practice on Wednesday evening NA
time (0200-0300 UTC Thursday, 29 November).

Don and I feel another practice will be useful since we all need to ensure
we have installed and configured WSJT-X 2.0, rc5 correctly.  (rc4 will

also

work, but rc5 is preferred since it has improvements and bug fixes beyond
rc4.)

73,
Ed W0YK
Don AA5AU

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu]
Sent: 26 November, 2018 13:55
To: WSJT software development
Subject: [wsjt-devel] "FT8 Roundup" mock contest

Hi all,

Another one-hour "practice contest" is scheduled for Saturday, December
1, 0200-0300 UTC (that's Friday evening, Nov 30, NA time).  This session
will serve as a final tune-up opportunity for those planning to operate
in the "FT8 Roundup" on December 1-2 (more details 

Re: [wsjt-devel] [RTTY] "FT8 Roundup" mock contest [Two Sessions]

[Ed Muns]

Hi Phil.

This question is really for the WSJT development team to address.  But, my
personal opinion as a user differs a bit from yours.  I'll offer it here as
another perspective.

In general, I agree with your stated principle of backward compatibility.
At the same time I tolerate breaking the principle for good reason.  And, in
this case, I believe there is good reason.

First of all, WSJT-X is not a commercial product and the developers aren't
compensated much (tongue-in-cheek) for their tremendous efforts.  Second,
this mode was invented 1-1/2 years ago and should rationally be considered
as still in development.  Third, the use cases for this wonderful mode are
very diverse so a lot of conflicting requirements are being juggled.
Fourth, the WSJT-X source code is fully open for others to use.  There is no
monopoly.

I am delighted to be able to participate as a user in this state-of-the-art
development and believe the developers try hard to maintain backward
compatibility when they can.  The exception we're traversing now is
acceptable to me, even though it is a bit inconvenient and perhaps even
annoying to some.

When I start using a mode that is still being actively developed, my
expectation is that there well could be migration bumps and other
inconveniences.  That's been my frequent experience when I choose to be an
early adopter.  My alternative would be to stick with a digital mode like
RTTY that is unlikely to have backward compatibility issues.

I think the FT8 backward compatibility issue is exacerbated by the explosive
popularity of the mode on HF.  I'm sure the WSJT-X developers understand
this reality and respect user convenience balanced with striving to make FT8
the best it can be.

Ed W0YK

-Original Message-
From: Phil Sussman [mailto:psuss...@pactor.com] 
Sent: 28 November, 2018 03:09
To: Ed W0YK
Cc: 'WSJT software development'; r...@groups.io; 'NCCC Reflector'
Subject: Re: [RTTY] "FT8 Roundup" mock contest [Two Sessions]
Importance: High

I am concerned that transition to Ver. 2.0 without backwards compatibility
to
previous versions is a serious shortfall. I do NOT plan to change because of
the lack of compatibility. There is a principle involved.

Not everyone is going to make the transition and I've spoken to others who
feel WSJT software is trying to monopolize the mode. (Those using JTDX and
some others.) Personally I don't care; however, as I mentioned backwards
compatibility is a must. Complexities aside, it's a basic concept that
should
be respected.

As someone who works with commercial software (e.g. Motorola, Harris, etc.)
all can be upgraded, but is always backwards compatible. Of course, that
makes future software revisions more complex, the price of maintaining a
base
of satisfied users who rely on support.

Thanks for reading and understanding.

73 de Phil - N8PS

---

Quoting Ed W0YK :

> In addition to this practice contest just prior to the actual FT8 Roundup
> next weekend, there will be an identical practice on Wednesday evening NA
> time (0200-0300 UTC Thursday, 29 November).
>
> Don and I feel another practice will be useful since we all need to ensure
> we have installed and configured WSJT-X 2.0, rc5 correctly.  (rc4 will
also
> work, but rc5 is preferred since it has improvements and bug fixes beyond
> rc4.)
>
> 73,
> Ed W0YK
> Don AA5AU
>
> -Original Message-
> From: Joe Taylor [mailto:j...@princeton.edu]
> Sent: 26 November, 2018 13:55
> To: WSJT software development
> Subject: [wsjt-devel] "FT8 Roundup" mock contest
>
> Hi all,
>
> Another one-hour "practice contest" is scheduled for Saturday, December
> 1, 0200-0300 UTC (that's Friday evening, Nov 30, NA time).  This session
> will serve as a final tune-up opportunity for those planning to operate
> in the "FT8 Roundup" on December 1-2 (more details below).
>
> DIAL FREQUENCIES
> 
>
> The practice event will use dial frequencies 7.080-7.100 and
> 14.130-14.150 MHz in 2 kHz increments -- the same as recommended for the
> FT8 Roundup and the ARRL RTTY Roundup (January 5-6, 2019).  Start at the
> low end, dial frequency 7.080 or 14.130.  If/when the lower sub-bands
> fill up, QSY upward in 2 kHz increments (7.082, 7.084, etc.).  (Use
> keyboard shortcuts Ctrl+Shift+F11 and Ctrl+Shift+F12 to move dial
> frequency down/up by 2 kHz.)
>
> Everyone works everyone.  Do not use a compound or nonstandard callsign
> in this event.
>
> To participate you must use WSJT-X 2.0 RC5 (or RC4, but RC5 is
> preferred).  Installation packages for RC5 in Windows, Linux, and macOS
> can be found near the bottom of this web page:
> https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
>
> A revised "Quick-Start Guide to WSJT-X 2.0" for RC5 is posted here:
> https://physics.princeton.edu/pulsar/k1jt/Quick_Start_WSJT-X_2.0.pdf
> Be sure to read this entire document before using WSJT-X 2.0.
>
> PREPARATION FOR THE MOCK CONTEST
> 
>
> Detailed setup instructions for the 

[wsjt-devel] WSJT-X Not Re-reading the Log File When Toggling Show DXCC, Grid, and Worked-Before Status

[bobraymond]

Hi gang,

 

For those of us wanting to import ADIF files from other sources into WSJT-X,
this feature, documented in the most-recent released user guide, is not
working in RC5: 

". turning Show DXCC entity and worked before status off and then on again
will cause WSJT-X to re-read the log file."

To test, I:

 

1.  Erased the wsjtx_log.adi file from the File menu of WSJT-X
V2.0.0-rc5, leaving WSJT-X up and running.
2.  Verified that all in-coming decodes were not "worked-before." 
3.  Populated the wsjtx_log.adi with FT8 contacts made on 160 through 2
meters.
4.  Toggled Show DXCC, Grid, and Worked-Before Status off then on. Saved
Settings.
5.  Verified that all in-coming decodes were not "worked-before." The
wsjtx_log.adi file had not been imported.
6.  Toggled Show DXCC, Grid, and Worked-Before Status off and saved
Settings. Then re-accessed Settings and toggled Show DXCC, Grid, and
Worked-Before Status on. Saved Settings.
7.  Verified that all in-coming decodes were not "worked-before." The
wsjtx_log.adi file had not been imported.
8.  Rebooted WSJT-X and observed the expected worked-before behavior as
the wsjtx_log.adi file had been imported. 

 

Prior to V2.0, I noticed that all one had to do to import (or re-import) the
wsjtx_log.adi into WSJT-X, was to simply press F2 and Enter (essentially
togging Settings) as long as Show DXCC entity and worked before status was
on. Easy and convenient, in my opinion.

 

Is there any interest in making it easy/convenient to have WSJT-X
read/re-read the wsjtx_log.adi file on demand, perhaps via a keyboard
shortcut?

 

Thanks for your consideration and for a wonderful program!

 

73,

 

Bob Raymond, NE1I

bobraym...@dxtreme.com  

 

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

Re: [wsjt-devel] Rcvd Exch

[Ryan Tourge]

Oh disregard I just noticed the bottom right Recd box.

On Wed, Nov 28, 2018 at 1:05 PM Ryan Tourge  wrote:

> The signal strength report you received from the other station.
>
> On Wed, Nov 28, 2018 at 1:01 PM Al  wrote:
>
>> When not in contest mode, what does the rcvd field signify on the log
>> form ?
>>
>>
>> AL, K0VM
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Rcvd Exch

[Al]

When not in contest mode, what does the rcvd field signify on the log form ?


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

Re: [wsjt-devel] WSJT-X 2.0 rc5: Open list problem

[John Nelson]

Hi Bill,

You are right.   Thanks for spotting the wrong chevron.

Problem solved.

— John G4KLA

smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] LoTW / No LoTW

[Jim Nuytens]

As a non-LoTW user, I'd have to agree with Uwe.

I'd much prefer there be a way to highlight non-LoTW folks. Maybe that 
way, folks in the USA who do use LoTW would stop calling me, especially 
when I'm calling for DX.



On 11/28/2018 15:14, DG2YCB, Uwe wrote:


May I ask you for a slight change in the logics regarding the 
highlighting of LoTW? Seems that there are only a very few stations 
NOT using LoTW. Means when LoTW option is selected, nearly all text is 
in red color (as for LoTW users foreground color is red). 
Consequently, any other use of differentiation by foreground color is 
more or less impossible. (In addition, currently LoTW / no LoTW 
currently seems to have highest priority.)


I would really appreciate, if the logic is the other way round, so 
that only stations NOT using LoTW are highlighted by red foreground 
color. If you cannot agree in that, perhaps you can make the logic for 
LoTW / No LoTW switchable?






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

Re: [wsjt-devel] RC5 Colors

[Al]

Bill,
  No, I have I never imported an ADIF into WSJT... This particular log 
was started new with RC4 and continued with RC5.


AL, K0VM

On 11/27/2018 3:47 PM, Bill Somerville wrote:

On 27/11/2018 21:30, Al wrote:
Note below the change  in color for GW4HDR after I called him the 
first time..
Note also that even though I had just worked N8TCP, now colored for 
new call...


Hi Al,

there is one outstanding issue in the highlighting that I am aware of, 
it is related to imported ADIF log files. Have you used an export from 
some logging application to replace the wsjtx_log.adi file?


73
Bill
G4WJS.



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


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

Re: [wsjt-devel] LoTW / No LoTW

[Lee. KX4TT via wsjt-devel]

Thanks, All

Lee KX4TT

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 


You have complete freedom to set the colors as you wish.

-- Joe, K1JT





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

Re: [wsjt-devel] LoTW / No LoTW

[WB5JJJ]

It's not the colour, but the usefulness of the option.  So, it's
UNCHECKED.  Problem sorta solved.

On Wed, Nov 28, 2018 at 9:39 AM Bill Somerville 
wrote:

> On 28/11/2018 15:27, Lee. KX4TT via wsjt-devel wrote:
>
> It also does not work well with the green highlighting for those who are
> color-blind; People with either protanomaly  or deuteranomaly may have
> problems in this case. The result for red lettering on a green background
> can be two indistinct non-contrasting grays………..I would actually
> suggest not using red at all for this.
>
>
>
>
>
> 73 de Lee KX4TT
>
> Lee,
>
> the colour is user configurable.
>
> 73
> Bill
> G4WJS.
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


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

Re: [wsjt-devel] LoTW / No LoTW

[Joe Taylor]

Lee --

On 11/28/2018 10:27 AM, Lee. KX4TT via wsjt-devel wrote:
It also does not work well with the green highlighting for those who are 
color-blind; People with either protanomaly  or deuteranomaly may have 
problems in this case. The result for red lettering on a green 
background can be two indistinct non-contrasting grays………..I would 
actually suggest not using red at all for this.


73 de Lee KX4TT


You have complete freedom to set the colors as you wish.

-- Joe, K1JT


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

Re: [wsjt-devel] LoTW / No LoTW

[Bill Somerville]

On 28/11/2018 15:14, DG2YCB, Uwe wrote:


May I ask you for a slight change in the logics regarding the 
highlighting of LoTW? Seems that there are only a very few stations 
NOT using LoTW. Means when LoTW option is selected, nearly all text is 
in red color (as for LoTW users foreground color is red). 
Consequently, any other use of differentiation by foreground color is 
more or less impossible. (In addition, currently LoTW / no LoTW 
currently seems to have highest priority.)


I would really appreciate, if the logic is the other way round, so 
that only stations NOT using LoTW are highlighted by red foreground 
color. If you cannot agree in that, perhaps you can make the logic for 
LoTW / No LoTW switchable?


Thanks for your understanding.


Hi Uwe,

you can get a similar effect by using a lower intensity colour for the 
LotW user highlighting. For example you might choose a mid-tone grey for 
the LotW highlighting foreground colour.


Another option is to disable LotW user highlighting if nearly all calls 
are highlighted. There seems little point in selecting LotW users 
specifically if the probability of QSO partners being LotW users is high.


73
Bill
G4WJS.

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

Re: [wsjt-devel] WSJT-X 2.0 rc5: Open list problem

[Bill Somerville]

On 28/11/2018 15:20, John Nelson wrote:

Hi Bill,

That does sort files in blocks of date order;  but within a block the sequence 
remains in numerical order.  I tried Data Modified and Data Created - which is 
effectively the same.   The drop down list doesn't have time ordered, ie:   ls 
-l

— John G4KLA


Hi John,

are you sure? I was under the impression that sort by date includes the 
time in the sort criteria. The files will appear in numerical order if 
you use "Date Created" as the numerical file name is the date and time.


73
Bill
G4WJS.



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

Re: [wsjt-devel] LoTW / No LoTW

[Lee. KX4TT via wsjt-devel]

It also does not work well with the green highlighting for those who are
color-blind; People with either protanomaly  or deuteranomaly may have
problems in this case. The result for red lettering on a green background
can be two indistinct non-contrasting grays.I would actually suggest
not using red at all for this.

 

 

73 de Lee KX4TT

 

 

 

From: DG2YCB, Uwe [mailto:dg2...@gmx.de] 



 

 

I would really appreciate, if the logic is the other way round, so that only
stations NOT using LoTW are highlighted by red foreground color. 

 

 

 

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

Re: [wsjt-devel] WSJT-X 2.0 rc5: Open list problem

[John Nelson]

Hi Steve,

> Personally, I prefer the naming convention the way it is now. I can tell 
> which files are FT8 and which are JT65 by their different name formats.

Good point.  I retract my suggestion…

— John G4KLA

smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.0 rc5: Open list problem

[Bill Somerville]

On 28/11/2018 14:34, John Nelson wrote:

I got caught out by the fact that the Open list is in strict numerical order 
not time order.


Hi John,

you can change the sort order for the Finder window:

Thank will list them in strict creation time order.

73
Bill
G4WJS.

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

Re: [wsjt-devel] WSJT-X 2.0 rc5: Open list problem

[Steven Franke via wsjt-devel]

> 
> *** Would it not be better if files were always numbered with 6 time digits 
> insted of a mix of 4 and 6 digits, then the list would be ordered in a 
> squential manner?

Hi John, 

Glad that you figured out what was going on. Personally, I prefer the naming 
convention the way it is now. I can tell which files are FT8 and which are JT65 
by their different name formats.

Steve



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

Re: [wsjt-devel] WSJT-X 2.0 rc5: Open list problem

[Joe Taylor]

Hi John,


Would it not be better if files were always numbered with 6 time digits insted 
of a mix of 4 and 6 digits, then the list would be ordered in a squential 
manner?


Possibly, but that's not the way we've done it.  Labeling files with 
4-digit times makes good sense for the modes with 60 s T/R sequences, 
and we've labeled them that way for nearly 20 years now.


-- Joe, K1JT


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

Re: [wsjt-devel] WSJT-X 2.0 rc5: Open list problem

[John Nelson]

Steve,

Agree there is not a problem.   I got caught out by the fact that the Open list 
is in strict numerical order not time order.

So my last FT8 WAV file was  181128_114500.wav before switching to JT65 and so 
I was looking for the JT65 files to appear next in the list.  

But  the first JT65 file is 181128.1146.wav in time order but in strict 
numerical order this appears at the very top of list before the first of the 
FT8 files for today, namely 181128_102015.wav

*** Would it not be better if files were always numbered with 6 time digits 
insted of a mix of 4 and 6 digits, then the list would be ordered in a 
squential manner?

— John G4KLA

smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FTDX3000 on 60m FT8

[Mike Saeger]

Yes, I could wideband the transceiver. I still don't understand why after a
transmission on 5.358.500 a CAT signal is being sent to the radio to change
frequency to 5.358.308 if I put 5.358.500 in the frequency dropdown box and
I turn off split operation. Apparently, this is NOT a bug in WSJT-x? This
is by design? Why? Is this a bug in Yaesu's firmware? Where is this
frequency coming from?

Mike



On Tue, Nov 27, 2018 at 5:19 PM Mike Saeger  wrote:

> My FTDX3000 works fine on FT8 on all bands except 60 meters.
> The FTDX3000 has preset channels. The channel in memory 3 is preset to
> 5.358.500. When I turn on Enable TX I can send one transmission. When the
> transmission is over, WSJT-X tries to set my VFO to 5.358.308.
> I don't know where this frequency is coming from because I manually added
> 5.358500 to the Frequency tab.
>
> The FTDX3000 will not transmit on this frequency. I have to push the
> MCH/GRP button, then the V/M button to get back to 5.358.500. The next
> transmission the same thing happens. When transmit is finished, WSJTX sets
> the VFO back to 5.358.308
> and transmit is locked out again.
>
> I have the Split operation set to NONE. I also tried Fake-It but that had
> the same result.
>
> I was able to make a contact by setting the Rig to NONE in the Radio tab
> and operate the PTT manually, but that is NOT a good option.
>
> What settings do I need to get it to work correctly?
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] tone markers in JT65

[Robert Rearden]

Peter,

I use a Mac computer and have observed this same behavior by rc5 on my 
computer. 
_

On Nov 27, 2018, at 9:35 PM, Peter Sumner  wrote:

Hello Dev team,
 while reading the last batch of posts here, I noticed a reference by another 
that their system appear to jump into JT9 in certain circumstances so while 
pondering what is going on with my RC5 install, I noticed the Red TX marker on 
the waterfall is the size I would expect for JT9 and not the wider one expected 
for JT65 A, B or C. When I do select JT65C I can start to see the RX tone 
marker but all scrunched up together, yet decoding of our local JT65B beacon 
works when I go back to JT65B.

When I select JT9 the RX and TX markers are the expected small complimentry 'u' 
and 'n' shapes, when I switch to JT65 the TX marker is the same narrow one it 
was for JT9.

As best as I can tell the actual decoder seems to be happy but the logic teling 
the Wide graph what to do seems to be confused.

O/S reasonably fresh install of Windows 10 Pro X64, all updates applied

Is it possible for others to please check the behaviour of the JT65 modes 
(VHF/UHF features enabled) ?
Regards,
Peter, vk5pj

> On Wed, Nov 28, 2018 at 10:17 AM Peter Sumner  wrote:
> Hello Dev team,
>   I was asked today about the tone markers in the Wide Graph when using JT65 
> as it would seem in V2.x these have been dropped.  Could not see any mention 
> of this in the release notes but guess it was a development decision, just 
> want to make sure it was not an unexpected outcome?
> 
> A side by side screen capture (1.91 and 2.0 TC5)  is here: 
> http://www.users.on.net/~pedroj/wsjtx/WSJT-JT65.JPG
> 
> Regards,
> Peter vk5pj
> 

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

[wsjt-devel] Odd occurance

[WB5JJJ]

I've noticed on RC5 that when I call CQ and a station answers, I have to
send their signal report at least twice before things move along.

In checking with the other station if they have JTAlert messaging on, they
do have their Auto Seq on, and are sending their Rxx information as normal.
I'm just not decoding it even though they show up in the WF more or less
the same signal display as when they responded to my CQ and no obvious
QRM.  This happens with all signals levels.  This does not happen for all
responses, but enough that it got me wondering.

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

Re: [wsjt-devel] WSJT-X 2.0 rc5: Open list problem

[Steven Franke via wsjt-devel]

Hi John,

I haven’t noticed that problem here on MacOS 10.14. 

Steve, k9an

> On Nov 28, 2018, at 7:03 AM, John Nelson  wrote:
> 
> macOS 10.13.6:   v2.0.0-rc5:
> 
> FT8 is working well, colours included, on 20m, 30m and 40m.   Several reports 
> of -24 dB so sensitivity is vey good.
> 
> I switched to JT65 for checks - all well.  But, when attempting to decode a 
> saved JT65 WAV file I notice that in the “Open” list, only FT8 WAV files are 
> shown and no JT65 WAV files although all the files are present in the Save 
> directory.
> 
> Next step:  select Open: select the FT8 WAV file immediately preceeding the 
> set of JT65 WAV files; this is loaded;  then select “Open next in directory” 
> and the first JT65 WAV file is decoded; “Open next in directory” continues 
> with the set of JT65 WAV files.
> 
> I find that the same curiosity is found with v1.9.1
> 
> Is the faulty loading of the Save directory a macOS problem?
> 
> — John G4KLA___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



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

Re: [wsjt-devel] Fwd: FTDX3000 on 60m FT8

[Eric Evans]

Plenty of vids on you tube to wideband the 3000.
Eric J Evans
FCC Licensed Amateur Radio Operator: *K4NDN*
Elkton, Virginia 22827
Grid FM08qj
540.335.6178


On Wed, Nov 28, 2018 at 5:02 AM Claude Frantz 
wrote:

> On 11/28/18 12:29 AM, Mike Saeger wrote:
>
> > My FTDX3000 works fine on FT8 on all bands except 60 meters.
> > The FTDX3000 has preset channels. The channel in memory 3 is preset to
> > 5.358.500.
>
> Hi Mike,
>
> The XCVR's from Yaesu have often differences depending on the countries
> where they are sold. This "configuration" is often done by solder
> bridges in the XCVR. You can change these if you known what you are
> doing. After such a modification of the bridges, a RESET of the XCVR is
> often necessary at the next power on of the device. Then, all the
> previous settings are lost. You have to set them again.
>
> The details are probably available in the maintenance manual.
>
> Best wishes,
> Claude (DJ0OT)
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.0 rc5: Open list problem

[John Nelson]

macOS 10.13.6:   v2.0.0-rc5:

FT8 is working well, colours included, on 20m, 30m and 40m.   Several reports 
of -24 dB so sensitivity is vey good.

I switched to JT65 for checks - all well.  But, when attempting to decode a 
saved JT65 WAV file I notice that in the “Open” list, only FT8 WAV files are 
shown and no JT65 WAV files although all the files are present in the Save 
directory.

Next step:  select Open: select the FT8 WAV file immediately preceeding the set 
of JT65 WAV files; this is loaded;  then select “Open next in directory” and 
the first JT65 WAV file is decoded; “Open next in directory” continues with the 
set of JT65 WAV files.

I find that the same curiosity is found with v1.9.1

Is the faulty loading of the Save directory a macOS problem?

— John G4KLA

smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Fwd: FTDX3000 on 60m FT8

[Claude Frantz]

On 11/28/18 12:29 AM, Mike Saeger wrote:


My FTDX3000 works fine on FT8 on all bands except 60 meters.
The FTDX3000 has preset channels. The channel in memory 3 is preset to 
5.358.500.


Hi Mike,

The XCVR's from Yaesu have often differences depending on the countries 
where they are sold. This "configuration" is often done by solder 
bridges in the XCVR. You can change these if you known what you are 
doing. After such a modification of the bridges, a RESET of the XCVR is 
often necessary at the next power on of the device. Then, all the 
previous settings are lost. You have to set them again.


The details are probably available in the maintenance manual.

Best wishes,
Claude (DJ0OT)


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