Re: [wsjt-devel] WSJTX 2.2.0-RC1 - xmit power drop down

[Bill Somerville]

On 12/05/2020 20:44, Josh Rovero wrote:
The 60 dBm transmit power drop-down is sticky - if you change it to a 
different value and save the configuration, the next time you start 
WSJT-X it will revert back to 60 dBm.


--
P.J. "Josh" Rovero http://www.roveroresearch.org
Ham Radio: KK1D http://www.roveroresearch 
.net


Hi Josh,

thanks for the issue report, I can confirm this is a defect. It will be 
fixed for the next release.


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 V 2.2.0 RC1

[Bill Somerville]

On 13/05/2020 00:44, Dave Anderson, K4SV via wsjt-devel wrote:

Hi Everyone,

I am new to the group here and not sure where to make a bug report 
other than what the WSJTX site suggests, which is here.


Overall software runs very well.  Using it for 630 meter WSPR at the 
moment.


Bug
After setting the transmit power level it transmits correctly but if 
the application is closed and reopened it forgets the previous power 
setting and reverts to a level of 0.


Win 7
WSJTX V2.2.0  rc1

Thanks in advance,

PS Please advise if bug reports should be reported differently.

Best 73

*Dave Anderson, K4SV*
*Tryon, NC*


Hi Dave,

thanks for the issue report, I can confirm it is a defect which will be 
fixed for the next release.


73
Bill
G4WJS.

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

Re: [wsjt-devel] v2.2.0 rc1 Dropdown Frequency list anomaly

[Greg Vatt]

Thanks Bill,


From my investigating today it looks like the problem might be a Qt issue that 
has crept back into the Qt library again. I have been reading through the Qt 
bug reports and the Qt forums today and this same problem was talked about a 
few years ago. It was recognized as a bug back then and appears to have been 
fixed around version 5.5 (at least it was closed at that time). At the time it 
was noted to be both a Mac and Windows problem.

Many Combo Box issues were grouped and marked as closed with the Qt 5.5 
release. I don’t know what version of Qt is used in the WSJT-X V2.1.2 release, 
but V2.1.2 doesn’t exhibit this same behavior for me. 

FYI:   On one of the forums a person posted on Feb. 28 of this year that this 
same problem is showing up again in his product, which runs on Linux platforms.

Thanks again to you, and all the other team members, for all your hard work,


Greg  NC7B



> On May 12, 2020, at 7:37 PM, Bill Somerville  wrote:
> 
> On 11/05/2020 18:13, Greg Vatt wrote:
>> Bill,
>> 
>> I downloaded v2.2.0 rc1 without a hitch and everything seemed to be working 
>> fine. I tried it out on the air and quickly had a successful QSO. Then I 
>> went to change bands and that’s when something strange happened.
>> 
>> I went to the dropdown list to change the frequency and the frequencies 
>> appeared as they should. I have a number of frequencies so sometimes it is 
>> necessary to scroll up or down depending on where I currently am in the 
>> list. It worked OK the first time. However, if I tried to be too quick, by 
>> doing a mouse-down and mouse-move in rapid succession, WSJT-x started 
>> commanding my IC-7610 to reconfigure multiple times a second, jumping 
>> seemingly randomly to various frequencies. This goes on for a few seconds.
>> 
>> 
>> 
>> 
>> 
>> As long as the initial mouse-down is clean it seems to be working. However, 
>> after the first successful commanded frequency change, from that point on if 
>> I move the mouse to be anywhere within the outline of the frequency list 
>> (shown in red above) and then do a mouse-scroll only it starts the erratic 
>> frequency commanding behavior (no mouse-down to initiate). Sometimes it 
>> stops on its own, but more often it ends with the Rig Control Error popup to 
>> reconfigure the radio interface.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Greg  NC7B
>> 
>> 
>> Configuration:
>> 
>> macOS Catalina 10.15.4, (Multi-Touch surface mouse),  ICOM IC-7610
> Hi Greg,
> 
> thanks for the issue report, I can confirm this is a defect. It is related to 
> another defect that renders the v2.2.0 RC1 WSJT-X GUI on macOS in a rather 
> clunky fashion. Both defects will be fixed in the next release.
> 
> 73
> Bill
> G4WJS.
> 

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

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

[Stephen Ireland]

Ps: I meant "previous contact" not "precious contact" ! Typnoing is bbbaaaddd 
and too much coffee this morning here !

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

Bill,

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

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

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

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

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

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

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

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

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

Steve I
VK3VM / VK3SIR

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




What I am suggesting is that o

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

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

Steve,

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

73
bill
G4WJS.



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


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


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

[wsjt-devel] An old regulatory issue resurfacing - Tunes and Identification and Timeouts

[Stephen Ireland]

Hi Folks,

My promised second post ! Sorry but its two related issues:

I am going to raise again the necessity of a "tune timeout" and "tune 
identification" functions to be set - not only to protect equipment, spectrum 
and frustration of others using bands but also to meet regulatory requirements 
that are in place in most countries (i.e. VK).

The tune timer if depressed accidentally has no identity nor timeout on its 
duration of operation (and I have just checked this checked  this and there are 
still no safeguards programmid in with r2.2.0 rc1 ). This has the capacity to 
create unnecessary garbage on our airwaves that is unidentified easily on our 
spectrum.

Regulations in most nations suggests that any transmission should be identified 
by its callsign. Tune sequences are not - they are a pure tone. Retired 
regulators here in Australia have made comments that tune sequences are not 
identified in any shape or fashion. This could be resolved by at intermittent 
points issuing high-speed morse into the tune tone sequence (i.e say after 30 
seconds of operation) or say by running a high-speed morse burst at the end of 
a tune sequence. Code already exists to do this within WSJT-X's code base.

Much testing would be required on this subject to optimise the times at which 
these station ID's are transmitted due to many of us using autotuners. 

Adjunct to this: In Australia, as well as many other nations, an 
Amateur-originated transmission must not go longer than 10 minutes without the 
transmission being identified from originating callsign

This request is minor I know - yet there is some risk associated with it to FT8 
operation in some domains. Remember that it is often the minor elements that 
blow up to be considerable. Even posting this now will have alerted regulators 
in some domains !

The second and more concerning practise revolves around the capability of the 
tune sequence to run indefinitely. 

As I have stated some years back I have myself had accidental circumstances 
where a fallen book has triggered a tune and I have accidentally not had the 
10-minute timer set (due to a firmware bug in my radio). I received a friendly 
call from a "regulator" asking me if I could please check my system ! 

Some of us also use ultra-stable, older radios or home-built SDR's where often 
hardware Tx time-out facilities do not exist. 

