Re: [wsjt-devel] S+P operation

[Paul Kube]

The documentation
http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf says,
re S+P: "Here “best potential QSO partner” means “New Multiplier” (1st
priority) or “New Call on Band” (2nd priority)."

Now it seems to me that "New Call" implies "New Call on Band", and so
should qualify as a potential QSO partner.

However, in my setup, it does not. (That is, a new call on the band can
trigger the S+P response; while entirely new call, i.e. new on all bands,
doesn't.)

73, Paul K6PO

P.S. I'm posting this as a reply to George's note, since its topic fits his
subject line. Just doing my part to try to keep comments here organized a
bit. I do not know how the developers continue to maintain their sanity
without a proper bug reporting and tracking system.


On Thu, May 2, 2019 at 7:45 AM WB5JJJ  wrote:

> Trying new features with FT4 and noticed that when S+P is active during
> non-CQ (receive only) operation, it will pounce on stations using directed
> calls such as CQ DX WB5JJJ EM35.  In a contest situation, which FT4 is
> designed for, this would be fine since there will not be any directed CQ's
> typically.  So, should this option not be shown on the main UI unless a
> contest is selected since it can cause frustration to some operators that
> don't want to be bothered by local stations pouncing on their directed CQ?
>
> Judging from some comments, it appears that FT4 may be the new norm for
> those seeking their first WAS, DXCC and not just contests.
>
> WB5JJJ - George
> ___
> 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] Bug Report

[Bill Somerville]

On 03/05/2019 01:27, Morris Wideman via wsjt-devel wrote:
Why would I want to call another station on top of someone else. If 
the TX/RX freqs are suppose to locked together thats what they should 
do, I do sometimes operate split but I try not to get on top of 
another station. 73 WA4MIT Morris


On Thursday, May 2, 2019, 5:44:44 PM CDT, Ron Koenig 
 wrote:



Why would you want to TX on his frequency ?

On Thu, 2 May 2019 at 15:30, Morris Wideman via wsjt-devel 
> wrote:


Many thanks to the development team for sharing FT4 with us all.
This faster FT should really help the DXpeditions and Contesters I
think it works great. Thank you all very much.
I do not believe this bug has been previously reported. When you
have answered a CQ (station 1) but get no response then proceed to
call a new station (2) and now station 1 answers you. When you
double click on his call to change to station 1 frequency the
receive channel changes to his freq but the TX does not it will
remain on present freq. Holding down the Ctrl key while double
clicking on station 1 will move both TX & RX and no I did not have
the Hold TX Freq selected it is doing this when it should be
locked together. Included 2 screen shots of this happening. Second
is a late return call from an EK station I have circled my return
to him at this time I was calling the TA station on another freq
as you see my return was on the TA freq not where the EK called me.
Otherwise I have managed to use FT4 RC5 with much success even it
seems to the contrary of the less sensitivity I seem to be reaching EU
with better results using less power?.
My Best 73 Morris WA4MIT


Hi Morris,

WSJT-X assumes you are still in the first QSO, if you want it to release 
the Tx frequency hold that is implicit in a QSO you must tell it you 
have abandoned the QSO. ESC to abort if you are transmitting or F4 is 
sufficient if you are not.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Bug Report

[Morris Wideman via wsjt-devel]

 Why would I want to call another station on top of someone else. If the TX/RX 
freqs are suppose to locked together thats what they should do, I do sometimes 
operate split but I try not to get on top of another station. 73 WA4MIT Morris 
On Thursday, May 2, 2019, 5:44:44 PM CDT, Ron Koenig  
wrote:  
 
 Why would you want to TX on his frequency ? 

On Thu, 2 May 2019 at 15:30, Morris Wideman via wsjt-devel 
 wrote:

Many thanks to the development team for sharing FT4 with us all. This faster FT 
should really help the DXpeditions and Contesters I think it works great. Thank 
you all very much.I do not believe this bug has been previously reported. When 
you have answered a CQ (station 1) but get no response then proceed to call a 
new station (2) and now station 1 answers you. When you double click on his 
call to change to station 1 frequency the receive channel changes to his freq 
but the TX does not it will remain on present freq. Holding down the Ctrl key 
while double clicking on station 1 will move both TX & RX and no I did not have 
the Hold TX Freq selected it is doing this when it should be locked together. 
Included 2 screen shots of this happening. Second is a late return call from an 
EK station I have circled my return to him at this time I was calling the TA 
station on another freq as you see my return was on the TA freq not where the 
EK called me.Otherwise I have managed to use FT4 RC5 with much success even it 
seems to the contrary of the less sensitivity I seem to be reaching EUwith 
better results using less power?.My Best 73 Morris 
WA4MIT___
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] Bug Report

[Ron Koenig]

Why would you want to TX on his frequency ?

On Thu, 2 May 2019 at 15:30, Morris Wideman via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Many thanks to the development team for sharing FT4 with us all. This
> faster FT should really help the DXpeditions and Contesters I think it
> works great. Thank you all very much.
> I do not believe this bug has been previously reported. When you have
> answered a CQ (station 1) but get no response then proceed to call a new
> station (2) and now station 1 answers you. When you double click on his
> call to change to station 1 frequency the receive channel changes to his
> freq but the TX does not it will remain on present freq. Holding down the
> Ctrl key while double clicking on station 1 will move both TX & RX and no I
> did not have the Hold TX Freq selected it is doing this when it should be
> locked together. Included 2 screen shots of this happening. Second is a
> late return call from an EK station I have circled my return to him at this
> time I was calling the TA station on another freq as you see my return was
> on the TA freq not where the EK called me.
> Otherwise I have managed to use FT4 RC5 with much success even it seems to
> the contrary of the less sensitivity I seem to be reaching EU
> with better results using less power?.
> My Best 73 Morris WA4MIT
> ___
> 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] TO19A dxped

[Iztok Saje]

Hi!

Yes, TO19A F/H is quite a confusion.
As nonstandard call, they can not send proper report.
Luckily, my call is short enough, so I get -1? report.

190502_11144521.078 Tx FT8  0  0.0 1710  S52D JN76
190502_11150021.078 Rx FT8  0  0.1  690 S52D TO19A -1
190502_11151521.078 Tx FT8  0  0.0  690  S52D R+00
190502_11153021.078 Rx FT8  2  0.1  510 S52D RR73; PA3ANF  -18

Funny, while normal answer is not OK, like:
190502_11123021.078 Rx FT8  7  0.1  510 EA1AHY TO19A
190502_11123021.078 Rx FT8  7  0.1  570 PA3ANF TO19A
190502_11123021.078 Rx FT8  7  0.1  630 JG1IGX TO19A
190502_11123021.078 Rx FT8  6  0.1  690 OK2LC TO19A +
190502_11123021.078 Rx FT8  6  0.1  750 IW6DGJ TO19A
All missing reports.
A lot of HAMs were lost, so RR73 messages were rare.

