Re: [wsjt-devel] FT8 False Decodes 2.2.0 rc1

[Stephen Ireland]

Allan,

I have been reporting exactly the same occurrence in exactly the same sequence 
in this place ! Bill has responded around 24 hours earlier !

You play recordings back and the "false decode" is not reported so its 
pointless posting these !

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] 2.2.0 RC1 Issues

[Black Michael via wsjt-devel]

There is a bug in DTR/RTS PTT in RC1 that will be fixed in the next release.
de Mike W9MDB

 

On Friday, May 15, 2020, 08:46:46 PM CDT, lgtngstk  
wrote:  
 
 Just to report, I am also having this issue as well.
On Wed, May 13, 2020 at 7:04 AM Bill Somerville  wrote:

  On 13/05/2020 00:37, 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! 
  
 
Hi David,
 
thanks for the issue report. Something is clearly not right. To help us 
diagnose this please open a terminal window and type the following command:
 /Applications/wsjtx.app/Contents/MacOS/rigctl-wsjtx -m 3027 -p 
/dev/cu.usbserial-141201 -P RTS -v -Z t pause 1 t pause 1 t 
Rreply with what gets printed please?
 
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 False Decodes 2.2.0 rc1

[Black Michael via wsjt-devel]

Save your WAV files and submit some examples.
de Mike W9MDB

 

On Friday, May 15, 2020, 10:10:38 PM CDT, Allan VK4QG 
 wrote:  
 
 Hi All,

While monitoring 6m, which for 99% of the time is very quiet here, (from 
a QRM and amateur activity perspective) I am getting a vast increase in 
the number of false decodes with the new version 2.2.0. rc1, compared 
with 2.1.2.  With the previous version, I would get maybe one false 
decode per week.

This occurs regardless of the Decode setting 'Fast, Normal or Deep' and 
'Enable AP' is not checked. In fact all settings are the same as per 2.1.2

This issue has also been observed by another amateur friend VK4ZB, while 
monitoring both 10m and 6m.

An example of the false decodes are below: -

200512_002930    50.313 Rx FT8    -24  2.0 1808 CQ J HQIZ4GD 0
200512_032845    50.313 Rx FT8    -24  1.2 2381 U71SSP/P M42TGQ/P OI41
200512_040245    50.313 Rx FT8    -24  0.7 1364 QP4BHA/R 1A4MVL R KK78
200512_040930    50.313 Rx FT8    -24 -2.4 2338 D72IQQ/R 2B7VII BD64
200512_05    50.313 Rx FT8    -24  1.1 1813 507D7D79D66E12EB7A
200512_234345    50.313 Rx FT8    -24 -2.1 3691 MR9/L3QWI 80

200513_000900    50.313 Rx FT8    -24  1.2 3981 WK5PMR <...> R 599 0804
200513_003430    50.313 Rx FT8    -24 -0.5 3851 K1QYN6U/KQA <...> RRR
200513_010045    50.313 Rx FT8    -24  0.8 1256 WX3GJ/P SS9BHE/P R PI36
200513_042015    50.313 Rx FT8    -24  1.6 2556 <...> <...> 561942 [I97KI
200513_053915    50.313 Rx FT8    -24  2.0 3771 TU; OE0OZT EC4QCC 569 7525

200514_021400    50.313 Rx FT8    -24  0.5  267 <...> <...> R 521355 ^H91WH
200514_023645    50.313 Rx FT8    -24  2.1 2976 9U2BYC ML6BHS R JF39
200514_061500    50.313 Rx FT8    -24  1.8 3091 CQ DXY594TSN5O
200514_063715    50.313 Rx FT8    -24  1.9 1178 <...> <...> R 541099 QA66CK
200514_070600    50.313 Rx FT8    -23 -1.6 1116 2U3MFE UT8XXJ R 549 3369
200514_222645    50.313 Rx FT8    -24  0.7 4049 <...> <...> 590273 LI86TB
200514_223100    50.313 Rx FT8    -24  1.9 2621

200515_00    50.313 Rx FT8    -24  0.8 2494 <...> <...> 550288 MF80PU
200515_011100    50.313 Rx FT8    -19  2.3 1702 QG9JQJ ZN5GT R 539 1171
200515_021200    50.313 Rx FT8    -24 -0.1  931 4X4AYF/P HR3SFK R LQ91
200515_024815    50.313 Rx FT8    -24  0.8 1130 3PG/45ZQ4EEIK
200515_035230    50.313 Rx FT8    -24  1.7 1072 75NMC/P UY2MGH/P R ID64
200515_063415    50.313 Rx FT8    -24  2.4 2618 <...> 816BNE IA00
200515_223815    50.313 Rx FT8    -22  0.1  143 <...> <...> R 532031 JA38SR

My system is a Dell1650, i7 @3.40 GHz, 16GB RAM, W10 pro 64bit

73,

Allan - VK4QG




___
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] FT8 False Decodes 2.2.0 rc1

