from:"Uwe, DG2YCB via wsjt\-devel"

Re: [wsjt-devel] SuperFox can have split misconfigured and make fewer QSOs (setXIT anomaly?)

2024-10-08 Thread Uwe, DG2YCB via wsjt-devel


Hi John, Charlie and all,

Here with my FT-991 it seems to work with both “Fake it” and “Rig” that
a SuperFox station is transmitting on the correct frequency now. If
anyone else wants to try it out, I've compiled a test build with Matt's
patch:
https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.7.1/Test%20versions/wsjtx-2.7.1-devel-win64_improved_PLUS_241005-RC7_001.exe

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 08.10.2024 um 12:18 schrieb John Nelson:

Hi Matt,

But what happens if after normal FT8 operation using Split-Rig instead of 
Split-Fake, then when  the switch to SuperFox is made, this will leave the rig 
with VFOB active and transmit frequency will not be 28.091 but 28.090.

The patch works for Split-Fake nicely.   But it seems the problem with 
Split-Rig remains…Am I correct?

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

Re: [wsjt-devel] SuperFox can have split misconfigured and make fewer QSOs (setXIT anomaly?)

2024-10-08 Thread Uwe, DG2YCB via wsjt-devel


Hi Matt,

Thanks for your patch. We really appreciate it when someone looks for
the cause of the undesirable effect themselves and offers a solution
instead of just complaining!

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 08.10.2024 um 00:46 schrieb Matt Power via wsjt-devel:

One way to address the single issue of a SuperFox with mismatched Tx
and Rx dial frequencies is this small change to setXIT. My
understanding is that, in the SuperFox case, setXIT still must
actively set the Tx frequency, because it may often be misconfigured
if (for example) normal FT8 had been used after WSJT-X was last
started. The setXIT function distributed in 2.7.0-rc7 does not
actively set the Tx frequency in this situation: it does set m_XIT to
zero but then skips the m_config.transceiver_tx_frequency line because
an if condition isn't met.

patch tested only with:
Rig: Hamlib NET rigctl
Network server: localhost:4532
PTT Method: CAT
Mode: Data/Pkt
Split Operation: Fake It

wsjtx built from wsjtx-2.7.0-rc7.tgz code on Ubuntu 20.04 x86_64
Hamlib Version In use:
  Hamlib 4.6-git 2024-09-26T03:35:16Z SHA=0b12c5 64-bit

Without the patch, if normal FT8 had just been used at a dial
frequency of 28.091 with Tx of 750 Hz, and now SuperFox is being used,
then the SuperFox transmits on 28.090.

With the patch in this scenario, the SuperFox transmits on 28.091.

--- widgets/mainwindow.cpp.old  2024-10-07 21:57:26.195726422 +
+++ widgets/mainwindow.cpp  2024-10-07 21:57:29.564032173 +
@@ -8595,6 +8595,17 @@
  m_config.transceiver_tx_frequency (m_freqTxNominal + 
m_astroCorrection.tx);
}
}
+  if (SpecOp::FOX==m_specOp && m_config.superFox()
+  && (m_monitoring || m_transmitting)
+  && m_config.is_transceiver_online ())
+  {
+// the transceiver Tx dial frequency must be consistent with
+// zero m_XIT for SuperFox
+m_freqTxNominal = base;
+if (m_astroWidget) m_astroWidget->nominal_frequency (m_freqNominal, 
m_freqTxNominal);
+m_config.transceiver_tx_frequency (m_freqTxNominal + 
m_astroCorrection.tx);
+  }
+
//Now set the audio Tx freq
Q_EMIT transmitFrequency (ui->TxFreqSpinBox->value () - m_XIT);
  }

Matt, KA1R


___
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] MacOS Sequoia loosing audio input

2024-09-23 Thread Uwe, DG2YCB via wsjt-devel


Hi Arkadiusz,

Thanks for your helpful bug report. I have removed this line. Also from
my point of view, it makes little sense and is even risky under certain
circumstances.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 22.09.2024 um 13:01 schrieb Arkadiusz Miśkiewicz via wsjt-devel:


Hello.

After upgrade from MacOS Sonoma to MacOS Sequoia (the rest of the
hardware/software setup is exactly the same) one thing has changed.
First wsjt-x transmission stops input audio.

Tests done on wsjt-x 2.7.0 rc6

Everything worked fine on MacOS Sonoma, so likely Sequoia changed
something that is a Sequoia bug or it triggers wsjtx bug.

It looks like this:
- starting the wsjt-x app, it receives audio, microphone icon appears
on macos menubar
- enable tx, transmission starts, microphone icon is there on menubar
for the whole transmission
- transmission ends, microphone icon disappears from macos menubar
- wsjt-x continues to try to decode incoming data but it can't do that
since it no longer receives the audio, 0dB on bar etc.
- changing anything in settings->audio recovers the thing (microphone
icon is back, wsjtx again sees and decodes incoming data). Probably
changing things there cause reopening of audio stream. Until next
transmission.
- in macos logs I see that macos report audio being closed but somehow
wsjt-x doesn't notice that

Now I've tracked that to this part of code (below).

Dropping m_stream.reset() call makes the problem on Sequoia go away.
I'm able to make multiple transmissions and input audio doesn't get
lost (microphone icon on macos bar is there all the time).

Audio/soundout.cpp

void SoundOutput::stop ()
{
  if (m_stream)
    {
  m_stream->reset ();
  m_stream->stop ();
    }
  m_stream.reset (); // <--- dropping this reset makes problem go
away
}

It was added in 2020:

commit 542ffe83112c16e9a56fe946c496c8b4973683ff
Author: Bill Somerville 
Date:   Sun Sep 20 18:20:16 2020 +0100

    Improve audio device handling and error recovery


The question is is that reset call correctly done there in that way
and the bug is in Sequoia or is it a wrong call?

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

Re: [wsjt-devel] ft8code -c (minor bug)

2024-08-14 Thread Uwe, DG2YCB via wsjt-devel


Hi Pengo,

No, the Git repo at SourceForge is not our working directory. That is
why merge requests do not work. Better send us your patch (diff file) by
e-mail.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 14.08.2024 um 12:21 schrieb Pengo VK3PGO via wsjt-devel:

I had a go at submitting this as a git pull request. I thought I'd try
this fairly trivial bug fix before trying to submit others. I went as
far as to get it to compile on Linux to test it.

I've added some details and also patched ft4code, which makes mention
of the same vestigial -c parameter.

The PR is here: https://sourceforge.net/p/wsjt/wsjtx/merge-requests/17/

If this git repo isn't the right place to submit PRs please let me know.

VK3PGO


___
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] Update after v2.7.0-rc6

2024-08-03 Thread Uwe, DG2YCB via wsjt-devel


Hi John,

If you have an M1 or M2, I recommend the 240730 version of my i+ version
of WSJT-
X
.
This should fix the problems on certain macOS versions (i.e. no more
crashes with SF or MSK144). If you have a Mac with Intel CPU, we would
have to ask John to compile a Darwin package from the 240730 code.
However, he is currently on vacation and can therefore only work to a
limited extent.

No new version is planned for our standard WSJT-X, by the way.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 02.08.2024 um 21:02 schrieb John Stengrevics via wsjt-devel:

Will there be an update before the Palmyra DXxpedition next week?  I am looking 
specifically for a fix for the Mac version.

73,

John
WA1EAZ

___
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] ALSA sound

2024-07-23 Thread Uwe, DG2YCB via wsjt-devel

Jarmo,

Mike meant: Those don't have "CARD" in there. See this topic on our WSJT
GROUP forum  for more
information. But I think we'll make it an optional feature.

73 de Uwe, DG2YCB

Am 23.07.2024 um 18:00 schrieb Black Michael via wsjt-devel:

Those don't have "CODE:" in there -- we're talking an exact match to
those 5 characterscolon included...
It's being implemented in WSJT-X improved and will both sort entries
and remove the CODE: ones -- there are two checkboxes for sort and
removal you can turn off if it suits you.  It removes a whole bunch of
unneeded entries in Linux.  Also removing any device that doesn't
support our format (not that many of those).

Mike W9MDB

On Tuesday, July 23, 2024 at 10:54:20 AM CDT, jarmo 
wrote:

Tue, 23 Jul 2024 03:41:52 + (UTC)
Black Michael via wsjt-devel 
kirjoitti:

> I'm only looking for anybody using a sound device with "CODE:" in the
> name.
>
> Mike W9MDB

If you mean these
alsa_input.usb_BurrBrown_from_Texas_Instruments_USB_AUDIO_CODEC-00.analog-stereo
alsa_output.usb_BurrBrown_from_Texas_Instruments_USB_AUDIO_CODEC-00.analog-stereo

Kenwood TS-890s
Fedora 40

Jarmo, oh1mrr

___
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] Super Issue on Apple MAC with M1 Processor

2024-07-14 Thread Uwe, DG2YCB via wsjt-devel


Dan, Scott, Gary and all,

Perhaps one more addition: The Mac users within our Dev Team will
hopefully find a solution until a future Release Candidate 6. I don't
have a Mac computer myself, but I have spent dozens of hours trying to
find a solution for you Mac users too over the past days. For WSJT-X as
well as for my i*+ versions, and for x86_64 as well as for Apple Silicon
(i.e. arm64). However, this doesn't make sense anymore as I cannot test
it thoroughly beforehand myself. I will now focus my activities on
Windows, Linux and the Raspberry Pi again.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 14.07.2024 um 19:43 schrieb Uwe, DG2YCB via wsjt-devel:

Hi Dan,

Unfortunately, also for our standard WSJT-X we are not yet able to
offer a solution for this error.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 14.07.2024 um 12:23 schrieb Dan Merrifield via wsjt-devel:

I’m running an Apple Mac Studio with an Apple M1 CPU. Software is
12.7.4. WSJTX 2.7.0 RC5

It will not decode super fox signals and gives the following error
code: Subprocess Error, Subprocess failed with exit code 2. When you
click on this error message, the program closes.

I works fine in the non super fox, normal FT8 mode.

Dan Merrifield K1DQ
k...@metrocast.net


___
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] Super Issue on Apple MAC with M1 Processor

2024-07-14 Thread Uwe, DG2YCB via wsjt-devel


Hi Dan,

Unfortunately, also for our standard WSJT-X we are not yet able to offer
a solution for this error.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 14.07.2024 um 12:23 schrieb Dan Merrifield via wsjt-devel:

I’m running an Apple Mac Studio with an Apple M1 CPU. Software is
12.7.4. WSJTX 2.7.0 RC5

It will not decode super fox signals and gives the following error
code: Subprocess Error, Subprocess failed with exit code 2. When you
click on this error message, the program closes.

I works fine in the non super fox, normal FT8 mode.

Dan Merrifield K1DQ
k...@metrocast.net


___
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] MacOS - error in SuperFox mode

2024-07-14 Thread Uwe, DG2YCB via wsjt-devel


Hi Gary,

Unfortunately, we are not yet able to offer a solution. We thought we
had one, but the hoped-for solution did not produce the desired results.
I will therefore no longer offer specific M1 versions for my i*+
variants of WSJT-X until further notice.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 14.07.2024 um 17:39 schrieb Gary Rogers via wsjt-devel:

Not sure if this is helpful but I am using
https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.7.1/macOS/wsjtx-2.7.1-devel_improved_AL_PLUS_240712_M1.zip/download
 and
am NOT having the subprocess error reported by other Mac users in
Superhound mode. MacBook Pro M2 chip Sonoma 14.6 (beta). I was just
monitoring many European stations working K8R on 18.095 MHz but could
not copy him (probably because of propagation). I am able to transmit
with my FTDX-10 so my setup  seems to be working properly.



On Jul 14, 2024, at 10:31 AM, V. Scott Moore via wsjt-devel
 wrote:

All:

Forgive me if this has already been reported as I have not been
paying attention to the list lately.

Error window:

*Subprocess Error*
*Subprocess failed with exit code 2*

Details:

Running: /Applications/wsjtx 2.7.0-rc5.app/Contents/MacOS/jt9 -s
WSJT-X -w 1 -m 3 -e "/Applications/wsjtx
2.7.0-rc5.app/Contents/MacOS" -a "/Users/vsmoore2/Library/Application
Support/WSJT-X" -t
/private/var/folders/qz/n31h0drj3xv4yytwk6k3316wgn/T/WSJT-X
sh: /Applications/wsjtx: No such file or directory
Fortran runtime error: EXECUTE_COMMAND_LINE: Invalid command line

Error termination. Backtrace:
#0  0x115bd48ee
#1  0x115bd55d5
#2  0x115bd5a18
#3  0x115e345e2
#4  0x115e34809
#5  0x115e348b1
#6  0x1005a4309

Mac Studio M1 Max 32Gig
Sonoma Version 14.0 (23A344)

Error happens in Hound superfox mode at the end of the first full
decode cycle.

When the deadly “OK” button is selected to close the error window the
program crashes.

Scott
W1SSN
“Got time to breath, got time for music” - Brisco Darling



___
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 v2.7.1-devel 240712 improved widescreen PLUS => Crash in SuperHound mode

2024-07-13 Thread Uwe, DG2YCB via wsjt-devel


Hi Kari and all,

Unfortunately, this means that our commit a87aacf has not yet completely
fixed this error (which we had hoped for), because the "240712" code
already has this commit.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 13.07.2024 um 09:28 schrieb Adrian via wsjt-devel:


Kari, ok, I thought you have have just built without install if you
run differrent wsjtx versions like I do,

running from the build folder.

I had that type of error in my case, but it also said it could not
find sfrx.

Sorry I could not help more.

73

vk4tux

On 13/07/2024 5:20 pm, Kari Sillanmäki wrote:

TNX Adrian,

but those files are already in place

  ls -l
yhteensä 768
-rwxr-xr-x 1 joe joe  10160 18. 6. 11:59 foxchk
-rwxr-xr-x 1 joe joe 287728 18. 6. 11:59 sfrx
-rwxr-xr-x 1 joe joe 255944 18. 6. 11:59 sftx

$ ls -l /usr/bin/foxchk /usr/bin/sfrx /usr/bin/sftx
-rwxr-xr-x 1 root root  10160 18. 6. 11:59 /usr/bin/foxchk
-rwxr-xr-x 1 root root 287728 18. 6. 11:59 /usr/bin/sfrx
-rwxr-xr-x 1 root root 255944 18. 6. 11:59 /usr/bin/sftx

'Kari
On 7/13/24 10:06, Adrian wrote:


If you compiled from source ; In your

wsjtx-2.7.0/wsjtx-prefix/src/wsjtx/lib