RR73 + report is OK.

Note: I tuned 200 Hz below nominal QRG to get their signal more into audio 
passband.

Some suggestions:
. 9A2AA/FR should work fine.
- limit number of streams, thus forcing more RR73 messages

As a side note, small nuisance for hounds:
If I click "P52D RR73; PA3ANF  -18 "to get their call,
WSJTX 2.0.1 selects RR73 not TO19A as DX call.
It took me a while to realize I am calling wrong call.


Best 73, sretno
Iztok, S52D

[http://psn.sdn.si/ts/neo-plus-naj-samopodpis_345x185.jpg]

Pravni pogoji / Legal disclaimer
Telekom Slovenije, d.d., Ljubljana 


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

Re: [wsjt-devel] FT8 decoding sensitivity: WSJT-X vs. JTDX

[Bill Somerville]

On 02/05/2019 21:27, Topher Petty wrote:
I tried to post wav files and a screenshot to back up my observations, 
but the message was rejected by the moderator.


Hi Topher,

this list limits the size of messages. You will have to post the file 
somewhere publicly visible and send a link.


73
Bill
G4WJS.



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

Re: [wsjt-devel] FT8 decoding sensitivity: WSJT-X vs. JTDX

[James Shaver]

.wav files are pretty big and it may cause issues for people with limited 
bandwidth internet connections who participate via email.  Perhaps host the 
.wav files via a third party site like SoundCloud, DropBox, or the like?

73,

Jim S. 
N2ADV (ex KD2BIP)

> On May 2, 2019, at 4:27 PM, Topher Petty  wrote:
> 
> I tried to post wav files and a screenshot to back up my observations, but 
> the message was rejected by the moderator.
> I do hope someone will look at the files, and they didn't just get lost to 
> the aether. I'd hate to think the information I attempted to provide would go 
> unused.
> 
> 
>> On Thu, May 2, 2019 at 1:12 PM Rebecca Milligan 
>>  wrote:
>> Hi, is it possible that the clock is off on the pc generating those signals 
>> by enough to cause this same issue?  The example sent earlier showed a .8 
>> second difference.  When it takes several times for my pc to decode a strong 
>> signal, it is usually due to their clock being off or two signals on top of 
>> each other. 
>> 
>>  
>> 
>> From: Topher Petty [mailto:ai8...@gmail.com] 
>> Sent: Thursday, May 2, 2019 12:53 PM
>> To: WSJT software development
>> Subject: Re: [wsjt-devel] FT8 decoding sensitivity: WSJT-X vs. JTDX
>> 
>>  
>> 
>> I've noted situations similar to this.. though I'm not running JTDX. There 
>> have been multiple times where a reply was strongly visible in the 
>> waterfall, yet nothing was decoded on that AF, and it took another TX/RX 
>> cycle to get the reply to decode a message.
>> At first, I thought it was because I was operating on an RPI (Pi 3B), so I 
>> copied the configs over to my T410 (twin Xeon X5670s with 64G RAM), and the 
>> same behavior occurs. even at less than 10% CPU utilization.
>> 
>> I don't believe it's available processor power, or RAM availability. With 
>> only WSJT-X, TQSL, and Chrome (six tabs open) running, the T410 has more 
>> than enough processor (24 threads) to handle these decodes, yet they're not 
>> being decoded.
>> 
>> I'm not judging, here. I'm only bringing information to the discussion.
>> 
>>  
>> 
>> 73 de AI8W, Chris
>> 
>>  
>> 
>> On Thu, May 2, 2019 at 11:09 AM Bill Somerville  
>> wrote:
>> 
>> On 02/05/2019 15:56, Black Michael via wsjt-devel wrote:
>> > Well yeahbut I would assume somebody would want to look at a 
>> > signal that seems to have sufficient SNR to decode.  Not enough info 
>> > in his snapshot to tell where JTDX decoded it or what else may have 
>> > happened.
>> >
>> > Seems to me a worthwhile exercise to ensure something pathological 
>> > isn't going on...all the reports of "loops" could just be overlaps, 
>> > fading, whateverbut worth a check isn't it to determine cause of a 
>> > few examples?
>> >
>> > de Mike W9MDB
>> >
>> >
>> Hi Mike,
>> 
>> absolutely agree, but I just wanted to make it clear to all that that 
>> signal strength is not the only parameter that determines successful 
>> decodes.
>> 
>> With respect to apparent anomalies, yes .WAV files are indeed valuable 
>> when linked to specific issues. For example your files provided 
>> Yesterday have highlighted a potential issue with transmissions of 
>> changed messages with respect to how quickly WSJT-X currently starts 
>> rendering the new message in the audio stream. This is something that is 
>> particularly critical with FT4 due to the transmission duration and 
>> thinking time approaching the limits of operator mental and manual agility.
>> 
>> 73
>> Bill
>> G4WJS.
>> 
>> 
>> 
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 decoding sensitivity: WSJT-X vs. JTDX

[Topher Petty]

I tried to post wav files and a screenshot to back up my observations, but
the message was rejected by the moderator.
I do hope someone will look at the files, and they didn't just get lost to
the aether. I'd hate to think the information I attempted to provide would
go unused.


On Thu, May 2, 2019 at 1:12 PM Rebecca Milligan 
wrote:

> Hi, is it possible that the clock is off on the pc generating those
> signals by enough to cause this same issue?  The example sent earlier
> showed a .8 second difference.  When it takes several times for my pc to
> decode a strong signal, it is usually due to their clock being off or two
> signals on top of each other.
>
>
>
> *From:* Topher Petty [mailto:ai8...@gmail.com]
> *Sent:* Thursday, May 2, 2019 12:53 PM
> *To:* WSJT software development
> *Subject:* Re: [wsjt-devel] FT8 decoding sensitivity: WSJT-X vs. JTDX
>
>
>
> I've noted situations similar to this.. though I'm not running JTDX. There
> have been multiple times where a reply was strongly visible in the
> waterfall, yet nothing was decoded on that AF, and it took another TX/RX
> cycle to get the reply to decode a message.
> At first, I thought it was because I was operating on an RPI (Pi 3B), so I
> copied the configs over to my T410 (twin Xeon X5670s with 64G RAM), and the
> same behavior occurs. even at less than 10% CPU utilization.
>
> I don't believe it's available processor power, or RAM availability. With
> only WSJT-X, TQSL, and Chrome (six tabs open) running, the T410 has more
> than enough processor (24 threads) to handle these decodes, yet they're not
> being decoded.
>
> I'm not judging, here. I'm only bringing information to the discussion.
>
>
>
> 73 de AI8W, Chris
>
>
>
> On Thu, May 2, 2019 at 11:09 AM Bill Somerville 
> wrote:
>
> On 02/05/2019 15:56, Black Michael via wsjt-devel wrote:
> > Well yeahbut I would assume somebody would want to look at a
> > signal that seems to have sufficient SNR to decode.  Not enough info
> > in his snapshot to tell where JTDX decoded it or what else may have
> > happened.
> >
> > Seems to me a worthwhile exercise to ensure something pathological
> > isn't going on...all the reports of "loops" could just be overlaps,
> > fading, whateverbut worth a check isn't it to determine cause of a
> > few examples?
> >
> > de Mike W9MDB
> >
> >
> Hi Mike,
>
> absolutely agree, but I just wanted to make it clear to all that that
> signal strength is not the only parameter that determines successful
> decodes.
>
> With respect to apparent anomalies, yes .WAV files are indeed valuable
> when linked to specific issues. For example your files provided
> Yesterday have highlighted a potential issue with transmissions of
> changed messages with respect to how quickly WSJT-X currently starts
> rendering the new message in the audio stream. This is something that is
> particularly critical with FT4 due to the transmission duration and
> thinking time approaching the limits of operator mental and manual agility.
>
> 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] TO19A dxped