[Allan VK4QG]

Hi All,

While monitoring 6m, which for 99% of the time is very quiet here, (from 
a QRM and amateur activity perspective) I am getting a vast increase in 
the number of false decodes with the new version 2.2.0. rc1, compared 
with 2.1.2.  With the previous version, I would get maybe one false 
decode per week.


This occurs regardless of the Decode setting 'Fast, Normal or Deep' and 
'Enable AP' is not checked. In fact all settings are the same as per 2.1.2


This issue has also been observed by another amateur friend VK4ZB, while 
monitoring both 10m and 6m.


An example of the false decodes are below: -

200512_002930    50.313 Rx FT8    -24  2.0 1808 CQ J HQIZ4GD 0
200512_032845    50.313 Rx FT8    -24  1.2 2381 U71SSP/P M42TGQ/P OI41
200512_040245    50.313 Rx FT8    -24  0.7 1364 QP4BHA/R 1A4MVL R KK78
200512_040930    50.313 Rx FT8    -24 -2.4 2338 D72IQQ/R 2B7VII BD64
200512_05    50.313 Rx FT8    -24  1.1 1813 507D7D79D66E12EB7A
200512_234345    50.313 Rx FT8    -24 -2.1 3691 MR9/L3QWI 80

200513_000900    50.313 Rx FT8    -24  1.2 3981 WK5PMR <...> R 599 0804
200513_003430    50.313 Rx FT8    -24 -0.5 3851 K1QYN6U/KQA <...> RRR
200513_010045    50.313 Rx FT8    -24  0.8 1256 WX3GJ/P SS9BHE/P R PI36
200513_042015    50.313 Rx FT8    -24  1.6 2556 <...> <...> 561942 [I97KI
200513_053915    50.313 Rx FT8    -24  2.0 3771 TU; OE0OZT EC4QCC 569 7525

200514_021400    50.313 Rx FT8    -24  0.5  267 <...> <...> R 521355 ^H91WH
200514_023645    50.313 Rx FT8    -24  2.1 2976 9U2BYC ML6BHS R JF39
200514_061500    50.313 Rx FT8    -24  1.8 3091 CQ DXY594TSN5O
200514_063715    50.313 Rx FT8    -24  1.9 1178 <...> <...> R 541099 QA66CK
200514_070600    50.313 Rx FT8    -23 -1.6 1116 2U3MFE UT8XXJ R 549 3369
200514_222645    50.313 Rx FT8    -24  0.7 4049 <...> <...> 590273 LI86TB
200514_223100    50.313 Rx FT8    -24  1.9 2621

200515_00    50.313 Rx FT8    -24  0.8 2494 <...> <...> 550288 MF80PU
200515_011100    50.313 Rx FT8    -19  2.3 1702 QG9JQJ ZN5GT R 539 1171
200515_021200    50.313 Rx FT8    -24 -0.1  931 4X4AYF/P HR3SFK R LQ91
200515_024815    50.313 Rx FT8    -24  0.8 1130 3PG/45ZQ4EEIK
200515_035230    50.313 Rx FT8    -24  1.7 1072 75NMC/P UY2MGH/P R ID64
200515_063415    50.313 Rx FT8    -24  2.4 2618 <...> 816BNE IA00
200515_223815    50.313 Rx FT8    -22  0.1  143 <...> <...> R 532031 JA38SR

My system is a Dell1650, i7 @3.40 GHz, 16GB RAM, W10 pro 64bit

73,

Allan - VK4QG




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

[wsjt-devel] 2.2.0-rc1 Bug Report - Blank Line between decodes not reliable

[Grant VK5GR]

Joe/Bill,

 

A minor bug but definitely new to 2.2

 

I am finding that I don't get the blank line between decodes drawn every
interval. You can see it here if you look at the timestamps. I was often
missing frames from Adrian when he transmitted - not sure if that was a
contributing factor. 

 

FYI

 

Regards, Grant VK5GR

 



 

Regards,

Grant VK5GR 

 

Email: vk5gr.ra...@gmail.com

Website:   https://vk5gr-iota.net/

 

 

 

___
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

[lgtngstk]

Just to report I am also having this issue as well.
___
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

[lgtngstk]

Just to report, I am also having this issue as well.

On Wed, May 13, 2020 at 7:04 AM Bill Somerville 
wrote:

> On 13/05/2020 00:37, 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!
>
> Hi David,
>
> thanks for the issue report. Something is clearly not right. To help us
> diagnose this please open a terminal window and type the following command:
>
> /Applications/wsjtx.app/Contents/MacOS/rigctl-wsjtx -m 3027 -p 
> /dev/cu.usbserial-141201 -P RTS -v -Z t pause 1 t pause 1 t
>
> Rreply with what gets printed please?
>
> 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] OE3FVU Bug report wsjtx 2.2. rc1