path, copy the superfox/arm (or whatever matches your OS) in
superfox folder sub OS type folder section files (3) to the

other wsjtx program executable's path, eg where wsjtx is...

usually these will be

foxchk

sfrx

sftx

73

vk4tux

On 13/7/24 16:35, Kari Sillanmäki via wsjt-devel wrote:


Hi,

SuperHound mode crashed with runtime error:

Computer: Raspberry Pi 4

OS: Debian GNU/Linux 12 (bookworm) 64 bit

Radio: ICOM IC7300

I left system running overnight and this morning I was greeted by
the error message above...

73 de Kari, oh2gqc



___
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] Adjustable frequency shift for split operation?

2024-07-06 Thread Uwe, DG2YCB via wsjt-devel


Richard,

Please email me the settings you have made for the various menu items on
your FT-991A. I have an FT-991 (without the "A"), and I don't have such
problems with the bandwidth. I therefore suspect that either something
is wrong with your rig or with your settings.

73 de Uwe, DG2YCB

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

Re: [wsjt-devel] Question about transmit hazard via mouse wheel

2024-06-03 Thread Uwe, DG2YCB via wsjt-devel


Hi Glenn,

Okay, then I don't think we need to change anything in our code. The
theoretically conceivable case you described is already covered.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 02.06.2024 um 23:56 schrieb Glenn Williams:

Hi Uwe,

My question was from ignorance.  I did not want to test my equipment
to find out. But if the problem could happen, somewhere someone will
experience it. Perhaps the coders already took care of the hazard, but
then I thought i would ask.

--73, Glenn, AF8C

On 6/2/2024 11:21 AM, Uwe, DG2YCB wrote:

Hi Glenn,

One question: Are your considerations theoretical or have you
actually found that you stay transmitting when you make a such band
change? Because I have just tried to reproduce this. Result: WSJT-X
stopped transmitting immediately when I changed the band during
transmission.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 01.06.2024 um 21:04 schrieb Glenn Williams via wsjt-devel:


This is a quote from the User Guide:

"Sliders and spinner controls respond to Arrow key presses and Page
Up/Down key presses, with the Page keys moving the controls in
larger steps. You can also type numbers directly into the spinner
controls or use the mouse wheel."



I recently discovered that the mouse wheel, besides being useful on
the spinners, can be placed on the band setting control box and then
be used for instant band up/down changes while receiving. On
transceivers with control via USB cable, such as TS590SG and IC7300,
the transceiver's CAT serial cable port can be used to control the
band a linear is on via a separate cable built for that purpose.
Thusly, spinning the mouse wheel in the band selection control box
will instantly switch transceiver AND linear to any band of choice.

So my question is, IF the system is currently transmitting and that
little box is tickled with the mouse, will the mouse wheel effects
be ignored by the software, or will the band be instantly switched? 
That can be hazardous for the linear or transceiver in the case of
antenna mismatch high VSWR coming into play on the new band.

--Glenn






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

Re: [wsjt-devel] Question about transmit hazard via mouse wheel

2024-06-02 Thread Uwe, DG2YCB via wsjt-devel


Hi Glenn,

One question: Are your considerations theoretical or have you actually
found that you stay transmitting when you make a such band change?
Because I have just tried to reproduce this. Result: WSJT-X stopped
transmitting immediately when I changed the band during transmission.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 01.06.2024 um 21:04 schrieb Glenn Williams via wsjt-devel:


This is a quote from the User Guide:

"Sliders and spinner controls respond to Arrow key presses and Page
Up/Down key presses, with the Page keys moving the controls in larger
steps. You can also type numbers directly into the spinner controls or
use the mouse wheel."



I recently discovered that the mouse wheel, besides being useful on
the spinners, can be placed on the band setting control box and then
be used for instant band up/down changes while receiving. On
transceivers with control via USB cable, such as TS590SG and IC7300,
the transceiver's CAT serial cable port can be used to control the
band a linear is on via a separate cable built for that purpose.
Thusly, spinning the mouse wheel in the band selection control box
will instantly switch transceiver AND linear to any band of choice.

So my question is, IF the system is currently transmitting and that
little box is tickled with the mouse, will the mouse wheel effects be
ignored by the software, or will the band be instantly switched?  That
can be hazardous for the linear or transceiver in the case of antenna
mismatch high VSWR coming into play on the new band.

--Glenn


___
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.7.0-rc4

2024-03-11 Thread Uwe, DG2YCB via wsjt-devel


Hi Dwayne,

It should now work. Make sure you clear your browser cache before
downloading the file again.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 11.03.2024 um 18:03 schrieb Uwe, DG2YCB via wsjt-devel:

Will check this.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 11.03.2024 um 17:55 schrieb Dwayne Sinclair via wsjt-devel:

The Darwin disk image for RC4 is corrupt. Only has a 281 byte file size.

Dwayne AB6A


On Mar 11, 2024, at 7:57 AM, Joe Taylor via 
wsjt-devel  wrote:

Dear WSJT-X Users,

We are pleased to announce that Release Candidate WSJT-X 2.7.0-rc4 is ready for 
download and use by beta testers.

WSJT-X 2.7.0 Release Candidate 4 includes new features (especially for 
companion program QMAP) as well as bug fixes.  A full list of enhancements can 
be found in the Release Notes:

___
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] Release Candidate WSJT-X 2.7.0-rc4

2024-03-11 Thread Uwe, DG2YCB via wsjt-devel


Will check this.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 11.03.2024 um 17:55 schrieb Dwayne Sinclair via wsjt-devel:

The Darwin disk image for RC4 is corrupt. Only has a 281 byte file size.

Dwayne AB6A


On Mar 11, 2024, at 7:57 AM, Joe Taylor via 
wsjt-devel  wrote:

Dear WSJT-X Users,

We are pleased to announce that Release Candidate WSJT-X 2.7.0-rc4 is ready for 
download and use by beta testers.

WSJT-X 2.7.0 Release Candidate 4 includes new features (especially for 
companion program QMAP) as well as bug fixes.  A full list of enhancements can 
be found in the Release Notes:



___
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] Updated swedish translation of WSJT-X user guide..

2024-03-05 Thread Uwe, DG2YCB via wsjt-devel


Hi Anders,

You can send such files to me.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 05.03.2024 um 15:53 schrieb Anders Rhodin via wsjt-devel:

Good day all,

I have an updated Swedish translation of the user guide ready to be
shared on the WSJT-X homepage if desired.
In addition I also have a Swedish translation of the DXpedition user
guide.

Who is to receive the files for publishing?

// 73 de SM7VRZ




___
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] Another fun hash collision P97USI

2024-02-27 Thread Uwe, DG2YCB via wsjt-devel


Jon and all,

For your information, we have already made two modifications to our
WSJT-X code that significantly reduce the likelihood of 10-bit hash
collisions occurring. The few OMs who are currently testing this have
all reported positive results. These improvements will be rolled out to
everyone with the upcoming Release Candidate 4.

In the example you reported, however, it also looks like a false decode
to me.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 27.02.2024 um 01:50 schrieb Jon Anhold via wsjt-devel:

231900 16 0.4 909 ~ BG2AUE  -25 Aruba
232530 5 0.4 909 ~ JR3UIC RR73; JA7WND  +06 DPR of Korea

Maybe some logic that checks "am I *really* North Korea?" would be good :)

73 de KM8V Jon


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

Re: [wsjt-devel] 2.7.0-rc3 UI defect

2024-02-12 Thread Uwe, DG2YCB via wsjt-devel


Laurie,

I have to set other priorities at the moment. A serious illness in the
family turned into a bereavement yesterday. Therefore, only briefly:
Please try wsjt-x_improved 2.7.1-devel "240202"
.
Why? I use a different method there for expanding the mode buttons
because of the button highlighting there. If this works better with your
app scaling settings, I would want to adopt this method in our WSJT-X.
Ensure that you don't have the "Disable button coloring unless
mandatory" checkbox checked, because this switches back to the old
method. Also ensure that the window width is sufficiently wide. Our GUI
intentionally allows smaller values than Qt suggests, because otherwise
the minimum width would be too large, and the program would no longer be
usable on small screens.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 11.02.2024 um 22:10 schrieb Laurie, VK3AMA via wsjt-devel:



On 10/02/2024 4:46 pm, Alan McDonald via wsjt-devel wrote:

I set my QT scaling to 75% with good results


Where is this documented? I could not find any mention of
QT_SCALE_FACTOR or QT_AUTO_SCREEN_SCALE_FACTOR in the 2.6.1 or 2.7.0
documentation.

Setting these environment variables affects all other QT based
applications installed like JTDX and MSHV.
This should not be needed to fix one specific broken area of the Wsjtx UI.

Hopefully one of the Wsjtx devs will respond.

de Laurie VK3AMA
(JTAlert author)



___
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] Response to CQ ignored

2024-01-30 Thread Uwe, DG2YCB via wsjt-devel


I think he had this enabled, Sam. Really have no idea why it didn't work
for him, because his slightly older "231202" version should also do the
job. But the best is if Ed tries again with the upcoming "240202" code.
Just to make sure it's not something that has already been fixed.

73 de Uwe, DG2YCB

Am 30.01.2024 um 13:40 schrieb Sam W2JDB via wsjt-devel:

Hi Uwe,


I sent this email earlier, somehow it did not go through.

Hi Ed,

Make sure you have the right option selected  "CQ:First"

73,

Sam W2JDB



On Tuesday, January 30, 2024 at 06:53:47 AM EST, Uwe, DG2YCB via
wsjt-devel  wrote:


Hi Ed,

At the moment, I have no explanation why it doesn't work with the
"231202" i+ version. What I can say is that it definitely works well
with the current "240106" code, as well as with the new "240202"
version that will be released on Friday this week. I recommend that
you download this version on Friday and then see whether the error
persists or not. This version will also bring a few nice new features,
which I'll explain in the following video:
https://www.youtube.com/watch?v=1CqyIGRjbvs
<https://www.youtube.com/watch?v=1CqyIGRjbvs>

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de <mailto:dg2...@gmx.de>
Info: www.qrz.com/db/DG2YCB <http://www.qrz.com/db/DG2YCB>


Am 30.01.2024 um 00:56 schrieb Ed Stokes via wsjt-devel:

I see this over and over….

Is it me or is this a bug?

I call CQ and someone responds.  But WSJT does not answer the caller.  It 
continues to call CQ until I force it to reply.

73, Ed
W1KOK


___
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] Response to CQ ignored

2024-01-30 Thread Uwe, DG2YCB via wsjt-devel


Hi Ed,

At the moment, I have no explanation why it doesn't work with the
"231202" i+ version. What I can say is that it definitely works well
with the current "240106" code, as well as with the new "240202" version
that will be released on Friday this week. I recommend that you download
this version on Friday and then see whether the error persists or not.
This version will also bring a few nice new features, which I'll explain
in the following video: https://www.youtube.com/watch?v=1CqyIGRjbvs

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 30.01.2024 um 00:56 schrieb Ed Stokes via wsjt-devel:

I see this over and over….

Is it me or is this a bug?

I call CQ and someone responds.  But WSJT does not answer the caller.  It 
continues to call CQ until I force it to reply.

73, Ed
W1KOK
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 46

2024-01-27 Thread Uwe, DG2YCB via wsjt-devel


The "240202" code will be released on February 2, 2024.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 27.01.2024 um 14:43 schrieb Black Michael:

I don't see the 240202 update at your "find it here" link.

It points 
tohttps://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.7.1/

Mike W9MDB








On Saturday, January 27, 2024 at 04:14:00 AM CST, Uwe, DG2YCB via 
wsjt-devel  wrote:





Hi all,

Short information: Although I could not reproduce this unwanted effect so far, I have now 
added another line of code as a test for my upcoming 'improved' 2.7.1-devel 
"240202" update, which has the effect that if you are in FT8 Hound mode, all 
messages (below 1000 Hz) are really displayed in the right window if they contain your 
own callsign.

This gives us double certainty that every report or whatever will be displayed 
there in the future. However, it also has the side effect that messages to 
A1BCD, for example, are also displayed there if your own callsign is A1BC. But 
since this is only effective in hound mode, this should be acceptable, because 
all messages on your Rx QRG are displayed there anyway.

Then we can see whether this really solves the problem or not. Depending on 
this, we can decide whether we also include this additional line in our regular 
WSJT-X.

The mentioned i+ update is planned to be rolled out on February 2. Those who 
are interested in testing will find it here. As always, I am announcing 
anything about my so-called 'improved' versions via the 
wsjt-x-improved-community email reflector, as this list here is primarily 
intended for our regular versions of WSJT-X.

By the way, with the "240202" update I also plan to deactivate this strange 
function that pressing the RETURN or ENTER keys switches your transmitter on when you are 
in FT8 Hound mode, because this confuses many OMs and makes little sense, at least from 
my point of view. Tell me if there is any good reason why this was/is necessary.


73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail:dg2...@gmx.de
Info:www.qrz.com/db/DG2YCB




Am 26.01.2024 um 23:06 schrieb Andy Durbin via wsjt-devel:





"I have noticed the same thing at times while running as Hound in F/H where
the report from the Fox will appear in the Band Activity column but not in

the Rx Frequency column. I am presently running the "WSJT-X V2.7.1 devel

231031 Improved PLUS" version."



I think I have seen this once with ver 2.6.1.  F/H QSO completed ok.



I think it's rare but not new in the versions later than 2.6.1.



It's a don't care for me as I'd prefer the RX frequency to only include decodes 
at the RX frequency as designated by the RX frequency cursor.  Only commenting 
because I don't think it's a new bug.



Andy, k3wyc






___
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-devel Digest, Vol 119, Issue 46

2024-01-27 Thread Uwe, DG2YCB via wsjt-devel


Yes, but then we also have to remove the <> characters, because
otherwise it won't work for compound callsigns. But the following code
should do the job. Will be included in "240202".

...
&&decodedtext.string().replace("<","").replace(">","").contains(""+m_baseCall+"")
...

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 27.01.2024 um 14:10 schrieb Black Michael:

Should be able to use this instead.  Your call always has a space before/after.

contains(" " + m_baseCall +" "))

Mike W9MDB






On Saturday, January 27, 2024 at 04:14:00 AM CST, Uwe, DG2YCB via 
wsjt-devel  wrote:





Hi all,

Short information: Although I could not reproduce this unwanted effect so far, I have now 
added another line of code as a test for my upcoming 'improved' 2.7.1-devel 
"240202" update, which has the effect that if you are in FT8 Hound mode, all 
messages (below 1000 Hz) are really displayed in the right window if they contain your 
own callsign.

