Re: [wsjt-devel] Changed to a new PC running Windows 11, now nothing works.

[Charles Suckling via wsjt-devel]

Hi David

Is a file called WSJT-X.ini.  Its usually in a path similar to
C:\Users\User\AppData\Local\WSJT-X   .  You may not be able to see the
AppData folder as on some systems it is hidden and you need to unhide it.

73

Charlie DL3WDG

On Tue, 30 Apr 2024 at 20:35, davidinlondon--- via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Having just changed to a new PC running Windows 11, now nothing works.
>
>
>
> I'll take the issues one at a time.
>
>
>
> For this post my question is...I've tried deleting WSJT-X 2.6.1 from my PC
> several times, even using "IOBit Uninstaller", to try to clear it, but when
> I download a fresh 2.6.1 from Sourceforge and run it, it still shows all my
> personal details, call etc., from the previous installations.  Somewhere
> there must be a hidden "details" file that isn't being deleted.  Any ideas
> where I can look?
>
>
>
> Thanks
>
>
>
> David G5HY
> ___
> 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] QMAP query

[Charles Suckling via wsjt-devel]

Hi David

I will have  a look here also.  I am not familiar with those settings, yet,
in SDRC. I more or less used it 'out of the box'.

73

Charlie

On Tue, 19 Dec 2023 at 11:35, David Hilton-Jones via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Many thanks Charlie
>
>
>
> Done some further testing this morning and I think I have a partial
> explanation/solution.
>
>
>
> Windows 10
>
>
>
> WSJT-X rc2
>
> QMAP
>
> SDRC
>
> RSPDx
>
>
>
> No moon to play with at the moment, but just played with hitting “Tune” in
> WSJT-X.
>
>
>
> If the auto-mute in DRC is off, then there is no problem. The QMAP
> thermometer reads ~48db.
>
>
>
> If auto-mute is on, AND the Peak and Mean options are set to -20db or
> lower, then QMAP does not recover when going to receive. Thermometer is
> zero. Have to exit and reload QMAP then OK.
>
>
>
> BUT, if Peak and Mean set to 0db, then after transmit QMAP returns to
> receive as normal.
>
>
>
> Will be interesting to see if you can duplicate.
>
>
>
> 73
>
>
> David
>
>
>
> *From:* Charles Suckling via wsjt-devel [mailto:
> wsjt-devel@lists.sourceforge.net]
> *Sent:* 19 December 2023 05:33
> *To:* WSJT software development
> *Cc:* Charles Suckling
> *Subject:* Re: [wsjt-devel] QMAP query
>
>
>
> Hi David
>
>
>
> As far as I know, this hasn't been reported before.
>
>
>
> I've been running SDRC to drive QMAP now for some time here, pretty much
> since SDRC build 3117 came out, and also haven't seen this behaviour.
>
>
>
> The only problem I had, at first, was to have SDRC's demodulated audio
> outputting to the same audio 'port' as WSJT-X uses for transmitting, cured
> by muting SDRC.  It did not result in loss of signal to QMAP as you are
> seeing.
>
>
>
> What level do you see on QMAP's thermometer normally?
>
>
>
> What operating system are you running?
>
>
>
> 73
>
>
>
> Charlie DL3WDG
>
>
>
> On Tue, 19 Dec 2023 at 03:00, David Hilton-Jones via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> I am using rc2, SDRconsole with RSPDx, and QMAP
>
>
>
>
> Today, all was running fine. I clicked on a station in “Active stations”,
> and WSJT-x took me to transmit, and the QSO ran as normal.
>
>
>
> However, after my first transmit period, on return to receive, QMAP was
> showing no input signal, whilst SDRconsole was displaying normally. WSJT-x
> was working normally. I closed QMAP, and re-opened it, then it was working
> again.
>
>
>
> I obviously need to try again a few more times, but didn’t have time today.
>
>
>
> Any thoughts?
>
>
>
> David, G4YTL
>
> Sent from the all-new AOL app for iOS
> <https://apps.apple.com/us/app/aol-news-email-weather-video/id646100661>
>
> ___
> 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] QMAP query

[Charles Suckling via wsjt-devel]

Hi David

As far as I know, this hasn't been reported before.

I've been running SDRC to drive QMAP now for some time here, pretty much
since SDRC build 3117 came out, and also haven't seen this behaviour.

The only problem I had, at first, was to have SDRC's demodulated audio
outputting to the same audio 'port' as WSJT-X uses for transmitting, cured
by muting SDRC.  It did not result in loss of signal to QMAP as you are
seeing.

What level do you see on QMAP's thermometer normally?

What operating system are you running?

73

Charlie DL3WDG

On Tue, 19 Dec 2023 at 03:00, David Hilton-Jones via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I am using rc2, SDRconsole with RSPDx, and QMAP
>
>
> Today, all was running fine. I clicked on a station in “Active stations”,
> and WSJT-x took me to transmit, and the QSO ran as normal.
>
> However, after my first transmit period, on return to receive, QMAP was
> showing no input signal, whilst SDRconsole was displaying normally. WSJT-x
> was working normally. I closed QMAP, and re-opened it, then it was working
> again.
>
> I obviously need to try again a few more times, but didn’t have time today.
>
> Any thoughts?
>
> David, G4YTL
>
> Sent from the all-new AOL app for iOS
> 
> ___
> 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] Astronomical window not working

[Charles Suckling via wsjt-devel]

RIchard

I once had a case where it had disappeared off my (single) screen.

This link might help:

https://www.wikihow.com/Bring-an-Off-Screen-Window-Back-on-Windows#:~:text=Press%20and%20hold%20the%20Win,display%20settings%20in%20System%20Settings
.

73

Charlie DL3WDG

On Sun, 26 Nov 2023 at 23:09, G Richard Kreuter via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I’m using WSJT-X 2.7.0-rc2 for 432MHz EME and when I check the
> astronomical box in “view” nothing happens.  I’m running WSJT-X on my
> windows computer. I did try echo test to see if it would show up but no it
> didn’t. I have restarted my computer and reloaded want-x but that didn’t
> work either.
>
> G Richard Kreuter
>
> WC8RK
>
> ___
> 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] 64 bit

[Charles Suckling via wsjt-devel]

Hi Don

Try the methods suggested here:

https://www.digitalcitizen.life/3-ways-learn-whether-windows-program-64-bit-or-32-bit/

Applicable to Win7 and 10.

73

Charlie DL3WDG

On Mon, 11 Sept 2023 at 04:37, Donhawbaker via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

>
> I am wondering if there is some way to identify which version of WSJTX
> that I am running?
>
> I download the 64 bit version, but when I look at REVO Uninstaller, it
> says 32 bits.
>
> 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] Transverter Offset

[Charles Suckling via wsjt-devel]

Hi Tom

I enter  the offset as a number with no commas or decimal point.  In the
station information table it then appears with comma separator and decimal
points

[image: image.png]

This is on a UK purchased PC, running 2.7.0-rc2

73

Charlie DL3WDG



On Tue, 18 Jul 2023 at 22:45, tom via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Thanks all.
>
> Yes I was following all comments - I have no issue at all with 2m or 70cms
> offsets - same version of Windows, same rig (TS680) same copy of WSJT. Yes
> saving all settings with the OK.
>
> Yes was entering -1268 as offset - one thing - could someone confirm the
> format of the offset on your working system. Here it is  -1,268.000 000 Mhz
> - note the comma as the separator on 1,268
>
> Harry your example had no comma.  Could it be the locale I have set to UK ?
>
>
> Thanks
>
> Tom
>
>
>
> Tom GM8MJV
> t...@tkrh.co.uk
>
>
>
>
>
> On 18 Jul 2023, at 17:37, Harry E. Hoffman via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> Hi Tom,
>
> Appending my post:
>
> The offset frequency is a negative number so it should read:
>
> Band = 23 cm
> Offset = -1268.000 000 (note the decimal point and the space)
>
> I am using an IC-7300 as the IF radio on my system and my transverter
> settings for 1.25 meters and 33 centimeters work fine. I don't use a
> transverter for 23 centimeters as I also have an IC-9700.
>
> 73 Harry (KA2ENE)
>
> ---
>
> On 7/18/2023 10:18 AM, Harry E. Hoffman via wsjt-devel wrote:
>
> Hi Tom,
> I use transverters for 1.25 meters and 33 centimeters, using the the same
> idea try this for 23 centimeters.
> Band = 23 cm
> Offset = 1268.000 000 (note the decimal point and the space)
> Check the frequency list and if there are no entries for 23 cm add them
> for the modes you want.
> Example: Region 2 FT8 1296.174 000
> good luck.
> 73 Harry (KA2ENE)
> ---
> On 7/18/2023 6:30 AM, tom via wsjt-devel wrote:
>
> Hi - posted on main list but no final solution.
>
> Windows 11, wsjt-X 2.6.2 and 2.7.0-rc2
>
> Setting up a 23cms Transverter with a 28 MHz IF - seems to be an issue.
> Used an offset -1268 and wsjt-x displayed 23cms ok but cat jumped rig to
> 1.065 MHz.
>
>
> Tried the example given on archive for 2m offset -116 and all worked fine,
> cat kicked in and rig (TS680) switched to 28 Mhz and WSJT-X displayed 144
> MHz.
>
> Could it be the , in offset freq -1268 is entered and software formats it
> to -1,268.000 000 MHz.
>
> Tried the same setup with MSHV and WSJT-X-Improved and worked as expected
> with -1268 offset. Cat and freq both ok.
>
> Thanks in advance for any suggestions but it does look like a bug rather
> than user error.
>
> Tom GM8MJV
> t...@tkrh.co.uk 
>
>
>
>
>
>
>
> ___
> 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 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] Transverter Offset

[Charles Suckling via wsjt-devel]

Hi Tom

If its a bug, its not present with all setups, as it works for me fine, and
always has.  Operating systems Win7 and 10, but a different radio to yours.

Did you remember to press OK to close  the Frequencies window? Else it
doesn't store the new offset  you have entered.

73

Charlie DL3WDG



On Tue, 18 Jul 2023 at 12:52, tom via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hi - posted on main list but no final solution.
>
> Windows 11, wsjt-X 2.6.2 and 2.7.0-rc2
>
> Setting up a 23cms Transverter with a 28 MHz IF - seems to be an issue.
> Used an offset -1268 and wsjt-x displayed 23cms ok but cat jumped rig to
> 1.065 MHz.
>
>
> Tried the example given on archive for 2m offset -116 and all worked fine,
> cat kicked in and rig (TS680) switched to 28 Mhz and WSJT-X displayed 144
> MHz.
>
> Could it be the , in offset freq -1268 is entered and software formats it
> to -1,268.000 000 MHz.
>
> Tried the same setup with MSHV and WSJT-X-Improved and worked as expected
> with -1268 offset. Cat and freq both ok.
>
> Thanks in advance for any suggestions but it does look like a bug rather
> than user error.
>
> Tom GM8MJV
> t...@tkrh.co.uk
>
>
>
>
>
> ___
> 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] Statement regarding WSJTX.groups.io

[Charles Suckling via wsjt-devel]

Hi Uwe

I probably can't see it for looking, but where is the setting for getting
emails direct when someone posts?  I can see the online version OK.  Have
not posted anything there yet.

73

Charlie DL3WDG

On Tue, 25 Apr 2023 at 16:32, Uwe, DG2YCB via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Dear WSJT-X Users,
>
> Unfortunately, complaints about the WSJTX.group.io forum have been piling
> up lately. Therefore, the following should be clarified at this point:
>
> 1. WSJTX.group.io is a private forum and is *NOT* operated by the Core
> WSJT Development Group!
> 2. It is *NOT* our intention to ban users on WSJTX.group.io anywhere else
> just because they use certain keywords in a technical-scientific
> discussion, which the owner of WSJTX.group.io obviously does not like.
> 3. We point out that *only the wsjt-devel mailing list is our official
> communication channel*. Please use this list if you want to report bugs
> or discuss with us developers.
> 4. With immediate effect, I have therefore disabled the mention of the
> WSJTX.group.io forum on the official WSJT-X homepage.
>
> 73 de Uwe, DG2YCB
> Core WSJT Development Group
>
> P.S.: As a temporary solution, I just created a new private forum (
> WSJTXY.groups.io), where you can discuss technical issues and help each
> other with problems. I hope that one day the moderator of WSJTX.group.io
> will realize that his behavior was not good, will change it accordingly and
> that we as WSJT core development group will be able to recommend the
> WSJTX.group.io forum again. At present, unfortunately, this is no longer
> the case!
>
> ___
> 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] Q65 false decode

[Charles Suckling via wsjt-devel]

Hi Gary

What setting do you have for Auto clear avg after decode ( under the decode
tab)?

For normal operation this should be checked.  I suspect you have it
unchecked, so that messages which are still in the accumulator appear as
'fresh' decodes.  In such a case you can sometimes see decodes after the
other station has stopped transmitting.

73

Charlie DL3WDG

On Sun, 16 Apr 2023 at 15:31, K9RX via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hello all.
>
>
>
> I was running Q65-60A on 6M EME this morning. I am using version 2.6.0
> b15b7. I have DEEP and ENA AVG turned on. I decoded the station I was
> calling every sequence. However twice WSJT decoded the “proper” signal
> (right doppler and seq) but then decoded, in the AVG window, a 2nd that
> was one sequence previously. Unfortunately I didn’t see that my TX then
> reverted back to the original and was not the follow on (proper one).
>
>
>
> This happened again the next sequence but I caught it that time.
> Unfortunately I do not normally have SAVE turned on so I don’t have the
> data file.
>
>
>
> I mentioned this as an FYI re false decodes. I don’t remember ever getting
> this before (this version).
>
>
>
> But I have a question: I have Q65-60A as a configuration and switch to it
> when doing EME. Can I set the SAVE as on for this config and will it then
> be off for the other configs I have built?
>
>
>
> Gary
>
> K9RX
>
>
>
> You can see below at 1303 I got, at -24, his RX3. WSJT started to send TX4
> at 1304. Then it (almost) immediately decoded his TX1 and WSJT switched
> back to TX2. I did not catch this. The next sequence you can see this
> repeated at 1307. I have since turned on SAVE DECODED and finally you can
> see false (AVG) decodes at 1309 – 1317. He was not transmitting during
> these sequences. I can send tis file if that would help.
>
>
>
>
>
> *1302 Tx 1500 : W5WP K9RX -26*
>
> *1303 -24 2.8 1442 : K9RX W5WP R-32  q3*
>
> *1304 Tx 1500 : W5WP K9RX RRR*
>
> *1303 -24 2.8 1447 : K9RX W5WP EM00  q35*
>
> *1304 Tx 1500 : W5WP K9RX -24*
>
> *1305 -19 2.8 1439 : K9RX W5WP R-32  q3*
>
> *1306 Tx 1500 : W5WP K9RX RRR*
>
> *1307 -24 2.8 1439 : K9RX W5WP RRR  q3*
>
> *1308 Tx 1500 : W5WP K9RX 73*
>
> *1307 -23 2.8 1441 : K9RX W5WP R-32  q37*
>
> *1308 Tx 1500 : W5WP K9RX 73*
>
> *1309 -24 2.8 1441 : K9RX W5WP R-32  q38*
>
> *1311 -26 2.8 1441 : K9RX W5WP R-32  q39*
>
> *1313 -28 2.8 1441 : K9RX W5WP R-32  q3**
>
> *1315 -29 2.8 1441 : K9RX W5WP R-32  q3**
>
> *1317 -31 2.8 1441 : K9RX W5WP R-32  q3**
>
> *1319 -32 2.8 1441 : K9RX W5WP R-32  q3**
>
>
>
> Sent from Mail  for
> Windows
>
>
> ___
> 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] Possible issue with ECHO mode - 2.6.0

[Charles Suckling via wsjt-devel]

Hi Gary

Have a look at these, which will hopefully help.

https://wsjt.sourceforge.io/Echo_Mode_in_WSJT-X_2.6.0.pdf
http://www.bobatkins.com/radio/EME_WSJTX_echo_mode_basic_guide.html

73

Charlie DL3WDG


On Wed, 22 Feb 2023 at 16:37, K9RX via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I like to use ECHO to test the station on 6M EME.
>
>
>
> But the latest version has changed enough I was wondering if there was a
> short help file for it?
>
>
>
> Also: The Echo graph will at times show the echo centered – and other
> times show it offset. I have a jpg showing a recent echo run where the echo
> was very strong – and it was showing it as the right numeric doppler shift,
> 96 Hz, but it was showing it on the graph as -96Hz and there was no SNR
> value reported (-99.0 shown). You can see the echo on the wide graph – you
> can see the echo on the echo graph – but both have it lower than it should
> be…
>
>
>
> A few minutes earlier I had 2 echos at -14.6 and others in to the low 20’s
> – these were all showing on the spreadsheet – and “properly” on both the
> wide and echo graphs.
>
>
>
> Gary Myers
>
> K9RX
>
>
>
>
>
> Sent from Mail  for
> Windows
>
>
> ___
> 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] Q65 T/R Cycle Submode Tracking

[Charles Suckling via wsjt-devel]

Hi Dwayne

Could you please provide some references to these websites and technical
discussions.

There is no general linkage of period length to tone spacing, since a
number of factors are in play.  Have you read the Q65 Quick Start Guide?

73

Charlie DL3WDG

On Mon, 6 Feb 2023 at 20:03, Dwayne Sinclair via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> There are technical discussions and associated websites that describes the
> optimal submode for the various T/R Cycles -
>
> T/R 15 Seconds Submode A
> T/R 30 Seconds Submode B
> T/R 60 Seconds Submode C
> T/R 120 Seconds Submode D
> T/R 300 Seconds Submode E
>
> Would it be possible to add a switch to setting to track submode to T/R
> cycle since both settings have to be changed when we switch T/R cycles?
>
> Regards Dwayne AB6A
>
>
>
> ___
> 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] Q65 T/R listbox disappears. WSJT-X 2.6.0 GA Release

[Charles Suckling via wsjt-devel]

Hi Hatt

This was reported earlier on the wsjt.io  list and Joe has commented that
this will be fixed in a release of 2.6.1 soon.

As of now, 2.6.0 will use the previous period length selected, so for most
users who use 60s periods this will probably go un-noticed. As you note, if
you want to change it then editing the .ini file is a workaround for now.

73

Charlie DL3WDG

On Sat, 7 Jan 2023 at 09:27, Hattori, Yoshihisa via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> In WSJT-X 2.6.0 GA Release, when Q65 is selected, T/R listbox disappears.
> The user cannot change T/R duration in Q65.(Previously selected value is
> used.)
> Other modes such as FST4/MSK144/FST4W look OK.
> Please fix it. Thanks
>
> Work around as of now is to modify WSJT-X.ini directly.
>
> De JO1LVZ/Hatt
>
>
> ___
> 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] Hamlib 4.5.2 test #hamlib

[Charles Suckling via wsjt-devel]

Hi Mike

Also tested SDR-Console and my IC202 (that uses G4JNT IC756 emulator in a
PIC).  So, happy here.

Charlie DL3WDG

On Tue, 20 Dec 2022 at 16:03, Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hamlib 4.5.2 is due to be released this week.
> All known bugs have been fixed.
>
> Please test and ensure everything is workingor report any bad
> behavior.  This will likely be the hamlib in the WSJT-X release.
>
> Here is a zip file for the 64-bit binaries.
> https://www.dropbox.com/s/q2cf6xb50pgsr61/hamlib-4.5.2-20221220.zip?dl=0
>
>
> And here is the 64-bit dll which can be placed in \WSJT\WSJT-X\bin
> https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0
>
> Mike W9MDB
>
>
> ___
> 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] Hamlib 4.5.2 test #hamlib

[Charles Suckling via wsjt-devel]

Same here.

Also OK with HDSDR.

Charlie DL3WDG

On Tue, 20 Dec 2022 at 19:43, Al via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Mike,
>   Looks ok with Flex 6xxx/2.6.0-rc5 so far..
> AL, K0VM
>
>
> On 12/20/2022 8:56 AM, Black Michael via wsjt-devel wrote:
>
> Hamlib 4.5.2 is due to be released this week.
> All known bugs have been fixed.
>
> Please test and ensure everything is workingor report any bad
> behavior.  This will likely be the hamlib in the WSJT-X release.
>
> Here is a zip file for the 64-bit binaries.
> https://www.dropbox.com/s/q2cf6xb50pgsr61/hamlib-4.5.2-20221220.zip?dl=0
>
>
> And here is the 64-bit dll which can be placed in \WSJT\WSJT-X\bin
> https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0
>
> Mike W9MDB
>
>
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RC5 multiple decode

[Charles Suckling via wsjt-devel]

Hi Don

I just tested -rc5 with a simulated two signal Q65-60D  wave file (with EME
delay)  and multiple decoding works fine here.

 The decoding threshold is higher than that needed to decode when the
signal is within the Ftol band, so maybe the signals you could not decode
were just too weak.

