Please test the latest hamlib and send a debug log.
Please place this file as described
belowhttps://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0
C:\Users\[username]\AppData\Local\WSJT-X The WSJT-X_Rigcontrol.log file will
be in the same location
For Linux put it in ~/.config
Crossing posts so I am not sure which post responds to what but using the
win64 hamlib dll linked below,
WSJT-X 2.7.0-rc2 still crashes when trying to use the IC-7610. Regardless
if the radio is on or off.
Björn SM7IUN
On Sat, Jul 15, 2023 at 2:49 PM Black Michael wrote:
> This has been fixed
This has been fixed in the latest hamlib...
New hamlib for installation directions
#1 Shut down WSJTX
#2 Download either the 32-bit or 64-bit DLL matching the 32/64-bit version of
WSJTX -- hopefully your browser doesn't block it but may warn you multiple
times.
If you can do a "Save As" you can
On 7/14/2023 10:30 PM, Björn Ekelund via wsjt-devel wrote:
1.30. I cannot believe why anyone would run an outdated firmware on a radio.
Björn,
You vastly overestimate the knowledge of the average ham (at least those
in the US), or their willingness to study more than it took to memorize
the
1.30. I cannot believe why anyone would run an outdated firmware on a radio.
In DXLog.ne we simply do not support outdated firmwares.
Björn
On Fri, Jul 14, 2023 at 12:13 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:
> Also what firmware version are you running?
> I
Also what firmware version are you running?I made some changes which SHOULD be
both forward/backward compatible with the new firmware.
Mike W9MDB
On Thursday, July 13, 2023 at 02:07:03 PM CDT, Björn Ekelund via wsjt-devel
wrote:
The currently published version of the hamlib dll still
Please place this file as described
belowhttps://www.dropbox.com/s/t52ngcalsgnpm8m/wsjtx_log_config.ini?dl=0
C:\Users\[username]\AppData\Local\WSJT-X The WSJT-X_Rigcontrol.log file will
be in the same location
For Linux put it in ~/.config The WSJT-X_Rigcontrol.log file will be here:
The currently published version of the hamlib dll still crashes when
selecting ICOM IC-7610, regardless of async setting.
It does not seem to work for other ICOM models either, but it does not
crash the program.
Control via DXLab Commander is a good workaround while this is being worked
on.
-
From: Black Michael
Sent: Wednesday, July 12, 2023 06:17
To: 'WSJT software development' ; Roger Newey
(K7GXB)
Subject: Re: [wsjt-devel] High CPU load with 2.7.0-rc2
Save this into a file called "hamlib_settings.json" and place in the same
folder as WSJT-X.ini Should improve things u
I confirm that I'm using Linux openSUSE Tumbleweed and this high CPU
load is not present at all.
Regards,
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**
Il 12/07/23 08:51, Black Michael via wsjt-devel ha scritto:
This is a problem on Windows with the async routine enabled. With async
Hi, with 2.6.0 CPU average load is around 0.3% to 0.7% in Rx, with
occasional peaks to 1.6 or 2%, on my W11 system.
Alan G0TLK
On 12/07/2023 13:44, Roger Newey (K7GXB) via wsjt-devel wrote:
Hi Mike,
FYI:
Win10 Task Manager shows:
WSJT-X CPU during Rx: 35-38%
WSJT-X CPU during Tx:
Save this into a file called "hamlib_settings.json" and place in the same
folder as WSJT-X.ini
Should improve things until I get this fixed.
{
"config": {
"async": "0"
}
}
Mike W9MDB
On Wednesday, July 12, 2023 at 07:44:53 AM CDT, Roger Newey (K7GXB)
wrote:
Hi Mike,
FYI:
Win10 Task Manager shows:
WSJT-X CPU during Rx: 35-38%
WSJT-X CPU during Tx: 35-36%
System:
WSJT-X running WSPR "wsjtx-2.7.0-rc2-win64.exe" as downloaded 07-Jul-2023
(Installed over WSJT 2.6.0);
Rig: ICOM 7300; Win10 on dedicated Celeron J4125 with 16GB RAM;
(J4125 has
This is a problem on Windows with the async routine enabled. With async
enabled Windows uses 100% of 1 core. Async disabled runs at 1.6% of 1 core.
It really should be closer to zero than the 1.6% but Windows has a problem with
timing.
Linux doesn't have this problem.
I'm working on a
On Tue, 11 Jul 2023 15:53:25 -0500
Andrew White via wsjt-devel wrote:
> On my Win10 PC, this new version idles at 32% usage which is
> essentially the same as the earlier "4.6~git Jun 28" version. The
> older libhamlib-4.dll v4.5.4 idles at less than 2%.
This new pull request may be relevant:
What rig do you have?
Mike W9MDB
On Tuesday, July 11, 2023 at 04:19:09 PM CDT, Andrew White via wsjt-devel
wrote:
On my Win10 PC, this new version idles at 32% usage which is essentially the
same as the earlier "4.6~git Jun 28" version. The older libhamlib-4.dll v4.5.4
idles at less
Hi Mike,
No, I am running Win10 Pro. I just copied the dll into the \bin
directory and restarted wsjtx270-rc2.
I did not know anything else was necessary. The expected version number
shows up in the wsjtx syslog.
Drew
On 7/11/2023 4:22 PM, Black Michael via wsjt-devel wrote:
Did you do
OH3mA
> -Original Message-
> From: Black Michael via wsjt-devel [mailto:wsjt-
> de...@lists.sourceforge.net]
> Sent: tiistai 11. heinäkuuta 2023 19.53
> To: wsjt-devel@lists.sourceforge.net
> Cc: Black Michael
> Subject: Re: [wsjt-devel] High CPU load with 2.7.0-rc2
&
Did you do an ldconfig after copying the new library
rigctl --version should show
rigctl Hamlib 4.6~git 2023-07-11T16:41:54Z SHA=5a8bd9 64-bit
Mike W9MDB
On Tuesday, July 11, 2023 at 04:19:09 PM CDT, Andrew White via wsjt-devel
wrote:
On my Win10 PC, this new version idles at
On my Win10 PC, this new version idles at 32% usage which is essentially
the same as the earlier "4.6~git Jun 28" version. The older
libhamlib-4.dll v4.5.4 idles at less than 2%.
Drew K9CW
On 7/11/2023 11:52 AM, Black Michael via wsjt-devel wrote:
It's fixedhad a new send_morse routine
: tiistai 11. heinäkuuta 2023 19.53
> To: wsjt-devel@lists.sourceforge.net
> Cc: Black Michael
> Subject: Re: [wsjt-devel] High CPU load with 2.7.0-rc2
>
> It's fixedhad a new send_morse routine (now takes up to 1023 chars to
> transmit) and missed putting a sleep in the main lo
On Tue, 11 Jul 2023 16:52:31 + (UTC)
Black Michael via wsjt-devel wrote:
> With 32 cores here
I must upgrade from my paltry 8 cores ;-)
--
Brian G8SEZ
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
It's fixedhad a new send_morse routine (now takes up to 1023 chars to
transmit) and missed putting a sleep in the main loop.
With 32 cores here the 3% usage didn't really pop out at me.
New 64-bit DLL
https://www.dropbox.com/s/snmkzu8eif89yqs/libhamlib-4.dll?dl=0
New Linux shared library
I can duplicate the problem herewill be fixed ASAP.
Mike W9MDB
On Tuesday, July 11, 2023 at 10:35:20 AM CDT, Brian Morrison via wsjt-devel
wrote:
On Tue, 11 Jul 2023 15:12:00 +0100
Brian Morrison via wsjt-devel wrote:
> Running on Linux under Fedora 38 I am seeing the latest
On Tue, 11 Jul 2023 15:12:00 +0100
Brian Morrison via wsjt-devel wrote:
> Running on Linux under Fedora 38 I am seeing the latest release using
> 100% of one CPU (8-core) when running, stopping monitoring/decoding
> makes no difference, closing the waterfall graph reduces the 100% to
> ~97%.
>
Running on Linux under Fedora 38 I am seeing the latest release using
100% of one CPU (8-core) when running, stopping monitoring/decoding
makes no difference, closing the waterfall graph reduces the 100% to
~97%.
Not sure what else to try, but this appears to be new behaviour with
this release.
26 matches
Mail list logo