I have also had first-hand reports of numerous unfortunate souls that have also 
had cats, dogs, birds etc. accidentally trigger the tunes - only been alerted 
by smoke being let out of an amplifier or a power cable burning that has an 
under-rated fuse holder. Many of us leave systems running 24/7 also to assist 
with propagation reporting (i.e. https://pskreporter.info ).

That can be a serious issue ... and is an issue that I have experienced and 
also observed in other people's systems whether it be Yaesu, Kenwood and Icom. 

Related to this is the issue of poor-quality under-rated power cables. Yaesu, 
Kenwood and Icom appear to source power cables from the same supplier;  all 
power cables - 12V with blade fuses - are in my opinion possibly under-rated 
for high-duty-cycle transmissions. I see frequently (and have experienced 
myself) hot fuses burning out the plastic fuse holders; likewise poor fuses can 
go high-resistance under heat and cause intermittent transceiver shutdowns (due 
to under-voltage),

Many responded in the past "fools" and "they deserve it" when referring to 
accidents ... but responding that way is abysmal ethics - not consistent with 
philosophies of HAM - Help All Mankind - that many of us aspire to. We all 
desire AR to be around for a much longer after we ourselves have fallen SK.

>From retired/let-go regulators that talk to me in Australia my arguments of 
>the past on this subject have not gone unnoticed; at the moment there are more 
>important "fish to fry". Yet use of WSJT-X and it having the capability in one 
>of its key functions for a transmission to be conducted indefinitely without 
>callsign and without breaks could (and at some stage will) attract regulatory 
>attention - somewhere. Hey it will now as I have raised this in the open !

That is why I have recommended placing a time-out on the "tune" facility. 
Thirty (30) seconds would be more than reasonable (perhaps customisable in the 
wsjtx.ini configuration file).

A precaution a day keeps the regulator(s) away I say !

Again all of these are suggestions. The most-commonly-used-fork of code here 
has implemented this (on regulatory advice). Perhaps it is needed here as well 
within the leader? Processing and coding consequences of what I am suggesting 
here are insignificant and most code libraries already exists to implement 
these functions!

Please only constructive responses to this (and not foolish comments like "they 
deserve it" or "they are bad operators" etc. etc.) as I restate this is not the 
HAM way. Even the best operators can make mistakes and can 

Re: [wsjt-devel] WSJT-X 2.2.0-rc1

[Bill Somerville]

On 13/05/2020 02:01, Paul Kube wrote:
On Tue, May 12, 2020 at 1:29 PM Bill Somerville > wrote:



  Most users will see ... more decodes overall with the last few
maybe only printing some time into the following period.

On this point: When a signal is sent in a period, but decoded in the 
next period, I have seen the transmission appear with the "wrong" 
timestamp in the Band Activity pane.


73, Paul K6PO


Paul,

are you observing this behaviour in WSJT-X v2.2.0 RC1, or in a prior 
version?


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.2.0-rc1

[Paul Kube]

On Tue, May 12, 2020 at 1:29 PM Bill Somerville 
wrote:

>   Most users will see ... more decodes overall with the last few maybe
> only printing some time into the following period.
>
> On this point: When a signal is sent in a period, but decoded in the next
period, I have seen the transmission appear with the "wrong" timestamp in
the Band Activity pane.

73, Paul K6PO


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

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

[Stephen Ireland]

Bill,

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

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

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

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

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

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

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

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

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

Steve I
VK3VM / VK3SIR

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




What I am suggesting is that o

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

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

Steve,

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

73
bill
G4WJS.



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


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

Re: [wsjt-devel] 2.2.0 RC1 Issues

[Ken Cox]

Installed [wsjt-devel] 2.2.0 RC1 on latest update of MacOs HiSierra with Icom 
IC7300. Only issue is with tune power level memory. Not sure I’m setting things 
properly. When all else fails, read the manual. Thanks for the effort everyone 
put into development of such a fine piece of software. Ken WA8OMR

> On May 12, 2020, at 7:37 PM, David Tiller  wrote:
> 
> Dear devs,
> 
> I began using the latest release candidate today and love the early decodes, 
> but I noticed a few things that seemed to be not working reliably under OSX.
> 
> My Setup: OSX 10.13.6, Icom 756PRO, and a RigExpert Standard. This setup 
> works flawlessly with 2.1.2.
> 
> 1) 2.20-RC1 does not remember the last band used on startup. It often starts 
> on 160m and ends up on  2m, sometimes changing it while the RC banner is 
> showing.
> 2) PTT on TX is intermittent, as is the 'tune' function. Note that I do NOT 
> use CAT control of the rig from WSJT-X (or anything else when testing this).
> 3) Testing PTT sometimes works. The button turns red by itself and only 
> actually keys the radio occasionally.
> 
> Going into the Preferences/Radio menu tab immediately after startup gives me 
> a red Test PTT button. With 2.1.2 I get a white button, as expected. See 
> image, below.
> 
> 
> I've made a video of the issues that can be downloaded from this folder link:
> 
> https://drive.google.com/open?id=1lRJIQFGZifH67zHoJUmajqDJiRrp43te 
> 
> 
> In case the listserv eats the link, it's:
> h t t p s:// drive_google_com / open ? id= 1lRJIQFGZifH67zHoJUmajqDJiRrp43te
> 
> sub '.' for '_' and remove spaces.
> 
> Thanks to all the devs for all their hard work!
> 
> 
> 
> ___
> 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] 2.2.0 RC1 Issues

[David Tiller]

Dear devs,

I began using the latest release candidate today and love the early decodes, 
but I noticed a few things that seemed to be not working reliably under OSX.

My Setup: OSX 10.13.6, Icom 756PRO, and a RigExpert Standard. This setup works 
flawlessly with 2.1.2.

1) 2.20-RC1 does not remember the last band used on startup. It often starts on 
160m and ends up on  2m, sometimes changing it while the RC banner is showing.
2) PTT on TX is intermittent, as is the 'tune' function. Note that I do NOT use 
CAT control of the rig from WSJT-X (or anything else when testing this).
3) Testing PTT sometimes works. The button turns red by itself and only 
actually keys the radio occasionally.

Going into the Preferences/Radio menu tab immediately after startup gives me a 
red Test PTT button. With 2.1.2 I get a white button, as expected. See image, 
below.


I've made a video of the issues that can be downloaded from this folder link:

https://drive.google.com/open?id=1lRJIQFGZifH67zHoJUmajqDJiRrp43te

In case the listserv eats the link, it's:
h t t p s:// drive_google_com / open ? id= 1lRJIQFGZifH67zHoJUmajqDJiRrp43te

sub '.' for '_' and remove spaces.

Thanks to all the devs for all their hard work!


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

Re: [wsjt-devel] v2.2.0 rc1 Dropdown Frequency list anomaly

[V. Scott Moore via wsjt-devel]

Update:

Upgraded to MacOS 10.15.4 this morning.

Indeed if I place the cursor over the frequency dropdown and initiate a scroll 
(move one finger) the band changes with no click required.  The ACOM was 
connected to the rig and you
would not believe how much noise the band swithing relay(s) make changing bands 
from 30 to 6 to 160 in 1/2 second.

This is not good but it might not be WSJT-X’s issue.  Along with the upgrade 
came multiple warnings of 
third party extensions not being compatible with newer MacOS versions.  One was 
the Silicon Lab driver for the radio and another for FTDI chipset (Keyspan 
USB/RS232).

Another note which I don’t understand.  I tried to go back to 2.1.2 and  the 
program will not complete a launch.  
2.1.2 attempts to start and I get the “WSJT-X quit unexpectedly click REOPEN to 
open the application again” dialog box.

I saved the report If anyone wants/needs it.

Scott
W1SSN

> On May 11, 2020, at 20:14, V. Scott Moore  wrote:
> 
> From the peanut gallery:
> 
> I am running Catalina 10.15.3, Icom 7610 with the stock magic mouse with no 
> issues in the freq dropdown.
> The look of the dropdown has changed but functionality is good here.
> I will do the update to 10.15.4 tomorrow and if different I will post.
> 
> scott
> w1ssn
> 
>> On May 11, 2020, at 19:17, Greg Vatt mailto:n...@cox.net>> 
>> wrote:
>> 
>> Mike,
>> 
>> At my first attempt to avoid writing a long email and not give every single 
>> detail it appears I didn’t communicate my point well. What I experienced, 
>> first, did not occur in the prior versions of WSJT-X and second, it exposes 
>> a potential underlying difference (maybe problem?) with how the code might 
>> be handling the drop down frequency list now. 
>> 
>> Observation:
>> 
>> After I change the frequency for the first time it appears the software 
>> never completely releases the action after the popup completes the original 
>> frequency change. The Frequency drop down remains active even after the list 
>> is collapsed (probably because it is both a drop down list and an editable 
>> text field). If I happen to pass the mouse over the frequency box again (no 
>> mouse down - no frequency list exposed) it can trigger a spontaneous 
>> repeating of the software to reconfigure the radio (multiple times on 
>> different frequencies in rapid fashion) until I get the popup with the Rig 
>> Control Error message. The recovery mode is then to select cancel which 
>> force quits WSJT-X and then reboot again. I only discovered the odd 
>> scrolling behavior when I tried to stop the action by forcing the drop down 
>> list to be exposed again and then select any frequency to stop it. Every 
>> once in a while it stops everything at that point before the Rig Control 
>> Error message comes up.
>> 
>> Observation:
>> 
>> If I resume operation after a successful frequency change without clicking 
>> on any other text field or control on the WSJT-X page both the mouse-scroll 
>> and the keyboard up/down keys can still cause the frequency to change even 
>> though the Frequency drop down list is no longer exposed (maybe desired - 
>> but not the same behavior on a Mac as V2.1.2 - see below). If I select some 
>> other text field in the window then only the up/down keys are disabled from 
>> making a frequency change from that point on but the scroll of the Frequency 
>> List (now hidden) still is operational if the mouse ventures into the 
>> Frequency control field again. (Doesn’t matter if the cursor is blinking and 
>> active in the Frequency Edit Field or blinking somewhere else on the page.)
>> 
>> (The behavior is the same for the up/down keys in V2.1.2, but V2.1.2 has the 
>> mouse scroll disabled on
>> a Mac for all conditions regarding frequency selection except when the 
>> Frequency List is exposed.)
>> 
>> I’m hoping to communicate that one would think the new Frequency selection 
>> would be determined when the Frequency selection list is opened on the first 
>> mouse-click and then the new frequency choice is finalized on the second 
>> mouse-click (when the list is collapsed again) no matter if the selection is 
>> made by scrolling to the frequency choice or using the up/down keys. All of 
>> these strange behaviors I’m experiencing can occur without the drop down 
>> list ever being exposed. If the scrolling action can cause bad things to 
>> happen then it shouldn’t be allowed in the code loop until after a drop down 
>> occurs (that was the V2.1.2 behavior on a Mac).
>> 
>> On a Mac, the WSJT-X frequency selection is a single-finger, one-step, 
>> no-mouse-move process, when using a Multi-Touch surface mouse. It becomes a 
>> multi-step move and mouse click process when the up/down keys are involved. 
>> So, I am just trying to take advantage of the simplified process that always 
>> worked before. 
>> 
>> Summary:
>> 
>> I’m just trying to report new observations that did not happen to me with 
>> the prior versions of WSJT-X while using 

[wsjt-devel] Bug Report V 2.2.0 RC1

[Dave Anderson, K4SV via wsjt-devel]