[Joe Taylor]

Franz --

On 5/15/2020 15:22, oe3fvu wrote:
Yes, stupid description. Sorry. The width of the input bar (lower left 
hand side if the window)  is different in msk compared to ft8.


On my systems they look the same.

These widgets are "stretchable", so if you make the window wider they 
get bigger.  Surely you must have more important things to worry about?


-- Joe, K1JT


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

Re: [wsjt-devel] WSJTX 2.2 RC1 - OE3FVU reports windowing issues on W10

[Joe Taylor]

Franz --


1. – Start-up sequence takes 13 to 14 seconds (2.1.2 takes 5-6 seconds)


Startup time depends on many system parameters, including hardware and 
how many other programs you have running.  On my system -- which is 
nothng very special -- WSJT-X 2.2.0-rc1 starts in about 3.5 s.


2 - changing window size in 2.2, closing 2.2 and starting 2.1 causes the 
windows of 2.1 to default position AND size


Closing 2.1 and starting 2.2 again: window position and size at default 
position.


Changing window size and position in 2.2 closing 2.2 and restarting 2.2 
has no effect on window size nor it’s position,
Changing the window position of 2.2 – i.e. moving the window – doesn’t 
cause 2.1 to start at the default size, but as expected at the same 
position and size of the 2.2 window.


These issues have been known for some time and discussed on this 
reflector.  Except possibly for early comparison tests -- which anyway 
we have been doing for some months already -- there is no good reason to 
keep starting or using v2.1.x.


3. The Fast Graph window used with MSK144 or ISCAT is not resizable like 
the Wide Graph of the other modes, and has it’s own position parameter. 
It would be very nice to have the
Same position and size as the Wide Graph window (this was already so in 
older versions of WSJTx – so merely a feature request).


There are good reasons for the Wide Graph to be resizable.  None of 
these apply to the Fast Graph.  Put the Fast Graps where you like it. 
and it will always return there.



A few more things I have noticed, which are different between 2.1 and 2.2. Now 
I don’t know if that is intentionally, I can’t find anything regarding this in 
the release notes.
I also understand that there may be more important things to address, as these 
are minor things.

1. It is not possible to highlight one line in the band Activity window; hence 
it is not possible to copy.


I cannot reproduce this behavior.  On all my systems highlighting text 
in the Band Activity window behaves as it should.



2. Double clicking in the Waterfall, only causes the RX frequency to move, 
while the TX frequency remains at the same spot.


Have you referred to the tutorials in the User Guide?  Or even read the 
help screen "Help | Special mouse commands" ??



I found this out during comparison between 2.1 and 2.2 – Behaviour is the same 
in both versions, but maybe it can be considered to change this.:

3. I am using short messages in JT65 (for EME) and switching back to MSK144 
doesn’t switch off Short messages. This is quite annoying


Again, you can get help from the User Guide.

You should define and use "Configurations" set up as you wish for each 
frequently used mode, rather than switching modes from the Mode menu.




as in Europe, short messages are not being used during MS contacts, while these 
are in EME contacts.


BTW: I know of no good reason for Europeans not to use short messages on 
144 MHz.



4. Having “hold TX Freq” set in FT8 and switching to MSK144 and back, causes 
the “hold TX freq” to be unset.


See comment above.  If you use many modes, set up a configuration for 
each mode.



Currently running 4 instances 2.2RC1 simultaneously on 4 rigs:  2m/FT8; 6m/FT8, 
15m/FT8 and 2m/MSK!44 reliably.
It seems that the CPU load is abt 50% of 2.1.


-- 73, Joe, K1JT


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

[wsjt-devel] Auto Log prompt anomaly

[Adrian]