This gives us double certainty that every report or whatever will be displayed 
there in the future. However, it also has the side effect that messages to 
A1BCD, for example, are also displayed there if your own callsign is A1BC. But 
since this is only effective in hound mode, this should be acceptable, because 
all messages on your Rx QRG are displayed there anyway.

Then we can see whether this really solves the problem or not. Depending on 
this, we can decide whether we also include this additional line in our regular 
WSJT-X.

The mentioned i+ update is planned to be rolled out on February 2. Those who 
are interested in testing will find it here. As always, I am announcing 
anything about my so-called 'improved' versions via the 
wsjt-x-improved-community email reflector, as this list here is primarily 
intended for our regular versions of WSJT-X.

By the way, with the "240202" update I also plan to deactivate this strange 
function that pressing the RETURN or ENTER keys switches your transmitter on when you are 
in FT8 Hound mode, because this confuses many OMs and makes little sense, at least from 
my point of view. Tell me if there is any good reason why this was/is necessary.


73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail:dg2...@gmx.de
Info:www.qrz.com/db/DG2YCB




Am 26.01.2024 um 23:06 schrieb Andy Durbin via wsjt-devel:





"I have noticed the same thing at times while running as Hound in F/H where
the report from the Fox will appear in the Band Activity column but not in

the Rx Frequency column. I am presently running the "WSJT-X V2.7.1 devel

231031 Improved PLUS" version."



I think I have seen this once with ver 2.6.1.  F/H QSO completed ok.



I think it's rare but not new in the versions later than 2.6.1.



It's a don't care for me as I'd prefer the RX frequency to only include decodes 
at the RX frequency as designated by the RX frequency cursor.  Only commenting 
because I don't think it's a new bug.



Andy, k3wyc






___
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-devel Digest, Vol 119, Issue 46

2024-01-27 Thread Uwe, DG2YCB via wsjt-devel


Hi all,

Short information: Although I could not reproduce this unwanted effect
so far, I have now added another line of code as a test for my upcoming
'improved' 2.7.1-devel "240202" update, which has the effect that if you
are in FT8 Hound mode, all messages (below 1000 Hz) are really displayed
in the right window if they contain your own callsign.

This gives us double certainty that every report or whatever will be
displayed there in the future. However, it also has the side effect that
messages to A1BCD, for example, are also displayed there if your own
callsign is A1BC. But since this is only effective in hound mode, this
should be acceptable, because all messages on your Rx QRG are displayed
there anyway.

Then we can see whether this really solves the problem or not. Depending
on this, we can decide whether we also include this additional line in
our regular WSJT-X.

The mentioned i+ update is planned to be rolled out on February 2. Those
who are interested in testing will find it here
.
As always, I am announcing anything about my so-called 'improved'
versions via the wsjt-x-improved-community email reflector
,
as this list here is primarily intended for our regular versions of WSJT-X.

By the way, with the "240202" update I also plan to deactivate this
strange function that pressing the RETURN or ENTER keys switches your
transmitter on when you are in FT8 Hound mode, because this confuses
many OMs and makes little sense, at least from my point of view. Tell me
if there is any good reason why this was/is necessary.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 26.01.2024 um 23:06 schrieb Andy Durbin via wsjt-devel:

"I have noticed the same thing at times while running as Hound in F/H
where
the report from the Fox will appear in the Band Activity column but not in
the Rx Frequency column. I am presently running the "WSJT-X V2.7.1 devel
231031 Improved PLUS" version."

I think I have seen this once with ver 2.6.1.  F/H QSO completed ok.

I think it's rare but not new in the versions later than 2.6.1.

It's a don't care for me as I'd prefer the RX frequency to only
include decodes at the RX frequency as designated by the RX frequency
cursor.  Only commenting because I don't think it's a new bug.

Andy, k3wyc


___
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-devel Digest, Vol 119, Issue 45

2024-01-26 Thread Uwe, DG2YCB via wsjt-devel

Okay, then let's continue to observe whether we can find a pattern under
which exact conditions the unwanted effect occurs. As said, the
F/H-related part of the code in v2.7.0-rc3 (regular version) is
identical to the i+ version. This should therefore make no difference.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB

Am 26.01.2024 um 18:26 schrieb Scott Armstrong via wsjt-devel:

I saw the same behavior over the past few days while working TX5S.

I am running 2.7.0-rc3 (regular version) not the improved version.

My first thoughts were that it was due to the Rx green goalpost in the
waterfall being over a different stream than the one sending the response.

I have no means of testing this scenario. So at this point, it is only
an observation.

-Scott AA5AM

On Fri, Jan 26, 2024, 10:12 AM Gary Rogers via wsjt-devel
wrote:

I had the same thing happen as with Fred.

Improved rc3 for Mac M1

Sent from my iPhone

On Jan 26, 2024, at 11:00 AM, Fred Price via wsjt-devel
wrote:

Screenshot of it happening to me with TX5S.

On Jan 26, 2024, at 10:51 AM, Uwe, DG2YCB via wsjt-devel
wrote:

But it worked also when I set my Rx QRG manually 275 Hz next
to the Fox offset.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB <http://www.qrz.com/db/DG2YCB>

Am 26.01.2024 um 16:44 schrieb Black Michael:

Perhaps when the fox offset for your callsign changes?
I think I've seen that.

On Friday, January 26, 2024 at 09:15:37 AM CST, Uwe, DG2YCB via
wsjt-devel
<mailto:wsjt-devel@lists.sourceforge.net> wrote:

Hi Rich,

Last night I ran some tests with our good old standard WSJT-X (latest code)
using three instances all connected via virtual audio. One in FT8 Fox mode and
the other two in FT8 Hound mode. Then I simulated just such QSO situations, but
each time the reports appeared in the right-hand window of the two Hound
stations. Not a single issue, even if I set the Rx frequency next to the Fox's
audio signal. So, at the moment I can't reproduce this unwanted effect.

Please note that the "231031" code of 2.7.1-devel has received several updates in the meantime.
Test it again with the current "240106" code, or with the soon-to-be released "240202"
code. With the latter I will repeat the same test from last night.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail:dg2...@gmx.de
Info:www.qrz.com/db/DG2YCB <http://www.qrz.com/db/DG2YCB>

Am 26.01.2024 um 15:18 schrieb Rich - K1HTV via wsjt-devel:

I have noticed the same thing at times while running as Hound in F/H where the report
from the Fox will appear in the Band Activity column but not in the Rx Frequency column.I
am presently running the "WSJT-X V2.7.1 devel 231031 Improved PLUS" version.

Also, when the "Start new period decodes at top" checkbox is checked, many
times a day the background color will change from white to another background color. When
this occurs it is not always the same color.

Also, at times when using the "Start new period decodes at top" option,
the Band activity columns display will revert back to the earliest decodes, often many
tens of minutes earlier.

73,

Rich - K1HTV

On Fri, Jan 26, 2024 at 7:55 AM
<mailto:wsjt-devel-requ...@lists.sourceforge.net> wrote:

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."
Today's Topics:

1. skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn Williams)

-- Forwarded message --
From: Glenn Williams
<mailto:a...@alumni.caltech.edu>
To:wsjt-devel@lists.sourceforge.net
Cc:
Bcc:
Date: Thu, 25 Jan 2024 08:12:51 -0500
Subject: [wsjt-devel] skips RX frequency window (bug?) wsjtx-2.7.0-rc3
V 2.7.0-rc3
Last night worked FT8 F/H with TX5S 80m. Rig TS590SG, PC Win 10. (This
has happened once or twice before.) His S/N report on me popped up in
Band Act window after my TX1, but no rep

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45

2024-01-26 Thread Uwe, DG2YCB via wsjt-devel

But it worked also when I set my Rx QRG manually 275 Hz next to the Fox
offset.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB

Am 26.01.2024 um 16:44 schrieb Black Michael:

Perhaps when the fox offset for your callsign changes?
I think I've seen that.

On Friday, January 26, 2024 at 09:15:37 AM CST, Uwe, DG2YCB via
wsjt-devel wrote:

Hi Rich,

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail:dg2...@gmx.de
Info:www.qrz.com/db/DG2YCB

Am 26.01.2024 um 15:18 schrieb Rich - K1HTV via wsjt-devel:

Also, at times when using the "Start new period decodes at top" option, the
Band activity columns display will revert back to the earliest decodes, often many tens
of minutes earlier.

73,

Rich - K1HTV

On Fri, Jan 26, 2024 at 7:55 AM
wrote:

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."
Today's Topics:

1. skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn Williams)

-- Forwarded message --
From: Glenn Williams
To:wsjt-devel@lists.sourceforge.net
Cc:
Bcc:
Date: Thu, 25 Jan 2024 08:12:51 -0500
Subject: [wsjt-devel] skips RX frequency window (bug?) wsjtx-2.7.0-rc3
V 2.7.0-rc3
Last night worked FT8 F/H with TX5S 80m. Rig TS590SG, PC Win 10. (This
has happened once or twice before.) His S/N report on me popped up in
Band Act window after my TX1, but no report in RX Freq window. TX3
completed OK in both Windows. I use COLORS and so red was instantly
obvious. Antenna is 160m inv-L about 360 feet away. Power on the order
of 450 watts with tuner. Not thinking RFI because no other times ever I
see any.

-73, Glenn, AF8C
--

--
This email has been checked for viruses by Avast antivirus software.
www.avast.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] wsjt-devel Digest, Vol 119, Issue 45

2024-01-26 Thread Uwe, DG2YCB via wsjt-devel


Rick,

Just completed the same test with the i+ 2.7.1-devel "240202" code.
Identical results as with our standard WSJT-X v2.7.0-rc3 (not
surprising, since this part of the code is identical). Not a single
issue, all messages to the own callsign were displayed correctly in the
right window. So, I can really not reproduce this unwanted effect.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 26.01.2024 um 16:12 schrieb Uwe, DG2YCB via wsjt-devel:

Hi Rich,

Last night I ran some tests with our good old standard WSJT-X (latest
code) using three instances all connected via virtual audio.  One in
FT8 Fox mode and the other two in FT8 Hound mode. Then I simulated
just such QSO situations, but each time the reports appeared in the
right-hand window of the two Hound stations. Not a single issue, even
if I set the Rx frequency next to the Fox's audio signal. So, at the
moment I can't reproduce this unwanted effect.

Please note that the "231031" code of 2.7.1-devel has received several
updates in the meantime. Test it again with the current "240106" code,
or with the soon-to-be released "240202" code. With the latter I will
repeat the same test from last night.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 26.01.2024 um 15:18 schrieb Rich - K1HTV via wsjt-devel:

I have noticed the same thing at times while running as Hound in F/H
where the report from the Fox will appear in the Band Activity column
but not in the Rx Frequency column.I am presently running the "WSJT-X
V2.7.1 devel 231031 Improved PLUS" version.

Also, when the "Start new period decodes at top" checkbox is checked,
many times a day the background color will change from white to
another background color. When this occurs it is not always the same
color.

Also, at times when using  the  "Start new period decodes at top"
option, the Band activity columns display will revert back to the
earliest decodes, often many tens of minutes earlier.

73,
Rich - K1HTV


On Fri, Jan 26, 2024 at 7:55 AM
 wrote:

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."
Today's Topics:

   1.  skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn
Williams)



-- Forwarded message --
From: Glenn Williams 
To: wsjt-devel@lists.sourceforge.net
Cc:
Bcc:
Date: Thu, 25 Jan 2024 08:12:51 -0500
Subject: [wsjt-devel]  skips RX frequency window (bug?)
wsjtx-2.7.0-rc3
V 2.7.0-rc3
Last night worked FT8 F/H with TX5S 80m.  Rig TS590SG, PC Win 10.
(This
has happened once or twice before.)  His S/N report on me popped
up in
Band Act window after my TX1, but no report in RX Freq window. TX3
completed OK in both Windows.  I use COLORS and so red was instantly
obvious.  Antenna is 160m inv-L about 360 feet away.  Power on
the order
of 450 watts with tuner. Not thinking RFI because no other times
ever I
see any.

-73, Glenn, AF8C
--

--
This email has been checked for viruses by Avast antivirus software.
www.avast.com <http://www.avast.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
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjt-devel Digest, Vol 119, Issue 45

2024-01-26 Thread Uwe, DG2YCB via wsjt-devel


Hi Rich,

Last night I ran some tests with our good old standard WSJT-X (latest
code) using three instances all connected via virtual audio.  One in FT8
Fox mode and the other two in FT8 Hound mode. Then I simulated just such
QSO situations, but each time the reports appeared in the right-hand
window of the two Hound stations. Not a single issue, even if I set the
Rx frequency next to the Fox's audio signal. So, at the moment I can't
reproduce this unwanted effect.

Please note that the "231031" code of 2.7.1-devel has received several
updates in the meantime. Test it again with the current "240106" code,
or with the soon-to-be released "240202" code. With the latter I will
repeat the same test from last night.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 26.01.2024 um 15:18 schrieb Rich - K1HTV via wsjt-devel:

I have noticed the same thing at times while running as Hound in F/H
where the report from the Fox will appear in the Band Activity column
but not in the Rx Frequency column.I am presently running the "WSJT-X
V2.7.1 devel 231031 Improved PLUS" version.

Also, when the "Start new period decodes at top" checkbox is checked,
many times a day the background color will change from white to
another background color. When this occurs it is not always the same
color.

Also, at times when using  the  "Start new period decodes at top"
option, the Band activity columns display will revert back to the
earliest decodes, often many tens of minutes earlier.

73,
Rich - K1HTV


On Fri, Jan 26, 2024 at 7:55 AM
 wrote:

Send wsjt-devel mailing list submissions to
wsjt-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
or, via email, send a message with subject or body 'help' to
wsjt-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
wsjt-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wsjt-devel digest..."
Today's Topics:

   1.  skips RX frequency window (bug?) wsjtx-2.7.0-rc3 (Glenn
Williams)



-- Forwarded message --
From: Glenn Williams 
To: wsjt-devel@lists.sourceforge.net
Cc:
Bcc:
Date: Thu, 25 Jan 2024 08:12:51 -0500
Subject: [wsjt-devel]  skips RX frequency window (bug?)
wsjtx-2.7.0-rc3
V 2.7.0-rc3
Last night worked FT8 F/H with TX5S 80m.  Rig TS590SG, PC Win 10.
(This
has happened once or twice before.)  His S/N report on me popped
up in
Band Act window after my TX1, but no report in RX Freq window. TX3
completed OK in both Windows.  I use COLORS and so red was instantly
obvious.  Antenna is 160m inv-L about 360 feet away.  Power on the
order
of 450 watts with tuner. Not thinking RFI because no other times
ever I
see any.