Test file is here:

https://drive.google.com/file/d/1ss7vaIISwwNW1KOUJ0xH3ZeyL_kpuCiB/view?usp=sharing

Regarding 902MHz in Echo mode, you can add that yourself - see section 4.6
of the User Guide.

73

Charlie DL3WDG



On Sat, 17 Dec 2022 at 23:42, Don Hawbaker via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I seem to have lost the ability to do multiple decodes.  The single decode
> is turned off.  No matter how many signals are on the waterfalls, I only
> get decode on the one where the cursor is sitting.  It used to do multiple
> decodes.
>
> Second item.  In echo mode, the frequency 902 MHz is missing from the
> frequency list.  In RC4, it appeared.
>
> 73s
>
>
>
>
>
> ___
> 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] Frequencies

[Charles Suckling via wsjt-devel]

Hi All

I have been playing with the new frequencies table and it looks very useful.

There is one behaviour of WSJT-X that often catches folks out, and I wonder
if its possible to address this as some point.

The behaviour is that when you have tuned to a particular frequency, and
then enter Settings to change something, on exiting Settings your frequency
is reset to the appropriate frequency as determined by the frequencies
table, not where you were tuned to before entering Settings.

 It would be preferable, I think, for the frequency to not change in this
way.

73

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

Re: [wsjt-devel] WSJT-X 2.6.0-rc5 hamlib failure for Flex radio

[Charles Suckling via wsjt-devel]

Same here - thanks Mike!

On Wed, 30 Nov 2022 at 03:15, Robert Wright via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> The manual copy of http://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll
> over the rc-5 install fixed the FlexRadio problem here.
>
> Thanks and 73,
> Bob, N7ZO
>
> -Original Message-
> From: Black Michael via wsjt-devel 
> Sent: Tuesday, November 29, 2022 10:37 AM
> To: wsjt-devel@lists.sourceforge.net
> Cc: Black Michael 
> Subject: Re: [wsjt-devel] WSJT-X 2.6.0-rc5 hamlib failure for Flex radio
>
> RC5 was built with an older hamlib.
>
> Please try the latest.
>
> New hamlib for installation directions
>
> #1 Shut down WSJTX
>
>
> #2 Download either the 32-bit or 64-bit DLL matching the 32/64-bit version
> of WSJTX -- hopefully your browser doesn't block it but may warn you
> multiple times.
>
>
> If you can do a "Save As" you can save it directly in the appropriate
> WSJTX directory C:\WSJT\WSJTX\bin and replace the libhamlib-4.dll that is
> there.
>
>
> http://n0nb.users.sourceforge.net/dll32/libhamlib-4.dll
>
>
> http://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll
>
>
> Linux/Unix/Mac users need to compile the latest tar file from
> http://n0nb.users.sourceforge.net
> Note: If compiling on Unix-like systems please uninstall any Hamlib
> package you have before installing the new build
>
>
> #3 If you don't save directly you need to open a file browser and move the
> file that way.
>
>
> If you're not familiar with that here's a video on the file browser -
> https://www.youtube.com/watch?v=AyVqCJrs9dk
>
>
> Mike W9MDB
>
>
>
>
>
>
>
>
> On Tuesday, November 29, 2022 at 12:08:03 PM CST, Jay via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>
>
>
>
> I just installed the new RC5 into my Windows 10 64 bit computer and am
> getting a Hamlib error when trying to activate CAT control.
>
> Radio is a Flex 6500 and I normally use TCP ports to control the Slice
> receiver, This is NOT the Kenwood emulation using COM ports. However I get
> this error message when I try to test the CAT connection in the
> Settings/Radio tab in WSJT-X RC5. See attached jpg.
>
> 73 Jay KA9CFD
>
>
> ___
> 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 mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Echo Testing

[Charles Suckling via wsjt-devel]

Hi LLoyd

Thanks for sharing your results.

You will certainly find on 144MHz a large variability in the results
depending on Faraday rotation at the time of your tests.  It will be
interesting to see how often you are able to find your echoes.

Does your system allow you to track the moon?

73

Charlie DL3WDG

On Fri, 26 Aug 2022 at 23:34, Lloyd Korb via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hello,
>
>
>
> Conditions were up and down but I was able to grab this picture.
>
> Sorry, I couldn't copy the .wav file.  Will try again tomorrow.
>
>
>
> 73,  Lloyd  K8DIO
> ___
> 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] Syslog dropped audio

[Charles Suckling via wsjt-devel]

Echoing earlier comments that Bill (sk) said that these short 'dropouts' do
not matter.  He told me once that they may not even be dropped samples at
all, and could well be  an artifact of the way they are measured.

Sometimes the dropouts can be several seconds or more, in which case it is
likely that the period in which they occurred may not decode. One
positively identified source of long problem dropouts has been when
Dimension4 decides to do a clock resync.

73

Charlie DL3WDG



On Sat, 23 Jul 2022 at 15:21, Josh Rovero via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> On my 64-bit fedora core 36 system, AMD Ryzen 5 2.2 GHz, about .05 second
> of audio is dropped on many 2-minute WSPR receive cycles.  Audio interface
> is Texas Instruments Burr-Brown (Signalink USB).  Version of WSJT-X doesn't
> matter, happens with 2.5.4 or the 2.6.0-rc* versions.
>
> [SYSLOG][2022-07-23 09:05:54.031504][42:26:11.815257][warning] Detected
> dropped audio source samples: -2400 (-0.05 S)
> [SYSLOG][2022-07-23 09:37:54.031366][42:58:11.815120][warning] Detected
> dropped audio source samples: 2400 (0.05 S)
> [SYSLOG][2022-07-23 09:43:54.031335][43:04:11.815090][warning] Detected
> dropped audio source samples: 2400 (0.05 S)
> [SYSLOG][2022-07-23 09:59:54.032360][43:20:11.816114][warning] Detected
> dropped audio source samples: 2448 (0.051 S)
> [SYSLOG][2022-07-23 10:03:54.031671][43:24:11.815424][warning] Detected
> dropped audio source samples: -2352 (-0.049 S)
> [SYSLOG][2022-07-23 10:07:54.033172][43:28:11.816926][warning] Detected
> dropped audio source samples: -2304 (-0.048 S)
> [SYSLOG][2022-07-23 10:13:54.032763][43:34:11.816516][warning] Detected
> dropped audio source samples: 2496 (0.052 S)
>
> --
> P.J. "Josh" Rovero http://www.roveroresearch.org
> Ham Radio: KK1D
> ___
> 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] Q65: Auto Clear Avg after decode

[Charles Suckling via wsjt-devel]

Hi Joe and Team

Unless there is a good reason to keep this, could I ask that this option be
removed, please, and this function be always active.

There has been a lot of confusion recently about perceived benefits of
having this unchecked,  in that more "decodes" appear.

I have done my best to explain, and demonstrate with examples, that these
"decodes" are produced after a pretty solid average accumulator has added
to it noise, another weak message or some other junk, and then produces a
decode out of what was stored plus the new input, so that the new input is
being understood by some folks to be a real message.

This confusion could be removed if the option was no longer there...

73

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

Re: [wsjt-devel] Are you building WSJT-X ?

[Charles Suckling via wsjt-devel]

Hi Joe

Building here on Windows, 64 bit only.  Needed some help from Uwe to get it
running again.  Using the JTSDK toolset, inside a VM on Windows 10.  I have
not been able to build debug versions with it.  Uwe hasn't been able to
help with that.  Not sure if its a deficiency my end, or in the toolset.

Programming skills are very limited.  I dabbled with Fortran (4?) at
University.  Tend to look for examples in the code which do what I want,
especially in C++, and needed help from Bill on a number of occasions.

With Bill's help I was able to stage and commit with Git, and made some
notes at the time, but not confident I could do it again.

Yes, I have made a number of changes to the code over time.  Fixing TX freq
to 1000Hz in QRA64 was one of the first, as Rex and I used to forget it
changed to 1500 in Echo mode and often someone would forget when going to
QRA64.  I also enabled Autosequencing to QRA64, mainly to help Rex as his
workload in his expeditions was very high. I also found it very
convenient.  May also have added single tone messages around the same
time.   Later, added OnDxEcho and Call DX Doppler methods, mainly for the
1296 folks who tend to use them traditionally, although CFOM is becoming
increasingly used now (good!).  Got familiar with User Guide and have made
some contributions to that.  I think I can still do that.  Also, made some
changes to the simulators to add single tone capability, and file numbering
to be compatible with averaging (with a little help again from Bill).  Also
added moon distance to Astro.

I would not go so far as to say there is much of the code that I  (fully)
understand.  Latterly, Bob pointed to the feature in Notepad ++ that allows
you to search the entire repository for a variable name, or other phrase,
which has helped to figure out what is 'connected' to what.  Passing
variables from one subroutine to another is beyond me, other than via files
(as we did with the recent work on Echo mode).

Btw, thanks for adding Clear Average to Echo per Bob's request.  That will
be indeed useful.

Charlie



On Mon, 25 Apr 2022 at 18:02, Joe Taylor via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> When I started work on WSJT some 21 years ago, my principal goal was to
> help bring amateur weak-signal communication techniques into the
> twenty-first century -- and in doing so, to help spread knowledge of
> modern communication theory into the amateur radio community.
>
> By 2005 WSJT was well established but mostly used for special purposes
> like meteor scatter and EME ("moonbounce").  A stable development path
> had been established: the program was fully Open Source, licensed under
> the GNU General Public License, and it could be built by anyone from
> source code using freely available compilers and development tools.  At
> this time WSJT was coded in a combination of Python, Fortran, and C.  A
> re-write in 2012 created the present program, WSJT-X, using the Qt
> platform and C++ language in addition to Fortran and C.
>
> To help gauge the extent to which my original educational goals are
> being met, we in the core development team are interested to know how
> many WSJT-X users are currently building the program for themselves,
> from source code.  If you are doing so, we would appreciate an email
> response -- either publicly, to this list, or in a private email to me.
> All responses will be appreciated, but particular things you might want
> to mention in your message include these:
>
>   - Building on what platform?  Windows, Linux, macOS, or other?
>
>   - What are your particular programming skills and interests?
>
>   - Are you making changes to the code?  If so, toward what end?
>
>   - What portions of the code have you studied well enough to understand?
>
> Many thanks -- I look forward to hearing from you!
>
> -- 73, Joe, K1JT
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] SUGGESTION

[Charles Suckling via wsjt-devel]

Uwe

As others have stated, there are occasions when one wants to use WSJT-X to
generate a carrier for a long, non-fixed time.  For example, someone on
10GHz EME was doing exactly that (to look for drift in a TWT over time.
Having a time limited Tune would be a new feature that a number of folks
won't like, as expressed here in other messages.

If a 'watchdog' is to be added to Tune, then please allow those of us who
don't want it to be able to revert to its historic behaviour.

73

Charlie DL3WDG

On Sun, 6 Mar 2022 at 19:55, DG2YCB, Uwe via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Well, basically it is no problem to make a checkbox to deactivate such a
> TUNE watchdog, but tell me: What do you need it for?
>
>
>
> 73 de Uwe DG2YCB
>
>
>
> *Von:* Carey Fisher via wsjt-devel [mailto:
> wsjt-devel@lists.sourceforge.net]
> *Gesendet:* Sonntag, 6. März 2022 19:29
> *An:* WSJT software development
> *Cc:* Carey Fisher
> *Betreff:* Re: [wsjt-devel] SUGGESTION
>
>
>
> Make it a programmable (up to 10 minutes)  time, default to 2 minutes.
>
>
>
> On Sun, Mar 6, 2022 at 12:19 PM DG2YCB, Uwe via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> Hi all,
>
>
>
> Since I had similar requests for such a function in the past, I already
> programmed a time limit for the TUNE button a few weeks ago. This will be
> included in the next WSJTX release. 10 seconds is of course much too short,
> but I think 2 minutes is reasonable. This should be long enough to tune
> your antenna, but it effectively prevents unwanted continuous transmissions.
>
>
>
> 73 de Uwe, DG2YCB
>
>
>
> *Von:* Carey Fisher via wsjt-devel [mailto:
> wsjt-devel@lists.sourceforge.net]
> *Gesendet:* Sonntag, 6. März 2022 14:26
> *An:* WSJT software development
> *Cc:* Carey Fisher
> *Betreff:* Re: [wsjt-devel] SUGGESTION
>
>
>
> Uh, no!
>
>
>
> On Sat, Mar 5, 2022 at 11:51 PM Gavin ZL3GAV via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> Hello
>
>
>
> Not a huge priority, but one of those nice to have please…
>
>
>
> With the TUNE button, can this be limited to timeout at 10 seconds maximum
> please?
>
>
>
> From experience, we all make silly mistakes, whilst tuning my FT-991A I
> got distracted, with the result, I nuked the radio *(since fixed)*
> running on full power on TUNE. It is not a pleasant experience the acrid
> smell of burning electronic components!
>
>
>
> 73
>
>
>
> Gavin
>
> ZL3GAV
>
>
>
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> --
>
> Carey Fisher
>
> careyfis...@gmail.com
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
>
> --
>
> Carey Fisher
>
> careyfis...@gmail.com
>
>
> ___
> 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

[Charles Suckling via wsjt-devel]

Good suggestion, Mike.  I would like an easy to use method of keeping it
continuous.

Charlie DL3WDG

On Sun, 6 Mar 2022 at 18:33, Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> And can you make CTRL-click keep it on please?
> There are use cases for it.
>
> Mike W9MDB
>
>
>
>
> On Sunday, March 6, 2022, 11:20:58 AM CST, DG2YCB, Uwe via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>
> Hi all,
>
>
>
> Since I had similar requests for such a function in the past, I already
> programmed a time limit for the TUNE button a few weeks ago. This will be
> included in the next WSJTX release. 10 seconds is of course much too short,
> but I think 2 minutes is reasonable. This should be long enough to tune
> your antenna, but it effectively prevents unwanted continuous transmissions.
>
>
>
> 73 de Uwe, DG2YCB
>
>
>
> *Von:* Carey Fisher via wsjt-devel [mailto:
> wsjt-devel@lists.sourceforge.net]
> *Gesendet:* Sonntag, 6. März 2022 14:26
> *An:* WSJT software development
> *Cc:* Carey Fisher
> *Betreff:* Re: [wsjt-devel] SUGGESTION
>
>
>
> Uh, no!
>
>
>
> On Sat, Mar 5, 2022 at 11:51 PM Gavin ZL3GAV via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> Hello
>
>
>
> Not a huge priority, but one of those nice to have please…
>
>
>
> With the TUNE button, can this be limited to timeout at 10 seconds maximum
> please?
>
>
>
> From experience, we all make silly mistakes, whilst tuning my FT-991A I
> got distracted, with the result, I nuked the radio *(since fixed)*
> running on full power on TUNE. It is not a pleasant experience the acrid
> smell of burning electronic components!
>
>
>
> 73
>
>
>
> Gavin
>
> ZL3GAV
>
>
>
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> --
>
> Carey Fisher
>
> careyfis...@gmail.com
>
>
> ___
> 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] SUGGESTION

[Charles Suckling via wsjt-devel]

Gavin, Tony et al

I personally find it useful to be able to generate a continuous carrier
with WSJT-X using the Tune button.

73

Charlie DL3WDG

On Sun, 6 Mar 2022 at 10:13, Tony ZL3HAM via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> A good idea Gavin and I don't think it would be too difficult to do, we're
> keep our fingers crossed.
>
> A very warm day today.
>
> 73 Tony
>
>
> On 6/03/2022 5:29 pm, Gavin ZL3GAV via wsjt-devel wrote:
>
>
>
> Not a huge priority, but one of those nice to have please…
>
>
>
> With the TUNE button, can this be limited to timeout at 10 seconds maximum
> please?
>
>
>
> From experience, we all make silly mistakes, whilst tuning my FT-991A I
> got distracted, with the result, I nuked the radio *(since fixed)*
> running on full power on TUNE. It is not a pleasant experience the acrid
> smell of burning electronic components!
>
>
>
> 73
>
>
>
> Gavin
>
> ZL3GAV
>
>
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://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] Memorial service for Bill Somerville, G4WJS

[Charles Suckling via wsjt-devel]

Hi Joe

The link is open already, so you can log in before the service starts.

Yes, the time is 1300 UTC.

73

Charlie DL3WDG

On Tue, 25 Jan 2022 at 01:46, Joe Taylor via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I write to let you know that a Memorial service for Bill Somerville,
> G4WJS. will take place at Chilterns Crematorium, Amersham, Milton
> Chapel, at 13:00 (I believe this means 1300 UTC) on Friday, January 28.
>
> You can view the service remotely, as follows:
>
> https://www.wesleymedia.co.uk/webcast-view
>
> Webcast Login PIN: 273-9083
>
> Webcast Viewing Instructions are available here:
>
>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclientportal.wesleymedia.co.uk%2Femail-template%2Fwebcast_viewing_instructions.pdf=04%7C01%7C%7C7579efac53b1463cbdfd08d9dc19a66b%7C84df9e7fe9f640afb435%7C1%7C0%7C637782825000764798%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=8CzOfX%2FqTLEudSP7jnFOKW%2Bs4eG7ek7cUvwKCPRy3S8%3D=0
>
> I take the instructions to mean that you can view the webcast starting
> at any time after the service has begun.
>
> Bill did not have many close family members.  Many of his friends were
> fellow ham radio enthusiasts, scattered all over the world, so it is
> good to have this option for a way to pay our last respects to a dear
> colleague.
>
> With best wishes to all,
>
> -- 73, Joe Taylor, K1JT
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bill Somerville, G4WJS, SK

[Charles Suckling via wsjt-devel]

Hi Joe

Thanks for passing this on.

73

Charlie

On Fri, 14 Jan 2022 at 16:37, Joe Taylor via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I am forwarding a message from Paul Welford, G4YKQ:
>
> #
> I have been requested to post this to The Group Re: The Late G4WJS Bill.
>
> Bill"s funeral will take place on Friday 28th January at 1-0 p.m at
> Amersham Crematorium, Whielden Lane, Amersham, Buckinghamshire. HP7 OND.
>
> A toast to Bill will be raised afterwards at The Fleur De Lis Public
> House. Oxford Road,Stokenchurch, High Wycombe, Buckinghamshire. HP14 3TZ.
>
> It"s acknowledged that Bill had made many friends Worldwide especially
> as being a major contributor to WSJT-X and solved many a user problems.
>
> As in the way of thanks please give a thought and raise a glass or two
> wherever you are on this day to Bill.
>
> I personally know of the countless hours he devoted to the group and
> helping others.As I have said before "He loved it"!!
>
> If you are going to attend ALL ARE WELCOME  please inform me due to food
> numbers, etc.
>
> I have just been informed that the short Humanist service will be
> available online .Please contact me for further details.
> g4ykq@yahoo .co.uk
>
> Many Thanks Paul
> #
> On 1/14/2022 9:56 AM, Joe Taylor via wsjt-devel wrote:
> > There is a nice piece in the February issue of QST about our departed
> > friend Bill Somerville, G4WJS.
> >
> > In case you do not subscribe to QST, I have posted a copy here:
> > https://physics.princeton.edu//pulsar/k1jt/G4WJS.jpg
> >
> >  -- 73, Joe, K1JT
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Q65 decoder only decodes only one of multiple signals in passband

[Charles Suckling via wsjt-devel]

Hi Peter

The example file  00_0003.wav in the link I sent is a simulated file,
with DT set to 2.5s as for an EME signal.

Try it with Ftol=100Hz and it should decode both signals OK.  For me, on
one quick test, with Ftol=1000 encompassing both signals only one decoded.

73

Charlie