Hi Everyone,
I am new to the group here and not sure where to make a bug report other than 
what the WSJTX site suggests, which is here.
Overall software runs very well.  Using it for 630 meter WSPR at the moment.
BugAfter setting the transmit power level it transmits correctly but if the 
application is closed and reopened it forgets the previous power setting and 
reverts to a level of 0.
Win 7WSJTX V2.2.0  rc1
Thanks in advance,
PS Please advise if bug reports should be reported differently.
Best 73
Dave Anderson, K4SVTryon, NC WWW.K4SV.NET

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

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

[Neil Zampella]

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

Neil, KN3ILZ

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

Folks,

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

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

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

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

73, and as I reiterate this is GREAT work !

Steve I
VK3VM / VK3SIR





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



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

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

[Bill Somerville]

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

Folks,

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

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

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

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

73, and as I reiterate this is GREAT work !

Steve I
VK3VM / VK3SIR


Steve,

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


73
bill
G4WJS.



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

Re: [wsjt-devel] WSJT-X 2.2.0-rc1 - Hamlib NET rigctl no longer works

[Bill Somerville]

Hi Erik,

I think you may be misunderstanding what rigctld is, it is the Hamlib 
network rig control server. The Hamlib API and the rigctl command line 
tool expect to be talking to an instance of rigctld running somewhere on 
the Internet (by default localhost:4532). The rigctld server has all the 
same rig back end drivers built in as are found in the rigctl library or 
in rigctl. It seems that SparkSDR have hijacked the internal network 
protocol between the Hamlib library and rigctld, i.e. spoofed a rigctld 
server, this makes little sense to me and a far better and conformant 
option would be for the SparkSDR authors to contribute a Hamlib back end 
driver for their SDR.


73
Bill
G4WJS.

On 12/05/2020 23:18, runninge...@gmail.com wrote:

Hi Bill,

Thanks for looking into this and I can already provide you with the
following answers :

- WSJT-X reports in its error dialog "Rig Failure" "Hamlib error :
Communication timed out while getting current VFO frequency"
- There is no error in the SparkSDR latest "corelog-2020-05-12-19-35-54.txt"
and I have a suspicion, the WSJTX 2.2.0 command does not reach the network
server at SparkSDR
- The reason for my using the "rigctl-wsjtx" command was to check the
network transport (which seems to work). Now that I presume / understand you
are using rigctld for connecting to a network server, I will check with
M0NNB if we can debug this offline (and put you in email copy).
- Lets maybe keep in mind that this was working in release 2.1.2.

73's and thanks again,
Erik
ON4PB

---
Message: 2
Date: Tue, 12 May 2020 22:34:02 +0100
From: Bill Somerville
To:wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc1 - Hamlib NET rigctl no
longer works
Message-ID:<6bc371e6-9e40-e938-c597-98af91d1d...@classdesign.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 12/05/2020 22:16,runninge...@gmail.com  wrote:

Hi,

thanks one more time for all the dedicated work with yet another big
step forward in decoding weal signals . !

Let me report that I am no longer able to CAT control my SparkSDR with
the "Hamlib NET rigctl" network server.

My settings are : "localhost:5" for Network server, which should
connect to my first (out of four) virtual transceiver in SparkSDR
(which is connected to a Hermes Lite II).
Substituting "localhost" with its IP address or hostname does not
solve the problem neither.
The same settings work fine with WSJT-X 2.1.2.

Some more observations :
- The "C:\WSJT\wsjtx\bin>rigctl-wsjtx -m 2 -r localhost:5 F
7253500 M LSB 0" command correctly sets the VFO and mode.
- Overwriting the 3 rigctl executables with the release 2.1.2 binaries
yields the same result (sorry but I could not withstand doing this .).

This is on a windows 10 - 64 bit config.

73's and best regards,
Erik
ON4PB

Hi Erik,

I see no mention of you running any form of rigctld, this makes me think
that SparkSDR has hijacked the Hamlib internal network protocol and is
acting as a fake rigctld. If that is so then the authors of SparkSDR
probably need to update their software to conform with the latest Hamlib
network protocol. It may well be that WSJT-X is sending commands that he
fake rigctld server does not understand. Do you get an error from WSJT-X, if
so what is it including the details? Does SparkSDR have an way of tracing
the commands sent to it?

73
Bill
G4WJS.



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

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

[Stephen Ireland]

Folks,

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

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

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

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

73, and as I reiterate this is GREAT work !

Steve I
VK3VM / VK3SIR



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

Re: [wsjt-devel] WSJT-X 2.2.0-rc1 - Hamlib NET rigctl no longer works

[runningerik]

Hi Bill,

Thanks for looking into this and I can already provide you with the
following answers :

- WSJT-X reports in its error dialog "Rig Failure" "Hamlib error :
Communication timed out while getting current VFO frequency"
- There is no error in the SparkSDR latest "corelog-2020-05-12-19-35-54.txt"
and I have a suspicion, the WSJTX 2.2.0 command does not reach the network
server at SparkSDR
- The reason for my using the "rigctl-wsjtx" command was to check the
network transport (which seems to work). Now that I presume / understand you
are using rigctld for connecting to a network server, I will check with
M0NNB if we can debug this offline (and put you in email copy).
- Lets maybe keep in mind that this was working in release 2.1.2.

73's and thanks again,
Erik
ON4PB

---
Message: 2
Date: Tue, 12 May 2020 22:34:02 +0100
From: Bill Somerville 
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc1 - Hamlib NET rigctl no
longer works
Message-ID: <6bc371e6-9e40-e938-c597-98af91d1d...@classdesign.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 12/05/2020 22:16, runninge...@gmail.com wrote:
> Hi,
>
> thanks one more time for all the dedicated work with yet another big 
> step forward in decoding weal signals . !
>
> Let me report that I am no longer able to CAT control my SparkSDR with 
> the "Hamlib NET rigctl" network server.
>
> My settings are : "localhost:5" for Network server, which should 
> connect to my first (out of four) virtual transceiver in SparkSDR 
> (which is connected to a Hermes Lite II).
> Substituting "localhost" with its IP address or hostname does not 
> solve the problem neither.
> The same settings work fine with WSJT-X 2.1.2.
>
> Some more observations :
> - The "C:\WSJT\wsjtx\bin>rigctl-wsjtx -m 2 -r localhost:5 F 
> 7253500 M LSB 0" command correctly sets the VFO and mode.
> - Overwriting the 3 rigctl executables with the release 2.1.2 binaries 
> yields the same result (sorry but I could not withstand doing this .).
>
> This is on a windows 10 - 64 bit config.
>
> 73's and best regards,
> Erik
> ON4PB

Hi Erik,

I see no mention of you running any form of rigctld, this makes me think
that SparkSDR has hijacked the Hamlib internal network protocol and is
acting as a fake rigctld. If that is so then the authors of SparkSDR
probably need to update their software to conform with the latest Hamlib
network protocol. It may well be that WSJT-X is sending commands that he
fake rigctld server does not understand. Do you get an error from WSJT-X, if
so what is it including the details? Does SparkSDR have an way of tracing
the commands sent to it?

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.2.0-rc1

[Black Michael via wsjt-devel]

You don't say what OS you use but there is JTAlert for Windows.And GridTracker 
and AlarmJT for Linux.
http://hamapps.com/
https://sourceforge.net/projects/alarmejt/
https://www.m0spn.co.uk/2020/02/01/gridtracker-a-jtalert-for-linux/


de Mike W9MDB

 

On Tuesday, May 12, 2020, 05:07:26 PM CDT, Gary Hinson  
wrote:  
 
 
The OPTION to sort each 15 second batch of decodes by any of the message fields 
or contents would be useful for DXers, Bill.  

  

DXers are not necessarily keen to respond the very instant decodes appear: 
sometimes, it is better to wait and watch a cycle or three, picking out DX 
stations of interest in QSO, maybe turning the beam and then calling when 
ready.  DXing is more about listening and watching than transmitting!  
‘Autorespond’ isn’t necessarily the best approach.

  

I can think of situations where, even if it took a while to do, it would be 
useful to be able to re-sort the batches of messages by:
   
   - dBs – DX signals are often weaker
   - Frequency – perhaps trying to figure out who is behind a weak trace on the 
waterfall, or a signal causing QRM to the DX I might be watching
   - Callsign worked – to work out where the DX station is listening and 
working other people, implying clear frequencies his end
   - Callsign used* – an obvious way to find exotic or unusual DX stations, or 
to hunt for decodes from a DX station that has been spotted on DXcluster
   - Locator* [from CQs] – either to hunt for stations outside the normal 
areas, maybe new states, or simply to collect grids
   - Distance away – this isn’t currently shown but might be calculated from 
the locator or estimated from the prefix, on the basis that DX is often distant 
 

  

* An alternative, perhaps complementary approach would be to align the 
displayed messages around the callsign used or locator (if present) rather than 
simply all being left-aligned.  That would make it easier to glance down the 
decodes for interesting stations.  So, instead of something like this:

  

213000  -10   0.2  1138  ~ CQ PE3T JO21

213000   -4    0.4  1862  ~ N1UL IZ2FDX JN25

213000   +2  -0.3  2598  ~ EL2BG JR3GWZ RR73

etc.

  

… which forces us to glance left and right to locate the fields of interest on 
each line while speed-reading the latest batch of decodes, we would see:

  

213000  -10   0.2  1138  ~    CQ PE3T JO21

213000   -4    0.4  1862  ~    N1UL IZ2FDX JN25