[Bill Somerville]

On 02/05/2019 20:47, Patrick 9A5CW wrote:

Hi,
Anyone could check if this Callsign Tango Oscar one nine Alpha -FR 
Reunion isl. comply with the FT8 2.0 callsign pfx rules?


A DXped op called me if i can help them to setup F/H beacuse they had 
and still have problems with Dxped mode to answer callers.
Automatic station picking doesnt work ... you need to click on the 
caller to put them in Que window - list.

The report and RR73 are not visible at all.

Best regards and RR73 9A5CW


Hi Patrick,

TO19A is not a standard callsign in WSJT-X terms.

73
Bill
G4WJS.



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

[wsjt-devel] TO19A dxped

[Patrick 9A5CW]

Hi,
Anyone could check if this Callsign Tango Oscar one nine Alpha -FR Reunion
isl. comply with the FT8 2.0 callsign pfx rules?

A DXped op called me if i can help them to setup F/H beacuse they had and
still have problems with Dxped mode to answer callers.
Automatic station picking doesnt work ... you need to click on the caller
to put them in Que window - list.
The report and RR73 are not visible at all.

Best regards and RR73 9A5CW
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Issue installing 2.1.0rc5

[brbroberts--- via wsjt-devel]

On May 2, 2019, at 3:46 AM, Bill Somerville  wrote:

On 02/05/2019 03:44, false via wsjt-devel wrote:
> Hi, folks, hoping to get some help with this issue. I searched the Yahoo 
> group archives and then sent this request to the group ~4 hours ago, have not 
> received a response yet.
> 
> I renamed my old installation and installed the rc5 version; the install 
> process produced no errors but when I try to start the app, the below 
> messages appear in Console. There are ~30 variations on the first message 
> regarding varios frameworks when I initially attempt to start the app (after 
> which the second message appears), any attempts to start the app again after 
> the first attempt results only in the third error message. I have deleted the 
> installation and reinstalled, with the same results. Any ideas? The 2.0 
> installation still functions...
> 
> Mac Mini 2.3GHz i7 16GB running El Capitan (10.11.6)
> 
> 5/1/19 2:20:44.830 PM CoreServicesUIAgent[70277]: error -1 while removing 
> quarantine data on path 
> /Applications/wsjtx.app/Contents/Frameworks/QtWidgets.framework/Versions/Current
> 
> 5/1/19 2:20:44.887 PM com.apple.xpc.launchd[1]: 
> (com.apple.xpc.launchd.oneshot.0x10bf.wsjtx[71512]) Service exited with 
> abnormal code: 1
> 
> 5/1/19 2:28:40.539 PM com.apple.xpc.launchd[1]: 
> (org.k1jt.wsjtx.307232[71588]) Service exited with abnormal code: 1
> 
> I'm attaching the full error message output as a text file.
Hi OM,

I am not fully conversant with the internals of the macOS built in anti-virus 
protection. When you download an unsigned application from an untrusted source, 
i.e. the Internet, it will be flagged as quarantined the first time an attempt 
to open it happens, this includes setting the quarantine extended attribute on 
all application files. This is the action of the Gatekeeper service, i.e. the 
lack of an "Open" button and a warning message unless you override by 
Control+clicking to open the application 
(https://support.apple.com/en-gb/HT202491) indicates this. Once you override 
that, another sub-system kicks in called XProtect which virus scans the 
application before finally allowing it to run. If XProtect detects malware (may 
be a false positive) it moves the offending application content to 
/private/var/something-or-other to quarantine it. If the application passes the 
virus scan then XProtect removes the quarantine extended attributes from the 
application files and it can run normally like any other application.

The messages you are seeing seems to be related to XProtect not finding the 
files it is trying to move to quarantine. I think the problem maybe occurred 
when you moved the old WSJT-X application. That shouldn't be an issue but it 
seems to be so. How you clear up the mess I have no idea, but start by deleting 
both of your WSJT-X applications and empty the Trash Can so they are really 
gone. Then try installing again. BTW we have taken the WSJT-X v2.1.0 RC5 for 
macOS off the project web site and Source Forge files area since it has some 
major defects, we will publish an RC6 soon with fixes.

73
Bill
G4WJS.

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

Thanks for the response, Bill.

I'll just wait for rc6 to be released.

Outrageous typos and other hilarity brought to you by iPhone AutoCorrect.___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 decoding sensitivity: WSJT-X vs. JTDX

[Joe Taylor]

Hi Chris,

On 5/2/2019 12:52 PM, Topher Petty AI8W wrote:
... I don't believe it's available processor power, or RAM availability. 
With only WSJT-X, TQSL, and Chrome (six tabs open) running, the T410 has 
more than enough processor (24 threads) to handle these decodes, yet 
they're not being decoded.

I'm not judging, here. I'm only bringing information to the discussion.


Long before FT8 was released for general use, we analyzed many thousands 
of received FT8 waveforms under a wide variety of conditions.  Soon 
after FT8 was released, and again after it was upgraded to use 77-bit 
message payloads, hundreds of thousands of additional FT8 waveforms were 
analyzed.  The FT8 decoder in WSJT-X (and also those in derivative 
programs like JTDX) could not exist without that extensive work.


Without the relevant .wav file -- and better still, an indication of the 
most likely message content for the signal in question -- reports that 
say something like "the signal was strong but it didn't decode" can't be 
very useful.


Tx messages changed in mid-stream are among the most likely causes of 
failed decodes.  If 40% of a transmission contains one message and 60% 
contains a different message, decoding is necessarily doomed to failure.


-- 73, Joe, K1JT


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

Re: [wsjt-devel] FT8 decoding sensitivity: WSJT-X vs. JTDX

[Topher Petty]

I've noted situations similar to this.. though I'm not running JTDX. There
have been multiple times where a reply was strongly visible in the
waterfall, yet nothing was decoded on that AF, and it took another TX/RX
cycle to get the reply to decode a message.
At first, I thought it was because I was operating on an RPI (Pi 3B), so I
copied the configs over to my T410 (twin Xeon X5670s with 64G RAM), and the
same behavior occurs. even at less than 10% CPU utilization.
I don't believe it's available processor power, or RAM availability. With
only WSJT-X, TQSL, and Chrome (six tabs open) running, the T410 has more
than enough processor (24 threads) to handle these decodes, yet they're not
being decoded.
I'm not judging, here. I'm only bringing information to the discussion.

73 de AI8W, Chris

On Thu, May 2, 2019 at 11:09 AM Bill Somerville 
wrote:

> On 02/05/2019 15:56, Black Michael via wsjt-devel wrote:
> > Well yeahbut I would assume somebody would want to look at a
> > signal that seems to have sufficient SNR to decode.  Not enough info
> > in his snapshot to tell where JTDX decoded it or what else may have
> > happened.
> >
> > Seems to me a worthwhile exercise to ensure something pathological
> > isn't going on...all the reports of "loops" could just be overlaps,
> > fading, whateverbut worth a check isn't it to determine cause of a
> > few examples?
> >
> > de Mike W9MDB
> >
> >
> Hi Mike,
>
> absolutely agree, but I just wanted to make it clear to all that that
> signal strength is not the only parameter that determines successful
> decodes.
>
> With respect to apparent anomalies, yes .WAV files are indeed valuable
> when linked to specific issues. For example your files provided
> Yesterday have highlighted a potential issue with transmissions of
> changed messages with respect to how quickly WSJT-X currently starts
> rendering the new message in the audio stream. This is something that is
> particularly critical with FT4 due to the transmission duration and
> thinking time approaching the limits of operator mental and manual agility.
>
> 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] Qt Newsletter today pushing "Download Qt LTS 5.12.3" ...