-73, Glenn, AF8C
--

--
This email has been checked for viruses by Avast antivirus software.
www.avast.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] I have in trouble JT65B of WSJT-X

2024-01-05 Thread Uwe, DG2YCB via wsjt-devel


Hi Taka,

I recommend you some systematic testing.

1. First, start just the instance which you use for your JT65B
   transmissions. It should work without any problem.
2. Start your second instance (the other polarization level for JT65B).
   See if it still works. (It should.)
3. Then start your other instances one after the other and check
   whether it still works or not.
4. Once you have found out which instance breaks it, take a closer look
   at its settings. First check whether you have really specified the "
   --rig-name=InstanceNameXYZ" parameter correctly. If this is really
   correct, check the other settings to see what is different from the
   others.

I can confirm that it basically works if you control an audio port from
several instances. At least with my FT-991 it also works with WSJT-X and
JTDX next to each other (respectively with the 'improved' versions).

Or are you transmitting with both instances at the same time? I haven't
tried this yet, but I don't think it makes sense because the audio
signals are not time-synchronized.

Also consider whether you really need so many instances running at the
same time. As I wrote to you before, other OMs solve the problem with H
and V by simply having the QRGs of the two down converters slightly
different (e.g. 1 or 2 kHz apart) and then mixing the audio signals.
Then you can transmit and receive both polarization levels with one
WSJT-X instance. Because the more complex the setup, the more
error-prone it becomes.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 05.01.2024 um 13:44 schrieb JP3EXR via wsjt-devel:


Hi Uwe and the wsjt development team.

Thank you for supporting us with our JT65B problem.

I sent two emails about my situation.

Probably my settings is different from other stations.

I ask you the following question.

I have 6 icons and I have 6 folders under AppData Local of two JT65B
for H and V-pol, Q65A for H and V-pol and FT8 for H and V-pol of WSJT-X.

And I have 2 icons and I have 2 folders under AppData Local of two FT8
for H and V-pol of JTDX.

So I have their 8 folders under AppData Local, are those folders
causing trouble?

And I use the output all of the audio port are the same port as H and
V-pol for each WSJT and JTDX.

This is because I just use one side of TX which both IC-746pro.

Of course, I use it the same as WSJT-X and JTDX.

Is it okay to use the output audio port of the only one port to all of
the instances as share on one PC?

Taka, JP3EXR

*From:*Uwe, DG2YCB via wsjt-devel 
*Sent:* Friday, January 5, 2024 7:44 PM
*To:* WSJT software development 
*Cc:* Uwe, DG2YCB 
*Subject:* Re: [wsjt-devel] I have in trouble JT65B of WSJT-X

Hi Taka, Larry, and all

I would really like to help you, but the error simply does not occur
on my PC. I have run numerous tests with two instances this morning.
Both with WSJT-X v2.6.1 and v2.7.0-rc3 and with wsjt-x_improved
v2.7.1-devel. I tested various settings (EME delay on/off, with FT-991
CAT control vs without (i.e. CAT = None), real transmission via
antenna vs virtual audio, and so on). Result: There was *not a single
case* where this error occurred. It always worked perfectly with
JT65B, and with the other modes. The decode button did not get stuck,
and I was also able to decode my own transmissions from the first
instance with the second one without any problems when using my
virtual audio cable. (Due to time constraints, I only tested the
latter for my 2.7.1-devel version).