On Tue, 4 Jan 2022 at 20:53, Peter Sumner via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hi Charlie,
>   may I ask were the Q65-60D recordings were EME or terrestrial ?  I have
> found that with Q65 it is quite dependent on the 'decode after eme delay'
> setting as to whether the signal decodes or not.
>
> After more testing last night, I found the samples from Lance W7GJ that
> decoded in Q65-60A but required me to have 'decode after eme delay' ticked
> which had me foxed for a few minutes.
>
> So far I have had no luck with any of the Q65-30A samples decoding, on air
> observations are the decoder works for one signal only. Checked again to be
> sure and the 'single decode'  option is not enabled.   If I go back and
> click on each signal I get a decode.
>
> It is behaving like the decoder is in DEEP mode even though FAST is
> selected.
>
> Regards,
> Peter, vk5pj
>
>
> Regards,
> Peter vk5pj
>
> On Tue, Jan 4, 2022 at 9:18 PM Charles Suckling via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>> Hi Peter
>>
>> This link has some Q65 examples, including simulated  one with two
>> different  Q65-60D signals in the passband.
>>
>>  Make sure of course that you have 'single decode' in main settings
>> unchecked (!).
>>
>>
>> https://drive.google.com/drive/folders/1RMdrOT7SVIrTDz4hMdmzZkfXJ2daf0yu?usp=sharing
>>
>> 73
>>
>> Charlie G3WDG
>>
>>
>>
>> On Tue, 4 Jan 2022 at 10:24, Peter Sumner via wsjt-devel <
>> wsjt-devel@lists.sourceforge.net> wrote:
>>
>>> Hi,
>>>   at some point the Q65 decoder engine has stopped showing decodes from
>>> multiple signals in the WSJT-X passband and I am at a loss to explain how
>>> or when this has occurred.
>>>
>>> I have downloaded the sample files from the main Pulsar web site and
>>> tried to follow the Q65 quick start guide to no avail.
>>>
>>> At this point none of the Q65-30A sample WAV files produce a decode for
>>> me, the single sample for Q65-60A seems to have two signals but can not get
>>> either to decode no matter what combination of Fast, Deep or Normal I have
>>> tried.
>>>
>>> While I have successfully had some Q65 contacts to the USA today from
>>> Australia, it is making me doubt the results of the decoder.
>>>
>>> Does anyone in the group have some proven Sample WAV files with multiple
>>> stations in a period I could try? (other than the ones from the WSJT-X web
>>> site)
>>>
>>> So far tried WSJT-X version, 2.4, 2.50, 2.51 and 2.54 with the
>>> same result.  I know this used to work for me as in June July it was doing
>>> multi pass decoding on the openings to the EU and was working on EME during
>>> the recent W7GJ trip away.
>>>
>>> I am leaning to this being a problem with a windows update as going back
>>> and testing with v2.4 should have given me good results but alas no
>>>
>>> Still scratching my head.
>>>
>>> Regards,
>>> Peter, vk5pj
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel 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] Q65 decoder only decodes only one of multiple signals in passband

[Charles Suckling via wsjt-devel]

Hi Peter

This link has some Q65 examples, including simulated  one with two
different  Q65-60D signals in the passband.

 Make sure of course that you have 'single decode' in main settings
unchecked (!).

https://drive.google.com/drive/folders/1RMdrOT7SVIrTDz4hMdmzZkfXJ2daf0yu?usp=sharing

73

Charlie G3WDG

On Tue, 4 Jan 2022 at 10:24, Peter Sumner via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hi,
>   at some point the Q65 decoder engine has stopped showing decodes from
> multiple signals in the WSJT-X passband and I am at a loss to explain how
> or when this has occurred.
>
> I have downloaded the sample files from the main Pulsar web site and tried
> to follow the Q65 quick start guide to no avail.
>
> At this point none of the Q65-30A sample WAV files produce a decode for
> me, the single sample for Q65-60A seems to have two signals but can not get
> either to decode no matter what combination of Fast, Deep or Normal I have
> tried.
>
> While I have successfully had some Q65 contacts to the USA today from
> Australia, it is making me doubt the results of the decoder.
>
> Does anyone in the group have some proven Sample WAV files with multiple
> stations in a period I could try? (other than the ones from the WSJT-X web
> site)
>
> So far tried WSJT-X version, 2.4, 2.50, 2.51 and 2.54 with the
> same result.  I know this used to work for me as in June July it was doing
> multi pass decoding on the openings to the EU and was working on EME during
> the recent W7GJ trip away.
>
> I am leaning to this being a problem with a windows update as going back
> and testing with v2.4 should have given me good results but alas no
>
> Still scratching my head.
>
> Regards,
> Peter, vk5pj
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Q65 decoder only decodes only one of multiple signals in passband

[Charles Suckling via wsjt-devel]

Hi Peter

This link has some Q65 examples, including simulated  one with two
different  Q65-60D signals in the passband.

 Make sure of course that you have 'single decode' in main settings
unchecked (!).

https://drive.google.com/drive/folders/1RMdrOT7SVIrTDz4hMdmzZkfXJ2daf0yu?usp=sharing

73

Charlie G3WDG



On Tue, 4 Jan 2022 at 10:24, Peter Sumner via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hi,
>   at some point the Q65 decoder engine has stopped showing decodes from
> multiple signals in the WSJT-X passband and I am at a loss to explain how
> or when this has occurred.
>
> I have downloaded the sample files from the main Pulsar web site and tried
> to follow the Q65 quick start guide to no avail.
>
> At this point none of the Q65-30A sample WAV files produce a decode for
> me, the single sample for Q65-60A seems to have two signals but can not get
> either to decode no matter what combination of Fast, Deep or Normal I have
> tried.
>
> While I have successfully had some Q65 contacts to the USA today from
> Australia, it is making me doubt the results of the decoder.
>
> Does anyone in the group have some proven Sample WAV files with multiple
> stations in a period I could try? (other than the ones from the WSJT-X web
> site)
>
> So far tried WSJT-X version, 2.4, 2.50, 2.51 and 2.54 with the
> same result.  I know this used to work for me as in June July it was doing
> multi pass decoding on the openings to the EU and was working on EME during
> the recent W7GJ trip away.
>
> I am leaning to this being a problem with a windows update as going back
> and testing with v2.4 should have given me good results but alas no
>
> Still scratching my head.
>
> Regards,
> Peter, vk5pj
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X syslog and the .WAV files issue.

[Charles Suckling via wsjt-devel]

Hi Mike

About a year ago, some work was done on audio dropouts by some of the EME
fraternity. At the time, the main issue was long dropouts seen in the
syslog file, lasting a number of seconds. The decoder did not attempt to
decode periods containing these, and also wave files were not saved.

Examining our syslogs, we also noted many examples similar to the one from
Marco, where the audio dropout was much shorter and flagged as a 'warning'
rather than as an 'error'. Periods containing these seemed to decode fine,
and wave files were saved.

In discussions with Bill, he commented that short audio dropouts were
unlikely to have any significant effects.

In my own case, long dropouts were perfectly correlated  with step changes
in setting PC time with Dimension 4.  These have not occurred since  Bill
helped me to get Meinberg to work.

73

Charlie G3WDG

On Sun, 2 Jan 2022 at 04:37, Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Look at the menu Save and pick None -- that will stop keeping the wav
> files.
>
> The dropped audio is due to sound card latency enough to cause frames of
> sound data to be missed.  Usually because the computer is too busy.  Disk
> I/O can cause lots of problems.
>
> Make sure you exclude all your ham software directories from your virus
> scanner.
>
> Mike W9MDB
>
>
>
> On Saturday, January 1, 2022, 07:14:19 PM CST, Marco Calistri via
> wsjt-devel  wrote:
>
>
> Hello and happy new year 2022!
>
> I have two request:
>
> 1- What this error I saw in the syslog means: *[SYSLOG][2022-01-01
> 23:55:44.398661][01:12:40.285677][warning] Detected dropped audio source
> samples: 472 (0.009834 S)*
>
> 2- Why you, dears developers, do not include the full disabling of the
> software save the so large . WAV files?
>
> I think that not everyone is using such audio files and due their size if
> you forget to empty the related folder, they tend to fill the disk space.
>
> IMHO you should include an user option to fully disable such audio files
> creation.
>
> Las but not least: from time to time I noticed WSJT-X closes suddenly
> without any apparent reason, then I need to restart it.
>
> Many thanks for your kindest attention and good DX!
>
>
> ---
>
> *73 de Marco, PY1ZRJ (former IK5BCU) *
> ___
> 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] WAV file input to JT9 command line program

[Charles Suckling via wsjt-devel]

Hi Eric

I can't find a specification for a standard WSJT-X wave file in the User
Guide.

Playing a standard file into Audacity indicates a 12000 sample rate and
"32 bit float".

Can't help with your Q1.

73

Charlie G3WDG/DL3WDG

On Thu, 9 Dec 2021 at 05:06, Eric Urban via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hello everyone,
>
> This was posted to the support group originally, but I don't think that
> was the correct venue for it.
>
> I have a GNURadio chart that I run and play audio into my loopback device.
> I can run the WSJTX program & decode it just fine. This all runs on Ubuntu
> Linux. I am listening to 7.074 MHz USB with a small loop antenna. I receive
> stations nearby me frequently and sometimes those from several states away.
>
> I modified my GNURadio flow chart to produce 15 second WAV files that are
> output synchronized to the FT8 transmission interval. My hope is I can just
> process these files to decode the signals rather than depend on a running
> WSJTX session.
>
> I want to decode these using the jt9 command line program. WSJTX has the
> option to download the included sample files. So I test again that using
> the following
>
> $ jt9 -8 -F 200 -f 1500 210703_133430.wav
> 133430  15  0.3 2571 ~  W1FC F5BZB -08
> 133430  -2 -0.8 1197 ~  CQ F5RXL IN94
> 133430  13 -0.1 2157 ~  WM3PEN EA6VQ -09
> 133430 -13  0.3  590 ~  K1JT HA0DU KN07
> 133430  -7  0.1  723 ~  A92EE F5PSR -14
> 133430  -3 -0.1 2695 ~  K1BZM EA3GP -09
> 133430 -13  0.3  641 ~  N1JFU EA6EE R-07
> 133430  -3  0.2  466 ~  N1PJT HB9CQK -10
> 133430  -7  0.4 2734 ~  W1DIG SV9CVY -14
> 133430 -16  0.1 1649 ~  K1JT EA3AGB -15
> 133430 -16  0.3  400 ~  W0RSJ EA3BMU RR73
>0  110
>
> This works fine.
>
> I run against my WAV file I created, which I name test.wav
>
> $ jt9 -8 -F 200 -f 1500 test.wav
> At line 238 of file /home/bill/wsjtx-prefix/src/lib/jt9.f90
> Fortran runtime error: Substring out of bounds: lower bound (0) of
> 'infile' is less than one
>
> Error termination. Backtrace:
>
> This crashes. I checked the Fortran source and it looks like it is trying
> to parse the command argument file name? So I padded out the file name
>
> $ jt9 -8 -F 200 -f 1500 test0.wav
>  EOF on input file test0.wav
>0   00
>
> This sidesteps whatever that problem is
>
> my test file is 15.335 seconds long. So it is long enough. I looked
> through the source code and notice that while the code appears to access
> the sample rate of the file, that value isn't used meaningfully. There is
> no apparent reference to bit depth.
>
> My file is 8000 Hz sample rate with 8 bit depth. The sample file is 12000
> sample rate with 16 bit depth. I converted my file to the same 12000
> Hz/16-bit depth
>
> $ sox ./test0.wav -r 12000 -b 16 ./test0c.wav
> $ jt9 -8 -F 200 -f 1500 test0c.wav
>0   00
>
> At least here the jt9 program completes without any issue.
>
> I have a few questions
>
> 1. Is the jt9 program trying to parse the file name? What is the expected
> file name format?
> 2. What sample rate should WAV audio files be in? Is it fixed with no
> ability to configure it
> 3. What bit depth should WAV audio files be in?
>
> Eric KK4KYE
> ___
> 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.5.0 GA Release

[Charles Suckling via wsjt-devel]

Hi Reino

It might be a good idea to direct folks here, to help formulate their
questions in sufficient detail:

https://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.5.2.html#_bug_reports

73

Charlie DL3WDG / G3WDG

On Tue, 7 Dec 2021 at 08:22, Reino Talarmo via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> >Why does "CQ DX" revert to simply CQ?
>
> Hi Ed,
>
> You need to provide a detailed description how you manage to get that
> happen.
>
> 73, Reino OH3mA
>
>
>
> ___
> 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] Bill Somerville, G4WJS, SK

[Charles Suckling via wsjt-devel]

 Joe

We were also shocked and very sorry to hear of Bill's sudden passing. I
never had the pleasure of meeting him in person.  Like Bob, he attended the
same University and read the same degree.

We are so grateful for his contributions over many years to WSJT-X. His
support for users was first class, and he even joined the EME reflectors to
give support to EME users during the roll-out of Q65, despite not being
active himself on EME.  He was contributing there regularly, and some of
his last efforts were to support the use of WSJT-X for Doppler control on
CW on the microwave bands.

He was also a very patient and diligent teacher, tutoring and helping
those who wished to make small contributions to the project. I am very
grateful for the time he spent in such ways.

Bill will surely be greatly missed, and sincere condolences to his family
and many friends.

RIP Bill.

Charlie G3WDG / DL3WDG

On Sat, 4 Dec 2021 at 22:27, Joe Taylor via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I am very sorry to convey the sad news that Bill Somerville, G4WJS, died
> suddenly and unexpectedly a few days ago.  He was only about 65 years old.
>
> Bill was a dear friend and very close colleague, though (as is often the
> case with worldwide ham radio friendships) we had met in person only a
> few times.  In 2013 he was the first to join me in forming a core
> development group for WSJT-X, which at that time was at program version
> 0.99.  Bill has been closely involved with WSJT-X and related software
> projects ever since.
>
> Our free, open-source software could not have achieved its extensive
> worldwide popularity and influence in ham radio without Bill's essential
> contributions.  In addition to writing code for important portions of
> the Qt-based user interface for WSJT-X, Bill helped to bring the overall
> program structure more nearly up to professional standards.  Moreover,
> he devoted countless hours to program support, patiently answering
> user's questions on WSJT-related forums.
>
> I have only started to think about the many ways in which I will miss
> Bill -- not no mention how we all will miss his immense and positive
> impact on WSJT-X and related projects.  For more than eight years Bill
> and I communicated closely and regularly on ham radio topics, sometimes
> many times per day.  Perhaps I will be able to write more about it in
> the near future.
>
> Rest in peace, dear friend G4WJS.
>
> -- Joe, K1JT
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug in 2.5.1?

[Charles Suckling via wsjt-devel]

Hi Lance

Yes, I understand.  But, I'm not sure there is a benefit in you keeping the
report the same for a previous caller if another QSO intervenes.

Consider the situation from the caller's perspective.  They start a QSO off
with you and get their first report.  If that does not decode, it will go
into their average accumulator.  If you then start working someone else,
then your non decoded signal will still go into their average accumulator,
with a different message content, thus 'corrupting' their accumulator.  If
you then go back to working them, the likelihood is that the report message
you sent them previously will essentially be lost.

Thus, I think sending them a different report later on would matter
little.  The best they could probably do is to manually clear their average
when they realise you are calling them again, to then be able to average
your then non-changing report.

The averaging routine places equal emphasis on the last 4 messages stored
when it comes to decoding the average accumulator.  Prior messages have
decreasing contribution. So eventually the averaging catches up with what
it happening at the time, so while helpful, manually clearing the average
is not essential.

73

Charlie DL3WDG



On Sun, 24 Oct 2021 at 01:33, Lance Collister, W7GJ 
wrote:

> Hi Charlie,
>
> I think the problem was operator fatigue - VY SRI! I did experience last
> night the same thing that you did.
>
> The problem I was encountering I guess was difficulty finding the exact
> same sequence to reply to again when I returned to calling a previous
> station, and wanted to maintain the same report in my reply so it would not
> upset their AVERAGE in trying to decode me. Normally of course, this is not
> a problem when you are running a sked with only one station.  However,
> during an EME DXpedition, when you are bouncing around from station to
> station, trying to see who is actually copying you at a given time, the
> AVERAGE screen on the right fills quickly with multiple calls from multiple
> callers, and it is really a challenge trying to find the correct previous
> sequence so your reply contains the report you originally sent to them.   I
> have been trying to keep track of the report sent to each station by hand
> so I can duplicate the same report, but find that it often takes me more
> than half a Q65-60A sequence to scroll up through all the decodes to find
> the original call. Actually, what often happens is that I pick the wrong
> decode to reply to and then have to manually adjust the report with the
> report wheel. Many times I only got it to the original sequence by the end
> of my transmission :-(  So when that happens, I guess I have ruined the
> chance of the other station building up an average of my replies.
>
> Maybe if there were an option to keep the signal report the same even if
> there are a number of intervening contacts or transmissions to other
> stations, I guess that is what I am trying to do by hand and failing
> miserably at... Do you understand my dilemma?
>
> MNI TNX and VY 73,  Lance
>
>
> On 10/23/2021 14:15, Charles Suckling wrote:
>
> Hi Lance
>
> I'm not seeing that here with 2.5.1.  I tested replying to a CQ call and
> clicking on an average decode (there were no single period decodes in my
> benchmark test files) it populates the messages correctly with the S/N of
> the decoded average message.
>
> 73
>
> Charlie
>
> On Sat, 23 Oct 2021 at 15:28, Lance Collister, W7GJ via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>> I finally was able to download 2.5.1, even though I am not using
>> compound callsign at the moment. One thing I noticed that seems to be
>> different is that when I click on a decode in the AVERAGE window to
>> reply, the program used to reply with the signal strength shown in the
>> decode. Now that doesn't happen anymore. So in order to make sure I
>> continue sending the same reply as I did previously, I have to refer to
>> my notes and then adjust the report dial to make the report match the
>> decode.
>>
>> I think it was better before...  TNX and VY 73, Lance
>>
>> --
>> Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX,
>> 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ,
>> S79GJ, FO/W7GJ, TX7MB)
>> P.O. Box 73
>> Frenchtown, MT   59834-0073
>> USA
>> TEL: (406) 626-5728
>> QTH: DN27ub
>> URL: http://www.bigskyspaces.com/w7gj
>> Skype: lanceW7GJ
>> 2m DXCC #11/6m DXCC #815
>>
>> Interested in 6m EME?  Ask me about subscribing to the Magic Band EME
>> email group, or just fill in the request box at the bottom of my web
>> page (above)!
>>
>>
>>
>> ___

Re: [wsjt-devel] Bug in 2.5.1?

[Charles Suckling via wsjt-devel]

Hi Lance

I'm not seeing that here with 2.5.1.  I tested replying to a CQ call and
clicking on an average decode (there were no single period decodes in my
benchmark test files) it populates the messages correctly with the S/N of
the decoded average message.

73

Charlie

On Sat, 23 Oct 2021 at 15:28, Lance Collister, W7GJ via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I finally was able to download 2.5.1, even though I am not using
> compound callsign at the moment. One thing I noticed that seems to be
> different is that when I click on a decode in the AVERAGE window to
> reply, the program used to reply with the signal strength shown in the
> decode. Now that doesn't happen anymore. So in order to make sure I
> continue sending the same reply as I did previously, I have to refer to
> my notes and then adjust the report dial to make the report match the
> decode.
>
> I think it was better before...  TNX and VY 73, Lance
>
> --
> Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX,
> 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ,
> S79GJ, FO/W7GJ, TX7MB)
> P.O. Box 73
> Frenchtown, MT   59834-0073
> USA
> TEL: (406) 626-5728
> QTH: DN27ub
> URL: http://www.bigskyspaces.com/w7gj
> Skype: lanceW7GJ
> 2m DXCC #11/6m DXCC #815
>
> Interested in 6m EME?  Ask me about subscribing to the Magic Band EME
> email group, or just fill in the request box at the bottom of my web
> page (above)!
>
>
>
> ___
> 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 for Q65 Astronomical Data table

[Charles Suckling via wsjt-devel]

Hi Lance

Its there already, labelled as Delay.

73

Charlie DL3WDG

On Tue, 19 Oct 2021 at 00:30, Lance Collister, W7GJ via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> As I am currently on an EME DXpedition without any access to internet or
> a reliable GPS puck that runs on Windows 10, it occurred to me that it
> should be very easy to add a very helpful item to the Astronomical Data
> table. If the correct DT were shown, I could make computer clock
> adjustments using W9MDB's TimeFudge ;-)  MNI TNX for your kind
> consideration!!  VY 73, Lance
>
> --
> Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX,
> 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ,
> S79GJ, FO/W7GJ, TX7MB)
> P.O. Box 73
> Frenchtown, MT   59834-0073
> USA
> TEL: (406) 626-5728
> QTH: DN27ub
> URL: http://www.bigskyspaces.com/w7gj
> Skype: lanceW7GJ
> 2m DXCC #11/6m DXCC #815
>
> Interested in 6m EME?  Ask me about subscribing to the Magic Band EME
> email group, or just fill in the request box at the bottom of my web
> page (above)!
>
>
>
> ___
> 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] Compound call behaviour Q65

[Charles Suckling via wsjt-devel]

Hi Conrad

I'm not sure there is any need to change the program with urgency.  If you
take the messages that are generatied automatically and don't manually
change them, then the RRR and 73 messages are transmitted with base calls
and the program recognises this and decodes the RRR and 73 with full AP ie
max decoding sensitivity.

73

Charlie DL3WDG