[Bill Somerville]

On 02/05/2019 17:20, Doug Jones wrote:


  Does this the Qt version include the fix for the bug causing audio 
level resets to max (WSJT-X 2.1.0 for Win64)?


Thanks, Doug AF4T


Hi Doug,

no it is scheduled for v5.12.4, currently targetted for release on 30th 
May. v5.12.3 came in one day late so I don't expect too much variance 
from their schedule.


73
bill
G4WJS.



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

Re: [wsjt-devel] Qt Newsletter today pushing "Download Qt LTS 5.12.3" ...

[Black Michael via wsjt-devel]

No...it's fixed in 5.12.4
https://bugreports.qt.io/browse/QTBUG-75024?jql=text%20~%20%22audio%22%20ORDER%20BY%20created%20DESC

de Mike W9MDB 

On Thursday, May 2, 2019, 11:24:44 AM CDT, Doug Jones  
wrote:  
 
   
  Does this the Qt version include the fix for the bug causing audio level 
resets to max (WSJT-X 2.1.0 for Win64)?
 
Thanks, Doug AF4T
 
 ___
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] Qt Newsletter today pushing "Download Qt LTS 5.12.3" ...

[Doug Jones]

  Does this the Qt version include the fix for the bug causing audio 
level resets to max (WSJT-X 2.1.0 for Win64)?


Thanks, Doug AF4T

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

Re: [wsjt-devel] FT8 decoding sensitivity: WSJT-X vs. JTDX

[Bill Somerville]

On 02/05/2019 15:56, Black Michael via wsjt-devel wrote:
Well yeahbut I would assume somebody would want to look at a 
signal that seems to have sufficient SNR to decode.  Not enough info 
in his snapshot to tell where JTDX decoded it or what else may have 
happened.


Seems to me a worthwhile exercise to ensure something pathological 
isn't going on...all the reports of "loops" could just be overlaps, 
fading, whateverbut worth a check isn't it to determine cause of a 
few examples?


de Mike W9MDB



Hi Mike,

absolutely agree, but I just wanted to make it clear to all that that 
signal strength is not the only parameter that determines successful 
decodes.


With respect to apparent anomalies, yes .WAV files are indeed valuable 
when linked to specific issues. For example your files provided 
Yesterday have highlighted a potential issue with transmissions of 
changed messages with respect to how quickly WSJT-X currently starts 
rendering the new message in the audio stream. This is something that is 
particularly critical with FT4 due to the transmission duration and 
thinking time approaching the limits of operator mental and manual agility.


73
Bill
G4WJS.



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

Re: [wsjt-devel] FT8 decoding sensitivity: WSJT-X vs. JTDX

[Black Michael via wsjt-devel]

Well yeahbut I would assume somebody would want to look at a signal that 
seems to have sufficient SNR to decode.  Not enough info in his snapshot to 
tell where JTDX decoded it or what else may have happened.
Seems to me a worthwhile exercise to ensure something pathological isn't going 
on...all the reports of "loops" could just be overlaps, fading, whateverbut 
worth a check isn't it to determine cause of a few examples?
de Mike W9MDB


 

On Thursday, May 2, 2019, 9:46:41 AM CDT, Bill Somerville 
 wrote:  
 
  Hi Mike, 
  signal strength alone does not guarantee successful decoding, for example a 
sender might change the transmitted messages twice during the transmission at, 
say 1/3  and 2/3 of the transmission length, there's no way that signal will be 
decoded in any of its three forms with normal decoding, however strong the 
signal is or deep the decoder looks. OTOH part way through a QSO with AP 
enabled, one of those 1/3 length portions may well deliver a successful and 
valid decode. The same comments apply to overlapping signals with multi-pass 
decoding using subtraction techniques too unmask weaker signals. 
  73
 Bill
 G4WJS. 
  On 02/05/2019 15:19, Black Michael via wsjt-devel wrote:
  
  Are you saving WAV files where you can send that WAV file to the group? 
If not, please turn on "Save/All" and when yoy get another like that one send 
it in.  Seems like there's some problem if it's not seeing a signal at the -06 
level. 
  Can't tell from your screen shot what pass# JTDX decoded it. 
  de Mike W9MDB 
   

  
On Thursday, May 2, 2019, 9:13:40 AM CDT, DG2YCB, Uwe 
 wrote:  
  
  
I’ve just made my first QSO with JTDX while running WSJT-X in parallel. And 
believe me or not: It happened exactly that what I noted in my first email. 
Look at the following screenshot: JTDX got the full QSO, but WSJT-X missed 
F5NK’s “+05” reply. Means with WSJT-X I would have needed one more exchange 
cycle. I would really be grateful if that could be fixed in WSJT-X!
 
  
 

 
  
  
73 de Uwe, DG2YCB 
   
 

 
 ___
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] FT8 decoding sensitivity: WSJT-X vs. JTDX

[Joe Taylor]