213000   +2  -0.3  2598  ~  EL2BG JR3GWZ RR73

etc.  [aligned by callsign used]

  

… or 

  

213000  -10   0.2  1138  ~  CQ PE3T JO21

213000   -4    0.4  1862  ~  N1UL IZ2FDX JN25

213000   +2  -0.3  2598  ~  EL2BG JR3GWZ RR73

etc.  [aligned by grid]

  

And for bonus marks, the aligned-by text might be shown in bold, drawing more 
attention to them, or perhaps delineated with a subtle (e.g. 1 pixel wide grey) 
vertical line immediately to its left.

  

The issue of the text jumping around on the screen as it is first 
displayed-as-decoded then re-sorted-as-required, and hence the difficulty of 
clicking on a specific line, would be lessened if updates (including display of 
the next batch of messages received) were automatically frozen while the mouse 
cursor is in that part of the screen, suggesting that the user is about to 
click a decode.  Mouse away to let it update and sort, mouse in to click a 
specific line.  Easy peasy!  [I appreciate this might confuse newbies leading 
to support calls about the messages being frozen, but they’d soon figure it out 
for themselves!  Maybe the screen freeze thing ought to be an ‘advanced 
option’, disabled by default?]

  

73

Gary  ZL2iFB

  

From: Bill Somerville  
Sent: 13 May 2020 07:29
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc1

  

On 12/05/2020 20:22, Christoph Berg wrote:

Re: Bill Somerville
this change is deliberate. Prior versions favour strong stations calling atthe 
lowest audio offset, we think it is better to randomize the frequencyorder to 
give all stations more equal weighting. This is particularly inrespect of the 
"Call 1st" feature. There is also another factor, the latestFT8 decoder makes 
up to three attempts at decoding, each doing up to threepasses. Each attempt 
subtracts signals from prior attempts to reveal maskedsignals. There is no 
sorting or randomizing across the attempts, theoverriding priority being to 
print he decodes as soon as possible after theyare discovered.
Well that still favors the stronger stations. Was "calling at loweroffset" 
something people were really rushing for, or did that have anybias towards them 
in contests or crowded bands?  What I wanted sometimes was a "favor callers 
*not* on my txfrequency". (But that's probably an unrelated thing to this 
change.)  Another plus of the old ordering was that you could see the 
threepasses and say "hey look it decoded this one because it subtracted 
astronger signal first". The new ordering seems to be pretty messyinstead.  
Christoph

Re: [wsjt-devel] JAVA class

[Heimir Thor Sverrisson]

Lorenzo,
take a look at my Github repository,
https://github.com/heimir-sverrisson/MapQSOs
It's Java code that runs a UDP listener and pushes all WSJTX messages
on to a queue.
You should be able to adapt the Consumer class to do whatever you want
with the messages.

Disclaimer:
I have not touched this code in a long time, but it was working fine
last time I checked.

Thanks,
Heimir, W1ANT

On Tue, May 12, 2020 at 11:58 AM Lloyd via wsjt-devel
 wrote:
>
> Hello,
>
> I'm Lorenzo IZ0KBA, student of Computer Science in University Sapienza
> of Rome.
>
> I found PYTHON class for WSJTX to decode UDP packet, exist the same
> CLASS for JAVA???
>
> Thanks
>
>
>
> ___
> 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.2.0-rc1

[Stephen Ireland]

Joe,

>From a Windows 64-bit capability on JTSDK 3.1 what I am seeing is absolutely 
>brilliant. Your coding throws no deprecation warnings and the Fortran 
>components have no integer division warnings (that can always be of concern) 
>with the "JTSDK 3.1 experiment" patches that I have provided. I observe is the 
>odd "possibly initialised" warnings .. and these are completely negligible at 
>any technical level in any case as often these can be thrown by just 
>fulfilling requirements for function/method parameters that need to be 
>fulfilled !

Brilliant !

>From an operational perspective the early start of decoders and dispatching of 
>the "easily decoded" first - leaving later decoding for weaker signals appears 
>to have improved the ability of the software to pick out stations much better 
>in this far-away town in a far-away land that is 200km away from any 
>population centre  greater than half a million people !

Initial observations of what I see on 20m operating FT8 "deep decoding" with 
"AP" mode suggests that the decoder is picking out considerably more signals 
and more reliably than observed with previous versions. I have made one 
successful but messy contact here from VK3 into BX5 on 20m - but propagation is 
not properly with me yet and there are obvious "waves" of QSB;  propagation 
will not be reliably allow Trans-Pacific work for around another 30 minutes or 
so yet this time of the year.

Brilliant. Thoroughly brilliant work to achieve this at a programming and 
technical standard by the Core Development Team.

Again well done to the team. I'll post more observations as I see them !

73

Steve I
VK3VM / VK3SIR


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

Re: [wsjt-devel] WSJT-X 2.2.0-rc1

[Gary Hinson]

The OPTION to sort each 15 second batch of decodes by any of the message fields 
or contents would be useful for DXers, Bill.  

 

DXers are not necessarily keen to respond the very instant decodes appear: 
sometimes, it is better to wait and watch a cycle or three, picking out DX 
stations of interest in QSO, maybe turning the beam and then calling when 
ready.  DXing is more about listening and watching than transmitting!  
‘Autorespond’ isn’t necessarily the best approach.

 

I can think of situations where, even if it took a while to do, it would be 
useful to be able to re-sort the batches of messages by:

*   dBs – DX signals are often weaker
*   Frequency – perhaps trying to figure out who is behind a weak trace on 
the waterfall, or a signal causing QRM to the DX I might be watching
*   Callsign worked – to work out where the DX station is listening and 
working other people, implying clear frequencies his end
*   Callsign used* – an obvious way to find exotic or unusual DX stations, 
or to hunt for decodes from a DX station that has been spotted on DXcluster
*   Locator* [from CQs] – either to hunt for stations outside the normal 
areas, maybe new states, or simply to collect grids
*   Distance away – this isn’t currently shown but might be calculated from 
the locator or estimated from the prefix, on the basis that DX is often distant 
 

 

* An alternative, perhaps complementary approach would be to align the 
displayed messages around the callsign used or locator (if present) rather than 
simply all being left-aligned.  That would make it easier to glance down the 
decodes for interesting stations.  So, instead of something like this:

 

213000  -10   0.2  1138  ~ CQ PE3T JO21

213000   -40.4  1862  ~ N1UL IZ2FDX JN25

213000   +2  -0.3  2598  ~ EL2BG JR3GWZ RR73

etc.

 

… which forces us to glance left and right to locate the fields of interest on 
each line while speed-reading the latest batch of decodes, we would see:

 

213000  -10   0.2  1138  ~CQ PE3T JO21

213000   -40.4  1862  ~N1UL IZ2FDX JN25

213000   +2  -0.3  2598  ~  EL2BG JR3GWZ RR73

etc.  [aligned by callsign used]

 

… or 

 

213000  -10   0.2  1138  ~  CQ PE3T JO21

213000   -40.4  1862  ~  N1UL IZ2FDX JN25

213000   +2  -0.3  2598  ~  EL2BG JR3GWZ RR73

etc.  [aligned by grid]

 

And for bonus marks, the aligned-by text might be shown in bold, drawing more 
attention to them, or perhaps delineated with a subtle (e.g. 1 pixel wide grey) 
vertical line immediately to its left.

 

The issue of the text jumping around on the screen as it is first 
displayed-as-decoded then re-sorted-as-required, and hence the difficulty of 
clicking on a specific line, would be lessened if updates (including display of 
the next batch of messages received) were automatically frozen while the mouse 
cursor is in that part of the screen, suggesting that the user is about to 
click a decode.  Mouse away to let it update and sort, mouse in to click a 
specific line.  Easy peasy!  [I appreciate this might confuse newbies leading 
to support calls about the messages being frozen, but they’d soon figure it out 
for themselves!  Maybe the screen freeze thing ought to be an ‘advanced 
option’, disabled by default?]

 

73

Gary  ZL2iFB

 

From: Bill Somerville  
Sent: 13 May 2020 07:29
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc1

 

On 12/05/2020 20:22, Christoph Berg wrote:

Re: Bill Somerville

this change is deliberate. Prior versions favour strong stations calling at
the lowest audio offset, we think it is better to randomize the frequency
order to give all stations more equal weighting. This is particularly in
respect of the "Call 1st" feature. There is also another factor, the latest
FT8 decoder makes up to three attempts at decoding, each doing up to three
passes. Each attempt subtracts signals from prior attempts to reveal masked
signals. There is no sorting or randomizing across the attempts, the
overriding priority being to print he decodes as soon as possible after they
are discovered.

Well that still favors the stronger stations. Was "calling at lower
offset" something people were really rushing for, or did that have any
bias towards them in contests or crowded bands?
 
What I wanted sometimes was a "favor callers *not* on my tx
frequency". (But that's probably an unrelated thing to this change.)
 
Another plus of the old ordering was that you could see the three
passes and say "hey look it decoded this one because it subtracted a
stronger signal first". The new ordering seems to be pretty messy
instead.
 
Christoph

Hi Christoph,