On Mon, 18 Oct 2021 at 18:09, Conrad PA5Y via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Thanks Bill, you can imagine for marginal QSOs such as this when Lance is
> expecting RRR it could be an issue, he is there right now. Any chance that
> this can be fixed as a matter of some urgency please
>
>
>
> 73
>
>
>
> Conrad PA5Y
>
>
>
> *From:* Bill Somerville via wsjt-devel 
> *Sent:* 18 October 2021 15:02
> *To:* wsjt-devel@lists.sourceforge.net
> *Cc:* Bill Somerville 
> *Subject:* Re: [wsjt-devel] Compound call behaviour Q65
>
>
>
> On 18/10/2021 11:09, Conrad PA5Y via wsjt-devel wrote:
>
> Hello team.
>
>
>
> Last night I was attempting to work FO/W7GJ on Q65-60A. My question is
> about the population of TX4 and TX5.
>
>
>
> When I Generate standard messages, I see TX1-3 are correct.
>
>
>
> TX1 PA5Y JO21
>
> TX2  PA5Y -27
>
> TX3  PA5Y R-27
>
>
>
> However, the compound call is omitted from TX4 and TX5
>
>
>
> TX4 W7GJ PA5Y RRR
>
> TX5 W7GJ PA5Y 73
>
>
>
> Is this expected behaviour? I can see that it does not affect the validity
> of a QSO as all the necessary information has already been passed. However,
> I noticed last night the following.
>
>
>
> 0307  -8  0.0  699 :  FO/W7GJ <...> RRR
>
>
>
> Obviously tropo but in this TX4 example the compound call appears to have
> been transmitted, whereas in my case above it is not.
>
>
>
> Regards
>
>
>
> Conrad PA5Y
>
> Hi Conrad,
>
> that appears to be a defect. Tx4 and Tx5 should be generated using hash
> codes rather than base callsigns. As you point out it is not too serious in
> this case as the full calls without hashing are exchanged earlier in the
> QSO. That is not the case with non-standard calls that are not compound so
> the issue needs repairing.
>
> 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] Release candidate: WSJT-X 2.4.0-rc2

[Charles Suckling]

Hi Claude

I just built it here. What differences do you see?

73

Charlie G3WDG/DL3WDG


On Sat, 6 Mar 2021 at 17:09, Claude Frantz 
wrote:

> On 3/6/21 9:06 AM, Claude Frantz wrote:
>
> Hi,
>
> > I cannot find the file
> > ./doc/user_guide/en/images/Q65_6m_ionoscatter.png
> > in the source code from the repo. It's needed to build the doc.
>
> For any reason unknown to me, the doc generated from
> ./doc/user_guide/en/ is different from the doc found here:
>
>
> https://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.4.0-rc2.html
>
> There is not only this image missing, there are other differences too.
>
> Anybody knows why ?
>
> Best wishes,
> Claude (DJ0OT)
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Q65 Multi-decode option...

[Charles Suckling]

Try unchecking 'Single Decode' in File | Settings | General

[image: image.png]
Charlie G3WDG


On Thu, 25 Feb 2021 at 16:58,  wrote:

> I have been unable to find how to envoke this option in Q65.
>
>
> BCNU DE N2LO~>___
> 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] What percentage of bits need to be decoded correctly?

[Charles Suckling]

Hi Jeff

Which mode are you asking about?

Charlie G3WDG

On Sat, 20 Feb 2021 at 14:44, jeff millar  wrote:

> Hello all,
>
> What percentage of bits are needed to produce a valid decode? I'm asking
> because sometimes I may start a transmit session some seconds late.
>
> Does it make a difference if the transmission is not started (Rx gets
> noise) vs started but changes message partway through?  Sometimes I may
> double click a call some seconds after a CQ is started.
>
> As an aside, I've noticed that my new very fast PC gets the decodes done
> much quicker and there is more time to view, think, and then select the
> transmit message.
>
> Not for the werid question...  If the signals are very strong, can I send
> RR73 for the first half of the message and the initial message for the next
> contact in the same cycle?  In other words, is it theoretically possible to
> work two stations at once?
>
> A variation on the last question, if signal are strong (BER is low) and
> the tx message changes halfway through, will the receiver decode both
> messages?
>
> jeff, wa1hco
>
> ___
> 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] Please save the T/R sequence lengths for each mode separately

[Charles Suckling]

Hi Neil

Judging by the activity reported today on the HB9Q EME logger, there is
lots of activity on Q65 already (432, 1296 and 10368). Stations are rapidly
learning to state the submode they are using, and increasingly their
TxFreq.  On 432 today,  folks were seeing for themselves the benefits of
AP, by experimenting with entries in the DX Call and Grid boxes.

73

Charlie G3WDG

On Tue, 16 Feb 2021 at 17:29, Neil Zampella  wrote:

> So .. ??
>
> It's like that for EVERY new mode, probably was like that for JT65 and
> its various permutations.  You have to setup Q65 at least once to
> get it up and running for the Q65 permutation you want to try.Saving
> that to a configuration takes a selection from a menu, typing a name,
> and saving.Using that setup to adjust for the other permutations
> starts with CLONING the original Q65 configuration and adjusting.
>
> Much less time and effort, and all your previous settings are saved in
> the original configuration. As far as 'very few use Q65', its still
> in beta and frankly is not a replacement for any of the FT modes, so
> fewer will use it currently.
>
> Neil, KN3ILZ
>
> On 2/16/2021 10:07 AM, Serge Szpilfogel wrote:
> > Very true Uwe I am on EME & if I go from JT65 to Q65 there is always an
> issue with configuration. So very few people use Q65 or if they do there is
> often an issue. Result they stay on JT65 & do not use Q65 which is a pity
> > 73,
> > Serge VE1KG
> >
> > -Original Message-
> > From: DG2YCB, Uwe 
> > Sent: Tuesday, February 16, 2021 15:51
> > To: 'WSJT software development' 
> > Subject: Re: [wsjt-devel] Please save the T/R sequence lengths for each
> mode separately
> >
> > Hasan, I’m sorry, but I totally disagree. Configurations are there to
> switch e.g. between 2 completely different hardware setups, but not between
> two modes (or bands). Come on! That is the most basic task of a multi-mode
> program itself.
> >
> > It is a pity that on this reflector EVERY suggestion for improvement is
> immediately discredited. Rather frustrating! That’s why the "clones" are
> more and more are growing in popularity ...
> >
> > The point is that in case of the new modes FST4, Q65, etc., a user
> cannot simply switch to the mode and get started (as it was with FT8, FT4,
> JT9, JT65, etc.) but first has to find out and put in the correct sub and
> sub-sub parameters, and has to do that every time he switches between these
> modes. No wonder that there are only VERY few users… (Here in EU the five
> or six stations using FST4 had QSOs with each other (or missed them because
> of sub-mode mismatch), and due to missing success they went back to FT8.)
> But all similar questions or comments from other users on that were also
> rejected. Sad story…
> >
> >
> >
> > 73 de Uwe, DG2YCB
> >
> >
> >
> > Von: Hasan N0AN [mailto:hbasri.schie...@gmail.com]
> > Gesendet: Dienstag, 16. Februar 2021 15:18
> > An: WSJT software development
> > Betreff: Re: [wsjt-devel] Please save the T/R sequence lengths for each
> mode separately
> >
> >
> >
> > It looks to me that's precisely why Configurations were created. Why
> reinvent the wheel?
> >
> >
> >
> > People should learn to use configurations and they can then customize
> their ops in any way they like.
> >
> >
> >
> > I have 12 configs, every mode has its own config. No mistakes, no
> forgetting, no mis-setting. ...and no code bloat.
> >
> >
> >
> > 73, N0AN
> >
> > Hasan
> >
> >
> >
> >
> >
> > On Tue, Feb 16, 2021 at 6:39 AM Bill Somerville   > wrote:
> >
> >   Uwe,
> >
> >
> >
> >   your description of your amendment sounds different from what you
> are asking for. If you have a version that switches to the T/R periods
> *you* use with certain modes, then that is fine for you but it is
> definitely not a general solution. if you have a general solution that you
> have tested for all modes and usage scenarios then why not contribute a
> patch?
> >
> >
> >
> >   73
> >   Bill
> >   G4WJS.
> >
> >
> >
> >   On 16/02/2021 12:27, DG2YCB, Uwe wrote:
> >
> >   Hi Bill,
> >
> >   Why are you not open to such a solution? Would certainly
> help to increase the extremely small number of FST4 users. It takes too
> long to switch configurations.
> >
> >   But: I've already found a solution for myself. In my
> wsjt-x_improved versions, I have now programmed it so that the mode buttons
> automatically switch on the most common sub-mode (FST4-A60 or Q65-A30).
> Only needed two additional lines in the source code ...
> >
> >   73 de Uwe, DG2YCB
> >
> >
> >
> >   Von: Bill Somerville [mailto:g4...@classdesign.com]
> >   Gesendet: Dienstag, 16. Februar 2021 11:39
> >   An: wsjt-devel@lists.sourceforge.net  wsjt-devel@lists.sourceforge.net>
> >   Betreff: Re: [wsjt-devel] Please save the T/R sequence
> lengths for each mode separately
> >
> >
> >
> > 

Re: [wsjt-devel] App name

[Charles Suckling]

looks same on Win 7

[image: image.png]

Charlie

On Tue, 5 Jan 2021 at 18:08, Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Yup...Winders 10on two different computers.
>
> [image: Inline image]
>
>
> Mike
>
>
>
>
> On Tuesday, January 5, 2021, 10:43:56 AM CST, Bill Somerville <
> g4...@classdesign.com> wrote:
>
>
> On 05/01/2021 16:36, Black Michael via wsjt-devel wrote:
>
> Windows is showing this for the app name.
>
> [image: Inline image]
>
>
> Mike W9MDB
>
> Hi Mike,
>
> that's not what was intended, is that installer or the installed
> application? Windows 10 I assume.
>
> 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] WSJT-X 2.2.0 rc2

[Charles Suckling]

Hi Allan

I see exactly the same as you with RS232 PTT.

I hadn't monitored the state of the Test PTT button.  As you observe,  if
this turns red during a receive period then the following transmission has
no audio.  If the button does not turn red during a receive period the
following transmission is OK.  Watched the behaviour for a number of
periods and this seems to be consistent.

73

Charlie G3WDG



On Tue, 26 May 2020 at 07:10, Allan VK4QG  wrote:

> Gentlemen,
>
> To start with, my system is a Dell 1650, i7 @3.40 GHz, 16GB RAM, W10 pro
> 64bit. I do not use CAT but instead use RTS on COM1 for opto-isolated PTT
> and XFR isolation for audio in and out of the sound-card, and have done so
> without issue since 2006.
>
> Two problems : -
>
> 1. I have found with rc2 that occasionally PTT is not working at all
> and when it does there is often no TX audio present either. While
> monitoring 'Radio' under 'Settings' I have noticed when this occurs, after
> a successful transmission about two seconds into the *RX* period the
> 'Test PTT' button turns red and from that point there is no PTT in the
> following TX period. After a time it appears to clear itself and PTT in the
> following period with or without TX audio.
>
> 2. I am still getting numerous false decodes. Most of these contain
> '/R' and '<.>'.   I am not using AP.
>
> Many thanks,
>
> 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

Re: [wsjt-devel] trouble keying PTT with com port RTS or DTS

[Charles Suckling]

Dave

A few of us have seen the same problem with this type of PTT control with
rc2.  Devel team are aware.

73

Charlie G3WDG

On Mon, 25 May 2020 at 17:43, David Tiller  wrote:

> FYI team, I also reported an issue with PTT with RC1 that does not seem to
> be solved in RC2. I believe the issue was the initialization of the cat
> state for rigs that cannot be queried.
>
> The command I was previously asked to run returns '0' each time, so it
> seems to be something else.
>
> dtiller$ ./Applications/wsjtx.app/Contents/MacOS/rigctl-wsjtx -p
> /dev/cu.usbserial-141201 -P RTS -v -Z t pause 1 t pause 1 t
> 2020-05-25:16:35:56.919181: rigctl, Hamlib 4.0~git May 23 2020 23:00:09
> 2020-05-25:16:35:56.919533: Report bugs to <
> hamlib-develo...@lists.sourceforge.net>
>
> 2020-05-25:16:35:56.919552: rig_init called
> 2020-05-25:16:35:56.919580: initrigs4_dummy: _init called
> 2020-05-25:16:35:56.919596: rig_register called
> 2020-05-25:16:35:56.919602: rig_register: rig_register (1)
> 2020-05-25:16:35:56.919614: rig_register called
> 2020-05-25:16:35:56.919620: rig_register: rig_register (2)
> 2020-05-25:16:35:56.919626: rig_register called
> 2020-05-25:16:35:56.919632: rig_register: rig_register (4)
> 2020-05-25:16:35:56.919638: rig_register called
> 2020-05-25:16:35:56.919676: rig_register: rig_register (5)
> 2020-05-25:16:35:56.919717: dummy_init called
> 2020-05-25:16:35:56.919749: rig_passband_normal called
> 2020-05-25:16:35:56.919757: rig_passband_normal called
> 2020-05-25:16:35:56.919774: rig_open called
> 2020-05-25:16:35:56.919794: port_open called
> 2020-05-25:16:35:56.919802: ser_open called
> 2020-05-25:16:35:56.922284: ser_set_dtr called
> 2020-05-25:16:35:56.922296: ser_set_dtr: DTR=0
> 2020-05-25:16:35:56.922332: ser_set_rts called
> 2020-05-25:16:35:56.922339: ser_set_rts: RTS=0
> 2020-05-25:16:35:56.922354: ser_close called
> 2020-05-25:16:35:56.922360: ser_close: no options for fd to restore
> 2020-05-25:16:35:56.923688: dummy_open called
> 2020-05-25:16:35:56.948756: rig_get_vfo called
> 2020-05-25:16:35:56.948788: elapsed_ms: start = 0,0
> 2020-05-25:16:35:56.948812: rig_get_vfo: cache check age=100ms
> 2020-05-25:16:35:56.948821: rig_get_vfo: cache miss age=100ms
> 2020-05-25:16:35:56.968886: dummy_get_vfo called: VFOA
> 2020-05-25:16:35:56.968917: elapsed_ms: start = 0,0
> 2020-05-25:16:35:56.968930: elapsed_ms: after gettime, start =
> 1590424556,968927000
> 2020-05-25:16:35:56.968953: rig_set_parm called
> 2020-05-25:16:35:56.968964: rig_has_set_parm called
> 2020-05-25:16:35:56.968980: rig_setting2idx called
> 2020-05-25:16:35:56.968992: rig_strparm called
> 2020-05-25:16:35:56.969009: rig_strparm called
> 2020-05-25:16:35:56.969018: dummy_set_parm called: SCREENSAVER 0
> Opened rig model 1, 'Dummy'
> 2020-05-25:16:35:56.969152: Backend version: 20200503.0, Status: Stable
> 2020-05-25:16:35:56.969176: rigctl_parse: called, interactive=0
> 2020-05-25:16:35:56.969204: rigctl_parse: debug1
> 2020-05-25:16:35:56.969217: rigctl_parse: debug5
> 2020-05-25:16:35:56.969228: rigctl_parse: debug10
> 2020-05-25:16:35:56.969244: rigctl_parse: vfo_mode=0
> 2020-05-25:16:35:56.969266: rig_get_ptt called
> 2020-05-25:16:35:56.969320: elapsed_ms: start = 0,0
> 2020-05-25:16:35:56.969339: rig_get_ptt: cache check age=100ms
> 2020-05-25:16:35:56.969357: rig_get_ptt: cache miss age=100ms
> 2020-05-25:16:35:56.991473: dummy_get_ptt called
> 2020-05-25:16:35:56.991570: elapsed_ms: start = 0,0
> 2020-05-25:16:35:56.991630: elapsed_ms: after gettime, start =
> 1590424556,991627000
> 0
> 2020-05-25:16:35:56.991650: rigctl_parse: retcode=0
> 2020-05-25:16:35:56.991668: rigctl_parse: called, interactive=0
> 2020-05-25:16:35:56.991723: rigctl_parse: debug1
> 2020-05-25:16:35:56.991738: rigctl_parse: debug3
> 2020-05-25:16:35:56.991754: rigctl_parse: debug5
> 2020-05-25:16:35:56.991775: rigctl_parse: debug10
> 2020-05-25:16:35:56.991785: rigctl_parse: vfo_mode=0
> 2020-05-25:16:35:57.996817: rigctl_parse: retcode=0
> 2020-05-25:16:35:57.996849: rigctl_parse: called, interactive=0
> 2020-05-25:16:35:57.996856: rigctl_parse: debug1
> 2020-05-25:16:35:57.996861: rigctl_parse: debug5
> 2020-05-25:16:35:57.996866: rigctl_parse: debug10
> 2020-05-25:16:35:57.996871: rigctl_parse: vfo_mode=0
> 2020-05-25:16:35:57.996878: rig_get_ptt called
> 2020-05-25:16:35:57.996884: elapsed_ms: start = 1590424556,991627000
> 2020-05-25:16:35:57.996893: elapsed_ms: elapsed_secs=1005.26
> 2020-05-25:16:35:57.996900: rig_get_ptt: cache check age=1005ms
> 2020-05-25:16:35:57.996905: rig_get_ptt: cache miss age=1005ms
> 2020-05-25:16:35:58.016952: dummy_get_ptt called
> 2020-05-25:16:35:58.016982: elapsed_ms: start = 0,0
> 2020-05-25:16:35:58.016992: elapsed_ms: after gettime, start =
> 1590424558,1699
> 0
> 2020-05-25:16:35:58.017007: rigctl_parse: retcode=0
> 2020-05-25:16:35:58.017016: rigctl_parse: called, interactive=0
> 2020-05-25:16:35:58.017027: rigctl_parse: debug1
> 2020-05-25:16:35:58.017036: 

[wsjt-devel] What happens when Hound does not receive RR73?

[Charles Suckling]

Hi All

 

20m conditions were a bit better today and I finally managed to work Baker
with 100W, lots of feeder loss and a sloping dipole.

 

The problem I had was, after receiving my report from KH7Z, I failed to
receive RR73.  Thanks to Bill's advice to start over again (TX1 message), on
the 4th QSO attempt (this time with G4KGC in the shack)  I finally got my
RR73.  Within about 5 sequences they came back again with a report again,
and QSO attempts proceeded normally.

 

Decoding was reasonably reliable at the time.  It seems  they did not
receive my TX3 message, hence did not send RR73, rather than me not decoding
the RR73.

 

What became apparent was that under these circumstances my TX freq was
shifted three times, then stuck on the final frequency and transmissions
would have continued at infinitum:

 

I guess this is what is expected as the User guide para 14 says:

 



 

Here is an example of one of the failed attempts:

 

083545 Tx 3056 ~ KH7Z G3WDG IO92 

083630 -13 -0.5 390 ~ G3WDG KH7Z -15

083645 Tx 390 ~ KH7Z G3WDG R-13 

083700 -16 -0.6 389 ~ G3WDG KH7Z -15

083715 Tx 389 ~ KH7Z G3WDG R-16 

083730 -14 -0.6 330 ~ G3WDG KH7Z -15

083745 Tx 330 ~ KH7Z G3WDG R-14 

083815 Tx 630 ~ KH7Z G3WDG R-14 

083845 Tx 630 ~ KH7Z G3WDG R-14 

083915 Tx 630 ~ KH7Z G3WDG R-14 

083945 Tx 630 ~ KH7Z G3WDG R-14 

084015 Tx 630 ~ KH7Z G3WDG R-14 

084045 Tx 630 ~ KH7Z G3WDG R-14

 

After moving to 630 it stayed there and continued transmitting until I
intervened, thinking that the QSO had failed and I was unnecessarily causing
QRM.

 

Should I have waited longer for Fox to respond?

 

In the situation where hounds to not receive their  RR73,  presumably  a
wall of QRM below 1000 develops for Fox making it more difficult for QSOs to
complete?  I saw other stations in the same fix as I was, repeating their
TX3 messages for many periods.

 

73

 

Charlie

 

 

 



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Observation on Expedition Mode

[Charles Suckling]

Hi Mike

 

I think this is worth considering. 

 

Or maybe a warning message like 'Do you *really* want to call when you have
not yet decoded the fox?' 

 

Charlie

 

  _  

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]

Sent: 30 June 2018 20:21
To: wsjt-devel@lists.sourceforge.net
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode

 

I'll modify the idea to recognize ANY call from the DXpedition (i.e. the
call in the DX Call box).

Surely you'd have to agree that you should see them once before
calling...either CQ or answering somebody else.  And the software should
enforce it.

 

de Mike W9MDB

 

 

 

 

On Saturday, June 30, 2018, 1:26:42 PM CDT, John L. Broughton
<2silverhon...@gmail.com> wrote: 

 

 

I can't say I agree with Mike that one should have to answer a CQ to work
the DXpedition station.

I worked KH7Z on 17M this past Thursday. However, in the time I was on the
frequency, I did not decode any CQ. KH7Z was working stations the entire
time I was on frequency. I simply kept an eye on his signal strength which
was varying from about -22 to -15. I set my transmit frequency at 3343 and
started calling. It didn't take very long, just several minutes, before he
called me and we completed the QSO. My report to him was -22 and his to me
was -06 (I'm running a hy-gain DX-88 vertical with my IC-7300; hardly a DX
big gun.) If I would have had to answer a CQ in order to work him, I could
not have gotten the QSO due to the short time I had to try to make  it and
with him just working station after station, not needing to call CQ.