On 5/2/2019 10:07 AM, DG2YCB, Uwe wrote:
I’ve just made my first QSO with JTDX while running WSJT-X in parallel. 
And believe me or not: It happened exactly that what I noted in my first 
email. Look at the following screenshot: JTDX got the full QSO, but 
WSJT-X missed F5NK’s “+05” reply. Means with WSJT-X I would have needed 
one more exchange cycle. I would really be grateful if that could be 
fixed in WSJT-X!


73 de Uwe, DG2YCB


It seems that you ask for a disproportionate share of bandwidth on the 
wsjt-devel list ... not to mention a disproportionate share of WSJT 
Developers' time.


Before asking us to look into why a particular transmission on a crowded 
band was decoded by one software package and not by another (while not 
providing relevant *.wav files for either package) please consider these 
questions:


1. How many person-hours of reading, thinking, coding, testing, 
re-coding, and retesting do you suppose are required to develop and make 
freely available a ham-radio protocol like FT8 or FT4?


2. It is really important that we (WSJT Developers) drop everything else 
to explore just how you might save an exchange cycle in one of your 
dozens (hundreds?) of FT8 QSOs?


3. This niche of our shared hobby is necessarily a cooperative venture.
How best might you volunteer to help, rather than simply requesting that 
something be done for you?


-- Joe, K1JT


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

Re: [wsjt-devel] FT8 decoding sensitivity: WSJT-X vs. JTDX

[Bill Somerville]

Hi Mike,

signal strength alone does not guarantee successful decoding, for 
example a sender might change the transmitted messages twice during the 
transmission at, say 1/3 and 2/3 of the transmission length, there's no 
way that signal will be decoded in any of its three forms with normal 
decoding, however strong the signal is or deep the decoder looks. OTOH 
part way through a QSO with AP enabled, one of those 1/3 length portions 
may well deliver a successful and valid decode. The same comments apply 
to overlapping signals with multi-pass decoding using subtraction 
techniques too unmask weaker signals.


73
Bill
G4WJS.

On 02/05/2019 15:19, Black Michael via wsjt-devel wrote:

Are you saving WAV files where you can send that WAV file to the group?
If not, please turn on "Save/All" and when yoy get another like that 
one send it in.  Seems like there's some problem if it's not seeing a 
signal at the -06 level.


Can't tell from your screen shot what pass# JTDX decoded it.

de Mike W9MDB




On Thursday, May 2, 2019, 9:13:40 AM CDT, DG2YCB, Uwe  
wrote:



I’ve just made my first QSO with JTDX while running WSJT-X in 
parallel. And believe me or not: It happened exactly that what I noted 
in my first email. Look at the following screenshot: JTDX got the full 
QSO, but WSJT-X missed F5NK’s “+05” reply. Means with WSJT-X I would 
have needed one more exchange cycle. I would really be grateful if 
that could be fixed in WSJT-X!


73 de Uwe, DG2YCB



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

[wsjt-devel] S+P operation

[WB5JJJ]

Trying new features with FT4 and noticed that when S+P is active during
non-CQ (receive only) operation, it will pounce on stations using directed
calls such as CQ DX WB5JJJ EM35.  In a contest situation, which FT4 is
designed for, this would be fine since there will not be any directed CQ's
typically.  So, should this option not be shown on the main UI unless a
contest is selected since it can cause frustration to some operators that
don't want to be bothered by local stations pouncing on their directed CQ?

Judging from some comments, it appears that FT4 may be the new norm for
those seeking their first WAS, DXCC and not just contests.

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

Re: [wsjt-devel] FT8 decoding sensitivity: WSJT-X vs. JTDX

[Bill Somerville]

On 02/05/2019 15:07, DG2YCB, Uwe wrote:
I’ve just made my first QSO with JTDX while running WSJT-X in 
parallel. And believe me or not: It happened exactly that what I noted 
in my first email. Look at the following screenshot: JTDX got the full 
QSO, but WSJT-X missed F5NK’s “+05” reply. Means with WSJT-X I would 
have needed one more exchange cycle. I would really be grateful if 
that could be fixed in WSJT-X!


Uwe,

decoding sensitivity is not something you can brand as broken like that. 
The decoding process is hard problem which can have better sensitivity 
if more processing effort is made, but there has to be a limit to how 
far you can go before the error rate exceeds that expected by users. 
JTDX in general turns all the knobs to 11 and then optionally does post 
processing to filter likely false decodes. This takes more CPU power 
than is available to many operators and requires information not 
retrieved from the communications channel. Most importantly the WSJT 
developers strongly feel that what you see is derived from what is 
received over the radio channel and not based on reviewing the decoded 
messages for content that might obviously be a false decode. There are a 
very small number of exceptions to this for pathological cases like 
continuous tones or other patterns that are common and happen to decode 
to a particular message that was not deliberately transmitted.


The sensitivity of WSJT-X is a design parameter set by the developers. 
If you are using FT8 and feel that the sensitivity is too low then try 
JT65 or JT9 rather than request more in WSJT-X. I expect this argument 
will be extended when users get a feel for the reduced sensitivity of 
FT4. Bottom line is "you can't have you cake and eat it" (substitute 
your local idiom for this common proverb of figure of speech).


73
Bill
G4WJS.

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

Re: [wsjt-devel] FT8 decoding sensitivity: WSJT-X vs. JTDX

[Black Michael via wsjt-devel]

Are you saving WAV files where you can send that WAV file to the group?If not, 
please turn on "Save/All" and when yoy get another like that one send it in.  
Seems like there's some problem if it's not seeing a signal at the -06 level.
Can't tell from your screen shot what pass# JTDX decoded it.
de Mike W9MDB

 

 On Thursday, May 2, 2019, 9:13:40 AM CDT, DG2YCB, Uwe  
wrote:  
 
 
I’ve just made my first QSO with JTDX while running WSJT-X in parallel. And 
believe me or not: It happened exactly that what I noted in my first email. 
Look at the following screenshot: JTDX got the full QSO, but WSJT-X missed 
F5NK’s “+05” reply. Means with WSJT-X I would have needed one more exchange 
cycle. I would really be grateful if that could be fixed in WSJT-X!

  



  

73 de Uwe, DG2YCB 
___
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] Might be off topic...

[Black Michael via wsjt-devel]

Loaded question.
You'll get numerous replies to this question...
Personally I use the idea of checking hamspots.net to see what my signal 
reports look like.  If the majority of sig reports are < 0dB I figure I'm OK.
The nice part of FT8 and such modes is they really don't interefer with anybody 
unless you're right on top of them and your audio is clean...and everybody is 
getting better at clean audio these daysthe way you're running for example 
of 50W into a 100W setting on the rig means you won't generate any harmonics.
Almost invariably when somebody gives me a + report they have a beam.  Once in 
a while propagation is really good between two spots and you'll get a booming 
signal report but if you check hamspots.net you'll find it's just that one 
station and maybe a couple more with the majority of sig reports < 0dB.
You've people out there running 1000W or more into a 10dB gain antenna for an 
effective 10,000W stationso don't be shy
de Mike W9MDB

 