I have also notice the auto log prompt not working  when TX is disabled 
and re-enabled on the same qso, and at RR73 no expected qso log popup 
occurs.


I restart the program to rectify.

vk4tux





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

Re: [wsjt-devel] Call 1st anomaly

[Martin Davies G0HDB]

On 15 May 2020 at 11:01, WB5JJJ wrote:

> I've noticed in rc1 that when i UNCHECK Call 1st it continues to connect to
> the 1st caller for a couple of CQ cycles and then ignores all incoming
> requests as expected.
> 
> -- 
> George - WB5JJJ

Hi George (and all), I haven't yet tried the latest v2.2.0-rc1 version but this 
anomalous 
behaviour of Call 1st remaining active after being unchecked has been present 
for quite a 
while - I reported it to this email list in December 2018 in connection with 
v2.0.0-rc5, and I 
also reported it again in March this year in connection with v2.1.2 via a 
posting to 
ws...@groups.io.  I don't recall there being a response from the developers to 
either of my 
reports.

---
Martin, G0HDB


-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



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

[wsjt-devel] Call 1st anomaly

[WB5JJJ]

I've noticed in rc1 that when i UNCHECK Call 1st it continues to connect to
the 1st caller for a couple of CQ cycles and then ignores all incoming
requests as expected.

-- 
George - WB5JJJ


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

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

[Al Pawlowski]

I have always run with the decode parameters you cite and it works for me the 
same now (with 2.2.0-rc1) as it always has - not a blank line, but a dashed 
line with the band, between decodes. I am currently running Win10-64bit, but 
have run WSJTx on Win 7 and Mac OS X.

I did notice though that, if unchecking “decodes at bottom” and checking “blank 
line between periods”, some late decodes would show at top without the dashed 
line.


Al Pawlowski, K6AVP
Los Osos, CA USA


> On May 15, 2020, at 05:52, wsjt-devel-requ...@lists.sourceforge.net wrote:
> 
> Date: Fri, 15 May 2020 09:58:28 +0200
> From: mailto:runninge...@gmail.com>>
> To:  >
> Subject: [wsjt-devel] WSJT-X 2.2.0-rc1 - Blank line between decoding
>   periods

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

Re: [wsjt-devel] OE3FVU Bug report wsjtx 2.2. rc1

[Joe Taylor]

Franz --

On 5/15/2020 10:42, Franz (OE3FVU _ PE0WGA) wrote:

A quick one: the size of the RX strength is different between MSK144 and 
FT8.


I have no idea what this means.  Can you elaborate?

-- Joe



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

[wsjt-devel] OE3FVU Bug report wsjtx 2.2. rc1

[Franz (OE3FVU _ PE0WGA)]

Hi team,

A quick one: the size of the RX strength is different between MSK144 and
FT8.
Probably already reported.
 
Best 73
 
Franz - OE3FVU
(also PE0WGA, ex-PE3FVU, ex-PA0WGA)
 
 
2m DX Station: 145 DXCC, 49 US States, 38 Zones, 800+ Grids
2m DXCC #121 and working on 2m WAS and WAZ
  www.oe3fvu.eu
 
144MHz DX stations meet at   www.on4kst.com
 
___
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 - Blank line between decoding periods

[Bill Somerville]

Hi Erik and Michael,

the problems with the "Settings->Reporting->Start new period at top" 
option in WSJT-X v2.2.0 RC1 are known, and fixed for the next release.


73
Bill
G4WJS.

On 15/05/2020 15:33, 5p1kzx Michael wrote:


Hi Erik

I had the same problem the first time I marked the Blank line between 
decoding periods". A restart off wsjt-x solved the problem. When one 
have the "Start new period decodes at top" only the decoded from the 
last step will remain in the Band Activity Window. So every dekoder 
step will clear the screen. Looks funny..


73 de Michael 5p1kzx


Den 15-05-2020 kl. 09:58 skrev runninge...@gmail.com:


Dear WSJTX developers,

When ticking “Blank line between decoding periods” (and “Start new 
period decodes at top” is unticked), there is no separation line 
anymore in the Band Activity window (when decoding FT8 for example).


My apologies if this is a dupe report ..

Stay safe and 73’s,

Erik

ON4PB



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

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

[Stephen Ireland]

Sorry I cannot read: Its CLAUDE !!! My apologies !

-Original Message-
To: WSJT software development 
Subject: RE: [wsjt-devel] Coming soon: WSJT-X 2.2.0-rc1

Claude,

I'll jump in here for a sec hopefully before Bill answers. I don't want a 
raging argument on this nor are my comments intended to offend ...