I was watching the stations he was calling to make sure they weren't, say,
all in Europe, as I did not know if he had called CQ for any particular
region. As most all the stations he was working were in the US, I had no
hesitation about calling him.

As far as finding where KH7Z is operating, I've just been using the HB9DRV-9
DX Cluster spots option in m HRD logbook program (I don't run the main HRD
program.) or just selecting various bands in the right hand window of it to
see if and where he is operating then, if on SSB or FT8, I go to the
frequency to see if he is strong enough to work.

John, WB9VGJ

John L. Broughton
www.wb9vgj.us
wb9...@arrl.net
2silverhon...@gmail.com

On 6/30/2018 7:14 AM, Black Michael via wsjt-devel wrote:

I have some observations too.

 

#1 Tons of ops calling KH7Z when they can't see them.  I assume this only
causes problems as it's quite possible KH7Z with their honker antennas and
can see them but not the other way round.  So KH7Z will put them in the
queue and try to process them taking up the limited slots they are using
right now (2 from what I've seen).  IMHO the solution to this is pretty
simplewhen you turn on Hound or switch bands you should be PREVENTED
FROM TRANSMITTING UNTIL YOU GET CQ FRO THE DX STATION.So, you would be
required to double-click on a CQ to allow transmitting.  I noticed the the
Baker team gave a lukewarm endorsement of FT8 on their news update quite
likely due to this problem.

 

#2 We need to turn on spotting for the DX station so that PSKReporter and
Hamspots can work and also so JTAlert can produce alerts when the DX station
is received.  Don't need to spot the hounds of course.  Trying to figure out
what band is good for local ops would be much improved with automatic
spotting for us and for the DX team who could then see where their signal is
going as more teams use internet on site via satellite links.

 

de Mike W9MDB

 

 

 

 

 

On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis
  wrote: 

 

 

Joe,

 

An observation if I may about expedition mode. I see with KH1/KH7Z that the
number of Fox TX channels varies - I presume as they place more stations in
the queue. As expected, the power per channel drops the more channels
running so that the amplifiers can keep up. However, this has an unintended
consequence perhaps of potentially breaking QSOs. A few times now I have
started calling KH1/KH7Z on 20m when I am receiving them around -09 (but
with pretty low S-meter  signal strength). Usually this is with 1-2 channels
running on their downlink. If they go to 3 channels I can still receive but
it falls to say -15. If they bring up channel 4 and 5 I loose them. There
just isn't the link budget left to receive them when the power is split
between more than 3 channels in this example.

 

Now the issue is, if they answer me by adding the 4th channel - I wont hear
them under those conditions. If I am part way through a QSO I can loose the
RR73 for the same reason if they answer someone else on the 4th channel-
simply because the link runs out of steam.

 

Now if I couldn't hear them in the first place I wouldn't have tried
calling. In this case however, they can disappear under load effectively and
I loose them mid QSO.

 

For future consideration perhaps is to have the setting of number of
channels vs 

Re: [wsjt-devel] Observation on Expedition Mode

[Charles Suckling]

Neil

 

Thanks - that's very helpful.  

 

I didn't waste much time calling!

 

The other clue was that it was at a time when the propagation predictions
were blank. 

 

Charlie

 

  _  

From: Neil Zampella [mailto:ne...@techie.com] 
Sent: 30 June 2018 17:21
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Observation on Expedition Mode

 

Charlie,

the consensus of many on the FB pages is that this station was a pirate.

Neil, KN3ILZ

 

On 6/30/2018 11:09 AM, Charles Suckling wrote:

Hi Mike

 

The problem with needing to see a CQ is that the dxpedition may rarely
transmit a CQ (some folks were reporting this yesterday).  Then, stations
were working them by just calling.  Majority were on the correct period,
most were above 1000Hz.  From what I could see here about 90% of hounds were
calling correctly.  Whether they could hear the dxpedition is another
matter.

 

Earlier this afternoon there was a run of CQ from them (or someone
pretending to be them) about 10dB stronger than they are here most of the
time (-18 to -20).  During this spell there seemed to be no QSOs.

 

Charlie


  _  


From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]

Sent: 30 June 2018 15:15
To: 'WSJT software development'
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode

 

I have some observations too.

 

#1 Tons of ops calling KH7Z when they can't see them.  I assume this only
causes problems as it's quite possible KH7Z with their honker antennas and
can see them but not the other way round.  So KH7Z will put them in the
queue and try to process them taking up the limited slots they are using
right now (2 from what I've seen).  IMHO the solution to this is pretty
simplewhen you turn on Hound or switch bands you should be PREVENTED
FROM TRANSMITTING UNTIL YOU GET CQ FRO THE DX STATION.So, you would be
required to double-click on a CQ to allow transmitting.  I noticed the the
Baker team gave a lukewarm endorsement of FT8 on their news update quite
likely due to this problem.

 

#2 We need to turn on spotting for the DX station so that PSKReporter and
Hamspots can work and also so JTAlert can produce alerts when the DX station
is received.  Don't need to spot the hounds of course.  Trying to figure out
what band is good for local ops would be much improved with automatic
spotting for us and for the DX team who could then see where their signal is
going as more teams use internet on site via satellite links.

 

de Mike W9MDB

 

 

 

 

 

On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis
<mailto:vk...@bigpond.com>  wrote: 

 

 

Joe,

 

An observation if I may about expedition mode. I see with KH1/KH7Z that the
number of Fox TX channels varies - I presume as they place more stations in
the queue. As expected, the power per channel drops the more channels
running so that the amplifiers can keep up. However, this has an unintended
consequence perhaps of potentially breaking QSOs. A few times now I have
started calling KH1/KH7Z on 20m when I am receiving them around -09 (but
with pretty low S-meter  signal strength). Usually this is with 1-2 channels
running on their downlink. If they go to 3 channels I can still receive but
it falls to say -15. If they bring up channel 4 and 5 I loose them. There
just isn't the link budget left to receive them when the power is split
between more than 3 channels in this example.

 

Now the issue is, if they answer me by adding the 4th channel - I wont hear
them under those conditions. If I am part way through a QSO I can loose the
RR73 for the same reason if they answer someone else on the 4th channel-
simply because the link runs out of steam.

 

Now if I couldn't hear them in the first place I wouldn't have tried
calling. In this case however, they can disappear under load effectively and
I loose them mid QSO.

 

For future consideration perhaps is to have the setting of number of
channels vs the number of active channels maintain a constant PER CHANNEL TX
power rather than the variable situation we have now. Ie I enable my fox
station to run say 4 channels, but only reply on 1 channel, then the output
power should be the equivalent of the power that would be in that channel if
all 4 were in fact on air but aren't. At least that way I have a constant
link budget I am working with on my comms channel with the fox station
rather than one that can have them drastically cut power mid QSO without
reference to the conditions on the path I am working them via.

 

If what I am describing is not how it is supposed to work already then there
is another factor at work somewhere in the chain to be explored. I would be
happy to discuss this further and use the KH1/KH7Z expedition to observe and
learn more about how the multi-channel nature of the mode works.

 

Regards,

Grant VK5GR

 


--
Check out the vibrant tech com

Re: [wsjt-devel] Observation on Expedition Mode

[Charles Suckling]

Hi Mike

 

The problem with needing to see a CQ is that the dxpedition may rarely
transmit a CQ (some folks were reporting this yesterday).  Then, stations
were working them by just calling.  Majority were on the correct period,
most were above 1000Hz.  From what I could see here about 90% of hounds were
calling correctly.  Whether they could hear the dxpedition is another
matter.

 

Earlier this afternoon there was a run of CQ from them (or someone
pretending to be them) about 10dB stronger than they are here most of the
time (-18 to -20).  During this spell there seemed to be no QSOs.

 

Charlie

  _  

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]

Sent: 30 June 2018 15:15
To: 'WSJT software development'
Cc: Black Michael
Subject: Re: [wsjt-devel] Observation on Expedition Mode

 

I have some observations too.

 

#1 Tons of ops calling KH7Z when they can't see them.  I assume this only
causes problems as it's quite possible KH7Z with their honker antennas and
can see them but not the other way round.  So KH7Z will put them in the
queue and try to process them taking up the limited slots they are using
right now (2 from what I've seen).  IMHO the solution to this is pretty
simplewhen you turn on Hound or switch bands you should be PREVENTED
FROM TRANSMITTING UNTIL YOU GET CQ FRO THE DX STATION.So, you would be
required to double-click on a CQ to allow transmitting.  I noticed the the
Baker team gave a lukewarm endorsement of FT8 on their news update quite
likely due to this problem.

 

#2 We need to turn on spotting for the DX station so that PSKReporter and
Hamspots can work and also so JTAlert can produce alerts when the DX station
is received.  Don't need to spot the hounds of course.  Trying to figure out
what band is good for local ops would be much improved with automatic
spotting for us and for the DX team who could then see where their signal is
going as more teams use internet on site via satellite links.

 

de Mike W9MDB

 

 

 

 

 

On Saturday, June 30, 2018, 8:13:39 AM CDT, Grant Willis 
wrote: 

 

 

Joe,

 

An observation if I may about expedition mode. I see with KH1/KH7Z that the
number of Fox TX channels varies - I presume as they place more stations in
the queue. As expected, the power per channel drops the more channels
running so that the amplifiers can keep up. However, this has an unintended
consequence perhaps of potentially breaking QSOs. A few times now I have
started calling KH1/KH7Z on 20m when I am receiving them around -09 (but
with pretty low S-meter  signal strength). Usually this is with 1-2 channels
running on their downlink. If they go to 3 channels I can still receive but
it falls to say -15. If they bring up channel 4 and 5 I loose them. There
just isn't the link budget left to receive them when the power is split
between more than 3 channels in this example.

 

Now the issue is, if they answer me by adding the 4th channel - I wont hear
them under those conditions. If I am part way through a QSO I can loose the
RR73 for the same reason if they answer someone else on the 4th channel-
simply because the link runs out of steam.

 

Now if I couldn't hear them in the first place I wouldn't have tried
calling. In this case however, they can disappear under load effectively and
I loose them mid QSO.

 

For future consideration perhaps is to have the setting of number of
channels vs the number of active channels maintain a constant PER CHANNEL TX
power rather than the variable situation we have now. Ie I enable my fox
station to run say 4 channels, but only reply on 1 channel, then the output
power should be the equivalent of the power that would be in that channel if
all 4 were in fact on air but aren't. At least that way I have a constant
link budget I am working with on my comms channel with the fox station
rather than one that can have them drastically cut power mid QSO without
reference to the conditions on the path I am working them via.

 

If what I am describing is not how it is supposed to work already then there
is another factor at work somewhere in the chain to be explored. I would be
happy to discuss this further and use the KH1/KH7Z expedition to observe and
learn more about how the multi-channel nature of the mode works.

 

Regards,

Grant VK5GR

 


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



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 

Re: [wsjt-devel] Transmitting at the wrong time in Hound mode

[Charles Suckling]

Hi Mike

 

Yes, clicking a Hound message caused  the greyed out box to get checked, and
it then tried to call the other Hound:

 

 



 

I saw one or two examples of Hounds calling other Hounds yesterday - this
perhaps explains how it happens.

 

Charlie

 

 

 

  _  

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]

Sent: 30 June 2018 05:08
To: WSJT software development
Cc: Black Michael
Subject: Re: [wsjt-devel] Transmitting at the wrong time in Hound mode

 

Double-click one of the Hound messages.

 

Perhaps the logic should force Tx even/1st based on Fox/Hound mode for those
modes and not the message time.

 

de Mike W9MDB

 

 

 

On Friday, June 29, 2018, 9:16:26 PM CDT, Joe Taylor 
wrote: 

 

 

On 6/29/2018 8:26 PM, David Fisher wrote:
> I have the "ALL LOG" excerpt of this if you want to see it.  You'll have 
> to take my word on the rest.
> 
> The code version is 1.9.0-rc4 R8642.  I built it from source a while back.

Version 1.9.0-rc4 was a program version made available for short-term 
beta testing.  It is NOT a general availability (GA) release of WSJt-X. 
None of our  "-rc#" releases are suitable for long-term use.

You should upgrade to the GA release on the WSJT Home Page, Version 1.9.1.

As I have written elsewhere: When you're in Hound mode, the *Tx 
even/1st* box (grayed out) must NOT be checked.  It's supposed to be 
impossible for this to happen, but several people have claimed that it 
can.  If you find the box is checked: exit Hound mode, clear the
box, then re-enter Hound mode.

And this is important: if you can figure out how to cause *Tx even/1st* 
to be checked while in Hound mode, please send me an exact series of 
steps that will do so.

-- 73, Joe, K1JT




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

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

[wsjt-devel] sub process failed with exit code 2 message

[Charles Suckling]

Hi All

 

I have just seen this message appear.  Closed/restarted program and it
reappeared after a short time.

 

System was previously working with no issues, so settings changed since.

 

Text from window states:

 

 

Running: C:\WSJT\wsjtx8732\bin\jt9 -s "WSJT-X - jt65" -w 1 -m 1 -e
C:\WSJT\wsjtx8732\bin -a "C:\Users\user\AppData\Local\WSJT-X - jt65" -t
"C:\Users\user\AppData\Local\Temp\WSJT-X - jt65"

At line 40 of file C:\JTSDK\src\wsjtx\trunk\lib\xcor4.f90

Fortran runtime error: Index '0' of dimension 1 of array 'nch' below lower
bound of 1

 

Operating system Vista 32.  Currently set to JT4, VHF enabled etc.

 

73

 

Charlie

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

Re: [wsjt-devel] Feature request: WSJT-X

[Charles Suckling]

Hi Peter

 

Re Bill's comment about not needing Settings menu during normal operation, I
just had an instance of needing to do just that.

 

 I was monitoring a weak station on 1296 EME working someone else, and
wanted to change MyCall temporarily to that of the station the weak station
was working to see if I could decode them (with AP or DS).  Accessing
Settings, changing MyCall and then back to monitoring and freq had jumped to
first default in frequency table, needing the sked frequency to be entered
again.

 

73

 

Charlie

 

  _  

From: Peter Sumner [mailto:vk8...@gmail.com] 
Sent: 16 March 2018 20:54
To: WSJT software development
Subject: Re: [wsjt-devel] Feature request: WSJT-X

 

Hello Bill,

  for a lot of my EME contacts on 50 MHz I had been using WSJT10, which
cannot do PTT via CAT so have changed over to use WSJT-X for these contacts
now as I have recently moved the IC-7600 to use only the onboard USB
interface in the radio to reduce the complexity of the shack PC as it had
three sound cards on it and multiple serial devices.  I am still trying to
find a good combination of settings to get the same decode rates as WSJT10
gave me on 50 MHz EME signals so at present there is a bit of fiddling going
on.

 

In the last few days have been running tests with Rex VK7MO on QRA64 on 144,
he has a birdie on the standard QRA64 freq so we have moved up a bit, in a
similar way I have been experimenting with configurations to seek the best
decodes from WSJT-X and again come across the behavior of being QSY'd back
to the standard frequency mid experiment.

 

It would seem my difficulty is not very common so maybe I should just stop
fiddling : -)

 

Regards,

Peter, vk5pj

 

On Sat, Mar 17, 2018 at 7:08 AM, Bill Somerville 
wrote:

On 16/03/2018 20:29, Peter Sumner wrote:

eg. on WSPR, 144.489 if I type into the box as you suggested (not tried that
before I must admit), my test frequency was 144.085 which moved the rig all
okay, then if I open the settings menu and close I am now set back to be on
144.489. This is the behaviour I would like to be able to temporarily
supress but still be able to use PTT via CAT.

Hi Peter,

can you explain why you need to open the settings menu mid-QSO please? This
seems to be the root of the issue you are describing.

73
Bill
G4WJS.



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

lists/listinfo/wsjt-devel

 

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

Re: [wsjt-devel] DXpedition mode: dissapointed somehow

[Charles Suckling]

Jim

 

I don't think the test was on the designated FT8 frequency for 40m, or am I
mistaken?

 

In which case I thought "private" tests were OK provided they don't QRM
users of other modes?

 

The answer to why the station is only transmitting to one station at a time
is because Nslots would have been set to 1, I think.

 

73

 

Charlie G3WDG

 

  _  

From: James Shaver (N2ADV) [mailto:n2...@windstream.net] 
Sent: 14 March 2018 10:25
To: WSJT software development
Subject: Re: [wsjt-devel] DXpedition mode: dissapointed somehow

 

TY7C should not have even been using DXPedition Mode. 

 

Jim S. 

N2ADV. 


On Mar 14, 2018, at 5:15 AM, DG2YCB, Uwe  wrote:

Hi,

Today I've had my first real-life experience with the new DXpedition mode.
TY7C was the fox, the frequency was 7.070 MHz. The station came in with a
rather stable signal around -12dB, and most stations (with exception of one
Italian and one Romanian and a few others.) were following the instructions
for DXpedition mode.

However, I was somehow disappointed: 

- Although about five to ten hounds were calling TY7C simultaneously (in the
correct range 1000 - 4000 Hz), in most cases TY7C sent his reply only to one
station each. Means that number of QSOs per minute was nearly the same as in
normal mode. As sometimes up to four stations occurred in the rage 300 - 900
Hz, there must have been more than one QSO in the queue. Why did that
happen?

- Fox disappeared and reappeared suddenly without any notice, leaving many
stations alone who were then finally trying to call Fox in his rage. I don't
know whether there were some troubles with power supply, but all in all it
was quite unsatisfactory.

I don't know either what might be improved. However, I wanted to share this
experience with you. For the purpose of further analysis: here is traffic in
Fox's range (two times I activated Rx All Freqs):

 40m

064730 -10 -0.1 298 ~ F6GCP TY7C RR73

 40m

064830 -10 -0.1 298 ~ IK8DNJ TY7C +13

 40m

064900 -12 -0.1 298 ~ IK8DNJ TY7C +13

 40m

064930 -11 -0.5 298 ~ IK8DNJ TY7C RR73

 40m

065000 -11 -0.1 298 ~ IK8DNJ TY7C RR73

 40m

065030 -8 -0.1 297 ~ CQ TY7C JJ16  ~Benin

 40m

065100 -10 -0.1 298 ~ CQ TY7C JJ16  ~Benin

 40m

065130 -11 -0.1 297 ~ CQ TY7C JJ16  ~Benin

 40m

065200 -9 -0.1 297 ~ CQ TY7C JJ16  ~Benin

 40m

065230 -10 -0.1 297 ~ CQ TY7C JJ16  ~Benin

 40m

065345 5 0.2 419 ~ TY7C F8BUO -04

065345 2 0.2 500 ~ TY7C ZL1AIX -06

065345 -6 -0.8 588 ~ TY7C DL5MFS -09

065345 7 0.1 1838 ~ TY7C F8DZU R-17

 40m

065415 5 0.2 419 ~ TY7C F8BUO -04

065415 0 0.2 500 ~ TY7C ZL1AIX -06

065415 -8 -0.8 688 ~ TY7C DL5MFS JN58

065415 -16 0.1 995 ~ TY7C KU4XO EM84

065415 9 0.1 1838 ~ TY7C F8DZU R-17

 40m

065430 -3 -0.2 298 ~ N6ML TY7C +05

 40m

065500 -11 -0.2 297 ~ N6ML RR73; ON6SM  +03

 40m

065530 -11 -0.3 297 ~ ON6SM TY7C +03

 40m

065600 -10 -0.2 297 ~ ON6SM TY7C +03

 40m

065630 -8 -0.2 298 ~ ON6SM TY7C +03

 40m

065645 -4 0.2 500 ~ TY7C ZL1AIX -06

065645 -7 -0.8 687 ~ TY7C DL5MFS -08

065645 -18 0.1 995 ~ TY7C KU4XO EM84

 40m

065700 -8 -0.2 297 ~ ON6SM TY7C +03

 40m

065730 -11 -0.2 297 ~ F6EQZ TY7C -01

 40m

065800 -12 -0.2 297 ~ F6EQZ RR73; DG2YCB  -17

 40m

065830 -9 -0.2 297 ~ DG2YCB TY7C -17

 40m

065900 -10 -0.2 297 ~ DG2YCB TY7C -17

 40m

065930 -13 -0.1 297 ~ DG2YCB RR73; F8DZU  -10

 40m

065945 5 -0.0 557 ~ CQ IZ1BII JN44  ~Italy

065945 -20 0.1 995 ~ TY7C KU4XO EM84

 40m

07 -16 -0.2 298 ~ DG2YCB RR73; ON6SM  -04

 40m

070030 -13 -0.2 298 ~ F8DZU TY7C -10

 40m

070100 -15 -0.2 298 ~ ON6SM TY7C -04

 40m

070115 -10 0.3 501 ~ TY7C ZL1AIX -06

070115 -10 -0.7 592 ~ TY7C DL5MFS -08

070115 -24 0.1 997 ~ TY7C KU4XO EM84

 40m