yes stronger signals may well be decoded on an earlier pass, but we cannot deal 
with that without delaying the printing of any decodes until all decodes 
attempts are completed, that would be very counterproductive given one feature 
of the latest decoder is there to yield decodes before all 

Re: [wsjt-devel] WSJT-X 2.2.0-rc1

[Joe Taylor]

Hi Ray,

Thanks for your feedback.  Happy to hear that v2.2.0 is working well for 
you!


We are well aware that many WSPR users devote a rather elderly computer 
to a WSPR setup.  Nevertheless, we don't put strict requirements on 
speed of the WSPR decoder; the nature of WSPR is that there's no real 
need to finish decoding before the next 2-minute sequence starts.


-- 73, Joe, K1JT

On 5/12/2020 17:35, Ray Rocker wrote:

Bill,

Some early observations of 2.2.0-rc1 decoding:

I parsed through my ALL.TXT (375+ MB) counting number of decodes per
cycle. Prior to yesterday, my highest number of unique FT8 decodes in
one cycle was 63.

After installing 2.2.0-rc1, I monitored 14.074 for a couple of hours
yesterday afternoon. During that time I logged 10 cycles with >63
unique decodes, the highest being 72. So, it's definitely working well
for me.

I also monitored 30 meter WSPR for a little while and was regularly
getting 10-15 decodes per cycle. Anecdotally that feels like a big
improvement but I don't monitor WSPR enough to have a meaningful
baseline.

I noticed that the final WSPR decode pass extended well into the next
cycle, 10 seconds or more, when the window was busy. Granted, this is
with a 10+ year old AMD CPU...

73 -- Ray WQ5L


On Tue, May 12, 2020 at 3:30 PM Bill Somerville  wrote:


On 12/05/2020 20:45, j...@comcast.net wrote:


one feature of the latest decoder is there to yield decodes before all 
transmissions are completed.




Bill,



Was this a user request, or just a result of the new decoding algorithm?   (My 
curiosity has been piqued.)



Ed N4II.

Hi Ed,

because the FT8 protocol includes Forward Error Correction (FEC) information it is possible to 
successfully decode a signal before the complete block of data has been received, this is an 
opportunity to pick the "low hanging fruit" as early as is practical, leaving more 
elapsed time to work on the remaining signals. The intent is both to deliver some decodes earlier 
and to utilize more CPU resource to yield more decodes in a reasonable time frame. Most users, 
probably all, on a busy band will see some decodes earlier in the receive period and also more 
decodes overall with the last few maybe only printing some time into the following period. We have 
not put a number to the extra decode yield but we have certainly see up to one third more when 
processing saved .WAV files from congested bands compared to the v2.1.2 FT8 decoder. Steve K9AN has 
a "golden" test FT8 .WAV file that he uses to verify decoder yield and I believe the 
current result from that file is 67 unique valid !

  decodes.


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] WSJT-X 2.2.0-rc1

[Ray Rocker]

Bill,

Some early observations of 2.2.0-rc1 decoding:

I parsed through my ALL.TXT (375+ MB) counting number of decodes per
cycle. Prior to yesterday, my highest number of unique FT8 decodes in
one cycle was 63.

After installing 2.2.0-rc1, I monitored 14.074 for a couple of hours
yesterday afternoon. During that time I logged 10 cycles with >63
unique decodes, the highest being 72. So, it's definitely working well
for me.

I also monitored 30 meter WSPR for a little while and was regularly
getting 10-15 decodes per cycle. Anecdotally that feels like a big
improvement but I don't monitor WSPR enough to have a meaningful
baseline.

I noticed that the final WSPR decode pass extended well into the next
cycle, 10 seconds or more, when the window was busy. Granted, this is
with a 10+ year old AMD CPU...

73 -- Ray WQ5L


On Tue, May 12, 2020 at 3:30 PM Bill Somerville  wrote:
>
> On 12/05/2020 20:45, j...@comcast.net wrote:
>
> >one feature of the latest decoder is there to yield decodes before all 
> >transmissions are completed.
>
>
>
> Bill,
>
>
>
> Was this a user request, or just a result of the new decoding algorithm?   
> (My curiosity has been piqued.)
>
>
>
> Ed N4II.
>
> Hi Ed,
>
> because the FT8 protocol includes Forward Error Correction (FEC) information 
> it is possible to successfully decode a signal before the complete block of 
> data has been received, this is an opportunity to pick the "low hanging 
> fruit" as early as is practical, leaving more elapsed time to work on the 
> remaining signals. The intent is both to deliver some decodes earlier and to 
> utilize more CPU resource to yield more decodes in a reasonable time frame. 
> Most users, probably all, on a busy band will see some decodes earlier in the 
> receive period and also more decodes overall with the last few maybe only 
> printing some time into the following period. We have not put a number to the 
> extra decode yield but we have certainly see up to one third more when 
> processing saved .WAV files from congested bands compared to the v2.1.2 FT8 
> decoder. Steve K9AN has a "golden" test FT8 .WAV file that he uses to verify 
> decoder yield and I believe the current result from that file is 67 unique 
> valid decodes.
>
> 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.2.0-rc1 - Hamlib NET rigctl no longer works

[Bill Somerville]

On 12/05/2020 22:16, runninge...@gmail.com wrote:

Hi,

thanks one more time for all the dedicated work with yet another big step
forward in decoding weal signals . !

Let me report that I am no longer able to CAT control my SparkSDR with the
"Hamlib NET rigctl" network server.

My settings are : "localhost:5" for Network server, which should connect
to my first (out of four) virtual transceiver in SparkSDR (which is
connected to a Hermes Lite II).
Substituting "localhost" with its IP address or hostname does not solve the
problem neither.
The same settings work fine with WSJT-X 2.1.2.

Some more observations :
- The "C:\WSJT\wsjtx\bin>rigctl-wsjtx -m 2 -r localhost:5 F 7253500 M
LSB 0" command correctly sets the VFO and mode.
- Overwriting the 3 rigctl executables with the release 2.1.2 binaries
yields the same result (sorry but I could not withstand doing this .).

This is on a windows 10 - 64 bit config.

73's and best regards,
Erik
ON4PB


Hi Erik,

I see no mention of you running any form of rigctld, this makes me think 
that SparkSDR has hijacked the Hamlib internal network protocol and is 
acting as a fake rigctld. If that is so then the authors of SparkSDR 
probably need to update their software to conform with the latest Hamlib 
network protocol. It may well be that WSJT-X is sending commands that he 
fake rigctld server does not understand. Do you get an error from 
WSJT-X, if so what is it including the details? Does SparkSDR have an 
way of tracing the commands sent to it?


73
Bill
G4WJS.



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

[wsjt-devel] WSJT-X 2.2.0-rc1 - Hamlib NET rigctl no longer works

[runningerik]

Hi, 

thanks one more time for all the dedicated work with yet another big step
forward in decoding weal signals . !

Let me report that I am no longer able to CAT control my SparkSDR with the
"Hamlib NET rigctl" network server.

My settings are : "localhost:5" for Network server, which should connect
to my first (out of four) virtual transceiver in SparkSDR (which is
connected to a Hermes Lite II). 
Substituting "localhost" with its IP address or hostname does not solve the
problem neither.
The same settings work fine with WSJT-X 2.1.2.

Some more observations :
- The "C:\WSJT\wsjtx\bin>rigctl-wsjtx -m 2 -r localhost:5 F 7253500 M
LSB 0" command correctly sets the VFO and mode.
- Overwriting the 3 rigctl executables with the release 2.1.2 binaries
yields the same result (sorry but I could not withstand doing this .).

This is on a windows 10 - 64 bit config.

73's and best regards,
Erik
ON4PB







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

Re: [wsjt-devel] Raspberry GPIO

[Bill Somerville]

Hi Lloyd,

that depends on your rig settings and serial port for CAT. Run this to 
get command line help:


rigctld-wsjtx -h

and this to discover your rig's model number:

rigctld-wsjtx -l

To discover the other configuration options for your rig you type:

rigctld-wsjtx -m 2014 -L

You probably need something like:

rigctld-wsjtx -m 2014 -r /dev/ttyUSB0 -s 57600 -P GPIO -p 17

substitute you CAT control device (maybe /dev/ttyAMA0 if you are using 
the onboard UART) or leave out the -r and -s switches if you have no CAT 
serial connection.


73
Bill
G4WJS.

On 12/05/2020 20:37, Lloyd via wsjt-devel wrote:

Hi Bill, thanks.

Can you tell me how I start rigctld server? And arguments? I use TS2000.

Thanks



Il 12/05/2020 21:11, Bill Somerville ha scritto:

On 12/05/2020 18:53, Lloyd via wsjt-devel wrote:

Hello!

It's possible to have PTT via GPIO of Raspberry??

Thanks

73 de IZ0KBA 


Hi Lloyd,

yes, you can do this using the rigctld server (a version called 
rigctld-wsjtx is packaged with WSJT-X). Set WSJT-X to use the "Hamlib 
NET rigctl" rig type with "PTT Method" as "CAT". Start the rigctld 
server with arguments to specify the GPIO pin to be used for PTT (-P 
GPIO -p 17 for example to use pin 17).


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.2.0-rc1

[jan0]

Excellent.  Thank you.

 