On Thursday, May 2, 2019, 8:44:33 AM CDT, Topher Petty  
wrote:  
 
 I'm simply curious about one thing...
What TX power levels does everyone run while working FT-8?
I don't own an amplifier, and generally run at around 50W output on an IC-718. 
I know I *CAN* push it to 100W (50% duty cycle) but I like to leave some 
"headroom" to keep the radio cool while working digital modes.
I do this by setting the rig's TX power to maximum ("H"), and only pushing the 
audio until I hit around 50 Watts.
What power levels are considered "acceptable" for FT-8, and what are considered 
best-practices for limiting power output?
Thanks in advance for any insight.
73 de AI8W, Chris___
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.1.0-rc5 OK logging button problematic for blind hams

[Bill Somerville]

On 02/05/2019 14:32, Mark James wrote:
4) I can't see that this change will possibly help with robot 
operators. Since this is open-source software, all the bad guys have 
to do is to fork it and make a build without these changes. And unless 
all the "clone" makers go along with the change, the robot folks will 
just switch to a clone.


Mark,

someone has to address this issue. If you think it's ok to sell a tool 
on eBay that automates WSJT-X to make it an unattended QSO robot by 
using the accessibility interface built into WSJT-X then that's ok, but 
you must then also be prepared to not have core developers of WSJT-X 
stick with the project because it is being misused.


As for modifying WSJT-X itself and releasing such modified versions as 
part of some sort of malware, we have the defence of the GPL licence as 
I doubt such bad actors will release the source code for their hacks.


Anyway, enough of this discussion thread and related ones. We are well 
aware what has been done is not popular and we are trying to help get 
the root issues addressed elsewhere away from unhelpful ranting, 
attempts at disruption, and posturing on public forums.


If any visually or otherwise impaired operator wants to help with 
testing WSJT-X v2.1.0 release candidates then please contact us directly 
and we can provide a version with the parts in question disabled, along 
with the necessary source code to meet our GPL licence obligations.


73
Bill
G4WJS.



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

Re: [wsjt-devel] Might be off topic...

[James Shaver]

Probably more a question for the WSJTGroup list rather than the Dev list - for 
what it’s worth, there are dozens of threads on this topic there already that 
are searchable.  :)

73,

Jim S. 
N2ADV

> On May 2, 2019, at 9:40 AM, Topher Petty  wrote:
> 
> I'm simply curious about one thing...
> 
> What TX power levels does everyone run while working FT-8?
> 
> I don't own an amplifier, and generally run at around 50W output on an 
> IC-718. I know I *CAN* push it to 100W (50% duty cycle) but I like to leave 
> some "headroom" to keep the radio cool while working digital modes.
> 
> I do this by setting the rig's TX power to maximum ("H"), and only pushing 
> the audio until I hit around 50 Watts.
> 
> What power levels are considered "acceptable" for FT-8, and what are 
> considered best-practices for limiting power output?
> 
> Thanks in advance for any insight.
> 
> 73 de AI8W, Chris
> ___
> 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] Might be off topic...

[Topher Petty]

I'm simply curious about one thing...

What TX power levels does everyone run while working FT-8?

I don't own an amplifier, and generally run at around 50W output on an
IC-718. I know I *CAN* push it to 100W (50% duty cycle) but I like to leave
some "headroom" to keep the radio cool while working digital modes.

I do this by setting the rig's TX power to maximum ("H"), and only pushing
the audio until I hit around 50 Watts.

What power levels are considered "acceptable" for FT-8, and what are
considered best-practices for limiting power output?

Thanks in advance for any insight.

73 de AI8W, Chris
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2.1.0-rc5 OK logging button problematic for blind hams

[Mark James]

I think some things here need to be addressed:

1) The implication that there might be only one person affected by this
doesn't make sense. You don't distribute something and then wait to see how
many blind people have problems before you see there's an issue.
2) "we are branded as anti-accessibility." I'm sorry, but if you
intentionally introduce something in a key part of the program that defeats
accessibility, I don't think that's just "branding" you to complain about
it.
3) Keyboard shortcuts are not just for blind users -- they are also for
low-vision users and users with motor skills problems, who simply can't use
a mouse. I have had a QSO with a ham who can't do anything else but WSJT
modes because of his disabilities.
4) I can't see that this change will possibly help with robot operators.
Since this is open-source software, all the bad guys have to do is to fork
it and make a build without these changes. And unless all the "clone"
makers go along with the change, the robot folks will just switch to a
clone.

Mark James, KC1GWX

On Thu, May 2, 2019 at 7:12 AM rjai...@gmail.com  wrote:

> Thanks Bill,
>
> He is using NVDA under Windows 10.
>
> If you want, he has agreed to allow TeamViewer access if you need to see
> the issues and possible solutions. But you can download the reader and
> attempt to re-create the problem yourself.
>
> https://www.nvaccess.org/
>
> Many thanks
> 73
> Ria
> N2RJ
>
>
> On Thu, May 2, 2019 at 6:16 AM Bill Somerville 
> wrote:
>
>> On 02/05/2019 01:52, rjai...@gmail.com wrote:
>> > I was helping a blind ham set up WSJT-X 2.1.0-rc5 today and it was
>> > apparent that this new arrangement to thwart robots simply isn't
>> > working for blind hams who rely upon screen readers and other
>> > accessibility technologies. There is no way for his screen reader
>> > software to focus on OK.
>> >
>> > Any help with this would be appreciated.
>> >
>> > 73
>> > Ria, N2RJ
>>
>> Hi Ria,
>>
>> sorry to here that, an unfortunate consequence of a few LIDs making
>> things worse for the good guys. As the community appears to have no
>> interest in stopping them from destroying the WSJT-X modes for everyone
>> who is adopting them, we are in a tough place. We could easily
>> distribute a version of WSJT-X with these defences disabled for those
>> that ask for it. All this noise in the defence of sight-challenged
>> operators seems selfish to me, yours is the first that actually mentions
>> someone having difficulty. We use tools that automatically build in
>> accessibility on all platforms, we work with other software developers
>> who are developing special tools for sight-challenged ops (e.g. Sam,
>> W2JDB, with his application Qlog). Yet when we have to make a change to
>> one pair of buttons within the hundreds of controls in WSJT-X, for
>> reasons we don't like either but we think they are justified, we are
>> branded as anti-accessibility.
>>
>> Come on folks, try and see the big  picture.
>>
>> Ria, which operating system is your colleague using? Also what screen
>> reader is their preference, if it is free of charge or otherwise easy to
>> obtain I would like to review how WSJT-X plays out when accessing the
>> programmatic accessible interfaces. I ask because we could do a lot more
>> with the accessible names and descriptions of the various windows and
>> controls in WSJT-X. They are largely at default values presently which
>> can't be very helpful.
>>
>> 73
>> Bill
>> G4WJS.
>>
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RC5 TX output level - 64 bit