070130 -15 -0.2 297 ~ F8DZU TY7C -10

 40m

070145 4 -0.0 467 ~ CQ IZ1BII JN44  ~Italy

070145 -19 -0.7 592 ~ TY7C DL5MFS -08

 40m

070200 -14 

Re: [wsjt-devel] Inconsistent JT65b reporting

[Charles Suckling]

Hi Steve

 

I made a mistake with the title slide on the report (now corrected).

 

I was in fact using the latest version of WSJT-X (r8394).  

 

Sri for the confusion!

 

73

 

Charlie

 

  _  

From: Steven Franke [mailto:s.j.fra...@icloud.com] 
Sent: 03 January 2018 19:36
To: WSJT software development
Subject: Re: [wsjt-devel] Inconsistent JT65b reporting

 

Hi Charlie,

 

Thanks for the report!

 

It seems clear that WSJT has a negative SNR bias across the board. The
version of WSJT-X (r8345) that you used has a smaller bias. If you get a
chance to test r8389 or later, I'd be interested to hear whether the tweaked
SNR calculation improves matters in WSJT-X. 

 

I found your SNR=-22 dB case to be interesting. WSJT-X was able to decode 8
of the 10 files just using the standard soft-symbol Franke-Taylor decoder.
The remaining two files were decoded using AP decoding. The correlation
decoder (deep search) was never invoked. On the other hand, only 1 out of 10
files was decoded by WSJT using the soft-symbol decoder. The remaining 9
required deep search. This large difference suggests that if you leave Deep
Search and AP decoding out of the picture, and consider just basic
soft-symbol decoding, WSJT-X probably has a lower (better) decoding
threshold - at least for the parameters that you tested.

 

Steve k9an

 

 

On Jan 3, 2018, at 12:43 PM, Charles Suckling
<char...@sucklingfamily.free-online.co.uk> wrote:

 

Hi Steve, Bill and Joe

 

I've done some more simulation work with the new jt65sim.

 

Results are here:

 

 
<https://drive.google.com/file/d/1qeTkWiHaNafMqYKlAHW8NaRNGYk1BCn0/view?usp=
sharing>
https://drive.google.com/file/d/1qeTkWiHaNafMqYKlAHW8NaRNGYk1BCn0/view?usp=s
haring

 

73

 

Charlie

 

-Original Message-
From: Steven Franke [mailto:s.j.fra...@icloud.com] 
Sent: 02 January 2018 14:50
To: WSJT software development
Subject: Re: [wsjt-devel] Inconsistent JT65b reporting

 

Hi Charlie,  Bill, and all,

 

> I also tried 40Hz spreading at -23 with 11025 with WSJT-X and found AP and

> no DS did not decode anything, whereas it gets 2/10 with 12000 sample

> rate.  It does OK however  with DS with these -23/40Hz 11025 signals. 

> Perhaps the resampling on very marginal signals like this is responsible?

 

I think that you need to look at a larger sample to decide whether or not
the decode probability is different between the two sample rates. 

 

I used the following to generate 100 JT65C files at SNR=-23 dB with 40 Hz
Doppler spread, at sample rate 12000 /s:

 

./jt65sim -d 40.0 -m C -n 1 -F 1200.0 -t 2.5 -f 100 -s \\-23 -G 10 -M "K9AN
G3WDG RRR"

 

With AP decoding enabled, G3WDG in the Dx Call box, and Tx5 selected, I got
34/100 decodes. All decodes were AP decodes with aptype=3 or 4. Deep Search
was not enabled.

 

Then, I repeated the experiment with -S added to the command line so that
the files were generated with 11025 /s rate. When WSJT-X detects a wav file
with 11025/s rate, it calls Joe's wav12.f90 resampler to resample the data
to 12000/s. In this case I got 38/100 decodes. 

 

It's worth noting that we expect the number of good decodes to have a
binomial distribution. The standard deviation of the binomial distribution
is sigma = sqrt( n*p*(1-p) ) where n is the sample size and p is the decode
probability. My results with 100 simulated wav files suggest that the decode
probability for the case that we are considering is somewhere in the
neighborhood of 0.36. With a sample size of 100, and p=0.36, the standard
deviation of the binomial distribution is sqrt(100*0.36(1-0.36))=4.8. 

 

Thus, the difference between my results with sample rate 12000 (34/100
decodes) and sample rate 11025 (38/100) is not statistically significant,
i.e. the observed differences are of the same order as the differences that
we'd expect if we just processed two different groups of files, with the
same underlying decode probability for each group. 

 

In summary, there is no evidence (so far) that resampling in WSJT-X causes
any degradation in decoding performance. It would take many more trials
(>1000) to be able to detect any differences in WSJT-X's decode probability
at the two sample rates. Of course, this experiment does *not* address what
happens when the operating system does the resampling, as would be the case
when processing audio data in real time.

 

Steve k9an

 

 


--

Check out the vibrant tech community on one of the world's most

engaging tech sites,  <http://slashdot.org/> Slashdot.org!
<http://sdm.link/slashdot> http://sdm.link/slashdot

___

wsjt-devel mailing list

 <mailto:wsjt-devel@lists.sourceforge.net> wsjt-devel@lists.sourceforge.net

 <https://lists.sourceforge.net/lists/listinfo/wsjt-deve

Re: [wsjt-devel] Inconsistent JT65b reporting

[Charles Suckling]

Hi Steve, Bill and Joe

 

I've done some more simulation work with the new jt65sim.

 

Results are here:

 

https://drive.google.com/file/d/1qeTkWiHaNafMqYKlAHW8NaRNGYk1BCn0/view?usp=s
haring

 

73

 

Charlie

 

-Original Message-
From: Steven Franke [mailto:s.j.fra...@icloud.com] 
Sent: 02 January 2018 14:50
To: WSJT software development
Subject: Re: [wsjt-devel] Inconsistent JT65b reporting

 

Hi Charlie,  Bill, and all,

 

> I also tried 40Hz spreading at -23 with 11025 with WSJT-X and found AP and

> no DS did not decode anything, whereas it gets 2/10 with 12000 sample

> rate.  It does OK however  with DS with these -23/40Hz 11025 signals. 

> Perhaps the resampling on very marginal signals like this is responsible?

 

I think that you need to look at a larger sample to decide whether or not
the decode probability is different between the two sample rates. 

 

I used the following to generate 100 JT65C files at SNR=-23 dB with 40 Hz
Doppler spread, at sample rate 12000 /s:

 

./jt65sim -d 40.0 -m C -n 1 -F 1200.0 -t 2.5 -f 100 -s \\-23 -G 10 -M "K9AN
G3WDG RRR"

 

With AP decoding enabled, G3WDG in the Dx Call box, and Tx5 selected, I got
34/100 decodes. All decodes were AP decodes with aptype=3 or 4. Deep Search
was not enabled.

 

Then, I repeated the experiment with -S added to the command line so that
the files were generated with 11025 /s rate. When WSJT-X detects a wav file
with 11025/s rate, it calls Joe's wav12.f90 resampler to resample the data
to 12000/s. In this case I got 38/100 decodes. 

 

It's worth noting that we expect the number of good decodes to have a
binomial distribution. The standard deviation of the binomial distribution
is sigma = sqrt( n*p*(1-p) ) where n is the sample size and p is the decode
probability. My results with 100 simulated wav files suggest that the decode
probability for the case that we are considering is somewhere in the
neighborhood of 0.36. With a sample size of 100, and p=0.36, the standard
deviation of the binomial distribution is sqrt(100*0.36(1-0.36))=4.8. 

 

Thus, the difference between my results with sample rate 12000 (34/100
decodes) and sample rate 11025 (38/100) is not statistically significant,
i.e. the observed differences are of the same order as the differences that
we'd expect if we just processed two different groups of files, with the
same underlying decode probability for each group. 

 

In summary, there is no evidence (so far) that resampling in WSJT-X causes
any degradation in decoding performance. It would take many more trials
(>1000) to be able to detect any differences in WSJT-X's decode probability
at the two sample rates. Of course, this experiment does *not* address what
happens when the operating system does the resampling, as would be the case
when processing audio data in real time.

 

Steve k9an

 

 


--

Check out the vibrant tech community on one of the world's most

engaging tech sites, Slashdot.org! http://sdm.link/slashdot

___

wsjt-devel mailing list

wsjt-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

Re: [wsjt-devel] Inconsistent JT65b reporting

[Charles Suckling]

Hi Steve

Thanks - yes the trap of small sample size caught me :-( 

I also fixed the other problems I reported earlier,  and learned a lesson
(do NOT use MS Powerpoint to edit and copy command lines from).  This is why
I could not get -G and -F to work.  Also, it often throws up slanted
inverted commas, which also don't work. Since moving to Notepad all is now
fine.  

Charlie



-Original Message-
From: Steven Franke [mailto:s.j.fra...@icloud.com] 
Sent: 02 January 2018 14:50
To: WSJT software development
Subject: Re: [wsjt-devel] Inconsistent JT65b reporting

Hi Charlie,  Bill, and all,

> I also tried 40Hz spreading at -23 with 11025 with WSJT-X and found AP and
> no DS did not decode anything, whereas it gets 2/10 with 12000 sample
> rate.  It does OK however  with DS with these -23/40Hz 11025 signals. 
> Perhaps the resampling on very marginal signals like this is responsible?

I think that you need to look at a larger sample to decide whether or not
the decode probability is different between the two sample rates. 

I used the following to generate 100 JT65C files at SNR=-23 dB with 40 Hz
Doppler spread, at sample rate 12000 /s:

./jt65sim -d 40.0 -m C -n 1 -F 1200.0 -t 2.5 -f 100 -s \\-23 -G 10 -M "K9AN
G3WDG RRR"

With AP decoding enabled, G3WDG in the Dx Call box, and Tx5 selected, I got
34/100 decodes. All decodes were AP decodes with aptype=3 or 4. Deep Search
was not enabled.

Then, I repeated the experiment with -S added to the command line so that
the files were generated with 11025 /s rate. When WSJT-X detects a wav file
with 11025/s rate, it calls Joe's wav12.f90 resampler to resample the data
to 12000/s. In this case I got 38/100 decodes. 

It's worth noting that we expect the number of good decodes to have a
binomial distribution. The standard deviation of the binomial distribution
is sigma = sqrt( n*p*(1-p) ) where n is the sample size and p is the decode
probability. My results with 100 simulated wav files suggest that the decode
probability for the case that we are considering is somewhere in the
neighborhood of 0.36. With a sample size of 100, and p=0.36, the standard
deviation of the binomial distribution is sqrt(100*0.36(1-0.36))=4.8. 

Thus, the difference between my results with sample rate 12000 (34/100
decodes) and sample rate 11025 (38/100) is not statistically significant,
i.e. the observed differences are of the same order as the differences that
we'd expect if we just processed two different groups of files, with the
same underlying decode probability for each group. 

In summary, there is no evidence (so far) that resampling in WSJT-X causes
any degradation in decoding performance. It would take many more trials
(>1000) to be able to detect any differences in WSJT-X's decode probability
at the two sample rates. Of course, this experiment does *not* address what
happens when the operating system does the resampling, as would be the case
when processing audio data in real time.

Steve k9an



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


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

Re: [wsjt-devel] Inconsistent JT65b reporting

[Charles Suckling]

Hi Bill

I am not able to run the command line with -G 30 added, nor -F 1000.  Either
triggers the help menu.

73

Charlie

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: 02 January 2018 08:54
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Inconsistent JT65b reporting

On 02/01/2018 07:30, char...@sucklingfamily.free-online.co.uk wrote:
> Hi Bill
>
> I've been testing the new jt65sim.
>
> Current command line is:
>
> jt65sim -m C -n 1 -d 40 -S -s \-15 -t 2.5 -f 10 -M "G3WDG VK7MO -15"
>
> With 11025 sample rate, I find WSJT decodes only the first file tried (it
> can be _0001, _0002 etc).  Subsequent attempts to decode another file in
> the set of 10 fail.  WSJT-X is fine with all 10.
>
> WSJT-X:
>
> 0001 -14  2.6 1498 #* G3WDG VK7MO -15f
> 0002 -14  2.5 1500 #* G3WDG VK7MO -15f
> 0003 -14  2.5 1499 #* G3WDG VK7MO -15f
> 0004 -14  2.5 1498 #* G3WDG VK7MO -15f
> 0005 -14  2.5 1501 #* G3WDG VK7MO -15f
> 0006 -14  2.5 1503 #* G3WDG VK7MO -15f
> 0007 -14  2.5 1503 #* G3WDG VK7MO -15f
> 0008 -14  2.5 1501 #* G3WDG VK7MO -15f
> 0009 -14  2.5 1500 #* G3WDG VK7MO -15f
> 0010 -15  2.5 1500 #* G3WDG VK7MO -15f
>
> WSJT:
>
> 0_0001 12  -21  2.5  226 16 *  G3WDG VK7MO -15   1  10
>
>
>
> I also tried 40Hz spreading at -23 with 11025 with WSJT-X and found AP and
> no DS did not decode anything, whereas it gets 2/10 with 12000 sample
> rate.  It does OK however  with DS with these -23/40Hz 11025 signals.
> Perhaps the resampling on very marginal signals like this is responsible?
>
> I was not successful in changing to 1000Hz base frequency by adding -F
> 1000 to the command line.  Maybe I'm not using the correct command?
>
> Charlie
>
Hi Charlie,

try adding -G 30 to that command. That will add 30dB gain to the output 
from the simulator which will satisfy WSJT's need for a higher level input.

73
Bill
G4WJS.



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


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

Re: [wsjt-devel] WSJT 9.7/10 audio feed

[Charles Suckling]

Hi Pete

I was also comparing WSJT10 and WSJT-X yesterday and saw exactly the same as
you. 

73

Charlie

-Original Message-
From: Peter Connors [mailto:sronno...@gmail.com] 
Sent: 01 January 2018 10:11
To: WSJT software development
Subject: [wsjt-devel] WSJT 9.7/10 audio feed

I have been using JT65b for eme for a couple of interesting and 
stimulating months. When I first installed WSJT (first 10 then 9.7) I 
read the user manual and got ready to calibrate the audio feed.
I started with the same 48kHz 16-bit input I had been using for WSJT-X 
and was intrigued to notice that, with the Rate in and Rate out still 
set at 1, the 'lower left' numbers varied between only 1.0001 and 
0.. At the next moonrise it was decoding and displaying well and 
remains so.
Have I entered a chronosynclastic infundibulum?

Pete G4PLZ


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


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

Re: [wsjt-devel] WSJT-x User feed back (1.8 RC3)

[Charles Suckling]

Charly

 

I believe its possible to save your table:

 



 

73

 

Charlie G3WDG

 

  _  

From: Karl Barth [mailto:df5...@darc.de] 
Sent: 23 October 2017 15:58
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] WSJT-x User feed back (1.8 RC3)

 

Thanks for explaining your comment rules,  so I registered as proposed.

73, Charly
 

My personal comment again:

Hello,

I use WSJT-x in ist various versions since abt 2 years and have seen many
changes and improvements and for sure, I appreciate all the efforts put in
such a complex software. 
I did not experience any major faults or bugs - and had very few situation
where the system was frozen.

However, personally I am not really pleased with one of the modifications
introduced in 1.8 RC3.
- 
I personally prefer the frequency settings (split or locked) in FT8 and
other modes as it was programmed up to V1.8 RC2.
>From my point of view, split operation (over here) is only needed during ES
openings whe we see with big pile up. Outside ES the majority of VHF/UHF
users seem to  operate "simplex"
I guess there are 50:50 pro and contra - so I take is "as is".

What I like to have added to WSJT.-x   when updating the software is more
important for me (and others?) :

a) Many european users have likely build up their own frequency tables,
adjusted to reflect the national restrictions in Europe (mainly on 4m and 6m
- but also on other VHF/UHF bands)

Every update (or reset) re-creates the default frequency tables. An option
NOT to override existing databases would be really helpful.

I have not found a way how to save and/or restore my personal frequency
table to avoid a manual recreation of that table after every update. 

Thanks for reading
73,
Charly, DF5VAE 

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

[wsjt-devel] More on Echo mode problem with Vista PC

[Charles Suckling]

Hi All

 

Testing rc3 shows the same problem.

 

Also, I notice there is no audio output with either Tune button or when
running Echo mode normally.

 

73

 

Charlie

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

[wsjt-devel] More on Echo mode problem with Vista PC

[Charles Suckling]

Hi All

 

Following on from my previous reports, today I tried building r8165 in two
ways, using Qt 5.2 and Qt 5.5 to see if the problem with Echo Graph and text
window not updating on my Vista shack  PC when transmitting echo sequences
might be related to the tool set used for building.

 

The experiment failed:  with the Qt 5.2 build I get the  error in sound
input message:

 



 

Thinking back, I think this is what prompted me to switch to Qt 5.5.

 

73

 

Charlie

 

 

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

Re: [wsjt-devel] building WSJT-X for windows using JTSDK

[Charles Suckling]

Hi Damon

 

I have some personal notes on installing JTSDK for Windows here, with links
etc to the relevant info:

 

https://drive.google.com/file/d/0B116IwQIUFNTSl9FNllsRFlOenc/view?usp=sharin
g

 

You will need a good internet connection as some of the downloads are quite
large.

 

73

 

Charlie G3WDG

 

  _  

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: 07 October 2017 11:44
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] building WSJT-X for windows using JTSDK

 

On 07/10/2017 03:02, Damon Register wrote:

> *as well as canned commands to manage the whole source control and build
process*. 
Are you telling me that there is a command or script that does 
all the steps necessary? 

Hi Damon,

yes, that is correct. I don't use the JTSDK myself but I'm sure someone who
does can help. I think there is a help command that lists all the commands
and options.

The INSTALL file does list the commands to build WSJT-X, it is all in the
first section entitled "Building from Source". The instructions are
basically the same for all platforms. The complexity comes from obtaining
all the prerequisite components, this is particularly so on Windows which
has no useful package management system. WSJT-X is partly written in C++ and
uses the Qt C++ framework for many cross-platform utilities and for the user
interface, C++ components cannot, in general, be built using a variety of
compilers so we must use the same build tools as Qt tool kit installed uses.
The Qt project makes this easy by including the development tools with their
package on Windows. There are two options, either MS VC or MinGW, our
project requires the MinGW variant. There are many other prerequisite
components on Windows which are necessary to bring it somewhere close to a
usable development environment but the JTSDK was developed by Greg, KI7MT,
for exactly the purpose of managing that complexity.

If you want an exercise in pain and frustration then go ahead and install
all the Windows prerequisites and tools manually but you will find it much
easier to use the JTSDK which basically reduces it all to one command once a
few well documented steps to install some components that cannot be legally
bundled with the JTSDK package.

73
Bill
G4WJS.

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

[wsjt-devel] r 8085 wider DT window for FT8

[Charles Suckling]

Hi Steve

 

Looks like it works:

 

080300 -11 -2.4 900 ~ CQ 7Z1IS LL34 !Saudi A

 

73

 

Charlie

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

Re: [wsjt-devel] Configurations

[Charles Suckling]

Thanks, Bill


-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: 12 September 2017 19:27
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Configurations

On 12/09/2017 17:51, char...@sucklingfamily.free-online.co.uk wrote:
> Is there any limit on the number of configurations that can be stored?

Hi Charlie,

not really but managing the list on screen will become unwieldy after a 
hundred or so.

73
Bill
G4WJS.



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


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

Re: [wsjt-devel] Echo Mode in 1.8.0 rc2

[Charles Suckling]

Hi All

 

I have tried removing the ! in the third line below, and this restores Echo
Graph and seems to behave as expected.

 

Problem with Echo graph not updating remains.  

 

if(i==21) ui->actionInclude_correlation->setVisible (b);