I have been a GREAT advocate of requesting and specifying the exact "specimen" 
environs under which WSJTX should compile. Therefore supplying a "snapshot" of 
the Hamlib code to which WSJTX 2.2 rc 1 is more than a great idea.

But as I have stated before Hamlib is a dynamic thing; someone reports a bug 
and the core team working on Hamlib moves swiftly. The base code is VERY mature 
and what is seen generally improves the HAM world when using the master repo's.

Some like me do not use the Windows JTSDK just for WSJTX ... Therefore having 
the ability to access the latest most up-to-date Hamlib is essential. 

As an example I run a FT-991 here (almost 24/7). There has been a lot of minor 
adjustments completely for the better for this radio within Hamlib !

In my opinion I would personally be concerned using the Hamlib supplied with 
WSJTX (or any other fork) to compile other things if there were "non-approved" 
patches and hacks included in the snapshot released with WSJTX code.

WSJTX in my opinion should confirm as much as possible to the key programming 
interfaces specified within Hamlib.

Again this is a puristic opinion - and why initial versions of the Windows 
JTSDK 3.1 "Experiment" reverted to the "Master" Hamlib repos. Note that the 
0.35a Alpha version has been hacked at reluctantly to allow access to the 
"master", "g4wjs" or a "static downloaded version" of the Hamlib code i.e. a 
version supplied with WSJTX and/or "Forks".

73

Steve I
VK3VM / VK3SIR

-Original Message-
From: Claude Frantz 
Sent: Friday, 15 May 2020 7:51 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Coming soon: WSJT-X 2.2.0-rc1

On 5/10/20 11:58 AM, Bill Somerville wrote:

>> Which releases of hamlib can be used to compile ?

> although it is still recommended to use my fork of Hamlib, currently 
> my fork integration branch is the same as its master branch which in 
> turn is close to the current Hamlib master branch at commit 320b2552.

Hi Bill,

Can this fork of Hamlib replace the "normal" Hamlib in any situation ? 
Can I use it to compile and build any pieces of software using Hamlib ?

Best wishes,
Claude


___
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 - Blank line between decoding periods

[5p1kzx Michael]

Hi Erik

I had the same problem the first time I marked the Blank line between 
decoding periods". A restart off wsjt-x solved the problem. When one 
have the "Start new period decodes at top" only the decoded from the 
last step will remain in the Band Activity Window. So every dekoder step 
will clear the screen. Looks funny..


73 de Michael 5p1kzx


Den 15-05-2020 kl. 09:58 skrev runninge...@gmail.com:


Dear WSJTX developers,

When ticking “Blank line between decoding periods” (and “Start new 
period decodes at top” is unticked), there is no separation line 
anymore in the Band Activity window (when decoding FT8 for example).


My apologies if this is a dupe report ..

Stay safe and 73’s,

Erik

ON4PB



___
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] Coming soon: WSJT-X 2.2.0-rc1

[Stephen Ireland]

Clause,

I'll jump in here for a sec hopefully before Bill answers. I don't want a 
raging argument on this nor are my comments intended to offend ...

I have been a GREAT advocate of requesting and specifying the exact "specimen" 
environs under which WSJTX should compile. Therefore supplying a "snapshot" of 
the Hamlib code to which WSJTX 2.2 rc 1 is more than a great idea.

But as I have stated before Hamlib is a dynamic thing; someone reports a bug 
and the core team working on Hamlib moves swiftly. The base code is VERY mature 
and what is seen generally improves the HAM world when using the master repo's.

Some like me do not use the Windows JTSDK just for WSJTX ... Therefore having 
the ability to access the latest most up-to-date Hamlib is essential. 

As an example I run a FT-991 here (almost 24/7). There has been a lot of minor 
adjustments completely for the better for this radio within Hamlib !

In my opinion I would personally be concerned using the Hamlib supplied with 
WSJTX (or any other fork) to compile other things if there were "non-approved" 
patches and hacks included in the snapshot released with WSJTX code.

WSJTX in my opinion should confirm as much as possible to the key programming 
interfaces specified within Hamlib.

Again this is a puristic opinion - and why initial versions of the Windows 
JTSDK 3.1 "Experiment" reverted to the "Master" Hamlib repos. Note that the 
0.35a Alpha version has been hacked at reluctantly to allow access to the 
"master", "g4wjs" or a "static downloaded version" of the Hamlib code i.e. a 
version supplied with WSJTX and/or "Forks".

73