[James Shaver]

For what it’s worth, I’m not seeing any difference with my 6300 and DAX/SSDR 
3.0.19 between 2.0.1 and 2.1.0 RC5.  ‘

Your 6600 must be defective - send it to me for, uh, proper disposal.  ;). 

73,

Jim S. 

> On May 2, 2019, at 8:16 AM, Bill Somerville  wrote:
> 
>> On 02/05/2019 12:55, Al wrote:
>> (Flex 6600, SSDR 3.0.19, Wsjt 2.1.0-rc5, Win10 )
>> I have noted the the TX output level from WSJT-x v2.1.0-rc5 64bit ( all 
>> modes ) is 8db lower than in v2.0.1.  The 32 bit version of 2.1.0-rc5 
>> produces the same TX output level as v2.0.1.
>> 
>> It's not an operational problem form me as I can compensate else where. It 
>> just different.
>> 
>> AL, K0VM
> Hi Al,
> 
> that is surprising as I was not aware of any changes. How are you measuring 
> that, and are you certain that you have all level controls set equally? I ask 
> because some o/s audio level settings are remembered per application.
> 
> One possibility may be a difference in the mapping of the internal level 
> control to the PCM stream level (log/lin/something else), are you running 
> with the WSJT-X Pwr slider at maximum? If not, do you see the same level 
> difference if you do set it to maximum?
> 
> 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] RC5 TX output level - 64 bit

[Black Michael via wsjt-devel]

I've got an ANAN 100 and I don't see any difference in power level between the 
32-bit and 64-bit versions.
You can use Audacity to record what's coming out of the WSJT-X audio to see if 
it's different between the two.  
de Mike W9MDB

 

On Thursday, May 2, 2019, 7:21:43 AM CDT, Bill Somerville 
 wrote:  
 
  On 02/05/2019 12:55, Al wrote:
  
(Flex 6600, SSDR 3.0.19, Wsjt 2.1.0-rc5, Win10 )
 I have noted the the TX output level from WSJT-x v2.1.0-rc5 64bit ( all modes 
) is 8db lower than in v2.0.1.  The 32 bit version of 2.1.0-rc5 produces the 
same TX output level as v2.0.1.
 
 It's not an operational problem form me as I can compensate else where. It 
just different.
 
 AL, K0VM
 
Hi Al,
 
that is surprising as I was not aware of any changes. How are you measuring 
that, and are you certain that you have all level controls set equally? I ask 
because some o/s audio level settings are remembered per application.
 
One possibility may be a difference in the mapping of the internal level 
control to the PCM stream level (log/lin/something else), are you running with 
the WSJT-X Pwr slider at maximum? If not, do you see the same level difference 
if you do set it to maximum?
 
 
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] Buggies 2

[Jari A]

Hi again,

Another bug, actually happen earlier with 2.0.1 but appear second time with
2.1.0.

Earlier I work Slovenian S57AT on FT4 - and got contest report on my "log
qso" window, even S57AT did not send such, location goes to Spain.
550003JN01VR

I just work VK1HX and I got again contest report 540001JN01VR

Neither sent that, they were normal qsos.

Another anomaly; I work station on hes qrg, second station calls me in the
middle of first qso, I finish it and then double click second caller. My tx
qrg remains at first station qrg. I can manually change my tx with "up
arrow" button, but it causes some surprises to me and first station as I tx
on first station qrg. No biggie if I spot that in time, but I did got
"FOOL" comment about it.

Running on wednesday like mad contester, I had 116 qsos despite jumping OK
and Cancel buttons. Adaptation to them wasnt too bad, but I got few errors
due the buttons. Most problem was to cancel unfinish qso.

Regards,

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

Re: [wsjt-devel] RC5 TX output level - 64 bit

[Bill Somerville]

On 02/05/2019 12:55, Al wrote:

(Flex 6600, SSDR 3.0.19, Wsjt 2.1.0-rc5, Win10 )
I have noted the the TX output level from WSJT-x v2.1.0-rc5 64bit ( 
all modes ) is 8db lower than in v2.0.1.  The 32 bit version of 
2.1.0-rc5 produces the same TX output level as v2.0.1.


It's not an operational problem form me as I can compensate else 
where. It just different.


AL, K0VM


Hi Al,

that is surprising as I was not aware of any changes. How are you 
measuring that, and are you certain that you have all level controls set 
equally? I ask because some o/s audio level settings are remembered per 
application.


One possibility may be a difference in the mapping of the internal level 
control to the PCM stream level (log/lin/something else), are you 
running with the WSJT-X Pwr slider at maximum? If not, do you see the 
same level difference if you do set it to maximum?


73
Bill
G4WJS.

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

[wsjt-devel] RC5 TX output level - 64 bit

[Al]

(Flex 6600, SSDR 3.0.19, Wsjt 2.1.0-rc5, Win10 )
I have noted the the TX output level from WSJT-x v2.1.0-rc5 64bit ( all 
modes ) is 8db lower than in v2.0.1.  The 32 bit version of 2.1.0-rc5 
produces the same TX output level as v2.0.1.


It's not an operational problem form me as I can compensate else where. 
It just different.


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

Re: [wsjt-devel] FT8 decoding sensitivity: WSJT-X vs. JTDX

[Claude Frantz]

On 5/2/19 11:47 AM, DG2YCB, Uwe wrote:

Hi Uwe & all,

Even when in JTDX decoder sensitivity is reduced 
to “use low thresholds” JTDX is still ahead regarding the number of decodes.


So, my question is: What can I do (or can be done by the development 
team) to increase the decoding sensitivity of WSJT-X?


The best would be to copy the improved code from JTDX and to incorporate 
it into WSJT-X.


All the best !

Claude (DJ0OT)


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

Re: [wsjt-devel] 2.1.0-rc5 OK logging button problematic for blind hams

[rjai...@gmail.com]

Thanks Bill,

He is using NVDA under Windows 10.

If you want, he has agreed to allow TeamViewer access if you need to see
the issues and possible solutions. But you can download the reader and
attempt to re-create the problem yourself.

https://www.nvaccess.org/

Many thanks
73
Ria
N2RJ


On Thu, May 2, 2019 at 6:16 AM Bill Somerville 
wrote:

> On 02/05/2019 01:52, rjai...@gmail.com wrote:
> > I was helping a blind ham set up WSJT-X 2.1.0-rc5 today and it was
> > apparent that this new arrangement to thwart robots simply isn't
> > working for blind hams who rely upon screen readers and other
> > accessibility technologies. There is no way for his screen reader
> > software to focus on OK.
> >
> > Any help with this would be appreciated.
> >
> > 73
> > Ria, N2RJ
>
> Hi Ria,
>
> sorry to here that, an unfortunate consequence of a few LIDs making
> things worse for the good guys. As the community appears to have no
> interest in stopping them from destroying the WSJT-X modes for everyone
> who is adopting them, we are in a tough place. We could easily
> distribute a version of WSJT-X with these defences disabled for those
> that ask for it. All this noise in the defence of sight-challenged
> operators seems selfish to me, yours is the first that actually mentions
> someone having difficulty. We use tools that automatically build in
> accessibility on all platforms, we work with other software developers
> who are developing special tools for sight-challenged ops (e.g. Sam,
> W2JDB, with his application Qlog). Yet when we have to make a change to
> one pair of buttons within the hundreds of controls in WSJT-X, for
> reasons we don't like either but we think they are justified, we are
> branded as anti-accessibility.
>
> Come on folks, try and see the big  picture.
>
> Ria, which operating system is your colleague using? Also what screen
> reader is their preference, if it is free of charge or otherwise easy to
> obtain I would like to review how WSJT-X plays out when accessing the
> programmatic accessible interfaces. I ask because we could do a lot more
> with the accessible names and descriptions of the various windows and
> controls in WSJT-X. They are largely at default values presently which
> can't be very helpful.
>
> 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] Issue installing 2.1.0rc5

[Bill Somerville]

On 02/05/2019 03:44, false via wsjt-devel wrote:


Hi, folks, hoping to get some help with this issue. I searched the 
Yahoo group archives and then sent this request to the group ~4 hours 
ago, have not received a response yet.


I renamed my old installation and installed the rc5 version; the 
install process produced no errors but when I try to start the app, 
the below messages appear in Console. There are ~30 variations on the 
first message regarding varios frameworks when I initially attempt to 
start the app (after which the second message appears), any attempts 
to start the app again after the first attempt results only in the 
third error message. I have deleted the installation and reinstalled, 
with the same results. Any ideas? The 2.0 installation still functions...


Mac Mini 2.3GHz i7 16GB running El Capitan (10.11.6)

5/1/19 2:20:44.830 PM CoreServicesUIAgent[70277]: error -1 while 
removing quarantine data on path 
/Applications/wsjtx.app/Contents/Frameworks/QtWidgets.framework/Versions/Current


5/1/19 2:20:44.887 PM com.apple.xpc.launchd[1]: 
(com.apple.xpc.launchd.oneshot.0x10bf.wsjtx[71512]) Service exited 
with abnormal code: 1


5/1/19 2:28:40.539 PM com.apple.xpc.launchd[1]: 
(org.k1jt.wsjtx.307232[71588]) Service exited with abnormal code: 1


I'm attaching the full error message output as a text file.


Hi OM,

I am not fully conversant with the internals of the macOS built in 
anti-virus protection. When you download an unsigned application from an 
untrusted source, i.e. the Internet, it will be flagged as quarantined 
the first time an attempt to open it happens, this includes setting the 
quarantine extended attribute on all application files. This is the 
action of the Gatekeeper service, i.e. the lack of an "Open" button and 
a warning message unless you override by Control+clicking to open the 
application (https://support.apple.com/en-gb/HT202491) indicates this. 
Once you override that, another sub-system kicks in called XProtect 
which virus scans the application before finally allowing it to run. If 
XProtect detects malware (may be a false positive) it moves the 
offending application content to /private/var/something-or-other to 
quarantine it. If the application passes the virus scan then XProtect 
removes the quarantine extended attributes from the application files 
and it can run normally like any other application.


The messages you are seeing seems to be related to XProtect not finding 
the files it is trying to move to quarantine. I think the problem maybe 
occurred when you moved the old WSJT-X application. That shouldn't be an 
issue but it seems to be so. How you clear up the mess I have no idea, 
but start by deleting both of your WSJT-X applications and empty the 
Trash Can so they are really gone. Then try installing again. BTW we 
have taken the WSJT-X v2.1.0 RC5 for macOS off the project web site and 
Source Forge files area since it has some major defects, we will publish 
an RC6 soon with fixes.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Log QSO Window -> OK and Cancel buttons oddbehavior -CRACKED

[Bill Somerville]

On 02/05/2019 01:55, rjai...@gmail.com wrote:
Apart from ADA stuff it simply isn't working for blind hams. Besides, 
the autobots have gotten advanced now to the point where they are 
simply modifying source code and bypassing all manual input.


Not sure what can be done other than maybe invalidate awards from 
automated robot cheating.


Ria
N2RJ


Hi Ria,

if an attacker modifies the WSJT-X source code then they have to 
distribute that to spread their malware, that would be in violation of 
the GPL Open Source Licence if they don't also publish their sources 
etc.. We have other defences against that, not least the community 
*should* actively shun such behaviour since it could easily cause key 
contributors to the WSJT projects to quit and do something else where 
their efforts are better appreciated and their rights as original 
authors unviolated. Free Open Source software is not without problems 
but if everyone understands that there are responsibilities as well as 
advantages then the efforts of the few with the vision, time and the 
skills can benefit the community greatly.


73
Bill
G4WJS.



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

Re: [wsjt-devel] 2.1.0-rc5 OK logging button problematic for blind hams

[Bill Somerville]

On 02/05/2019 01:52, rjai...@gmail.com wrote:

I was helping a blind ham set up WSJT-X 2.1.0-rc5 today and it was
apparent that this new arrangement to thwart robots simply isn't
working for blind hams who rely upon screen readers and other
accessibility technologies. There is no way for his screen reader
software to focus on OK.

Any help with this would be appreciated.

73
Ria, N2RJ


Hi Ria,

sorry to here that, an unfortunate consequence of a few LIDs making 
things worse for the good guys. As the community appears to have no 
interest in stopping them from destroying the WSJT-X modes for everyone 
who is adopting them, we are in a tough place. We could easily 
distribute a version of WSJT-X with these defences disabled for those 
that ask for it. All this noise in the defence of sight-challenged 
operators seems selfish to me, yours is the first that actually mentions 
someone having difficulty. We use tools that automatically build in 
accessibility on all platforms, we work with other software developers 
who are developing special tools for sight-challenged ops (e.g. Sam, 
W2JDB, with his application Qlog). Yet when we have to make a change to 
one pair of buttons within the hundreds of controls in WSJT-X, for 
reasons we don't like either but we think they are justified, we are 
branded as anti-accessibility.


Come on folks, try and see the big  picture.

Ria, which operating system is your colleague using? Also what screen 
reader is their preference, if it is free of charge or otherwise easy to 
obtain I would like to review how WSJT-X plays out when accessing the 
programmatic accessible interfaces. I ask because we could do a lot more 
with the accessible names and descriptions of the various windows and 
controls in WSJT-X. They are largely at default values presently which 
can't be very helpful.


73
Bill
G4WJS.



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