Very important: The error that the second instance hangs after you
have transmitted with the first one (visible by the fact that the
Decode button remains cyan) always occurs if not both instances were
started with the " --rig-name=InstanceNameXYZ" parameter but only the
second one. In this case, the "zeroth" instance (that without the "
--rig-name..." parameter) shoots down all the others. So please make
sure once again that this is not the case. Perhaps caused by a
spelling mistake (" -rig-name..." instead of " --rig-name..." or
something like that).


73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB <http://www.qrz.com/db/DG2YCB>

Am 05.01.2024 um 04:19 schrieb Larry Davis via wsjt-devel:

i can run any of the other modes msk q65 but to try to run 2 jt65b
on the same computer one tx and one rxing the second one hang up
on decode you can run one all day long no problem i just stoped
running two version of jt65b

On Thursday, January 4, 2024 at 08:27:45 PM CST, Larry Davis via
wsjt-devel 
<mailto:wsjt-devel@lists.sourceforge.net> wrote:

i don,t think it is a problem with the computer i ran into same
problem with 13900k 64 gb of ram with 2 wsjtx open o

Re: [wsjt-devel] I have in trouble JT65B of WSJT-X

2024-01-05 Thread Uwe, DG2YCB via wsjt-devel


Hi Taka, Larry, and all

I would really like to help you, but the error simply does not occur on
my PC. I have run numerous tests with two instances this morning. Both
with WSJT-X v2.6.1 and v2.7.0-rc3 and with wsjt-x_improved v2.7.1-devel.
I tested various settings (EME delay on/off, with FT-991 CAT control vs
without (i.e. CAT = None), real transmission via antenna vs virtual
audio, and so on). Result: There was *not a single case* where this
error occurred. It always worked perfectly with JT65B, and with the
other modes. The decode button did not get stuck, and I was also able to
decode my own transmissions from the first instance with the second one
without any problems when using my virtual audio cable. (Due to time
constraints, I only tested the latter for my 2.7.1-devel version).

Very important: The error that the second instance hangs after you have
transmitted with the first one (visible by the fact that the Decode
button remains cyan) always occurs if not both instances were started
with the " --rig-name=InstanceNameXYZ" parameter but only the second
one. In this case, the "zeroth" instance (that without the "
--rig-name..." parameter) shoots down all the others. So please make
sure once again that this is not the case. Perhaps caused by a spelling
mistake (" -rig-name..." instead of " --rig-name..." or something like
that).

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 05.01.2024 um 04:19 schrieb Larry Davis via wsjt-devel:


i can run any of the other modes msk q65 but to try to run 2 jt65b on
the same computer one tx and one rxing the second one hang up on
decode you can run one all day long no problem i just stoped running
two version of jt65b
On Thursday, January 4, 2024 at 08:27:45 PM CST, Larry Davis via
wsjt-devel  wrote:


i don,t think it is a problem with the computer i ran into same
problem with 13900k 64 gb of ram with 2 wsjtx open on jt65b second
computer 14900k 64gb of ram  same problem  i just think it a bug when
you run 2 wsjtx the second one hang up on decodes


*From:* JP3EXR via wsjt-devel 
*Sent:* Thursday, January 4, 2024 5:28 PM
*To:* 'Black Michael' ;
wsjt-devel@lists.sourceforge.net 
*Cc:* JP3EXR 
*Subject:* Re: [wsjt-devel] I have in trouble JT65B of WSJT-X
Hi Mike W9MDB

Good morning from Japan.
Thank you for your cooperation.

Thank you for asked me about my current PC spec.
You are able to see the attached picture of my current PC specification.
My current PC has 16GB memory and CPU has i7-4790K.

I used an older PC has 8GB memory and i5 CPU for WSJT-X.
I thought that my JT65B in problem was caused by the slow speed of my
old PC.
So I was thinking the same thing as Mike until November last year.
I thought I was able to solve my JT65B problem by replacing it with
the current faster PC.
Then I replaced my older PC to my current PC in November last year.
But unfortunately, my in problem with run two JT65B cannot be resolved
at this time.

I will test the advice you gave me yesterday on my WSJT PC today.
Then I will also email you of the test results.

Thank you

Taka, JP3EXR

-Original Message-
From: Black Michael 
Sent: Friday, January 5, 2024 2:40 AM
To: wsjt-devel@lists.sourceforge.net
Cc: JP3EXR 
Subject: Re: [wsjt-devel] I have in trouble JT65B of WSJT-X

How much memory do you have in your computer?


Mike W9MDB





On Thursday, January 4, 2024 at 03:51:24 AM CST, JP3EXR via wsjt-devel
 wrote:






Hi wsjtx development team.

Thank you for helping me with my trouble.

Sorry I forgot to send you about my trouble situation.
Please check the two attached pictures.
I am sorry for the Japanese display on the two attached screens.

Both pictures run two JT65B of WSJT-X on my PC.
Then you know two JT65B were decoding every periods.

Please check the sample aa.
I turned on the Enable TX on the left side of two JT65B.
Then on the left side of two JT65B had TXing started at 0721.
The on the right side JT65B was decoding every periods even on the
left side of two JT65B had TXing started.
You can see the decoding time of the single pass decode on the right
side of JT65B.
The decoding process of JT65B on the right side became freezing from 0721.

Please check the sample ca.
I turned on the Enable TX on the right side of two JT65B.
Then on the right side of two JT65B had TXing started.
Then The decoding process of JT65B on the left side is the same as the
sample a.

I am checking under what circumstances multiple JT65B are decoding freeze.
I think two JT65B are decoding every periods if both JT65B does not TX.
But JT65B of the TXing side does not decode in the TX period.
I think the decoding freeze of JT65B at the same periods of not TX
side of JT65B when TXing of JT65B finished of TXing period.
And the decoding freeze may occur immediately at the earliest, or
until about 10 TXing

Re: [wsjt-devel] WSJT-X parsing of the country file, specifically 4U1A (and others)

2023-12-08 Thread Uwe, DG2YCB via wsjt-devel


Hi all,

Once again regarding my question about EU / AS Turkey: My commit only
changes the displayed country name. Theoretically, the distinction
between continents etc. should therefore remain unaffected. I have just
looked up how LotW and QRZ.com do it. There is also only one entry
there, namely "Turkey". So this should not be wrong if this is also the
case with WSJT-X in the future. If someone wants to differentiate
between the two, all they have to do is activate the "Include extra WAE
entites" checkbox. And why should this be treated differently for AF
Italy than for EU Turkey?

How do you see it?

73 de Uwe, DG2YCB


Am 08.12.2023 um 18:50 schrieb Uwe, DG2YCB via wsjt-devel:

This may all be correct, but at least to me, the decisive factor is
what the DXCC rules are. And according to the DXCC list
<https://www.arrl.org/files/file/DXCC/2022_DXCC_Current.pdf> available
to me, there is only one "Turkey", namely DXCC No. 390.

TA-TC* Turkey EU/AS 39 20 390

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 08.12.2023 um 18:22 schrieb robert evans LAST_NAME via wsjt-devel:

East Thrace or Eastern Thrace, also known as Turkish Thrace or
European Turkey, is the part of Turkey that is geographically a part
of Southeast Europe. It accounts for 3.03% of Turkey's land area and
15% of its population. The largest city is Istanbul, which straddles
the Bosporus between Europe and Asia.
Asiatic Turkey is east of the Bosporus.
The Bosporus is where the Aegean and Mediterranean Seas broke through
and flooded the Black Sea.
I spent some time in Karamursel, Sinop, and Incirlik which are in
Asiatic Turkey.
Karamursel had a elephant cage AN/FLR-9 until they bombed
Cyprus and they closed this base when USA came out against it.
Sinop is a spit of land that sticks out in the Black Sea and was a NATO
listening post just south of Crimea and might still be.
Incirlik is still a very busy base down near the Mediterranean Sea.
Merhaba Arkadaslar. Nasiliniz?

On 12/08/2023 11:38 AM EST Uwe, DG2YCB via wsjt-devel
 wrote:
Hi Jim and all,

I have analyzed our WSJT-X code regarding this aspect. Results:
There seems to be nowhere specified which countries the WAE entities
shall be assigned to when the "Include extra WAE entites" checkbox
is *not* checked, neither in the CTY.DAT file nor in WSJT-X. This
means, if these entities are not queried, "" appears as a country
name. Quite logical in my eyes.

Therefore, I reprogrammed it in a way, that the WAE entities are now
always queried but that these special country names are replaced by
the correct DXCCs later in case the "Include extra WAE entites"
checkbox is not checked.

The first tests look already promising. (My setup: Two instances
connected via virtual audio, meaning that nothing goes over HF, and
I can simulate almost each QSO situation.)



By the way, what is with "European Turkey"? Must both "Asiatic
Turkey" and "European Turkey" then be displayed as "Turkey" if the
"Include extra WAE entites" checkbox is not checked?

Did I forget anything else?

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 07.12.2023 um 02:50 schrieb Jim Reisert AD1C via wsjt-devel:

This message is rather long, but I want to address this issue so it
can be fixed before WSJT-X 2.7 is released.  Also note that this
message contains a lot of formatting.  If it doesn't pass through
the mailing list correctly, please contact me and I can send you
the original copy.
I recently received this message:

On Tue, Nov 28, 2023 at 9:03 AM Dave Garber ve3wej
 wrote:

I am getting 4u1a on ft4 today, and wsjt-x is showing it as
Italy.  I have downloaded the updated cty-3388 file, and put
the cty.dat file ( which does show Austria , not Italy.  and
put it the the save folder of each of my wsjt versions..   am I
in the wrong folder, because it still shows Italy still

Ron Whitsel, W3RJW also wrote me:

4U1A comes up as 'Italy' in WSJT-X Band Activity window.   
Should be Austria

He later wrote:

OK I fixed it:

Added:

Removed 4U from Italy

Now 4U1A comes up as Austria in WSJT-X.

After some back-and-forth with Brett VR2BG today, I think I might
understand the problem.  I believe that WSJT-X is either parsing or
using the country file incorrectly.
First some background:
The CQWW DX contest uses two different country lists.  It uses the
ARRL DXCC lists, plus five (5) entities which are multipliers for
the WAEDC contest, plus one other:
https://www.darc.de/der-club/referate/conteste/wae-dx-contest/en/wae-rules/

Look at the bottom of that page for "WAE Country List".  It lists
these additional European enti

Re: [wsjt-devel] WSJT-X parsing of the country file, specifically 4U1A (and others)

2023-12-08 Thread Uwe, DG2YCB via wsjt-devel


This may all be correct, but at least to me, the decisive factor is what
the DXCC rules are. And according to the DXCC list
<https://www.arrl.org/files/file/DXCC/2022_DXCC_Current.pdf> available
to me, there is only one "Turkey", namely DXCC No. 390.

TA-TC* Turkey EU/AS 39 20 390

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 08.12.2023 um 18:22 schrieb robert evans LAST_NAME via wsjt-devel:

East Thrace or Eastern Thrace, also known as Turkish Thrace or
European Turkey, is the part of Turkey that is geographically a part
of Southeast Europe. It accounts for 3.03% of Turkey's land area and
15% of its population. The largest city is Istanbul, which straddles
the Bosporus between Europe and Asia.
Asiatic Turkey is east of the Bosporus.
The Bosporus is where the Aegean and Mediterranean Seas broke through
and flooded the Black Sea.
I spent some time in Karamursel, Sinop, and Incirlik which are in
Asiatic Turkey.
Karamursel had a elephant cage AN/FLR-9 until they bombed
Cyprus and they closed this base when USA came out against it.
Sinop is a spit of land that sticks out in the Black Sea and was a NATO
listening post just south of Crimea and might still be.
Incirlik is still a very busy base down near the Mediterranean Sea.
Merhaba Arkadaslar. Nasiliniz?

On 12/08/2023 11:38 AM EST Uwe, DG2YCB via wsjt-devel
 wrote:
Hi Jim and all,

I have analyzed our WSJT-X code regarding this aspect. Results: There
seems to be nowhere specified which countries the WAE entities shall
be assigned to when the "Include extra WAE entites" checkbox is *not*
checked, neither in the CTY.DAT file nor in WSJT-X. This means, if
these entities are not queried, "" appears as a country name. Quite
logical in my eyes.

Therefore, I reprogrammed it in a way, that the WAE entities are now
always queried but that these special country names are replaced by
the correct DXCCs later in case the "Include extra WAE entites"
checkbox is not checked.

The first tests look already promising. (My setup: Two instances
connected via virtual audio, meaning that nothing goes over HF, and I
can simulate almost each QSO situation.)



By the way, what is with "European Turkey"? Must both "Asiatic
Turkey" and "European Turkey" then be displayed as "Turkey" if the
"Include extra WAE entites" checkbox is not checked?

Did I forget anything else?

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 07.12.2023 um 02:50 schrieb Jim Reisert AD1C via wsjt-devel:

This message is rather long, but I want to address this issue so it
can be fixed before WSJT-X 2.7 is released.  Also note that this
message contains a lot of formatting.  If it doesn't pass through
the mailing list correctly, please contact me and I can send you the
original copy.
I recently received this message:

On Tue, Nov 28, 2023 at 9:03 AM Dave Garber ve3wej
 wrote:

I am getting 4u1a on ft4 today, and wsjt-x is showing it as
Italy.  I have downloaded the updated cty-3388 file, and put the
cty.dat file ( which does show Austria , not Italy.  and put it
the the save folder of each of my wsjt versions..   am I in the
wrong folder, because it still shows Italy still

Ron Whitsel, W3RJW also wrote me:

4U1A comes up as 'Italy' in WSJT-X Band Activity window.   
Should be Austria

He later wrote:

OK I fixed it:

Added:

Removed 4U from Italy

Now 4U1A comes up as Austria in WSJT-X.

After some back-and-forth with Brett VR2BG today, I think I might
understand the problem.  I believe that WSJT-X is either parsing or
using the country file incorrectly.
First some background:
The CQWW DX contest uses two different country lists. It uses the
ARRL DXCC lists, plus five (5) entities which are multipliers for
the WAEDC contest, plus one other:
https://www.darc.de/der-club/referate/conteste/wae-dx-contest/en/wae-rules/

Look at the bottom of that page for "WAE Country List".  It lists
these additional European entities:

  * 4U1V (Vienna Int'l Center)
  * GM/s (Shetland & Faire Islands)
  * IT (without IG9/IH9 Zone 33) (Sicily)
  * JW/b (Bear Island)
  * TA1 (European part of Turkey)

Now IG9/IH9 are special.  Normally they would be included as part of
Sicily, but they are in Africa, not Europe.  Therefore they are
counted as a separate multiplier in CQWW DX (but not in WAEDC)
There is another point to take into account.  A "prefix" in the
country file can be either a prefix or a full callsign.  Full
callsigns are prefixed with '='.  You will see some examples in the
next part. *Matching a full callsign should always have priority
over matching a prefix (partial callsign). *
One

Re: [wsjt-devel] WSJT-X parsing of the country file, specifically 4U1A (and others)

2023-12-08 Thread Uwe, DG2YCB via wsjt-devel


Hi Jim and all,

I have analyzed our WSJT-X code regarding this aspect. Results: There
seems to be nowhere specified which countries the WAE entities shall be
assigned to when the "Include extra WAE entites" checkbox is *not*
checked, neither in the CTY.DAT file nor in WSJT-X. This means, if these
entities are not queried, "" appears as a country name. Quite logical in
my eyes.

Therefore, I reprogrammed it in a way, that the WAE entities are now
always queried but that these special country names are replaced by the
correct DXCCs later in case the "Include extra WAE entites" checkbox is
not checked.

The first tests look already promising. (My setup: Two instances
connected via virtual audio, meaning that nothing goes over HF, and I
can simulate almost each QSO situation.)



By the way, what is with "European Turkey"? Must both "Asiatic Turkey"
and "European Turkey" then be displayed as "Turkey" if the "Include
extra WAE entites" checkbox is not checked?

Did I forget anything else?

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 07.12.2023 um 02:50 schrieb Jim Reisert AD1C via wsjt-devel:

This message is rather long, but I want to address this issue so it
can be fixed before WSJT-X 2.7 is released.  Also note that this
message contains a lot of formatting.  If it doesn't pass through the
mailing list correctly, please contact me and I can send you the
original copy.


I recently received this message:

On Tue, Nov 28, 2023 at 9:03 AM Dave Garber ve3wej 
wrote:

I am getting 4u1a on ft4 today, and wsjt-x is showing it as
Italy.  I have downloaded the updated cty-3388 file, and put the
cty.dat file ( which does show Austria , not Italy.  and put it
the the save folder of each of my wsjt versions..  am I in the
wrong folder, because it still shows Italy still


Ron Whitsel, W3RJW also wrote me:

4U1A comes up as 'Italy' in WSJT-X Band Activity window.   
Should be Austria


He later wrote:

OK I fixed it:

Added:

Removed 4U from Italy

Now 4U1A comes up as Austria in WSJT-X.


After some back-and-forth with Brett VR2BG today, I think I might
understand the problem.  I believe that WSJT-X is either parsing or
using the country file incorrectly.

First some background:

The CQWW DX contest uses two different country lists.  It uses the
ARRL DXCC lists, plus five (5) entities which are multipliers for the
WAEDC contest, plus one other:

https://www.darc.de/der-club/referate/conteste/wae-dx-contest/en/wae-rules/

Look at the bottom of that page for "WAE Country List".  It lists
these additional European entities:

  * 4U1V (Vienna Int'l Center)
  * GM/s (Shetland & Faire Islands)
  * IT (without IG9/IH9 Zone 33) (Sicily)
  * JW/b (Bear Island)
  * TA1 (European part of Turkey)

Now IG9/IH9 are special.  Normally they would be included as part of
Sicily, but they are in Africa, not Europe. Therefore they are counted
as a separate multiplier in CQWW DX (but not in WAEDC)

There is another point to take into account.  A "prefix" in the
country file can be either a prefix or a full callsign. Full callsigns
are prefixed with '='.  You will see some examples in the next part.
*Matching a full callsign should always have priority over matching a
prefix (partial callsign). *

One last point is that the "prefix" at the end of the line in the
country file that contains the entity name is for display purposes
only.  It should never be included in the list of prefixes for the
given entity.


Now let's focus specifically on the country file.  I have highlighted
some prefixes/callsigns.

Here is the 4U1/v entity as shown in the country file:

Vienna Intl Ctr:    15:  28:  EU:   48.20:   -16.30:    -1.0:  *4U1V:
    =4U0R,=4U100QO,=4U1A,=4U1VIC,=4U2U,=4Y1A,=C7A;

Here is the Italy entity as shown in the country file:

Italy:    15:  28:  EU:   42.82:   -12.58:    -1.0:  I:
4U,I,=I2DMK/RM,=IT9ELM/0,=IT9PQJ/0;

Here is the Austria entity as shown in the country file;

Austria:    15:  28:  EU:   47.33:   -13.33:    -1.0:  OE:
    OE,=4U0R,=4U100QO,=4U1A,=4U1VIC,=4U2U,=4Y1A,=C7A;

You should notice a few things:

 1. The "prefix" at the end of the line beginning with "Vienna Intl
Ctr" has a '*' in front of it.  That means that this entity is
only used in the CQWW DX and WAEDC contests.  It is not a DXCC entity.
 2. 4U1A (full callsign) is listed twice, once under "Vienna Intl Ctr"
and once under "Austria"
 3. 4U is listed as a prefix for Italy.

Regarding #3, this was done so that "new" (previously unknown) 4U
callsigns that are spotted on the DX cluster will propagate through
the network.  If that prefix mapping were not there, those calls would
be ignored because they could not be associated with any entity in the
country file.  Tis was done at the request of Lee VE7CC.  4U has been
used numerous times from Italy.  4U24OCT is a recent example.  The Q

Re: [wsjt-devel] WSJT-X 2.7.0-rc2 Switching caller in TX1 message

2023-10-11 Thread Uwe, DG2YCB via wsjt-devel


Hi Clay,

Thanks for this issue report. With WSJT-X, CQ: Max Dist only works with
certain contest messages, and when you have the Active Stations window
open. I have changed this with my wsjt-x_improved
 program. There it works also
for normal messages. This program also contains a number of bug fixes
that might also fix the first problem. Feel free to try it out, and then
please be so kind and report if the mentioned issues are gone with it.

Wsjt-x_improved is an extended version of WSJT-X. It has the same source
code core. I use it to try out new features and fixes that sometimes
become part of WSJT-X later. Examples were the mode buttons and numerous
detail improvements to the WSJT-X source code.

The main reason for offering two programs, WSJT-X and wsjt-x_improved,
is that there are two groups of users. One group has been using WSJT-X
for a long time and doesn't really want any changes or new features.
Just look at how few of the v2.6.1 users have tried v2.7.0-rc so far.
According to PSK Reporter statistics, that's only 9.7%. And then
remember the numerous protests just because we had introduced a new Tune
watchdog function.
The second group of users, on the other hand, would like to have exactly
such new features. They eagerly await every new improvement and
immediately test or use them intensively. This second group is currently
served with wsjt-x_improved. There are a lot of useful additional
features, bug fixes as well as new program versions as soon as it is
worthwhile (about three to four times as often as with WSJT-X).


73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 11.10.2023 um 02:25 schrieb Clay Couger via wsjt-devel:

After transmitting RR73 or 73 to WB0OQV, but before the next
transmission cycle I select 'I4RHP N5YJZ -11' message to send. WSJT-X
2.7.0 RS2 replaces my request with 'W8NGA N5YJZ -03' This issue is not
seen in WSJT-X 2.6.1

There is another bug in both 2.6.1 and 2.7.0 RC2 where the first call
is always picked to respond to even if max dist is slected.

Capture2.PNG


___
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] Button sizes not correct

2023-09-01 Thread Uwe, DG2YCB via wsjt-devel


Hi Mark,

In most cases, this effect is triggered by App Scaling. Try setting this
to 100%. Probably everything will look normal then. Please try a few
combinations of App Scaling and font size to find the best settings for you.

It is almost impossible to compensate for all the unsightly side effects
of this App Scaling. We also have to take into account the many OMs who
have smaller screen sizes. If you have App Scaling set to 100%, the
WSJT-X GUI should work fine with font sizes between say 8 and 16 pt, on
all operating systems.

The problem has come when people have increasingly bought monitors with
extremely high pixel counts. Of course, all program windows and icons
are displayed smaller there, because a 4K monitor is typically not four
times as big as a 27-inch HD monitor. Consequence: For many users,
everything is then much too small for their eyes and thus no longer
properly readable. Therefore, App Scaling is then often set to high
values, but this affects the GUI proportions of many programs.

No matter how much Laurie grumbles, this is hard to impossible to solve.
Of course, it would be no problem to make a suitable GUI for say 200%
App Scaling, but then all the other OMs who have normal-sized monitors
and use normal font sizes between say 8 and 12 pt and a normal App
Scaling of 100% would rightly complain why the minimum size of the
WSJT-X window is now suddenly so large. We have had all this before.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 01.09.2023 um 00:15 schrieb Mark Galbraith via wsjt-devel:


Not sure what’s happening here, but my guess would be that the screen
resolution may be off, but I was seeing this on other computers as well.

My computer is a Microsoft Surfacebook 2, with a screen resolution of
3240 x 2160.  I was also seeing the same thing on my other computer
with a 32” ultra widescreen resolution of 2560 x 1080.  I’m also
seeing this on v2.6.1 and v2.7.0-rc2.  Is there a setting I need to
adjust, or is this something that requires a program change to fix?

73

-.. . / -- .- .-. -.- / -. --... -.-- -..

DE  MARK  N7YD



___
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] Problem with Hamlib

2023-08-29 Thread Uwe, DG2YCB via wsjt-devel


Hi Rudy,

Ensure you use DATA-USB mode at your Yaesu FT-991 (*not* USB). Important
are also the following menu settings at your FT-991: 072=USB.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 29.08.2023 um 18:53 schrieb on4...@telenet.be:

Hi Uwe, Mike
Problem has already been partly solved. Parameter 033 CAT RTS was set
to disable in the transceiver. I set this to Enable and the CAT
control worked, as well as the PTT control. I also have reception, so
I see stations appear on the screen, but when I go on a broadcast,
there is no power from the transceiver. It seems that there is no
modulation going through the CAT to the transceiver, because when I
take the microphone and I whistle into the microphone, I do see power
coming out of the transceiver. Still, I think the audio setting is
correct, input is on microphone (USB audio codec) and the autput is on
speakers (USB audio codec). I have already checked the volume setting
of the microphone audio code and it is set to 80%.
Do you have any suggestions/tips?

Regards,
ON4CKT Rudy

*Van: *"DG2YCB Uwe" 
*Aan: *"on4ckt" 
*Verzonden: *Dinsdag 29 augustus 2023 11:35:15
*Onderwerp: *Re: [wsjt-devel] Problem with Hamlib

Really strange. Or is perhaps com0com breaking the connection? What
happens if you temporarily disable com0com and use COM3 only for WSJT-X?
But in case FreeDV supports OmniRig, I would really recommend you
OmniRig 1.20. It is a *much* better solution than com0com.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB 


Am 29.08.2023 um 11:31 schrieb on4...@telenet.be:

Hi Uwe,

Yes I also use that COM port 3 for FreeDV. But I don't use the
programs at the same time.
And when I start the laptop, just connect the laptop to the FT991
via the USB cable and then start WSJT-X for entering the
parameters in the radio tab, then after setting those parameters
when I press OK I get that Hamlib mistake. And yes I know you
cannot use the same COM port twice, but normally I get a message
that the com port is in use. I had this problem on another PC, but
I used the com0com program there, and that works fine.


*Van: *"DG2YCB Uwe"  
*Aan: *"on4ckt"  
*Verzonden: *Dinsdag 29 augustus 2023 11:24:23
*Onderwerp: *Re: [wsjt-devel] Problem with Hamlib

Hello Rudy,

Allow me a "simple" question: but you don't have COM3 in use via
another program, do you? Because a COM port can only be used by
one application at the same time.

If you need the same COM port for more programs at the same time,
OmniRig is a good solution (as long as the programs support it,
WSJT-X does).

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB 


Am 29.08.2023 um 10:52 schrieb on4...@telenet.be:


Dear Uwe,

As far as the COM ports and the device manager are concerned,
I had already tested and seen which ports were added. That was
com ports 3 and 4. I tested both to no avail. And I'm sure
it's com 3 that I have to use, because in the program FreeDV
(digital voice over HF) I also use the CAT control, and
everything works fine there. But I'll go through all the
parameters again and see if I'm wrong. I'll keep you informed.

ON4CKT Rudy


*Van: *"Uwe, DG2YCB"  
*Aan: *"on4ckt"  
*Verzonden: *Maandag 28 augustus 2023 20:38:56
*Onderwerp: *Re: [wsjt-devel] Problem with Hamlib

Hello Rudy,

As a very first test, I recommend that you start your computer
without a physical USB connection to your FT-991. Then open
the Windows device manager and see, which COM ports are
available. If you then already see COM3 and COM4, it means
that they are for something else. Then connect your USB cable
to your PC and switch the FT-991 on while the device manager
is still open. Now you must see two new COM ports. Your CAT
can then be connected via one of these newly visible COM ports.

But be careful. At my FT-991, two times the virtual USB COM
ports were broken. The first time it was within the warranty
period. As far as I know they had to exchange the entire main
board. But when it broke again the

Re: [wsjt-devel] Problem with Hamlib

2023-08-28 Thread Uwe, DG2YCB via wsjt-devel


Hello Rudy,

Your settings for the FT-991 seem to be fine. I have the same settings
here (and 028=RS232C), and everything works well. How is your PTT
connected? I use CAT. If you have DTR or RTS selected, make sure the COM
port for that is different from the CAT serial port. Is COM3 the right
one? When you open your Windows Device Manager, what COM ports are
additionally listed there when you connect your FT-991?

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 28.08.2023 um 17:01 schrieb on4ckt--- via wsjt-devel:

Hello, today I tried to install WSJT-X v2.7.0-rc2 on my laptop
Windows10 and connect via CAT to my Yaesu FT991. But I get the
following error message in WSJT-X.

Hamlib error: rig_settings_get_path: path=.hamlib_settings

rig_settings_load_all: settings_file (.hamlib_settings): No such file
or directory

rig_open: cwd=C:\WSJT\wsjtx

rig_open: C:\WSJT\wsjtx/hamlib_settings does not exist

rig_open: async_data_enable=1, async_data_supported=0

serial_open: COM3

serial_setup: tcgetattr

serial_setup: cfsetispeed=38400,0x000f

serial_setup: cfsetospeed=38400,0x000f

serial_setup: data_bits=8

serial_setup: parity=0

serial_setup: Handshake=Hardware

serial_setup: tcsetattr TCSANOW

serial_setup: tcsetattr failed: No error

port_open: serial_open(COM3) status=-2, err=No error

rig_open: rs->comm_state==0?=0

rig.c(1069):rig_open returning2(-2) Invalid configuration

Invalid configuration

Invalid configuration

while opening connection to rig

Timestamp: 2023-08-28T14:46:31.621Z

On the transceiver I have adjusted the following parameters:
029=38400, 030=10msec, 031=38400, 062=OTHERS, 064=1500Hz, 066=OFF,
068=OFF, 070=REAR, 071=DAKY and 072=USB. Can someone help me further
with this.

Thanks in advance.


--
73's ON4CKT Rudy
https://www.qsl.net/on4ckt


___
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] WSJTX 2.6.1 fails to initialize with a misleading error "Failed to start OmniRig COM server"

2023-07-22 Thread Uwe, DG2YCB via wsjt-devel


Hi Chris,

Do I understand you correctly that you are using OmniRig but have
selected "Icom IC-7300" as Rig in WSJT-X? Of course this can't work
then. You must then select "OmniRig 1" in WSJT-X. And in the OmniRig
Settings you have to select your IC-7300 as Rig type in RIG 1 and enter
the correct data (COM Port, Baud rate, etc.).

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 22.07.2023 um 13:37 schrieb Christopher Wawak via wsjt-devel:

TLDR: Thanks for opening your development community to me. I'd like to ask for 
help confirming whether my troubleshooting of this issue is correct, and if so, 
to submit a feature request for improving handling errors with the Windows 
sound subsystem. This seems to happen about once a year for me, and I've now 
hit the point that trying to figure this out is taking more time than trying to 
get it fixed would take!

Summary: WSJTX 2.6.1 fails to initialize the ICOM 7300 with an incorrect error 
"Failed to start OmniRig COM server" when the underlying problem is with the 
Windows sound subsystem, leading to a loss of functionality and user confusion.

Product: WSJTX 2.6.1
Hardware: ICOM 7300
OS: Windows 11 Version 10.0.22621

Impact:

This bug causes WSJTX to fail initializing the ICOM 7300, rendering the 
application non-functional. The user is misled by an incorrect error message, 
causing frustration and unnecessary troubleshooting efforts.

Steps to Reproduce:

1. Perform a fresh Windows 11 install.
2. Install OmniRig 1.20.
3. Install WSJTX 2.6.1.
4. Configure the ICOM 7300 Rig in WSJTX and OmniRig.
5. Exit WSJTX.
6. Trigger a condition that causes the Windows sound subsystem to re-enumerate the USB 
bus, leading to the audio device getting a new identification number, and thus appearing 
as "not found" in the WSJTX settings.

Expected Result:

WSJTX should still be able to initialize the radio, even if the sound devices 
are not found.
WSJTX should give an error about the missing sound devices, rather than 
reporting a failure with the OmniRig COM server.

Actual Result:

WSJTX fails to initialize the rig, confusingly producing the error "Failed to start 
OmniRig COM server".

Logs:

Logs can be found here:https://pastebin.com/VmC74rDd

Error messages of note:

[SYSLOG][2023-07-19 16:07:39.264928][00:00:15.540760][warning] 
QAxBase::setControl: requested control {0839e8c6-ed30-4950-8087-966f970f0cae} 
could not be instantiated
[RIGCTRL][2023-07-19 16:07:39.264928][00:00:15.540783][error] failed to start 
COM server
[SYSLOG][2023-07-19 16:07:39.265921][00:00:15.541872][error] 
handle_transceiver_failure: reason: Failed to start OmniRig COM server

Additional Notes:

This issue does not affect other applications using OmniRig.
This issue has occurred on many previous versions of WSJTX and on Windows 10 as 
well.
My current workaround is to manually enter the settings screen and correct the 
sound settings.

Thank you + 73,

Chris Wawak - KC2IEB

___
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] WSJTX V2.7 sample files error

2023-07-12 Thread Uwe, DG2YCB via wsjt-devel


Hi Sandro and all,

I created the missing contents_2.7.json file and put it on our WSJT
SourceForge page. This should make downloading samples work again.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 12.07.2023 um 00:59 schrieb Alessandro Gorobey via wsjt-devel:

Hi All,

I noticed that on any OS Menu-->Help-->Download samples
give file not found error.

I think it's enough to copy
https://sourceforge.net/projects/wsjt/files/samples/contents_2.6.json  

to
https://sourceforge.net/projects/wsjt/files/samples/contents_2.7.json  


Thank in advance

--
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] Possible bug related to CQ with individual contest name

2023-06-27 Thread Uwe, DG2YCB via wsjt-devel


Hi Mark,

Thank you for reporting this. However, this bug was fixed months ago
(February 15, 2023).

Allow me to make a general comment on this topic. It is always good when
you detect a bug to try the latest available version first. This is
v2.7.0-rc1
 for
WSJT-X, or this special version of my wsjt-x_improved fork
,
which as you know contains the same source code kernel, but where I
usually release my bug fixes more timely.

Anyway, the good news is, we will release v2.7.0-rc2 soon. It brings
some more bug fixes.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 27.06.2023 um 01:12 schrieb mark mgg4.com via wsjt-devel:


I almost hesitate to post this, as I have not isolated the precise
trigger for this bug.  I’m mentioning it now so we might collect data
points from other users to see if the trigger can be found.

WSJT-X version: 2.6.1

OS Version: Windows 11

Description: The setting for “Contest name” occasionally resets to “PACC”.

This issue recurred several times during Field Day 2023.  Most of the
time I noticed it after changing the “Op Call” setting on the
Reporting tab.  After saving the new operator’s call, I would notice
that the Tx6 string had changed to “CQ PACC  ”.  This
did not happen frequently enough for me to determine the exact
sequence to reproduce this issue 100%, just often enough to be
annoying.  To me, it seemed like when the configuration dialog values
were being populated, the “Contest name” field was being set to a
default value.  If the user did not check the Advanced tab prior to
saving, then this new value for Contest name was saved with the rest
of the values.  Where I’m having trouble is finding a reason the code
would think that value needed to be set to the “PACC” default.

I’m a developer with 45 years of experience.  I haven’t looked at the
code yet, but I will see if I can narrow things down a bit over the
next few days. Thanks for taking a look with me, as you will have much
more familiarity with the code base and may be able to find the issue
faster than I could.

73

-.. . / -- .- .-. -.- / -. --... -.-- -..

DE  MARK N7YD



___
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 Hungarian localization

2023-05-22 Thread Uwe, DG2YCB via wsjt-devel


Hi Janos,

Thank you for your Hungarian translation file. I have added it to our
source code. I will send you a WSJT-X test version with your file by
private email soon.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 21.05.2023 um 22:42 schrieb János Isgum via wsjt-devel:

Dear wsjt program-developer OM!

I apologize for the impersonal address, but I don't know who in the
wsjt development team is responsible for the localization part of the
program.
The wsjt-x is the most popular digital amateur radio program also
among the Hungarian hams.

I have created the Hungarian localization of the wsjt program (based
on the wsjtx_en_GB.ts file of the source code).
Here I am sending the Hungarian wsjt_hu.ts file as an attachment.
Dear OM, my request is that you include this file in the program and
send me the executable wsjtx.exe file for testing.
After testing the Hungarian localization, I will send you the final
wsjtx_hu.ts file.

I have also translated and prepared the Hungarian User Manual for wsjt-x.
In it, some pictures still need to be replaced to have Hungarian
subtitles where necessary.
I will send this as well.

Thanks in advance for your patience and help!
I wish you good programming, good health, and I hope my next letter
can be personal!
73,  Janos, HA5GG

Postscript:
Some programs for which I have already done the Hungarian localization:
LogHX3 Logger > Hungarian localization
N1MM+ Logger > Hungarian localization, and Hungarian User Manual
DXLog Logger > Hungarian User Manual


___
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] "U.S.A" displayed as "U.S.A. of America"

2023-05-17 Thread Uwe, DG2YCB via wsjt-devel


Hi all,

Some users complain that "U.S.A." is displayed as "U.S.A. of America".
The reason for this is that the maintainers of the CTY.DAT file have
suddenly changed the name from "United States" to "United States of
America". But since all programs (WSJT-X, JTDX, wsjt-x_improved,
jtdx_improved, I think also MSHV) have a built-in algorithm to
abbreviate/replace "United States" by "U.S.A.", this now results in
"U.S.A. of America".