if(i==22) {

if(b && !m_echoGraph->isVisible()) {

m_echoGraph->show();

} else {

if(m_echoGraph->isVisible()) m_echoGraph->hide();

 

73  Charlie

  _  

From: Charles Suckling [mailto:char...@sucklingfamily.free-online.co.uk] 
Sent: 11 September 2017 18:12
To: 'WSJT software development'
Subject: Re: [wsjt-devel] Echo Mode in 1.8.0 rc2

 

Hi All

 

Non automatic appearance of Echo Graph was between r7924 and r7939.

 

Charlie

 

  _  

From: Charles Suckling [mailto:char...@sucklingfamily.free-online.co.uk] 
Sent: 11 September 2017 18:00
To: 'WSJT software development'
Subject: Re: [wsjt-devel] Echo Mode in 1.8.0 rc2

 

Hi All

 

Further investigation by looking at old devel builds here  indicates that
the problem with echo graph not updating after receiving echo occurred
somewhere between r7754 and r7782.

 

The non-appearance of Echo graph automatically seems to have been introduced
later than r7782.

 

Charlie

 

 

  _  

From: Charles Suckling [mailto:char...@sucklingfamily.free-online.co.uk] 
Sent: 11 September 2017 07:21
To: 'WSJT software development'
Subject: [wsjt-devel] Echo Mode in 1.8.0 rc2

 

Hi All

 

Echo mode seems to have a bug.

 

Echo graph does not appear automatically and needs to be enabled from View
tab.

 

After opening Echo graph data, while not transmitting the trace updates and
data is written to main window every 3s.

 

When transmitting, the trace does not update and no data is written to main
window.

 

Otherwise the mode is functional, in that Doppler control is working and
echoes appear on the waterfall.

 

I briefly tested an old version (r7609) and that behaved normally.

 

73

 

Charlie

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

Re: [wsjt-devel] Echo Mode in 1.8.0 rc2

[Charles Suckling]

Hi All

 

Non automatic appearance of Echo Graph was between r7924 and r7939.

 

Charlie

 

  _  

From: Charles Suckling [mailto:char...@sucklingfamily.free-online.co.uk] 
Sent: 11 September 2017 18:00
To: 'WSJT software development'
Subject: Re: [wsjt-devel] Echo Mode in 1.8.0 rc2

 

Hi All

 

Further investigation by looking at old devel builds here  indicates that
the problem with echo graph not updating after receiving echo occurred
somewhere between r7754 and r7782.

 

The non-appearance of Echo graph automatically seems to have been introduced
later than r7782.

 

Charlie

 

 

  _  

From: Charles Suckling [mailto:char...@sucklingfamily.free-online.co.uk] 
Sent: 11 September 2017 07:21
To: 'WSJT software development'
Subject: [wsjt-devel] Echo Mode in 1.8.0 rc2

 

Hi All

 

Echo mode seems to have a bug.

 

Echo graph does not appear automatically and needs to be enabled from View
tab.

 

After opening Echo graph data, while not transmitting the trace updates and
data is written to main window every 3s.

 

When transmitting, the trace does not update and no data is written to main
window.

 

Otherwise the mode is functional, in that Doppler control is working and
echoes appear on the waterfall.

 

I briefly tested an old version (r7609) and that behaved normally.

 

73

 

Charlie

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

Re: [wsjt-devel] Echo Mode in 1.8.0 rc2

[Charles Suckling]

Hi All

 

Further investigation by looking at old devel builds here  indicates that
the problem with echo graph not updating after receiving echo occurred
somewhere between r7754 and r7782.

 

The non-appearance of Echo graph automatically seems to have been introduced
later than r7782.

 

Charlie

 

 

  _  

From: Charles Suckling [mailto:char...@sucklingfamily.free-online.co.uk] 
Sent: 11 September 2017 07:21
To: 'WSJT software development'
Subject: [wsjt-devel] Echo Mode in 1.8.0 rc2

 

Hi All

 

Echo mode seems to have a bug.

 

Echo graph does not appear automatically and needs to be enabled from View
tab.

 

After opening Echo graph data, while not transmitting the trace updates and
data is written to main window every 3s.

 

When transmitting, the trace does not update and no data is written to main
window.

 

Otherwise the mode is functional, in that Doppler control is working and
echoes appear on the waterfall.

 

I briefly tested an old version (r7609) and that behaved normally.

 

73

 

Charlie

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

[wsjt-devel] Echo Mode in 1.8.0 rc2

[Charles Suckling]

Hi All

 

Echo mode seems to have a bug.

 

Echo graph does not appear automatically and needs to be enabled from View
tab.

 

After opening Echo graph data, while not transmitting the trace updates and
data is written to main window every 3s.

 

When transmitting, the trace does not update and no data is written to main
window.

 

Otherwise the mode is functional, in that Doppler control is working and
echoes appear on the waterfall.

 

I briefly tested an old version (r7609) and that behaved normally.

 

73

 

Charlie

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

Re: [wsjt-devel] Feature request - sticky reports

[Charles Suckling]

Hi Gary

I think yours is a different requirement.  

On EME, some operators prefer to receive the same report every transmission.
This probably comes from experience with correlation decoding, where under
marginal conditions the decoder may produce flagged low confidence decodes.
Standard practice has been, if the receiving operator is uncertain, to wait
for another decode as confirmation before proceeding to a R report message
or RRR. 

73

Charlie

-Original Message-
From: Gary McDuffie [mailto:mcduf...@ag0n.net] 
Sent: 04 August 2017 18:55
To: WSJT software development
Subject: Re: [wsjt-devel] Feature request - sticky reports


> On Aug 4, 2017, at 1:37 AM, Charles Suckling
<char...@sucklingfamily.free-online.co.uk> wrote:
> 
> The subject of sticky reports has already come up.  It seems desirable
(from user feedback)  if the first decoded report could be used in all
subsequent messages in that QSO,  to avoid confusion over existing practice
where the sent report does not change as the QSO progresses.

I'm not involved in EME, but I've often wished that when the signal report
is given more than once, it would send the highest report to that point.  In
other words, if the signal went from -12 to -10 before it was acknowledged,
the -10 would be the official report and put in the log that way.  This
could be the case for all modes, I assume.  I don't know if this would cause
a problem, but I thought I would mention it in relation to your post.

Gary - AG0N

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


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

[wsjt-devel] Feature request - sticky reports

[Charles Suckling]

Hi Bill and Joe

 

Several stations have  been testing out auto-seq on QRA64 10GHz EME these
last couple of days,  with excellent results. It certainly eases the
workload, with other many other things to keep track of.

 

The subject of sticky reports has already come up.  It seems desirable (from
user feedback)  if the first decoded report could be used in all subsequent
messages in that QSO,  to avoid confusion over existing practice where the
sent report does not change as the QSO progresses.

 

We'd be grateful if you could consider this as a user selectable option for
QRA64 at some point.

 

Recent tests under very marginal conditions have once again shown the
benefits of QRA64.  It is working really well on Rex's dxpedition, and more
stations are now joining in.  We seem to have pretty much settled  on
sub-mode D for general use.  

 

73

 

Charlie

 

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

Re: [wsjt-devel] r 7970 : Sked frequency moving

[Charles Suckling]

Hi Bill

 

I've been testing your fix and after  running it for one hour continuously
there were no changes to Sked Frequency.

 

Thanks!

 

73

 

Charlie

 

  _  

From: Charles Suckling [mailto:char...@sucklingfamily.free-online.co.uk] 
Sent: 01 August 2017 08:57
To: 'WSJT software development'
Cc: 'Daniel Gautschi'
Subject: Re: [wsjt-devel] r 7970 : Sked frequency moving

 

Hi Bill

 

I now have set up to have rig control (IC735) operating with WSJT-X, and can
confirm Dan's observations.

 

Recipe:

 

Receiving just band noise.

 

Mode QRA64D, no auto seq.

 

First observation (possibly unrelated to the current issue)  is that with
Doppler tracking set to none (and CFOM, other methods not tested) tuning the
radio dial alters sked frequency. Tool tip and my memory was that this is
only supposed to happen with CTRL key pressed.

 

Increment tests:

 

With TX not enabled, both sked frequencies stay fixed indefinitely (in this
case 225k).

 

With TX enabled, and Doppler tracking set to none,  after 10 cycles of
transmit/receive cycles both sked frequencies did not change.

 

With TX enabled and Doppler tracking set to CFOM the incrementing of sked
frequencies is seen.

 

At end of T period 1 RX sked freq decreased by 30Hz.

At end of R period 1 TX sked freq decreased by 30Hz.

 

At end of T period 2 RX sked freq decreased again by 30Hz.

At end of R period 2 TX sked freq decreased again by 30Hz.

 

At end of T period 3 RX sked freq decreased again by 30Hz.

At end of R period 3 TX sked freq decreased again by 30Hz.

 

At end of T period 4 RX sked freq decreased again by 30Hz.

At end of R period 4 TX sked freq decreased again by 30Hz.

 

The point in the cycle at which  the frequency changes seems to be:  TX sked
frequency changes on the minute change, while RX sked frequency changes at a
variable time between end of decode attempt and the minute change.

 

73

 

Charlie

 

 

 

 

 

  _  

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: 31 July 2017 19:10
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] r 7970 : Sked frequency moving

 

On 31/07/2017 18:53, Charles Suckling wrote:

We were testing r7970  today on 10GHz EME QRA64D.

 

HB9Q (who unlike me routinely runs Doppler correction using rig control from
WSJT-X) noticed a progressive change in sked frequency from period to
period, of the order of 25-30Hz.  This behaviour is has not been seen with
1.8 rc1.  We were using constant freq on moon Doppler.

 

Hi Charlie,

it would be helpful to know what rig is being used, also if the nominal sked
frequency displays in the "Astronomical Data" window are shifting or staying
put.

Is it possible that there is an undisciplined oscillator somewhere and this
is drift, admittedly I can't see any obvious Rx period drift on the
waterfall sample but with 10G Doppler spreading and 64 tones it is hard to
judge. Nice strong signals off the Moon BTW! Perhaps we should be looking at
wide tone spaced FT8 for super quick microwave EME QSOs.

73
Bill
G4WJS.

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

Re: [wsjt-devel] r 7970 : Sked frequency moving

[Charles Suckling]

Hi Bill

 

I now have set up to have rig control (IC735) operating with WSJT-X, and can
confirm Dan's observations.

 

Recipe:

 

Receiving just band noise.

 

Mode QRA64D, no auto seq.

 

First observation (possibly unrelated to the current issue)  is that with
Doppler tracking set to none (and CFOM, other methods not tested) tuning the
radio dial alters sked frequency. Tool tip and my memory was that this is
only supposed to happen with CTRL key pressed.

 

Increment tests:

 

With TX not enabled, both sked frequencies stay fixed indefinitely (in this
case 225k).

 

With TX enabled, and Doppler tracking set to none,  after 10 cycles of
transmit/receive cycles both sked frequencies did not change.

 

With TX enabled and Doppler tracking set to CFOM the incrementing of sked
frequencies is seen.

 

At end of T period 1 RX sked freq decreased by 30Hz.

At end of R period 1 TX sked freq decreased by 30Hz.

 

At end of T period 2 RX sked freq decreased again by 30Hz.

At end of R period 2 TX sked freq decreased again by 30Hz.

 

At end of T period 3 RX sked freq decreased again by 30Hz.

At end of R period 3 TX sked freq decreased again by 30Hz.

 

At end of T period 4 RX sked freq decreased again by 30Hz.

At end of R period 4 TX sked freq decreased again by 30Hz.

 

The point in the cycle at which  the frequency changes seems to be:  TX sked
frequency changes on the minute change, while RX sked frequency changes at a
variable time between end of decode attempt and the minute change.

 

73

 

Charlie

 

 

 

 

 

  _  

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: 31 July 2017 19:10
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] r 7970 : Sked frequency moving

 

On 31/07/2017 18:53, Charles Suckling wrote:

We were testing r7970  today on 10GHz EME QRA64D.

 

HB9Q (who unlike me routinely runs Doppler correction using rig control from
WSJT-X) noticed a progressive change in sked frequency from period to
period, of the order of 25-30Hz.  This behaviour is has not been seen with
1.8 rc1.  We were using constant freq on moon Doppler.

 

Hi Charlie,

it would be helpful to know what rig is being used, also if the nominal sked
frequency displays in the "Astronomical Data" window are shifting or staying
put.

Is it possible that there is an undisciplined oscillator somewhere and this
is drift, admittedly I can't see any obvious Rx period drift on the
waterfall sample but with 10G Doppler spreading and 64 tones it is hard to
judge. Nice strong signals off the Moon BTW! Perhaps we should be looking at
wide tone spaced FT8 for super quick microwave EME QSOs.

73
Bill
G4WJS.

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

Re: [wsjt-devel] r 7970 : Sked frequency moving

[Charles Suckling]

Hi Bill

 

Dan's rig is a K3 and it is 10MHz locked.  Normally frequencies are very
stable. Dan also saw the effect when working Rex.

 

Dan had TX and RX freq's unlocked.

 

Dan was testing with my recent patch, but the incrementing happened whether
autoseq was  on and off.

 

Yes, the sked frequency was observed to change.  It had started out as 225k
above band edge:

 

 



 

I think this screen was captured after 3 or 4 transmit periods.

 

Dan commented:

 

"As long as "Enable TX" is off all is ok.

When "Enable TX" is on, doing a QSO, after TXing 1 period the RX frequency
in the "Astronomical Data" " Sked frequency" window gets adjusted by +25Hz.
After 1 period of RX, just before TX starts, the TX gets adjusted by +25Hz.
It did this all the time and added up to 76Hz. Of course this adjusted my
RTX accordingly. See screenshot.

I did see the same yesterday in QSO with Rex.

 

The 1.8.0 didn't do that"

 

73

 

Charlie

 

 

 

  _  

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: 31 July 2017 19:10
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] r 7970 : Sked frequency moving

 

On 31/07/2017 18:53, Charles Suckling wrote:

We were testing r7970  today on 10GHz EME QRA64D.

 

HB9Q (who unlike me routinely runs Doppler correction using rig control from
WSJT-X) noticed a progressive change in sked frequency from period to
period, of the order of 25-30Hz.  This behaviour is has not been seen with
1.8 rc1.  We were using constant freq on moon Doppler.

 

Hi Charlie,

it would be helpful to know what rig is being used, also if the nominal sked
frequency displays in the "Astronomical Data" window are shifting or staying
put.

Is it possible that there is an undisciplined oscillator somewhere and this
is drift, admittedly I can't see any obvious Rx period drift on the
waterfall sample but with 10G Doppler spreading and 64 tones it is hard to
judge. Nice strong signals off the Moon BTW! Perhaps we should be looking at
wide tone spaced FT8 for super quick microwave EME QSOs.

73
Bill
G4WJS.

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

[wsjt-devel] r 7970 : Sked frequency moving

[Charles Suckling]

Hi All

 

We were testing r7970  today on 10GHz EME QRA64D.

 

HB9Q (who unlike me routinely runs Doppler correction using rig control from
WSJT-X) noticed a progressive change in sked frequency from period to
period, of the order of 25-30Hz.  This behaviour is has not been seen with
1.8 rc1.  We were using constant freq on moon Doppler.

 



 

I will try to reproduce this here later, so just a heads up for now.

 

73

 

Charlie

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

[wsjt-devel] QRA64 Auto-sequence Patch

[Charles Suckling]

Hi All

 

I have posted a small  patch to allow QRA64 to operate with auto-sequencing
here:

 

https://drive.google.com/file/d/0B116IwQIUFNTT1hLTU9Idjl5UDQ/view?usp=sharin
g

 

It is compatible with r7970.

 

Having seen autosequencing work very well on FT8, I felt that this facility
could also be of benefit for microwave EME,  where solo operator workload
can at some times be quite  high.  

 

It was tested satisfactorily this morning between VK7MO and myself on 10GHz
EME, with auto-sequencing operating at my end.  Normal QSO procedure
including answering a CQ call was tested.

 

Rex was also  able to determine his 'current' signal at my end by sending a
[call call report] message], to which auto-sequencing replied with [call
call R report] indicating his level at my end for the previous decode.  

 

While reports sent are not sticky, I don't see any issue with this as
averaging is not used on QRA64. 

 

73

 

Charlie

 

 

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

Re: [wsjt-devel] 72-Bit Contest Mode, Rover support

[Charles Suckling]

Hi Joe

Does Generate Std Msgs set up these messages or does it all happen when
someone calls you?  Haven't used contest mode in MSK144 before.

Charlie

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: 28 July 2017 18:34
To: WSJT
Subject: [wsjt-devel] 72-Bit Contest Mode, Rover support

Hi all Beta Testers,

In code revision r7969 the WSJT-X development branch supports "Contest 
Mode" in FT8 as well as MSK144.  This mode is designed for NA VHF+ 
contests in which the required exchange is a 4-character grid locator.

Contest Mode is enabled by checking the box labeled "FT8 and MSK144 
Contest Mode" on the *Settings -> Advanced* tab.  When that has been 
done by both QSO partners, QSOs in the following formats are supported:

1. CQ K1ABC FN42
2.   K1ABC W9XYZ EN37
3. W9XYZ K1ABC R FN42
4.   K1ABC W9XYZ RRR
5. W9XYZ K1ABC 73

1. CQ 290 K1ABC FN42
2.   K1ABC W9XYZ EN37
3. W9XYZ K1ABC R FN42
4.   K1ABC W9XYZ RRR
5. W9XYZ K1ABC 73

Note that only message #3 is special to Contest Mode.  Some details 
about how its extra acknowledgment "R " is conveyed within the 72-bit 
message frame are described in Section 16.3.3 of the WSJT-X User Guide:
http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.7.1-deve
l.html#FAST_MODES

The second model QSO is suitable mainly for MSK144.


I should point out that Rover callsigns (as used in NA VHF+ contests) 
can be used in WSJT-X, as in the following examples:

1. CQ K1ABC/R FN41
2.   K1ABC W9XYZ EN37
3. W9XYZ K1ABC R FN41
4.   K1ABC W9XYZ RRR
5. DE K1ABC/R 73

1. CQ K1ABC FN42
2.   DE W9XYZ/R EN37
3. W9XYZ K1ABC R FN42
4.   K1ABC W9XYZ RRR
5. W9XYZ K1ABC 73

The callsign suffix "/R" used by the Rover is treated as a "Type 2" 
add-on prefix/suffix.  In the first model QSO immediately above, K1ABC 
sends his full Rover callsign K1ABC/R in messages 1 and 5.  In the 
second model QSO, rover W9XYZ/R responds to a CQ from home-station K1ABC.

Please note that these features do not (yet) take advantage of the 
enhanced 75-bit messages possible in FT8.  We are currently working on 
uses for the extra 3 bits that will provide support for other contest 
types, perhaps including RTTY-like  and EU VHF+ contests, as well as 
improved support for messaged containing compound callsigns.

If you are able to build WSJT-X r7969 and to find a partner with whom 
you can test these new features, please send reports to this list.

-- 73, Joe, K1JT


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


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

Re: [wsjt-devel] r7829 Call 1st / weak

[Charles Suckling]

and maybe call1st and weak greyed out unless auto seq is checked?

 

I also see these checkboxes on other modes that do not use auto seq.

 

Charlie 

 

  _  

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]

Sent: 10 July 2017 06:06
To: WSJT software development
Cc: Black Michael
Subject: Re: [wsjt-devel] r7829 Call 1st / weak

 

So call 1st (and I guess weak too) should maybe be disabled after starting
the QSO and then re-enabled at Tx 6 again?  Or perhaps only enable when Tx 6
is active?

 

de Mike W9MDB

 

 

  _  

From: Jim - N4ST 
To: 'WSJT software development'  
Sent: Sunday, July 9, 2017 11:46 PM
Subject: Re: [wsjt-devel] r7829 Call 1st / weak

 

Call 1st is great for us old guys that are slower on the mouse clicks.  It
does seem to work.  The problem I had was if some over anxious caller (I
guess because I am in the rare state of Virginia) would call me before I
finished my current QSO sequence, WSJT-X would jump to the other caller's
frequency!  So now, as soon as I establish a QSO, I click off the Call 1st
feature and then re-engage it when I call CQ again.

___ 
73,
Jim - N4ST


-Original Message-
From: Richard Lamont [mailto:rich...@lamont.me.uk] 
Sent: Sunday, July 9, 2017 20:21
To: WSJT software development 
Subject: [wsjt-devel] r7829 Call 1st / weak

r7829
Ubuntu 16.04

I've been trying out the new UI feature for auto-responding to a CQ, for
which many thanks Joe.

The Call 1st option works like a champ. It enables a station to work a 'run'
without any duplicated transmissions even if you're a bit slow on the
uptake.

I couldn't persuade 'Weak' to work, though. Tried it a couple of times and
in both cases my station responded with another CQ. There was only one
caller in each case.


73,
Richard G4DYA




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





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

 

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

Re: [wsjt-devel] Double Display in Rx window

[Charles Suckling]

Hi All

 

Yes, I see the same.  Its as if messages with calls in are printed twice -
maybe band decode and QSO freq decode.

 

Just had a qso with DL5XL  with his signal (upper) overlapping with some
QRM:

 



 

I'd moved the frequency off afterwards for his 73 and only saw one decode in
the right hand window.

 

73

 

Charlie

 

  _  

From: Ricky Scott [mailto:w7...@w7psk.net] 
Sent: 08 July 2017 07:10
To: WSJT software development; iain macdonnell - N6ML
Subject: Re: [wsjt-devel] Double Display in Rx window

 

Yes its double in the received window on the right side, ok on the left.
Only calls directed at me, if I 

put the cursor on someone in the window its a single.

 

On July 7, 2017 at 10:20 PM iain macdonnell - N6ML  wrote:

On Fri, Jul 7, 2017 at 5:52 PM, Neil Zampella  wrote:

Seeing double entries for the replying station in the RX window, r7812.

Yep, me too... seems to be only on messages directed to my callsign.

73,

~iain / N6ML


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

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

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

Re: [wsjt-devel] Patch files for Windows