From: Bill Somerville  
Sent: Tuesday, May 12, 2020 4:25 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc1

 

On 12/05/2020 20:45, j...@comcast.net   wrote:

>one feature of the latest decoder is there to yield decodes before all 
>transmissions are completed.

 

Bill,

 

Was this a user request, or just a result of the new decoding algorithm?   (My 
curiosity has been piqued.)

 

Ed N4II.

Hi Ed,

because the FT8 protocol includes Forward Error Correction (FEC) information it 
is possible to successfully decode a signal before the complete block of data 
has been received, this is an opportunity to pick the "low hanging fruit" as 
early as is practical, leaving more elapsed time to work on the remaining 
signals. The intent is both to deliver some decodes earlier and to utilize more 
CPU resource to yield more decodes in a reasonable time frame. Most users, 
probably all, on a busy band will see some decodes earlier in the receive 
period and also more decodes overall with the last few maybe only printing some 
time into the following period. We have not put a number to the extra decode 
yield but we have certainly see up to one third more when processing saved .WAV 
files from congested bands compared to the v2.1.2 FT8 decoder. Steve K9AN has a 
"golden" test FT8 .WAV file that he uses to verify decoder yield and I believe 
the current result from that file is 67 unique valid decodes.

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.2.0-rc1

[Bill Somerville]

On 12/05/2020 20:45, j...@comcast.net wrote:


>one feature of the latest decoder is there to yield decodes before 
all transmissions are completed.


Bill,

Was this a user request, or just a result of the new decoding 
algorithm?   (My curiosity has been piqued.)


Ed N4II.


Hi Ed,

because the FT8 protocol includes Forward Error Correction (FEC) 
information it is possible to successfully decode a signal before the 
complete block of data has been received, this is an opportunity to pick 
the "low hanging fruit" as early as is practical, leaving more elapsed 
time to work on the remaining signals. The intent is both to deliver 
some decodes earlier and to utilize more CPU resource to yield more 
decodes in a reasonable time frame. Most users, probably all, on a busy 
band will see some decodes earlier in the receive period and also more 
decodes overall with the last few maybe only printing some time into the 
following period. We have not put a number to the extra decode yield but 
we have certainly see up to one third more when processing saved .WAV 
files from congested bands compared to the v2.1.2 FT8 decoder. Steve 
K9AN has a "golden" test FT8 .WAV file that he uses to verify decoder 
yield and I believe the current result from that file is 67 unique valid 
decodes.


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.2.0-rc1

[Joe Taylor]

Hi Christoph,

On 5/12/2020 15:22, Christoph Berg DFG7CB wrote:


Well that still favors the stronger stations. Was "calling at lower
offset" something people were really rushing for, or did that have any
bias towards them in contests or crowded bands?


Of course stronger signals are easier to decode.  How could that not be 
true?


What's really bad is a signal that is strong and has DT > 0.396 s.  When 
those conditions are both true, the signal might be decoded but cannot 
be subtracted (thus providing an opportunity to decode a weaker signal 
an nearly the same frequency) until the final decoding pass.



What I wanted sometimes was a "favor callers *not* on my tx
frequency". (But that's probably an unrelated thing to this change.)


You can always uncheck "Call 1st" and select responses to your CQs 
manually.  You have complete control over who you answer first.



Another plus of the old ordering was that you could see the three
passes and say "hey look it decoded this one because it subtracted a
stronger signal first". The new ordering seems to be pretty messy
instead.


We have always displayed each and every decode as soon as it is known to 
the decoder.  This remains the basic ordering of displayed decodes -- no 
more, no less.


When designing program behavior and writing code there are numerous 
choices that must be made, including many that might admit reasonable 
decisions different from the ones we make.  One of the reasons the 
program is Open Source is so anyone can modify it in whatever way suits 
them best.


One recent decision is that "sooner is better" applies to all
decodes just as much as does "more is better".

-- 73, 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.2.0-rc1

[jan0]

>one feature of the latest decoder is there to yield decodes before all 
>transmissions are completed.

 

Bill,

 

Was this a user request, or just a result of the new decoding algorithm?   (My 
curiosity has been piqued.)

 

Ed N4II.

 

From: Bill Somerville  
Sent: Tuesday, May 12, 2020 3:29 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc1

 

On 12/05/2020 20:22, Christoph Berg wrote:

Re: Bill Somerville

this change is deliberate. Prior versions favour strong stations calling at
the lowest audio offset, we think it is better to randomize the frequency
order to give all stations more equal weighting. This is particularly in
respect of the "Call 1st" feature. There is also another factor, the latest
FT8 decoder makes up to three attempts at decoding, each doing up to three
passes. Each attempt subtracts signals from prior attempts to reveal masked
signals. There is no sorting or randomizing across the attempts, the
overriding priority being to print he decodes as soon as possible after they
are discovered.

Well that still favors the stronger stations. Was "calling at lower
offset" something people were really rushing for, or did that have any
bias towards them in contests or crowded bands?
 
What I wanted sometimes was a "favor callers *not* on my tx
frequency". (But that's probably an unrelated thing to this change.)
 
Another plus of the old ordering was that you could see the three
passes and say "hey look it decoded this one because it subtracted a
stronger signal first". The new ordering seems to be pretty messy
instead.
 
Christoph

Hi Christoph,

yes stronger signals may well be decoded on an earlier pass, but we cannot deal 
with that without delaying the printing of any decodes until all decodes 
attempts are completed, that would be very counterproductive given one feature 
of the latest decoder is there to yield decodes before all transmissions are 
completed. We could of course sort decodes continuously as they flow in, but 
that would make the UI very confusing with decodes continuously shuffling just 
as you are trying to read them. There is no optimal solution.

73
Bill
G4WJS.

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

[wsjt-devel] WSJTX 2.2.0-RC1 - xmit power drop down

[Josh Rovero]

The 60 dBm transmit power drop-down is sticky - if you change it to a
different value and save the configuration, the next time you start WSJT-X
it will revert back to 60 dBm.

-- 
P.J. "Josh" Rovero http://www.roveroresearch.org
Ham Radio: KK1D http://www.roveroresearch
.net
http://www.roveroresearch.info
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Raspberry GPIO

[Lloyd via wsjt-devel]

Hi Bill, thanks.

Can you tell me how I start rigctld server? And arguments? I use TS2000.

Thanks



Il 12/05/2020 21:11, Bill Somerville ha scritto:

On 12/05/2020 18:53, Lloyd via wsjt-devel wrote:

Hello!

It's possible to have PTT via GPIO of Raspberry??

Thanks

73 de IZ0KBA 


Hi Lloyd,

yes, you can do this using the rigctld server (a version called 
rigctld-wsjtx is packaged with WSJT-X). Set WSJT-X to use the "Hamlib 
NET rigctl" rig type with "PTT Method" as "CAT". Start the rigctld 
server with arguments to specify the GPIO pin to be used for PTT (-P 
GPIO -p 17 for example to use pin 17).


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] WSJT-X 2.2.0-rc1

[Bill Somerville]

On 12/05/2020 20:22, Christoph Berg wrote:

Re: Bill Somerville

this change is deliberate. Prior versions favour strong stations calling at
the lowest audio offset, we think it is better to randomize the frequency
order to give all stations more equal weighting. This is particularly in
respect of the "Call 1st" feature. There is also another factor, the latest
FT8 decoder makes up to three attempts at decoding, each doing up to three
passes. Each attempt subtracts signals from prior attempts to reveal masked
signals. There is no sorting or randomizing across the attempts, the
overriding priority being to print he decodes as soon as possible after they
are discovered.

Well that still favors the stronger stations. Was "calling at lower
offset" something people were really rushing for, or did that have any
bias towards them in contests or crowded bands?

What I wanted sometimes was a "favor callers*not*  on my tx
frequency". (But that's probably an unrelated thing to this change.)

Another plus of the old ordering was that you could see the three
passes and say "hey look it decoded this one because it subtracted a
stronger signal first". The new ordering seems to be pretty messy
instead.

Christoph


Hi Christoph,

yes stronger signals may well be decoded on an earlier pass, but we 
cannot deal with that without delaying the printing of any decodes until 
all decodes attempts are completed, that would be very counterproductive 
given one feature of the latest decoder is there to yield decodes before 
all transmissions are completed. We could of course sort decodes 
continuously as they flow in, but that would make the UI very confusing 
with decodes continuously shuffling just as you are trying to read them. 
There is no optimal solution.


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.2.0-rc1

[Christoph Berg]

Re: Bill Somerville
> this change is deliberate. Prior versions favour strong stations calling at
> the lowest audio offset, we think it is better to randomize the frequency
> order to give all stations more equal weighting. This is particularly in
> respect of the "Call 1st" feature. There is also another factor, the latest
> FT8 decoder makes up to three attempts at decoding, each doing up to three
> passes. Each attempt subtracts signals from prior attempts to reveal masked
> signals. There is no sorting or randomizing across the attempts, the
> overriding priority being to print he decodes as soon as possible after they
> are discovered.

Well that still favors the stronger stations. Was "calling at lower
offset" something people were really rushing for, or did that have any
bias towards them in contests or crowded bands?