This, by the way, is a good example of someone who makes a small change
with good intentions but doesn't think about the side effects it can cause.

The undesirable side effect only affects users who have downloaded an
updated cty.dat file themselves, because the cty.dat file that comes
with WSJT-X or wsjt-x_improved still uses "United States" as the name in
its cty.dat file.

However, the good news is: You can change it very easily yourself.
Either delete any cty.dat file in your log directory, or edit this file
and change "United States of America" to "United States".

I will inform the maintainers of the cty.dat file about this annoying
side effect and hope that they understand that it is better to use the
name "United States" again.

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

Re: [wsjt-devel] Error Loading LOTW Users Data

2023-05-13 Thread Uwe, DG2YCB via wsjt-devel


Hi Jim,

This is something for Brian, N9ADG. He programmed this feature. Have you
followed the steps described in chapter 3.1 of the user guide and
installed the Windows OpenSSL Packages
?

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 13.05.2023 um 16:34 schrieb Jim Preston via wsjt-devel:

Using WSJT-X 2.7.0-rc1.
Windows 11

When I click "Fetch Now" in the "Logbook of the World User Validation
section, I get an error stating:

Error Loading LOTW Users Data
TLS initialization failed.

73,

Jim N6VH


___
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] Hamlib hotfixes

2023-05-13 Thread Uwe, DG2YCB via wsjt-devel


Hi all,

As a help for those of you having problems with CAT control of your rig
with v2.7.0-rc1, I have copied the latest hamlib hotfixes to the folder
listed below. You will find there not only files for Windows but also
for macOS and Raspberry Pi.

https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.7.0/hamlib/

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

[wsjt-devel] Head of a new Hamlib Beta Testing Group found

2023-05-13 Thread Uwe, DG2YCB via wsjt-devel


Hi all,

I am pleased to announce that Dennis, W1UE has agreed to take
responsibility for hamlib beta testing.

So: *I hereby appoint him as our new official head of the Hamlib Beta
Testing Group!*

Concrete next steps of the new Hamlib Beta Testing Group should be the
following:

1. Find beta testers for the most widely used, say 12 to 25 rigs and
   assign the responsibilities.
2. *The first concrete task of the Hamlib Beta Testing Group is to find
   as soon as possible (realistically within 2 to 3 weeks) _one_ hamlib
   version that runs on all these "key rigs" without problems.* As
   before, technical problems should be solved in close cooperation
   with Mike W9MDB, whose work and expertise I greatly appreciate. But
   this is something else than systematic testing and bug finding, and
   we need both.
3. Then I can use this version for the next update of WSJT-X or
   wsjt-x_improved, which I plan to do in the not too distant future
   (at least for wsjt-x_improved).
4. If a date for the next release is foreseeable, I would inform Dennis
   in advance, so that he and his Hamlib Beta Testing Group can select
   the best performing hamlib version. Keep in mind, that I always need
   the hamlib source code, as well as the binaries in 64-bit and
   32-bit. So the group must make sure that these 3 files are available
   for the selected hamlib version.