[Charles Suckling]

Hi Bill

 

Thanks for your help.

 

I am trying a few things out locally and may make some proposals to the
development team in due course if they work.

 

73

 

Charlie

 

 

 

  _  

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: 05 July 2017 10:44
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Patch files for Windows

 

On 05/07/2017 09:37, Charles Suckling wrote:

Just wondering what folks use to generate patch files, recommendations etc.

 

I've downloaded Winmerge but not yet installed or tried it.

 

73

 

Charlie

Hi Charlie,

patches have many uses, do you mean proposing changes to the development
team or applying patches from others?

The tools used are almost always the command line ones. Source control
systems normally have their own versions. The main tools are `diff` and
`patch`. Universal diff format is usually best if there is an option.

The `diff` tool and SCS equivalents (`svn diff`, `git diif`, etc.) allow
patches to be created.

The `patch` tool and SCS eqivalents (`git apply` etc.) allow patches to be
applied and reverted (-R). The `patch` tool has a command option to ignore a
given number of directory levels from the files to patch paths in the diff
file, learning how this works is essential. Also `patch` is a Unix style
filter application and it takes input from the standard input stream so you
might use it like:

svn diff >~/my-patch.diff  # record all the current differences from the
repository

cd 

patch -p0 <~/my-patch.diff

If you later wish to revert the patch then you can do:

patch -Rp0 <~/my-patch.diff

On Windows these tools are available in an MSys command line environment,
for example the one provided by MinGW which in turn is part of the Qt
installation.

73
Bill
G4WJS.

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

[wsjt-devel] Simulating QSO progress

[Charles Suckling]

To test out autosequencing, is is possible to play back wave files with
different types of message,  as would be the case as a QSO progresses?

 

73

 

Charlie

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

[wsjt-devel] Patch files for Windows

[Charles Suckling]

Just wondering what folks use to generate patch files, recommendations etc.

 

I've downloaded Winmerge but not yet installed or tried it.

 

73

 

Charlie

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

Re: [wsjt-devel] Colors - FT8

[Charles Suckling]

Hi Joe

Seems to be working fine, learning how to use it now.

Charlie

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: 02 July 2017 19:01
To: WSJT software development
Subject: Re: [wsjt-devel] Colors - FT8

Hi Kari,

> The 'worked before' feature is also not working with FT8.
> 
> I think this could be fixed by adding test for
> FT8 on line 105 of "logbook/adif.cpp"

Thanks!  I believe it's fixed in r.

-- Joe, K1JT


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


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

Re: [wsjt-devel] Minimum transmission length for FT8

[Charles Suckling]

tnx

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: 02 July 2017 18:45
To: WSJT software development
Subject: Re: [wsjt-devel] Minimum transmission length for FT8

Hi Charlie,

> What fraction of the transmission is needed for a successful decode 
> given 'good' S/N?
> 
> I've seen some "short" messages decode just now (using r7776).

The code rate is 1/2, so without AP decoding the bare minimum must be 
about half a transmission.  I've seen done good decodes with not much 
more than that.
-- Joe


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


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

[wsjt-devel] Minimum transmission length for FT8

[Charles Suckling]

Hi Joe/Steve

 

What fraction of the transmission is needed for a successful decode given
'good' S/N?

 

I've seen some "short" messages decode just now (using r7776).

 

73

 

Charlie

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

Re: [wsjt-devel] FT8 - build 7752 and rig control

[Charles Suckling]

Hi George

 

Simple solution here is to select rig as 'none' and tune manually.  

 

Just had my first QSO on 20m.  All looks very good.

 

73

 

Charlie

 

  _  

From: George J Molnar [mailto:geo...@molnar.com] 
Sent: 30 June 2017 17:08
To: WSJT software development
Subject: Re: [wsjt-devel] FT8 - build 7752 and rig control

 

Thanks, Mike and Bill, for the clarification.

 

Still feel like the way this is being implemented is counter-intuitive for
most operators. After your explanation, I get it. That said, I've made
10,000 JT-mode QSOs and it never occurred to me when I saw this. I think we
might see a fair number of folks fall into the same confusion that I felt.
It's made more difficult since it's not standardized across the platform. 

 

 

Not sure what the solution is. For me, I will probably just build a
configuration that prevents split for FT8, since my Flex is pretty flat
across the passband and no audio card is involved. 

 

George J Molnar

Nevada, USA
KF2T  @GJMolnar

 

 

 

 

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

Re: [wsjt-devel] Error in Sound input

[Charles Suckling]

Hi Bill

"does the Windows Vista machine have any sound devices that do not support
48000Hz 16-bit sample format? The only thing I can think of is that somehow
WSJT-X has selected a sound device that is not the one you normally use with
your rig."

I have checked and no, not as far as I can see.  Both releases have
identical selections for the soundcard, and Device Manager only shows one
sound device.

73

Charlie

 

 

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

[wsjt-devel] Error in Sound input

[Charles Suckling]

Hi All

 

I've recently built r7698 (after not having built anything since r7609).

 

I see a difference in behaviour with r7698  whereby on a  Win 7 machine all
runs fine, but  with my shack Vista machine  I get an error message box
"Error in sound input, requested audio format is not available on device"
shortly after starting WSJT-X.  Error box clears with "OK" but program is
not getting any audio.  r7609 runs fine on the Vista.

 

The same package installer  was used on both machines.

 

Has anyone else seen this?

 

73

 

Charlie

 

 

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

Re: [wsjt-devel] submode menu not available

[Charles Suckling]

Hi Robert

You need to have VHF/UHF features enabled (File->Settings->General).

73

Charlie G3WDG

-Original Message-
From: Robert Schneider [mailto:rjschnei...@gmail.com] 
Sent: 01 May 2017 15:30
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] submode menu not available

Hi,
i am running wsjt-x R7405 on WIN10.
In  all JT Modes the Submodes-Menu in the Main-Window is not shown. In  
QRA64, ISCAT it is available.
Where is my mistake?

Best regards
robert, db1jj



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


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

Re: [wsjt-devel] Reset menu item in Configurations

[Charles Suckling]

Thanks, Mike.

 

No there wasn't, but someone on HB9Q logger!

 

Charlie

 

  _  

From: Black Michael [mailto:mdblac...@yahoo.com] 
Sent: 19 February 2017 15:04
To: WSJT software development
Subject: Re: [wsjt-devel] Reset menu item in Configurations

 

Hopefully there was someone in the room at the time you heard the question
:-)

 

Reset simply returns that config to the WSJT-X default values.  So you'll
lose all your custom settings.

Mostly a sanity check/last resort for when things aren't working as
expected.

 

de Mike W9MDB

 

  _  

From: Charles Suckling <char...@sucklingfamily.free-online.co.uk>
To: 'WSJT software development' <wsjt-devel@lists.sourceforge.net> 
Sent: Sunday, February 19, 2017 8:37 AM
Subject: [wsjt-devel] Reset menu item in Configurations

 

Hi All

 

Someone just asked what the function of the 'Reset' menu item is in
Configurations.

 

73

 

Charlie



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



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

[wsjt-devel] Reset menu item in Configurations

[Charles Suckling]

Hi All

 

Someone just asked what the function of the 'Reset' menu item is in
Configurations.

 

73

 

Charlie

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

Re: [wsjt-devel] Saving settings for MSK144 - Feature request

[Charles Suckling]

Hi Bill

Thanks for taking a look.

On my own JTSDK build of r7447 for Windows, on starting the program  decode
depth is always Deep.  If I select Fast (or Normal) then close and restart
it is back to Deep.

73

Charlie

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: 04 January 2017 17:14
To: WSJT software development
Subject: Re: [wsjt-devel] Saving settings for MSK144 - Feature request

On 04/01/2017 16:08, Charles Suckling wrote:
> Checking again, I see that Ftol is remembered on restart, but not Decode
> type or T/R period.

Hi Charlie,

I can only reproduce issues with T/R period not being faithfully 
restored from startups or configuration changes. This is not very 
surprising as the T/R period coding is a bit complicated. I will see if 
I can improve matters.

For the decode depth I would appreciate a simple recipe to reproduce the 
issue as I cannot yet do that here.

73
Bill
G4WJS.



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


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

Re: [wsjt-devel] Saving settings for MSK144 - Feature request

[Charles Suckling]

Hi Joe

Checking again, I see that Ftol is remembered on restart, but not Decode
type or T/R period. 

In case its relevant, this is all with a named instance of WSJT-X.

Charlie

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: 04 January 2017 15:09
To: WSJT software development
Subject: Re: [wsjt-devel] Saving settings for MSK144 - Feature request

Hi Charlie,

> Having used MSK144 now with a rather slow PC, it would be a 'nice to
> have' if some previous settings could be recalled on restarting the
> program in MSK144 or switching from another mode into MSK144.
>
> Specifically, the decode setting (in my case 'fast') and possibly Ftol.
>  Getting access to these settings with >100% processor load is somewhat
> difficult as with the defaults the program is slow to respond.
>
> On-air tests on 144MHz have been impressive - it also works nicely with
> aircraft scatter at shorter ranges.

All of the settings you mention will saved if you exit the program in 
MSK144 mode, and restored on program restart.

In many circumstances switching between modes is more convenient if you 
use the Configurations menu to make a Configuration for each operating 
mode.  Then, whenever you switch to that Configuration your favorite 
parameters will be restored.

-- Joe, K1JT


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


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

[wsjt-devel] Saving settings for MSK144 - Feature request

[Charles Suckling]

Hi All

 

Having used MSK144 now with a rather slow PC, it would be a 'nice to have'
if some previous settings could be recalled on restarting the program in
MSK144 or switching from another mode into MSK144.

 

Specifically, the decode setting (in my case 'fast') and possibly Ftol.
Getting access to these settings with >100% processor load is somewhat
difficult as with the defaults the program is slow to respond.

 

On-air tests on 144MHz have been impressive - it also works nicely with
aircraft scatter at shorter ranges.

 

73

 

Charlie

 

 

 

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

Re: [wsjt-devel] My problems while trying to get the audio samples

[Charles Suckling]

Hi Bill

Agreed - the link  should definitely  go in the User Guide.

73

Charlie

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: 04 December 2016 17:38
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] My problems while trying to get the audio samples

On 04/12/2016 17:35, Charles Suckling wrote:
> This fixed it for me, thanks.

Hi Charlie,

thanks for the feedback. Looks like that info needs adding to the 
release notes or User Guide install section for Windows users.

73
Bill
G4WJS.



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


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

Re: [wsjt-devel] My problems while trying to get the audio samples

[Charles Suckling]

Hi Bill

This fixed it for me, thanks.

Tested with r7359.

73

Charlie

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: 04 December 2016 14:37
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] My problems while trying to get the audio samples

On 04/12/2016 12:09, Charles Suckling wrote:
> It's the unable to initiate SSL context one.

Hi Charlie,

I believe that error is due to the OpenSSL libraries not being installed 
on your system. Due to US state and federal laws restricting export of 
strong cryptography software we cannot include the OpenSSL libraries in 
the WSJT-X installer package, so you must install them yourself assuming 
you are able to accept the terms and conditions. For Windows you can get 
an approved, by the OpenSSL team, installer package from here: 
http://slproweb.com/products/Win32OpenSSL.html . You need at least the 
Win32 v1.0.2j Light package. Take the default options in the installer, 
particularly the option to install into the Windows system directory.

Let me know how it goes please?

73
Bill
G4WJS.



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


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

Re: [wsjt-devel] My problems while trying to get the audio samples

[Charles Suckling]

Hi Bill

It's the unable to initiate SSL context one.

Charlie

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: 04 December 2016 12:01
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] My problems while trying to get the audio samples

On 04/12/2016 11:56, Charles Suckling wrote:
> I still get the error box here with r7359.

Hi Charlie,

are you getting the same error as Claude or are you getting "Unable to 
init SSL context"?

73
Bill
G4WJS.



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


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

Re: [wsjt-devel] Effect of TX Delay on QRA64

[Charles Suckling]

Hi Joe

Agreed - there is no substitute for proper sequencing.

It might be a good idea to limit it to 0.5s.

I was troubleshooting another problem (probably a slow to changeover WG
relay at my QSO partner).  Turned out he had TX delay at 0.2s so actually
this wasn't the issue.

Charlie



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

Re: [wsjt-devel] Help on Help --> download samples

[Charles Suckling]

Hi Bill

I have the same problem on both my machines, one Vista the other Win7.

I had previously been able to download sample files with no problem.

The appearance of this error seemed to start around r7330, when some old
files were removed and new ones added.

Charlie

-Original Message-
From: Alessandro Gorobey [mailto:algi...@libero.it] 
Sent: 29 November 2016 00:16
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Help on Help --> download samples

Hi Bill,

there is a misunderstanding.
The problem is in windows 10.
Linux perfectly work.

In W10 a old version r7220 compiled at october 23 also work.
The ACTUAL version in W10 give me the error.
There is also a difference in
https://sourceforge.net/projects/wsjt/files/samples/contents_1.7.json/downlo
ad 
and the files present in QRA64A, but this can be wanted as current code 
adjustment.

In Windows 10, ver 1607 build 14393.447 I have only the QT 5.5 as 
provided by Windows JTSDK v2.0.5-1 Release 696.

No programs installed/removed last month, but in W10 updates can do 
strange effects..

Thanks,



Il 29/11/2016 00:15, Bill Somerville ha scritto:
> On 28/11/2016 23:05, Alessandro Gorobey wrote:
>> the installed QT is part of JTSDK, no other additional QT's are
installed.
>> I'm absolute sure that download work last month. I have file dated in
>> last days of October in two profiles.
>
> Hi Sandro,
>
> to download files from an SSL secured server, which the download server
> is, requires the OpenSSL libraries to be installed. They are not part of
> Qt and if not already installed must be added to your system. Try:
>
> sudo apt install openssl
>
> 73
> Bill
> G4WJS.
>
>
>

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

-- 
73
Sandro
IW3RAB


--
___
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] Small bug in 1.7_RC2, Windows

[Charles Suckling]

Hi Miles

 

In r7300 it looks OK.

 

Charlie, G3WDG

 

  _  

From: Miles Treacher [mailto:mi...@treacher.net] 
Sent: 08 November 2016 05:59
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] Small bug in 1.7_RC2, Windows

 

If the option to "Display distance in miles" is checked, the column header
for

distance in WSPR mode still displays as "km". Can anyone else reproduce
this?

 

G0ODS

 

- 
Miles, Dawn and Clare Treacher 
Welburn, Malton, Ryedale, England

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Lock Tx=Rx issue

[Charles Suckling]

Hi Allan

 

Yes, I also saw lock TX freq check box true after editing it to be false,
and the program behaved correctly.

 

Did you then  try unchecking it, which as I remember for me did unlock it?  

 

The original behaviour you described could then be initiated by swapping
modes and going back to JT65.

 

73

 

Charlie

 

  _  

From: Allan Downie [mailto:vk...@westnet.com.au] 
Sent: 06 November 2016 06:51
To: WSJT software development
Subject: Re: [wsjt-devel] Lock Tx=Rx issue

 

Hi Charlie and all,

Many thanks for your reply and all comments noted.

I did as you suggested, I edited the WSJT-X.ini file to change to
LockTxFreq=false.  Interestingly, after editing and saving the .ini file and
confirming that indeed the edit has taken place, closing WSJT-X and
restarting and immediately viewing the .ini file again, it has returned to
LockTxFreq=true.  All of this is in JT65 or JT9 modes.

I have subsequently discovered however, that this and the obviously related
problem originally described, does not occur in QRA64 mode, only JT9, JT65
and JT9+JT65 modes.  I think this is similar to your JT4 experience Charlie.

It gets even more interesting though. If I go to QRA64, click the 'Lock
Tx=Rx' box, such that TX and Rx are not locked (and confirm that they are
indeed unlocked), then return to either JT65 or JT9 modes, they are now not
locked either. I can exit the program and restart in JT65 with the RX and TX
frequencies remaining unlocked. This would be a work around but surely not
ideal.

I wonder if anyone else is using WSJT-X for JT65 EME?  Any similar issues?

Any help appreciated.

Cheers,

Allan
VK4EME
VK4QG





 

On 11/5/2016 12:20 AM, char...@sucklingfamily.free-online.co.uk wrote:

Hi Allan
 
I can reproduce the behaviour you see.
 
I edited one line in [common] of the .ini file as follows:
 
LockTxFreq=false
 
then saved the file and closed WSJT-X.
 
After restarting it, the tickbox appeared checked, and tx/rx frequencies
followed each other.
 
Unchecking the box made them independent, as you want.
 
All was well until I switched to JT4 (where the lock box disappears) and
reverted back to JT65.  I then can see the behaviour you have.
 
Charlie
 

Hi Joe and all,
 
I originally started this enquiry on Yahoo Groups 'wsjtgroup' and very
kindly received a possible solution from Joe K1JT. However I seem to be
having great trouble with Yahoo, so I am continuing on here. I hope that
is okay.
 
My Original posting was something like: -
 
/I currently use WSJT v10 r6088 for 70cm EME. I do not use CAT control,
instead I use a simple 2 x transformer radio to PC (win 10) interface.
Normal EME operation is to transmit with a fixed TX frequency (1500Hz
tone) and to vary the RX (Green bar) within the passband window in order
to follow / decode a particular station due to doppler. With rc2 r7265,
it appears split TX/RX can only be achieved if 'Enable VHF/UHF/Microwave
features" check-box is NOT checked. When it is checked, RX and TX are
permanently locked regardless of whether the 'Lock Tx=Rx' check-box is
checked or not. //Strangely, the box when clicked, will show a tick
momentarily and then disappear, but remains locked. I have verified this
'fault' with a friend of mine and he has exactly the same issue. It is
not a concern for him however as he is not on EME.
 
I have uninstalled and reinstalled r7265 and the condition remains. I
HAVE read the guide and as one would expect, this is not how the
software is meant to function...see graphic 8.3.JT65
 
What have I missed, or is this a fault?
 
 
/
Subsequently, I have done as Joe advised (below) but to no avail
unfortunately.  I have also installed r7265 on another PC which has
never had any WSJT software on it previously. I have exactly the same
issue there too.
 
Your help would be most welcome,
 
Cheers,
Allan
VK4EME
/
 
/On 11/1/2016 3:53 AM, vk4eme@...   
[wsjtgroup] wrote:
 > In the current version of WSJT-X, RX and TX can be locked or unlocked
 > ONLY if the 'VHF/UHF/Microwave features" box is unchecked. When the
 > VHF/etc box is checked, RX is always locked to TX. Strangely, the box
 > when clicked, will show a tick momentarily and then disappear, but
 > remains locked.
 >
 > I have verified this with another user and he has the same issue. Maybe
 > I'm missing something, but I have read the guide and it doe! sn't
appear
 > to agree with the graphic in 8.3.JT65.
 
What you describe is not what I observe here, and is not what's
intended. As far as I can see, the documentation in Section 8.3 of the
User Guide is correct.
 
As an attempt to find out what's wrong, please try the following test
that will ensure startup with a "pristine" default setup:
 
1. With WSJT-X running in your normal way, select *Open log directory*
on the File menu.
 
2. Right-click on the file WSJT-X.ini, select *Rename*, and rename the
file to (say) WSJT-X.ini.0.
 
3. Exit WSJT-X.
 
4. Restart WSJT-X. You will need to re-enter 

Re: [wsjt-devel] call3.txt

[Charles Suckling]

Hi Bob

 

There was a discussion about this a while back, and if I recall correctly a
"safe" number of entries is approximately 10.

 

73

 

Charlie G3WDG

 

  _  

From: Bob Thornton [mailto:bob.thorn...@ntlworld.com] 
Sent: 02 November 2016 09:24
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] call3.txt

 

I think the problem here is the error message that is being generated if
call3.txt is considered too short. The required length is not specified but
3 entries is too short. The error message appears to print a random number
of times in each decode period. To avoid this I Googled and found a
populated call3.txt. That stopped the error message, but of course there
were then a couple of 'unexpected' DX spots! (I won't claim the first 2
metre transatlantic long path contact though!) I was monitoring a beacon
with a lot of aircraft Doppler.

  I think the right behaviour is to bring up the "call3.txt is too short "
message just once, but if I was only interested in spotting one beacon who
is to say what is too short?

 

Bob Thornton

G3WKW 





Date: Tue, 01 Nov 2016 19:05:37 -0400
From: Joe Taylor 
Subject: Re: [wsjt-devel] call3.txt
To: WSJT software development 
Message-ID: <58191fc1.1070...@princeton.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 11/1/2016 6:54 PM, Relu Jianu wrote:



Is there a mechanism of updating the call3.txt list?







Thanks



73 Relu NJ9R




Everyone's working habits of band, mode, location, etc., are different. 
 The callsign database is best maintained by you, yourself, using the 
"Add" button on the WSJT or WSJT-X main window.

   -- 73, Joe, K1JT



 

 

 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel