Building from the rc1 source:
/home/josh/Downloads/wsjtx-2.7.0/src/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:23:39:
23 |ndepth,ndiskdat,neme,newdat,nfa,nfb,nfcal,nfshift,
&
| 1
Error: Symbol ‘nfa’ at (1) is USE associated from module
Same errors as with FC37, 64-bit.
On FC38, gcc version 13.1.1 20230511 (Red Hat 13.1.1-2) (GCC)
/home/josh/Downloads/wsjtx-2.7.0/src/wsjtx-prefix/src/wsjtx/qmap/libqmap/q65c.f90:23:39:
23 |ndepth,ndiskdat,neme,newdat,nfa,nfb,nfcal,nfshift,
&
|
Everything compiles after applying the patch, thanks.
Operating 64-bit FC38 to Signalink USB to Yaesu FT-950:
In WSPR receiving mode, frequency hopping, everything is normal.
If "ENABLE TX" is set, it gets unset after every cycle. If manually reset
to "ENABLE TX" during a transmit cycle, it will
Since installing 2.7.0-rc1 (built from source), I have observed the
following behavior on Fedora Core 38, 64-bit, hamlib 4.5.4. Yaesu FT-950,
tty/USB0 for serial, and Signalink USB sound card. PTT method is CAT.
Everything worked normally in FC37 and wsjtx-2.6.1.
"Test CAT" does not turn green,
I normally operate WSPR with band-hopping enabled. Today I turned it off
for testing.
Fedora Core 38, 64-bit, built from source, to Yaesu FT-950 via Signalink
USB.
With band-hopping off, the "Enable TX" button stays enabled during multiple
receive cycles and even after a scheduled transmit cycle.
Builds and runs well on Fedora Core 38 64-bit.
While WSPR band hopping, the first band change cycle "unsets" Enable Tx,
but after resetting Enable TX, subsequent band changes keep it set.
--
P.J. "Josh" Rovero http://www.roveroresearch.org
Ham Radio: KK1D
On Fedora Core 39, 64 bit, (uname -a
Linux fedora 6.7.7-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 1
16:53:59 UTC 2024 x86_64 GNU/Linux, gcc version 13.2.1 20231205 (Red Hat
13.2.1-6) (GCC))
I get the following errors building RC4:
[ 94%] Building Fortran object
qmap/libqmap/CMakeFiles/qmap_i
All,
WSJT-X 2.5.0-rc3, running on both ancient AMD Athlon and brand new AMD
Ryzen 5-3600 running 64-bit Fedora Core 34. After a few days of WSPR
operation, some time intervals report 6+ second DT values. Eventually all
time intervals report 6+ second DTs.
Computers are sync'd to Stratum 2 NTP s
I use Rig Split with FT-950 via a USB serial adapter.
On the first tune/transmit cycle after starting the software, the "Enable
Tx" button turns off, but manually turning it on keeps it on for subsequent
tune/transmit cycles.
--
P.J. "Josh" Rovero http://www.roveroresearch.org
Ham Radio: KK1
Joe, et al,
I am building the code on Fedora Core Linux, 64-bit.
Most of my past programming has been non-GUI scientific data decoding and
analysis, plus some simulation of satellite components and systems.
The only changes I have made are some minor contributions a few years back
to make multip
2.6.0-rc1, built from source for 64-bit linux Fedora Core - In WSPR mode,
repeatedly switches bands on odd-minutes, after only 1 minute of
receive/transmit.
--
P.J. "Josh" Rovero http://www.roveroresearch.org
Ham Radio: KK1D
___
wsjt-devel mailing l
2.6.0-rc1, built from source on Fedora Core 36, 64-bit.
In the WSPR mode, the first transmit cycle (after several normal receive
cycles) ends 95 seconds after the start of the window.. Example - Transmit
window starts at 14:16:00, ends at 14:17:35. WSJT-X stays on the same band
from that point u
This causes problems with WSJT-X 2.5.4 and 2.6.0-rc1 on Fedora Core 36,
64-bit. The behavior was not present in Fedora Core 35.
It appears that the system rescans and renumbers/relabels USB devices once
a day, resulting in hamlib losing control of an operating WSJT-X instance.
When WSJT-X is rest
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"
On my 64-bit fedora core 36 system, AMD Ryzen 5 2.2 GHz, about .05 second
of audio is dropped on many 2-minute WSPR receive cycles. Audio interface
is Texas Instruments Burr-Brown (Signalink USB). Version of WSJT-X doesn't
matter, happens with 2.5.4 or the 2.6.0-rc* versions.
[SYSLOG][2022-07-23
Uwe, Joe,
Built the rc2_WSPR_big_fixed tgz on Fedora Core 36, 64-bit. The latest
version still truncates the WSPR transmit period at 90 seconds.
On Mon, Jul 25, 2022 at 1:07 PM Uwe, DG2YCB wrote:
> Hi Josh,
>
> We believe we have found and fixed the bug that was causing WSPR
> transmissions to
The latest release candidate builds and runs fine on Fedora Core 36, 64-bit.
Long term testing continues.
--
P.J. "Josh" Rovero http://www.roveroresearch.org
Ham Radio: KK1D
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lis
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 trans
Continued from 2.6.0-rc3, still in rc4, 64-bit compiled from source on FC36:
The ALL_WSPR.TXT log file transmit bands are incorrect. The logged
transmit band is the previous receive band, while the main UI shows the
correct band.
Example:
UI reporting correct rig transmit band:
1108 ---
Builds and runs fine on Fedora Core 37 Linux, 64-bit.
And the ALL_WSPR.TXT incorrect transmit band issue looks like it's fixed.
--
P.J. "Josh" Rovero http://www.roveroresearch.org
Ham Radio: KK1D
___
wsjt-devel mailing list
wsjt-devel@lists.sourcef
20 matches
Mail list logo