So, now it is enough from me on this topic. *From now on, Dennis is
called to start with the work.* I wish from the bottom of my heart much
success!

73 de Uwe, DG2YCB


Am 13.05.2023 um 09:09 schrieb Uwe, DG2YCB via wsjt-devel:

Dear WSJT-X users,

Please allow me to summarize again here on this email reflector a
topic that is very important to me and to all of us. My original post
was on https://groups.io/g/wsjtgroup, so maybe it's best if you join
the discussion there.

Despite great personal commitment of the hamlib developers it has
unfortunately happened very often that immediately after a new WSJT-X
release serious problems with one or another hamlib rig driver become
apparent. If something like this happens over and over again, it shows
that there is a *systematic* error somewhere. In my opinion this is
due to the fact that *too few* users try the current development
versions of hamlib, so that errors are detected *too late*. Keep in
mind that hamlib drivers often change as they evolve.

So I*would like to ask you all that enough OMs act as hamlib bata
tester in the future.* For those who own one of the rigs below and
work on Windows, just do the following every 2, 3 or 4 weeks:

 1. Download the daily updated libhamlib-4.dll file available on
https://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll.
 2. Copy the file to the bin folder of your WSJT-X installation (i.e.
usually c:\WSJT\wsjtx\bin). Rename the existing libhamlib-4.dll
file beforehand so you can use it again later.
 3. Start WSJT-X (or the respective variant), connect your rig via
hamlib (i.e. *not* via OmniRig, HRD, DXLabSuite, etc.) and check
if the CAT control runs properly.
 4. If anything is not working properly, please contact Mike W9MDB via
direct email, so he or his team can fix the bug in time.
 5. If everything works fine, keep the new libhamlib-4.dll file,
otherwise delete it and rename the previously used one.
 6. In the future I would like to contact you before a new WSJT-X or
wsjt-x_improved release to be able to choose a bug free hamlib
version.

In my opinion, at least the following rigs need to be tested regularly
regarding hamlib:

  * Yaesu: FT-991, FT-101, FT-847
  * Kenwood: which models?
  * Icom: IC-7300, IC-9100, IC-9700, IC-705
  * Elecraft: KX3, what else?
  * FlexRadio: which models?
  * Anything else?

*Now, the most important thing is that **one of you* *organizes it*. I
can't do it myself because of time constraints, and Mike W9MDB is also
overloaded with work.

For example, what about the people who have stood out so intensively
in the last few days with posts about something trivial? Wouldn't one
of you like to take over and invest your energy there? *Seriously:
Who?* *Y**ou are now requested!
*
I mean, what needs to be done is evident:

 1. Create a list of commonly used rig models.
 2. Find beta testers for each of these models and assign
responsibilities.
 3. Get an overview of the status quo and summarize the results clearly.

Something like this can be done e.g. with a simple Excel file:




It's sad enough that obviously, the hamlib development team can't do
something so essential themselves. But *this definitely has to come
now*, because we can't get the next frustration after every new WSJT-X
release. Makes no sense!

So, again: *Who of you will take this in hand and organize such a
systematic beta testing?

*I do not want to see one more "stupid" post as long as this problem
is not solved, hi, hi!*

*73 de Uwe, DG2YCB

[wsjt-devel] Hamlib Beta Testing Group needed

2023-05-13 Thread Uwe, DG2YCB via wsjt-devel


Dear WSJT-X users,

Please allow me to summarize again here on this email reflector a topic
that is very important to me and to all of us. My original post was on
https://groups.io/g/wsjtgroup, so maybe it's best if you join the
discussion there.

Despite great personal commitment of the hamlib developers it has
unfortunately happened very often that immediately after a new WSJT-X
release serious problems with one or another hamlib rig driver become
apparent. If something like this happens over and over again, it shows
that there is a *systematic* error somewhere. In my opinion this is due
to the fact that *too few* users try the current development versions of
hamlib, so that errors are detected *too late*. Keep in mind that hamlib
drivers often change as they evolve.

So I*would like to ask you all that enough OMs act as hamlib bata tester
in the future.* For those who own one of the rigs below and work on
Windows, just do the following every 2, 3 or 4 weeks:

1. Download the daily updated libhamlib-4.dll file available on
   https://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll.
2. Copy the file to the bin folder of your WSJT-X installation (i.e.
   usually c:\WSJT\wsjtx\bin). Rename the existing libhamlib-4.dll file
   beforehand so you can use it again later.
3. Start WSJT-X (or the respective variant), connect your rig via
   hamlib (i.e. *not* via OmniRig, HRD, DXLabSuite, etc.) and check if
   the CAT control runs properly.
4. If anything is not working properly, please contact Mike W9MDB via
   direct email, so he or his team can fix the bug in time.
5. If everything works fine, keep the new libhamlib-4.dll file,
   otherwise delete it and rename the previously used one.
6. In the future I would like to contact you before a new WSJT-X or
   wsjt-x_improved release to be able to choose a bug free hamlib version.

In my opinion, at least the following rigs need to be tested regularly
regarding hamlib:

 * Yaesu: FT-991, FT-101, FT-847
 * Kenwood: which models?
 * Icom: IC-7300, IC-9100, IC-9700, IC-705
 * Elecraft: KX3, what else?
 * FlexRadio: which models?
 * Anything else?

*Now, the most important thing is that **one of you* *organizes it*. I
can't do it myself because of time constraints, and Mike W9MDB is also
overloaded with work.

For example, what about the people who have stood out so intensively in
the last few days with posts about something trivial? Wouldn't one of
you like to take over and invest your energy there? *Seriously: Who?*
*Y**ou are now requested!
*
I mean, what needs to be done is evident:

1. Create a list of commonly used rig models.
2. Find beta testers for each of these models and assign responsibilities.
3. Get an overview of the status quo and summarize the results clearly.

Something like this can be done e.g. with a simple Excel file:




It's sad enough that obviously, the hamlib development team can't do
something so essential themselves. But *this definitely has to come
now*, because we can't get the next frustration after every new WSJT-X
release. Makes no sense!

So, again: *Who of you will take this in hand and organize such a
systematic beta testing?

*I do not want to see one more "stupid" post as long as this problem is
not solved, hi, hi!*

*73 de Uwe, DG2YCB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Permanent solution for a new forum found: wsjtgr...@groups.io

2023-04-26 Thread Uwe, DG2YCB via wsjt-devel


Here is the URL: https://groups.io/g/wsjtgroup

73 de Uwe, DG2YCB


Am 26.04.2023 um 20:37 schrieb Uwe, DG2YCB:

Dear WSJT-X Users,

The overwhelming success of the temporary WSJT-XY forum has brought us
close to the limit of 100 users within one day. The good news is that
a permanent solution has now been found: *wsjtgr...@groups.io*. This
forum has no limit on the number of members. I think this is an
opportunity we should not miss! Thanks to everyone who made this possible!

Unfortunately, this means that we have to move one more time. I am
very sorry about that, but I think you will understand the reason.
Once everyone has moved, I plan to close our temporary WSJT-XY forum.

Note: For technical reasons, groups.io requires messages from new
members to be approved once. After that, posts are possible without
further hurdles.

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

[wsjt-devel] Permanent solution for a new forum found: wsjtgr...@groups.io

2023-04-26 Thread Uwe, DG2YCB via wsjt-devel


Dear WSJT-X Users,

The overwhelming success of the temporary WSJT-XY forum has brought us
close to the limit of 100 users within one day. The good news is that a
permanent solution has now been found: *wsjtgr...@groups.io*. This forum
has no limit on the number of members. I think this is an opportunity we
should not miss! Thanks to everyone who made this possible!

Unfortunately, this means that we have to move one more time. I am very
sorry about that, but I think you will understand the reason. Once
everyone has moved, I plan to close our temporary WSJT-XY forum.

Note: For technical reasons, groups.io requires messages from new
members to be approved once. After that, posts are possible without
further hurdles.

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

[wsjt-devel] Statement regarding WSJTX.groups.io

2023-04-25 Thread Uwe, DG2YCB via wsjt-devel


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] Today is the PACCdigi Contest

2023-04-15 Thread Uwe, DG2YCB via wsjt-devel


Hi all,

Today is the PACCdigi Contest
,
which will be held for the first time with our new extended FT Roundup
protocol. So those who want to test it have a good opportunity to do so
today. Follow the Contest Rules
.
At least our 2.6.0 GA version must be used as software!

The transceiver dial frequencies that will be used for FT8 are: 1,843 -
3,577 -7,077 – 14,077 – 21,077 and 28,077 MHz. Stations outside the
Netherlands please use the following settings:



Stations inside the Netherlands use as FT RU Exch
theabbreviationsfortheDutchProvinces,
whichare:NH,ZH,ZL,NB,UT,FL,FR,GR,OV,DR,GD,LB.

By the way. The extended FT Roundup messages protocol also includes 99
neutral exchanges (X01 ... X99) that can be used for counties,
provinces, cities, sub-devisions, etc. This allows a whole new set of
nice little contests or QSO parties.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB

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

[wsjt-devel] Sourceforge fixed the download issue

2023-04-10 Thread Uwe, DG2YCB via wsjt-devel


Hi all,

The download issue should be fixed now. Something was broken at
Sourceforge. The SF support team told me "there was an error with an
update to our database on Friday. We recently performed some unrelated
work on our website, and unfortunately, this caused an accidental side
effect that resulted in the reported issue." I think we all make
mistakes and should therefore "forgive" them.

I had already temporarily redirected the download links on our
http://wsjt.sourceforge.io/wsjtx.html page yesterday so that the
download of the v2.6.1 installer packages was already possible again.

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

[wsjt-devel] Sourceforge download from https://wsjt.sourceforge.io/wsjtx.html should work again

2023-04-09 Thread Uwe, DG2YCB via wsjt-devel


Download of the v2.6.1 WSJT-X installer packages via our
https://wsjt.sourceforge.io/wsjtx.html homepage should work again now.
There seems to be some problem with SourceForge at the moment. But I
found another solution that seems to work, at least for now.

73 de Uwe DG2YCB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjtx-2.6.1: TX is activated when frequency is changed in the hound mode

2023-02-13 Thread Uwe, DG2YCB via wsjt-devel


Thanks for the report, Jaroslav. I have changed the code accordingly to
prevent this.

73 de Uwe, DG2YCB


Am 13.02.2023 um 12:51 schrieb Jaroslav Skarvada via wsjt-devel:

If hound mode is enabled and frequency is manually changed by entering
the frequency directly to the "band" box and hitting enter, e.g:
18.107 
the TX is activated. It happens anytime the frequency is changed this
way. What's worse is that if there is TX period the radio is
immediately keyed. This is really bad, because the antenna may not yet
be matched. I was unable to find any config option to prevent it from
doing this

73! Jaroslav, OK2JRQ



___
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] Transmit Audio Source

2023-01-31 Thread Uwe, DG2YCB via wsjt-devel


Karl,

Is the audio source perhaps disabled at Windows level? Have a look at
the Windows Sounds settings (right-click on the speaker icon at the
bottom right and then "Sounds"). It may be that your FT-991 is now
recognized as a "new" audio source, and the old one no longer works.

73 de Uwe, DG2YCB


Am 31.01.2023 um 15:24 schrieb Karl Read via wsjt-devel:

hi All,

After having to do a factory restart on my FT991, I used the settings
which I had saved on the PC using the RT Systems Software.

Every thing seemed to be ok but I could not get the radio to TX using
WSJT-X V2.6.1 , Windows 10..

The Radio setting page, in WSJT-X, shows the Transmit Audio Source
greyed out with the Front/Mic ticked..

Any ideas how to correct this please...

Thanks

Karl   M5DND


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

Re: [wsjt-devel] UDP Status message defect. WD status not set when in Hound mode.

2023-01-18 Thread Uwe, DG2YCB via wsjt-devel


Yes, Laurie, but exactly this is (hopefully) being done with the two
test installers I sent you. Please confirm that it works with them.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 18.01.2023 um 17:05 schrieb Laurie, VK3AMA via wsjt-devel:



On 19/01/2023 1:45 am, Frode Igland wrote:

this tells that the WD timer in Hound mode is deliberately hardcoded
and non-editable


I am not asking that the Hound mode WD timer be editable. I am fine
with it being fixed. I fully support that design.

The problem (defect) is that the status of the WD is not being
reported in the UDP Status message. That is, when the Hound WD is
triggered it is not setting the WD flag in the status message.

de Laurie VK3AMA



___
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.6.0 GA Release

2023-01-06 Thread Uwe, DG2YCB via wsjt-devel


Try to download again. I think Sourceforge still had the old copy. But
the one I downloaded 1 minute ago has the correct entry.

73 de DG2YCB,
Uwe


Am 06.01.2023 um 18:07 schrieb Gary Rogers via wsjt-devel:

Same issue for me downloaded from new WSJT-X site.


On Jan 6, 2023, at 8:55 AM, Kari Sillanmäki via wsjt-devel
 wrote:


Hi Uwe,

I just downloaded the tarball.
It still has the wrong CmakeLists.txt entry...

I used this link to download:
https://sourceforge.net/projects/wsjt/files/wsjtx-2.6.0/wsjtx-2.6.0.tgz
Is this the correct link??

73's de Kari, oh2gqc

On 6.1.2023 18.05, Uwe, DG2YCB via wsjt-devel wrote:


Hi Stefan,

Yes, it must be 4.5.3. I have updated the tarball. Please download
again and see if it works better now.

73 de DG2YCB,
Uwe


Am 06.01.2023 um 16:57 schrieb Stefan HB9TMC via wsjt-devel:

Hi,

cmake generated an error:
CMake Error at CMakeLists.txt:56 (file):
  file failed to open for reading (No such file or directory):

    ~/bin/wsjtx-2.6.0/src/hamlib-4.5.tar.gz.md5sum



I think CMakeLists.txt should be:
6c6
< set (__hamlib_upstream hamlib-4.5.3)
---
> set (__hamlib_upstream hamlib-4.5)


73
Stefan


___
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] WSJT-X 2.6.0 GA Release

2023-01-06 Thread Uwe, DG2YCB via wsjt-devel


Hi Stefan,

Yes, it must be 4.5.3. I have updated the tarball. Please download again
and see if it works better now.

73 de DG2YCB,
Uwe


Am 06.01.2023 um 16:57 schrieb Stefan HB9TMC via wsjt-devel:

Hi,