What I wanted sometimes was a "favor callers *not* on my tx
frequency". (But that's probably an unrelated thing to this change.)

Another plus of the old ordering was that you could see the three
passes and say "hey look it decoded this one because it subtracted a
stronger signal first". The new ordering seems to be pretty messy
instead.

Christoph


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

Re: [wsjt-devel] Raspberry GPIO

[Bill Somerville]

On 12/05/2020 18:53, Lloyd via wsjt-devel wrote:

Hello!

It's possible to have PTT via GPIO of Raspberry??

Thanks

73 de IZ0KBA 


Hi Lloyd,

yes, you can do this using the rigctld server (a version called 
rigctld-wsjtx is packaged with WSJT-X). Set WSJT-X to use the "Hamlib 
NET rigctl" rig type with "PTT Method" as "CAT". Start the rigctld 
server with arguments to specify the GPIO pin to be used for PTT (-P 
GPIO -p 17 for example to use pin 17).


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.2.0-rc1

[Bill Somerville]

On 12/05/2020 11:56, Christoph Berg wrote:

Re: Joe Taylor

WSJT-X 2.2.0 will be a significant program upgrade offering many new
features.

The new "show most decodes earlier" feature is awesome, thanks!

Probably related: I noticed that the list of decodes is now pretty
much unsorted. Would it be possible to at least sort each batch by
frequency as they appear, much like it used to be?

I'm often looking at signals in the waterfall and then try to find
them in the decode window by frequency which is now much harder.

Christoph DF7CB


Hi Christoph,

this change is deliberate. Prior versions favour strong stations calling 
at the lowest audio offset, we think it is better to randomize the 
frequency order to give all stations more equal weighting. This is 
particularly in respect of the "Call 1st" feature. There is also another 
factor, the latest FT8 decoder makes up to three attempts at decoding, 
each doing up to three passes. Each attempt subtracts signals from prior 
attempts to reveal masked signals. There is no sorting or randomizing 
across the attempts, the overriding priority being to print he decodes 
as soon as possible after they are discovered.


73
Bill
G4WJS.

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

[wsjt-devel] JAVA class

[Lloyd via wsjt-devel]

Hello,

I'm Lorenzo IZ0KBA, student of Computer Science in University Sapienza 
of Rome.


I found PYTHON class for WSJTX to decode UDP packet, exist the same 
CLASS for JAVA???


Thanks



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

[wsjt-devel] Raspberry GPIO

[Lloyd via wsjt-devel]

Hello!

It's possible to have PTT via GPIO of Raspberry??

Thanks

73 de IZ0KBA



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

[wsjt-devel] WSJT-X cppcheck

[Black Michael via wsjt-devel]

A couple of minor warnings from simple cppcheck of 2.2.1 -- neither of which 
should be problematic since they are error conditions.There are, of course, a 
lot more warnings with cppcheck --enable=all -- some of which look important.

de Mike W9MDB
getfile.cpp -- resource leak on fp not being closed    // read header    if 
(fread(, sizeof desc, 1, fp) < 1) return; // RIFF    if (fread(type, 
sizeof type, 1, fp) < 1) return;  // WAVE

wsprd.c -- resource leak on buf2
    buf2 = calloc(npoints,sizeof(short int));    nr=fread(buf2,2,22,fp);      
//Read and ignore header    nr=fread(buf2,2,npoints,fp); //Read raw data    
fclose(fp);    if( nr == 0 ) {        fprintf(stderr, "No data in file '%s'\n", 
ptr_to_infile);        return 1;    }
Just to show some of the warnings from --enable=all -- these 3 lines are using 
string comparison against a char array instead of a C++ string so the 
comparison operator for that isn't boolean.
1529:widgets/mainwindow.cpp:3104:45: warning: Comparison of a boolean 
expression with an integer other than 0 or 1. 
[compareBoolExpressionWithInt]1532:widgets/mainwindow.cpp:4641:60: warning: 
Comparison of a boolean expression with an integer other than 0 or 1. 
[compareBoolExpressionWithInt]1815:widgets/plotter.cpp:241:30: warning: 
Comparison of a boolean expression with an integer other than 0 or 1. 
[compareBoolExpressionWithInt]

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

Re: [wsjt-devel] Installing WSJT-X 2.2.0-rc1 in Ubuntu 20.04 LTS doesn't work

[Bill Somerville]

Hi David,

thanks for the dependent package name updates, and well done!

You need to install the runtime pulseaudio plugin for Qt:

sudo apt install libqt5multimedia5-plugins

to get pulse audio to hook up with WSJT-X, as noted here in the WSJT-X 
User Guide:


https://physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.2.0-rc1.html#INSTALL_LINUX

73
Bill
G4WJS.

On 12/05/2020 12:12, David Spoelstra wrote:

Hi Bill,

I figured out the few differences in the pre-install package names for 
Ubuntu 20.04 if anyone is interested:

svn -> subversion
libusb-1.0.0-dev -> libusb-1.0-0-dev
libqt5libserialport5-dev -> libqt5serialport5-dev

So, these three lines should install all the pre-installs for Ubuntu 
20.04:
sudo apt install build-essential gcc clang g++ gfortran cmake git 
asciidoc texinfo subversion

sudo apt install qtmultimedia5-dev qttools5-dev qttools5-dev-tools
sudo apt install libfftw3-dev libusb-1.0-0-dev libqt5serialport5-dev

Then I just followed the instructions and everything built.

On launch, the program starts but has three sound I/O errors:
"An error opening the audio output device has occurred."
"Requested output audio format is not supported on device."
"Requested input audio format is not supported on device."

After clicking "OK" the program looks fine like everything is fine. I 
just figured that I needed to go into settings and configure the sound 
I/O.


The problem is that Soundcard Input: and Output: in Settings are blank 
and have no drop down choices. Any ideas?


Thanks!
-David, N9KT






On Mon, May 11, 2020 at 8:17 PM Bill Somerville > wrote:


Hi David,

it's not very difficult, start with the self contained sources
tarball from the WSJT-X project web page, unpack it and read the
file INSTALL at the top level.

73
Bill
G4WJS.

On 12/05/2020 00:51, David Spoelstra wrote:

Thanks Bill. I might take a crack at building it...
-David, N9KT

On Mon, May 11, 2020 at 2:58 PM Bill Somerville
mailto:g4...@classdesign.com>> wrote:

Hi David,

as noted on the WSJT-X web page
https://physics.princeton.edu/pulsar/K1JT/wsjtx.html and in
the README info on the project SourceForge files area
https://sourceforge.net/projects/wsjt/files/wsjtx-2.2.0-rc1/
, the Debian style packages target Ubuntu 18.04. Although
Ubuntu 20.04 is released there is no easy upgrade path for
users until the 20.04.1 release in a couple of months, until
then we will target the 18.04.x LTS release.

The Ubuntu package maintainers for WSJT-X will probably make
packages available soon that are suitable for various
versions. In the meantime you can build WSJT-X from sources.

73
Bill
G4WJS.

On 11/05/2020 19:21, David Spoelstra wrote:

As a follow-on, I did install "gfortran": sudo apt install
gfortran and got this:
Reading package lists... Done
Building dependency tree
Reading state information... Done
gfortran is already the newest version (4:9.3.0-1ubuntu2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

However I still get the error: "Depends: libgfortran3 (>=
4.8.2) but it is not installable" when I try and install wsjt-x

Thanks!
-David, N9KT


On Mon, May 11, 2020 at 2:16 PM David Spoelstra
mailto:dav...@mediamachine.com>>
wrote:

When I tried to install in the latest Ubuntu 20.04 LTS,
I got:
The following packages have unmet dependencies:
 wsjtx : Depends: libgfortran3 (>= 4.8.2) but it is not
installable

When I try "sudo apt install libgfortran3" I get:
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libgfortran3

I'm a little lost as to how to get libgfortran3.
Any suggestions?

Thanks!
-David, N9KT



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

Re: [wsjt-devel] Installing WSJT-X 2.2.0-rc1 in Ubuntu 20.04 LTS doesn't work

[David Spoelstra]

Bill-

Digging around in the archives I found that I also
needed: libqt5multimedia5-plugins

So for anyone following along, for Ubuntu 20.04 you need the following
pre-installs:
sudo apt install build-essential gcc clang g++ gfortran cmake git asciidoc
texinfo subversion
sudo apt install qtmultimedia5-dev qttools5-dev
qttools5-dev-tools libqt5multimedia5-plugins
sudo apt install libfftw3-dev libusb-1.0-0-dev libqt5serialport5-dev

and then just follow the instructions in the INSTALL file in the source
package.

Thanks for your help and encouragement Bill!
-David, N9KT


On Tue, May 12, 2020 at 7:12 AM David Spoelstra 
wrote:

> Hi Bill,
>
> I figured out the few differences in the pre-install package names for
> Ubuntu 20.04 if anyone is interested:
> svn -> subversion
> libusb-1.0.0-dev -> libusb-1.0-0-dev
> libqt5libserialport5-dev -> libqt5serialport5-dev
>
> So, these three lines should install all the pre-installs for Ubuntu 20.04:
> sudo apt install build-essential gcc clang g++ gfortran cmake git asciidoc
> texinfo subversion
> sudo apt install qtmultimedia5-dev qttools5-dev qttools5-dev-tools
> sudo apt install libfftw3-dev libusb-1.0-0-dev libqt5serialport5-dev
>
> Then I just followed the instructions and everything built.
>
> On launch, the program starts but has three sound I/O errors:
> "An error opening the audio output device has occurred."
> "Requested output audio format is not supported on device."
> "Requested input audio format is not supported on device."
>
> After clicking "OK" the program looks fine like everything is fine. I just
> figured that I needed to go into settings and configure the sound I/O.
>
> The problem is that Soundcard Input: and Output: in Settings are blank and
> have no drop down choices. Any ideas?
>
> Thanks!
> -David, N9KT
>
>
>
>
>
>
> On Mon, May 11, 2020 at 8:17 PM Bill Somerville 
> wrote:
>
>> Hi David,
>>
>> it's not very difficult, start with the self contained sources tarball
>> from the WSJT-X project web page, unpack it and read the file INSTALL at
>> the top level.
>>
>> 73
>> Bill
>> G4WJS.
>>
>> On 12/05/2020 00:51, David Spoelstra wrote:
>>
>> Thanks Bill. I might take a crack at building it...
>> -David, N9KT
>>
>> On Mon, May 11, 2020 at 2:58 PM Bill Somerville 
>> wrote:
>>
>>> Hi David,
>>>
>>> as noted on the WSJT-X web page
>>> https://physics.princeton.edu/pulsar/K1JT/wsjtx.html and in the README
>>> info on the project SourceForge files area
>>> https://sourceforge.net/projects/wsjt/files/wsjtx-2.2.0-rc1/ , the
>>> Debian style packages target Ubuntu 18.04. Although Ubuntu 20.04 is
>>> released there is no easy upgrade path for users until the 20.04.1 release
>>> in a couple of months, until then we will target the 18.04.x LTS release.
>>>
>>> The Ubuntu package maintainers for WSJT-X will probably make packages
>>> available soon that are suitable for various versions. In the meantime you
>>> can build WSJT-X from sources.
>>>
>>> 73
>>> Bill
>>> G4WJS.
>>>
>>> On 11/05/2020 19:21, David Spoelstra wrote:
>>>
>>> As a follow-on, I did install "gfortran": sudo apt install gfortran and
>>> got this:
>>> Reading package lists... Done
>>> Building dependency tree
>>> Reading state information... Done
>>> gfortran is already the newest version (4:9.3.0-1ubuntu2).
>>> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>>>
>>> However I still get the error: "Depends: libgfortran3 (>= 4.8.2) but it
>>> is not installable" when I try and install wsjt-x
>>>
>>> Thanks!
>>> -David, N9KT
>>>
>>>
>>> On Mon, May 11, 2020 at 2:16 PM David Spoelstra 
>>> wrote:
>>>
 When I tried to install in the latest Ubuntu 20.04 LTS, I got:
 The following packages have unmet dependencies:
  wsjtx : Depends: libgfortran3 (>= 4.8.2) but it is not installable

 When I try "sudo apt install libgfortran3" I get:
 Reading package lists... Done
 Building dependency tree
 Reading state information... Done
 E: Unable to locate package libgfortran3

 I'm a little lost as to how to get libgfortran3. Any suggestions?

 Thanks!
 -David, N9KT


>> ___
>> 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.2.0-rc1

[Christoph Berg]

Re: Joe Taylor
> WSJT-X 2.2.0 will be a significant program upgrade offering many new
> features.

The new "show most decodes earlier" feature is awesome, thanks!

Probably related: I noticed that the list of decodes is now pretty
much unsorted. Would it be possible to at least sort each batch by
frequency as they appear, much like it used to be?

I'm often looking at signals in the waterfall and then try to find
them in the decode window by frequency which is now much harder.

Christoph DF7CB


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

Re: [wsjt-devel] Installing WSJT-X 2.2.0-rc1 in Ubuntu 20.04 LTS doesn't work

[David Spoelstra]

Hi Bill,

I figured out the few differences in the pre-install package names for
Ubuntu 20.04 if anyone is interested:
svn -> subversion
libusb-1.0.0-dev -> libusb-1.0-0-dev
libqt5libserialport5-dev -> libqt5serialport5-dev

So, these three lines should install all the pre-installs for Ubuntu 20.04:
sudo apt install build-essential gcc clang g++ gfortran cmake git asciidoc
texinfo subversion
sudo apt install qtmultimedia5-dev qttools5-dev qttools5-dev-tools
sudo apt install libfftw3-dev libusb-1.0-0-dev libqt5serialport5-dev

Then I just followed the instructions and everything built.

On launch, the program starts but has three sound I/O errors:
"An error opening the audio output device has occurred."
"Requested output audio format is not supported on device."
"Requested input audio format is not supported on device."

After clicking "OK" the program looks fine like everything is fine. I just
figured that I needed to go into settings and configure the sound I/O.

The problem is that Soundcard Input: and Output: in Settings are blank and
have no drop down choices. Any ideas?

Thanks!
-David, N9KT






On Mon, May 11, 2020 at 8:17 PM Bill Somerville 
wrote:

> Hi David,
>
> it's not very difficult, start with the self contained sources tarball
> from the WSJT-X project web page, unpack it and read the file INSTALL at
> the top level.
>
> 73
> Bill
> G4WJS.
>
> On 12/05/2020 00:51, David Spoelstra wrote:
>
> Thanks Bill. I might take a crack at building it...
> -David, N9KT
>
> On Mon, May 11, 2020 at 2:58 PM Bill Somerville 
> wrote:
>
>> Hi David,
>>
>> as noted on the WSJT-X web page
>> https://physics.princeton.edu/pulsar/K1JT/wsjtx.html and in the README
>> info on the project SourceForge files area
>> https://sourceforge.net/projects/wsjt/files/wsjtx-2.2.0-rc1/ , the
>> Debian style packages target Ubuntu 18.04. Although Ubuntu 20.04 is
>> released there is no easy upgrade path for users until the 20.04.1 release
>> in a couple of months, until then we will target the 18.04.x LTS release.
>>
>> The Ubuntu package maintainers for WSJT-X will probably make packages
>> available soon that are suitable for various versions. In the meantime you
>> can build WSJT-X from sources.
>>
>> 73
>> Bill
>> G4WJS.
>>
>> On 11/05/2020 19:21, David Spoelstra wrote:
>>
>> As a follow-on, I did install "gfortran": sudo apt install gfortran and
>> got this:
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> gfortran is already the newest version (4:9.3.0-1ubuntu2).
>> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>>
>> However I still get the error: "Depends: libgfortran3 (>= 4.8.2) but it
>> is not installable" when I try and install wsjt-x
>>
>> Thanks!
>> -David, N9KT
>>
>>
>> On Mon, May 11, 2020 at 2:16 PM David Spoelstra 
>> wrote:
>>
>>> When I tried to install in the latest Ubuntu 20.04 LTS, I got:
>>> The following packages have unmet dependencies:
>>>  wsjtx : Depends: libgfortran3 (>= 4.8.2) but it is not installable
>>>
>>> When I try "sudo apt install libgfortran3" I get:
>>> Reading package lists... Done
>>> Building dependency tree
>>> Reading state information... Done
>>> E: Unable to locate package libgfortran3
>>>
>>> I'm a little lost as to how to get libgfortran3. Any suggestions?
>>>
>>> Thanks!
>>> -David, N9KT
>>>
>>>
> ___
> 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] 2.2.0-rc1 Transmit Power dropdown

[Josh Rovero]

For WSPR, the dropdown setting changed from 30 dBm (1w) to 60 dBm (1 kw)
after installation.

Most other settings hadn't changed, so didn't notice it for an hour or so.
So, no, I wasn't transmitting WSPR at 1 kw rf output  :-)

-- 
P.J. "Josh" Rovero http://www.roveroresearch.org
Ham Radio: KK1D http://www.roveroresearch
.net
http://www.roveroresearch.info
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc1 Crash on Mac

[Bill Somerville]

On 12/05/2020 08:25, John Nelson via wsjt-devel wrote:

Hi Bill,

I could not duplicate the Font problem reported by Chuck WV8A.   Also tested  
Decode Text Font and this responded as expected.

When upgrading to a new version of WSJT-X I always remove WSJT-X.ini and start 
from fresh.

MacBook Pro:   10.14.6
Left running overnight:  decoding on 20m and 15m is fine.

— John G4KLA


Hi John,

thanks for that. I think I will have to write a minimal example 
application that exercises the Qt QFontDialog::getFont API and send it 
to Chuck to try, if that crashes I can use it to back a bug report with 
the Qt team. I would guess it is somehow related to the fonts installed 
on Chuck's machine unless we have a more subtle problem with memory 
corruption in WSJT-X.


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.2.0-rc1 Crash on Mac

[John Nelson via wsjt-devel]

Hi Bill,

I could not duplicate the Font problem reported by Chuck WV8A.   Also tested  
Decode Text Font and this responded as expected.

When upgrading to a new version of WSJT-X I always remove WSJT-X.ini and start 
from fresh. 

MacBook Pro:   10.14.6
Left running overnight:  decoding on 20m and 15m is fine.

— 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