Steve I
VK3VM / VK3SIR

-Original Message-
From: Claude Frantz  
Sent: Friday, 15 May 2020 7:51 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Coming soon: WSJT-X 2.2.0-rc1

On 5/10/20 11:58 AM, Bill Somerville wrote:

>> Which releases of hamlib can be used to compile ?

> although it is still recommended to use my fork of Hamlib, currently 
> my fork integration branch is the same as its master branch which in 
> turn is close to the current Hamlib master branch at commit 320b2552.

Hi Bill,

Can this fork of Hamlib replace the "normal" Hamlib in any situation ? 
Can I use it to compile and build any pieces of software using Hamlib ?

Best wishes,
Claude


___
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] Coming soon: WSJT-X 2.2.0-rc1

[Black Michael via wsjt-devel]

You can use any version of hamlib as long you build WSJT-X too.
de Mike W9MDB

 

On Friday, May 15, 2020, 04:57:44 AM CDT, Claude Frantz 
 wrote:  
 
 On 5/10/20 11:58 AM, Bill Somerville wrote:

>> Which releases of hamlib can be used to compile ?

> although it is still recommended to use my fork of Hamlib, currently my 
> fork integration branch is the same as its master branch which in turn 
> is close to the current Hamlib master branch at commit 320b2552.

Hi Bill,

Can this fork of Hamlib replace the "normal" Hamlib in any situation ? 
Can I use it to compile and build any pieces of software using Hamlib ?

Best wishes,
Claude


___
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] Coming soon: WSJT-X 2.2.0-rc1

[Claude Frantz]

On 5/10/20 11:58 AM, Bill Somerville wrote:


Which releases of hamlib can be used to compile ?


although it is still recommended to use my fork of Hamlib, currently my 
fork integration branch is the same as its master branch which in turn 
is close to the current Hamlib master branch at commit 320b2552.


Hi Bill,

Can this fork of Hamlib replace the "normal" Hamlib in any situation ? 
Can I use it to compile and build any pieces of software using Hamlib ?


Best wishes,
Claude


___
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 - WSPR decoding stops when multiple WSJT-X instances are running

[runningerik]

Dear developers,

Please allow me to report a situation where WSPR decoding halts when
multiple WSJT-X instances are running.

My setup is as follows : 

Two Hermes Lite II SDR's connected to a single instance of SparkSDR (yes !
my Hamlib Net rigctl is now working).
Two WSJTX instances (WSJT-X and WSJT-X - HL1 decoding FT8) are connected to
the first Hermes Lite II.
One WSJTX instance (WSJT-X - HL7 decoding WSPR) is connected to the second
Hermes Lite II.

When I turn on "Monitor" on WSJTX instances WSJT-X and WSJT-X - HL1
(decoding FT8), WSPR decoding stops on WSJTX instance WSJT-X - HL7 (decoding
WSPR).
And reversely, when I turn off "Monitor" on WSJTX instances WSJT-X and
WSJT-X - HL1 (decoding FT8), WSPR decoding resumes (on the fly) on WSJTX
instance WSJT-X - HL7 (decoding WSPR).
All this without restarting any WSJT-X instance.

Something to mention is that when switching on "Monitor" on WSJTX instances
WSJT-X and WSJT-X - HL1, the current WSPR time frame will be correctly
decoded, but not the next ones.

A screenshot of the 3 instances running, with WSPR decoding failing
(although the Wide Graph shows incoming signals) can be found here :
https://1drv.ms/u/s!AtBGol2-BnqRhfsJ7UXRuhRsil7olQ?e=3jRr4c

I have verified that no packets are lost between my transceivers and
SparkSDR. As well as no audio buffer underruns / overflows on the VAC's.
As well as deleted all AppData files and recreated the instances.

I also observed that the "Save -> Save All" option, sometimes does not save
wave files for my WSJT-X - HL7 instance decoding WSPR, when the decoding
failed (only one out of two wave files are written).

All running W10 - 64 bit.

Could someone maybe try to reproduce this problem (maybe a Red Pitaya SDR
user ?).

73's and hoping I don't have it all wrong ..
Erik
ON4PB.







___
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 - Blank line between decoding periods

[runningerik]

Dear WSJTX developers,

 

When ticking "Blank line between decoding periods" (and "Start new period
decodes at top" is unticked), there is no separation line anymore in the
Band Activity window (when decoding FT8 for example).

 

My apologies if this is a dupe report .. 

 

Stay safe and 73's,

Erik

ON4PB

 

 

 

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