cmake generated an error:
CMake Error at CMakeLists.txt:56 (file):
  file failed to open for reading (No such file or directory):

    ~/bin/wsjtx-2.6.0/src/hamlib-4.5.tar.gz.md5sum



I think CMakeLists.txt should be:
6c6
< set (__hamlib_upstream hamlib-4.5.3)
---
> set (__hamlib_upstream hamlib-4.5)


73
Stefan


___
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 Wrong name for audio CODEC

2022-11-27 Thread Uwe, DG2YCB via wsjt-devel


The reason is that Windows has internally two sets of audio names. One
is for the new Windows Settings menus, but the "true" name is still that
which is used when you open the old "Sounds" menu. And in the registry,
it is stored somewhere else. It is a known Windows bug, that sometimes,
these two sets of audio names may differ. Do you use Windows 10, 11, or 7?


73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 27.11.2022 um 17:09 schrieb Andy Durbin via wsjt-devel:

WSJT-X versions 2.3.0, 2.5.4, and 2.6.0 rc4 do not display the correct
audio device names if the names have been changed. Other apps, such as
Soundcard Scope, show the current device name.

E.g. I change my TS-590S audio CODEC name from "microphone" to "TS-590
RX".  That name shows in the audio device list of Soundcard Scope but
WSJT-X settings/audio does not show the revised name.

The TX and RX audio path can still be correctly selected but the
device names are not correct.

Why doesn't WSJT-X use the current USB Audio CODEC device names?

Thanks and 73,
Andy k3wyc





___
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] Help with Omni-Rig

2022-11-26 Thread Uwe, DG2YCB via wsjt-devel


Hi Andy,


WSJT-X gets the path to OmniRig from Windows. No settings are required
for this within WSJT-X. Usually, OmniRig installs into "C:\Program Files
(x86)\Afreet\OmniRig" but the only thing that matters is which path is
stored in the registry, and whether this path is correct. Please check
if your firewall or your virus scanner block somehow the communication
between WSJT-X and OmniRig. And see if there is a hanging process
somewhere (wsjtx.exe, jt9.exe or omnirig.exe). I am using OmniRig
myself. It works here very well with my Yaesu FT-991 and numerous WSJT-X
versions. I am currently using 1.20, but 1.18 or 1.19 work as well.
Yesterday or the day before, I noticed that some Windows update seemed
to briefly interfere with the connection to OmniRig. But that has since
resolved itself for me.


73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 26.11.2022 um 17:56 schrieb Andy Durbin via wsjt-devel:

I have been running various versions of WSJ-X with Omni-Rig for many
years.  After having my station shut down for about a week I can no
longer run WSJT-X with Omni-Rig.  Error "Failed to start OmniRig COM
server".

If I run Omni-Rig client it connects to my TS-590S with no issue.  If
I close Omni-Rig client and open HDSDR or CW Skimmer both connect to
Omni-Rig and establish 2 way communication with my TS-590S.

It's clear that Omni-Rig and the client are working but it appears
that WSJT-X either cannot find Omni-Rig client or is unable to start it.

Where does WSJT-X expect to find Omni-Rig client and where is the path
specified?

I have found several discussions of this problem but have not found a
solution.  WSJT-X installation was not intentionally changed and I see
the same problem with ver 2.3.0, ver 2.5.4, and 2.6.0 rc4.  All these
versions used to connect to Omni-Rig until this new problem started.

I changed WSJT-X to start with admin privilege and have the same
error.  I also see the same with Omni-Rig 1.19 and 1.20.  Omni-Rig
client seems to have been unchanged since 2004.

Any ideas on how to fix this?

Thanks and 73,
Andy k3wyc


___
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] Some comments for WSJT-X 2.6.0-RC4

2022-11-11 Thread Uwe, DG2YCB via wsjt-devel


Hello Marco,

FYI. The second issue should be fixed with v2.6.0-rc5. We have
fine-tuned some GUI settings so that it now works better with different
font sizes and on different operating systems.

And issue #1 can also be RFI. Does it also happen on all bands or only
on some? Check whether the error is still there when TX PWR is very low.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 10.11.2022 um 21:40 schrieb Marco Calistri via wsjt-devel:

Hello,

I'm using latest release of WSJT-X (2.6.0-RC4) and I faced two issues
so far related to my Linux installation:

1 - Suddenly the audio IN/OUT communication with the default sound
system get lost and WSJT-X stop to receive and to send audio. *Please
note that it happens just within WSJT-X and the default sound system,*
I verified this by opening a YouTube video whose audio plays
perfectly. To resolve this issue I have to "*pkill*"wsjtx, eventually
delete its lock file in /tmp and restart the app.

2 - With my desktop environment (XFCE), I need to start WSJT-X with a
specific *"style"* option, otherwise the band frequencies and other
graphical details (buttons, menus) of the program window are resulting
not perfectly adjusted for the window itself. More in detail, I use a
script to start my WSJT-X which executes the following command:

*/home/marco/WSJT-X_build/.wsjtx/bin/wsjtx -style Fusion*

Would like to know if is there an option, during the program source
compiling of WSJT-X, to *force* a specific starting window environment
style.

3 - Please note that the issue at point 1 is *not present with WSJT-X
for Windows as I could verify under Windows 11.**

*
Many thanks for your kindest attention!

Best regards,


---
*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

Re: [wsjt-devel] 2.6.0-RC4 GUI error

2022-10-17 Thread Uwe, DG2YCB via wsjt-devel


Hi Barry,

A couple of days ago, we already made a few minor improvements to the
GUI stretching. It should be better in the next release. However, this
error occurs only under certain conditions (application font, font size,
screen size, style sheet, Qt version, etc.), and primarily on Linux.
Therefore, the fix is not quite as easy as one might think. Currently, I
can only suggest you to reduce the font size (e.g. to 9 pt).

73 de Uwe, DG2YCB


Am 17.10.2022 um 00:56 schrieb Barry Jackson via wsjt-devel:

An annoying error has crept in that chops half the leading character
in the band field on the left of the main window.

Mageia cauldron (dev) (Linux)
Using 1024x1280 resolution monitor.

See in the attached photo that the 3 of '30m' is indistinguishable
from an 8.

Cheers,
Barry
G4MKT


___
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.6.0-rc3 ALL_WSPR.TXT error

2022-09-29 Thread Uwe, DG2YCB via wsjt-devel


Hi Josh,

Thanks for reporting this bug. We found and fixed the root cause. The
fix will be included in the next release.

The error occurred when the user transmitted at t < 0.6 * TRPeriod after
a band change. This is typically the case with WSPR when band hopping is
enabled, but almost never with the other modes. That is why it has not
been noticed there yet. For some time now, late decodes are assigned to
the previous band, even if they are coming shortly after the band change
(this was a long-standing defect in old WSJT-X versions), but for Tx of
course the current band must be used for the ALL.TXT entries. The
missing Rx/Tx differentiation was the bug.

73 de DG2YCB,
Uwe

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB


Am 03.09.2022 um 18:30 schrieb Josh Rovero via wsjt-devel:

64-bit built from source on Fedora Core 36:

The transmit log entries in ALL_WSPR.TXT show the incorrect band.

For example, if WSJT-X WSPR was receiving on 18 MHz, then transmits on
7 MHz, the WSJT-X window shows the correct transmit 7 MHz band, but
the ALL_WSPR.TXT entry shows 18 MHz as the transmit band.

--
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

Re: [wsjt-devel] Second wsjt-x2.6.0-rc4-Linux64 Hound issue

2022-09-20 Thread Uwe, DG2YCB via wsjt-devel


Hi Saku,

Thanks for the bug report. Should be fixed with the next release. Under
certain conditions, some special operating modes were not fully
initialized when WSJT-X was started in such a mode.

73 de Uwe, DG2YCB


Am 18.09.2022 um 15:13 schrieb Saku via wsjt-devel:


Hi!

Found also another issue:

If wsjt-x is closed with Hound-mode running the *next start will
activate hound-mode again* (tested that by setting TX under 1000Hz and
started TX. It jumped random ove 1000Hz) *but the mainwidow view is
mixed*.


As you can see red "hound" stays there, but there is also "Hold TX
frequency" visible.
In addition to that the button "H" is not colored as should.

Pressing "H" button will color it and also remove "Hold TX frequency".

Tested that with clean start to be sure that any of my settings could
effect that:

wsjtx -r testing
Then set callsign, locator,rig,audio and hound mode on.
Out of settings -> stopped wsjtx
Started again
wsjtx -r testing

View can be repeated.


Fedora release 35 (Thirty Five)
wsjt-x2.6.0-rc4 self compiled, source from
https://git.code.sf.net/p/wsjt/wsjtx (same day as Hamlib below)
rigctl Hamlib 4.5~git fri sep 16 13:33:51 2022 + SHA=b1d132


--
Saku
OH1KH


___
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] V. 2.6 Error and Crash

2022-07-28 Thread Uwe, DG2YCB via wsjt-devel


Hi,

For those of you who have problems with occasional program crashes, I
can recommend the following:

 * Download this "wsjtx_log_config.ini" file and save it to your log
   directory (for Linux, put it in ~/.config):
   
https://sourceforge.net/projects/wsjt/files/wsjtx-2.6.0-rc2/Tests/wsjtx_log_config.ini.
   It enables trace logging, so that we can see every "event".
 * Close WSJT-X, start it once again, and reproduce the error (in this
   case, let WSJT-X run until the program crashes).
 * On your desktop appears a new "logs" folder, and two files in it are
   created: "WSJT-X_RigControl.log" and "wsjtx_syslog.log". The first
   one is relevant to detect hamlib issues, but especially the latter
   is helpful to detect any abnormal behavior (i.e. abnormal termination).
 * Open the "wsjtx_syslog.log" file with a text editor, copy the last
   20 or 25 lines of this file and send it to me. Experienced users
   can, of course, already analyze themselves what causes the crash.
 * Then delete (or rename) the "wsjtx_log_config.ini" file again,
   because due to the trace logging the two .log files grow quickly in
   size.
 * Delete the "logs" folder if you don't need it anymore.

Perhaps also helpful to know: I recently did the same procedure with an
OM who also reported occasional sudden program crashes. It turned out
that HRD caused the crashes for him.

73 de Uwe, DG2YCB


Am 28.07.2022 um 10:28 schrieb Dennis W1UE via wsjt-devel:

Mike
Green found the same as you.  If I just deleted the JT9 process, it
still didn’t work with N1MM. I have to restart the computer to again
operate.

UE

On Wed, Jul 27, 2022 at 21:54 mpcorey--- via wsjt-devel
 wrote:

Thanks Dennis, it sounds very similar to what I’m experiencing.
Just this evening, while calling CQ on 40, it has crashed three
times. Each time I open task manager and find the JT9 process, end
it, and it will restart. Although in once instance it crashed
again within seconds of restarting. I’m not getting the error
messages though, like I did with 2.6rc1, unless I try and restart
the program without first ending the jt9 process.

*From:* Dennis W1UE via wsjt-devel 
*Sent:* Wednesday, July 27, 2022 8:40 PM
*To:* WSJT software development 
*Cc:* Dennis W1UE 
*Subject:* Re: [wsjt-devel] V. 2.6 Error and Crash

Mike

I wrote this up and submitted it a week ago.  I could not find any
sequence of events to cause  the WSJT window to suddenly close.  I
found it took anywhere from 15min to 3 hrs between crashes.  I
also get a TCP error when it closes, as I have wsjt mated to N1mm+
for logging.

Dennis W1UE

On Wed, Jul 27, 2022 at 20:26 mpcorey--- via wsjt-devel
 wrote:

So I posted to this list a few weeks ago about the problem
with 2.6rc1 suddenly crashing, and to restart ending a JT9
process through task manager. Last week, prior to the release
of rc2, this problem was occurring about 2 times per day while
I was on an Iota activation. So, when I returned home, I
downloaded rc2 to the main station computer. The problem is
still occurring, just had a crash and “end JT9 process” fix to
restart it. I recall others mentioning they experienced this,
has anyone else had it happen with rc2? Is this a software
bug? Or something to fix on the operator end?

Thanks,

Mike, KI1U

___
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] WSJT-X 2.6.0-rc2 - possible bug (WSPR messages truncated)

2022-07-25 Thread Uwe, DG2YCB via wsjt-devel


Hi Josh,

We believe we have found and fixed the bug that was causing WSPR
transmissions to stop after about 90 seconds under certain conditions. I
have prepared a new tarball for you that includes this bug fix. You can
download it here:

https://sourceforge.net/projects/wsjt/files/wsjtx-2.6.0-rc2/Tests/wsjtx-2.6.0-rc2_WSPR_bug_fixed.tgz

I have also created a 64-bit Windows installer that contains the same
bug fix:

https://sourceforge.net/projects/wsjt/files/wsjtx-2.6.0-rc2/Tests/wsjtx-2.6.0-rc2-win64_WSPR_bug_fixed.exe

Would be nice if you could give us feedback if it works.

73 de Uwe, DG2YCB



Am 21.07.2022 um 16:35 schrieb Josh Rovero via wsjt-devel:

Built from source on 64-bit Fedora Core 36.  NTP and chronyc show time
sync to less than 13 ms.

WSPR mode.  Receive cycles are timed correctly.  The transmit cycles
end after 90 seconds, instead of going for 2 minutes.

The release 2.5.4 version of WSJT-X does not have this issue.

--
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

Re: [wsjt-devel] hamlib test

2022-07-08 Thread Uwe, DG2YCB via wsjt-devel


Hi Al,

Please be so kind and test it again with this test version of WSJT-X:
https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.6.0/Tests/wsjtx-2.6.0-rc1-win64_with_patch_for_IC7100_and_IC7610.exe

It is our current WSJT-X v2.6.0-rc1, but with one additional patch,
which hopefully fixes the VFOB error on IC7100 and IC7610.

The installer comes already with the latest hamlib files. Only in case
the VFOB error is really still there with this version, replace also the
libhamlib-4.dll file afterwards, and try again.

73 de Uwe, DG2YCB


Am 08.07.2022 um 18:31 schrieb Al Flapan AF4FA via wsjt-devel:

I tested the new vn of hamlib on my IC7100 and attached is the syslog
file.

It still shows the VFO B error and it now shows a file not found error.

Al AF4FA


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

2022-06-20 Thread Uwe, DG2YCB via wsjt-devel


Hi Tony,

As you already mentioned, this can have several reasons. My tip: If you
are working on Windows, just open the task manager in such a case. Most
likely, you will see a hanging wsjtx.exe or jt9.exe process. Close this
process manually and WSJT-X should start again.

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

66 matches

Mail list logo