Re: [wsjt-devel] [PATCH v1] Add itone data to the status message packet
Can you supply the updated udp message structure with the new field(s). Thanks 73, Sam W2JDB On Saturday, July 15, 2023 at 06:49:51 AM AKDT, Dhiru Kholia via wsjt-devel wrote: Hi, This patch adds itone data to the status message packet. This feature is useful for 'digital transceivers' as they NO longer need to rely on the AFP-FSK technique, which introduces a non-zero error into the transmitted tone values. While this approach is not as transparent as the AFP-FSK technique, it eliminates the non-zero error associated with AFP-FSK. As an alternate approach, the 'digital transceivers' can use ft8_lib to derive the tones from the 'm_currentMessage' data, which is already a part of the status message packet. However, ft8_lib is currently unable to handle all the possible types of input messages. Related: - https://github.com/kholia/Easy-Transceiver/ (PDX++ design and others) - https://qrpguys.com/qrpguys-digital-fsk-transceiver-iii - https://github.com/agustinmartino/wsjtx_transceiver_interface - https://github.com/agustinmartino/wsjt_transceiver Testing notes: This patch was tested with following software: - https://github.com/bmo/py-wsjtx software - https://github.com/kholia/py-wsjtx (can show 'itone data') A packet capture file (.pcapng) which has samples of the new UDP status message packets in it can be found at the following URL: https://github.com/kholia/py-wsjtx Thanks for your time, and attention. Cheers, Dhiru (VU3CER / WQ6W) ___ 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] [PATCH v1] Add itone data to the status message packet
Hi,
This patch adds itone data to the status message packet.
This feature is useful for 'digital transceivers' as they NO longer need
to rely on the AFP-FSK technique, which introduces a non-zero error into
the transmitted tone values.
While this approach is not as transparent as the AFP-FSK technique, it
eliminates the non-zero error associated with AFP-FSK.
As an alternate approach, the 'digital transceivers' can use ft8_lib
to derive the tones from the 'm_currentMessage' data, which is already a
part of the status message packet. However, ft8_lib is currently unable
to handle all the possible types of input messages.
Related:
- https://github.com/kholia/Easy-Transceiver/ (PDX++ design and others)
- https://qrpguys.com/qrpguys-digital-fsk-transceiver-iii
- https://github.com/agustinmartino/wsjtx_transceiver_interface
- https://github.com/agustinmartino/wsjt_transceiver
Testing notes:
This patch was tested with following software:
- https://github.com/bmo/py-wsjtx software
- https://github.com/kholia/py-wsjtx (can show 'itone data')
A packet capture file (.pcapng) which has samples of the new UDP status
message packets in it can be found at the following URL:
https://github.com/kholia/py-wsjtx
Thanks for your time, and attention.
Cheers,
Dhiru (VU3CER / WQ6W)
From 24e9761818a3e4bf8062630d816983997e1ea032 Mon Sep 17 00:00:00 2001
From: Dhiru Kholia
Date: Sun, 31 Oct 2021 11:36:48 +0530
Subject: [PATCH] [PATCH v1] Add itone data to the status message packet
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This feature is useful for 'digital transceivers' as they NO longer need
to rely on the AFP-FSK technique, which introduces a non-zero error into
the transmitted tone values.
While this approach is not as transparent as the AFP-FSK technique, it
eliminates the non-zero error associated with AFP-FSK.
As an alternate approach, the 'digital transceivers' can use ft8_lib
to derive the tones from the 'm_currentMessage' data, which is already a
part of the status message packet. However, ft8_lib is currently unable
to handle all the possible types of input messages.
Related:
- https://github.com/kholia/Easy-Transceiver/ (PDX++ design and others)
- https://qrpguys.com/qrpguys-digital-fsk-transceiver-iii
- https://github.com/agustinmartino/wsjtx_transceiver_interface
- https://github.com/agustinmartino/wsjt_transceiver
Testing notes:
This patch was tested with following software:
- https://github.com/bmo/py-wsjtx software
- https://github.com/kholia/py-wsjtx (can show 'itone data')
A packet capture file (.pcapng) which has samples of the new UDP status
message packets in it can be found at the following URL:
https://github.com/kholia/py-wsjtx
Co-authored-by: Rafał Rozestwiński
---
Network/MessageClient.cpp | 7 ---
Network/MessageClient.hpp | 2 +-
Network/NetworkMessage.hpp| 1 +
UDPExamples/MessageServer.cpp | 6 --
UDPExamples/MessageServer.hpp | 3 ++-
widgets/mainwindow.cpp| 33 -
6 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/Network/MessageClient.cpp b/Network/MessageClient.cpp
index 1991f1593..fc3998500 100644
--- a/Network/MessageClient.cpp
+++ b/Network/MessageClient.cpp
@@ -571,7 +571,8 @@ void MessageClient::status_update (Frequency f, QString const& mode, QString con
, bool fast_mode, quint8 special_op_mode
, quint32 frequency_tolerance, quint32 tr_period
, QString const& configuration_name
- , QString const& tx_message)
+ , QString const& tx_message
+ , QString const& itone_data)
{
if (m_->server_port_ && !m_->server_.isNull ())
{
@@ -581,8 +582,8 @@ void MessageClient::status_update (Frequency f, QString const& mode, QString con
<< tx_enabled << transmitting << decoding << rx_df << tx_df << de_call.toUtf8 ()
<< de_grid.toUtf8 () << dx_grid.toUtf8 () << watchdog_timeout << sub_mode.toUtf8 ()
<< fast_mode << special_op_mode << frequency_tolerance << tr_period << configuration_name.toUtf8 ()
- << tx_message.toUtf8 ();
- TRACE_UDP ("frequency:" << f << "mode:" << mode << "DX:" << dx_call << "report:" << report << "Tx mode:" << tx_mode << "tx_enabled:" << tx_enabled << "Tx:" << transmitting << "decoding:" << decoding << "Rx df:" << rx_df << "Tx df:" << tx_df << "DE:" << de_call << "DE grid:" << de_grid << "DX grid:" << dx_grid << "w/d t/o:" << watchdog_timeout << "sub_mode:" << sub_mode << "fast mode:" << fast_mode << "spec op mode:" << special_op_mode << "frequency tolerance:" << frequency_tolerance << "T/R period:" << tr_period << "configuration name:" << configuration_name << "Tx message:" << tx_message);
+ << tx_message.toUtf8 () << itone_data.toUtf8 ();
+ TRACE_UDP
Re: [wsjt-devel] High CPU load with 2.7.0-rc2
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 The WSJT-X_Rigcontrol.log file will be here:
~/.local/share/WSJT-X
For MacOS put it in /Users/[username]/Library/Preferences Restart WSJT-X and
duplicate the problem.Shut down WSJT-X
Then send me the WSJT-X_RigControl.log fileMike W9MDB
On Saturday, July 15, 2023 at 08:46:28 AM CDT, Björn Ekelund
wrote:
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 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 save it directly in the appropriate WSJTX
directoryC:\WSJT\WSJTX\bin and replace the libhamlib-4.dll that is there.
http://n0nb.users.sourceforge.net/dll32/libhamlib-4.dll
http://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll
Linux/Unix/Mac users need to compile the latest tar file from
http://n0nb.users.sourceforge.netNote: If compiling on Unix-like systems please
uninstall any Hamlib package you have before installing the new build
#3 If you don't save directly you need to open a file browser and move the file
that way.
If you're not familiar with that here's a video on the file browser -
https://www.youtube.com/watch?v=AyVqCJrs9dk
Once installed on Linux do "ldconfig".
rigctl --version should then show a relatively recent date of the download
Mike W9MDB
On Saturday, July 15, 2023 at 12:30:39 AM CDT, Björn Ekelund
wrote:
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
wrote:
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 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.
Björn SM7IUN
On Wed, Jul 12, 2023 at 3:20 PM Black Michael via wsjt-devel
wrote:
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 Cores. 4 ; Threads. 4 ; Burst 2.70 GHz ; Processor Base 2.00 GHz ;
Cache. 4 MB).
Regret I don't have comparable CPU data for 2.6.0 but will install it if that
helps.
73,
Roger (K7GXB)
-Original Message-
From: Black Michael via wsjt-devel
Sent: Tuesday, July 11, 2023 20:47
What rig do you have?
Mike W9MDB
...
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
...
---
___
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] High CPU load with 2.7.0-rc2
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 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 save it directly in the appropriate
> WSJTX directory
> C:\WSJT\WSJTX\bin and replace the libhamlib-4.dll that is there.
>
> http://n0nb.users.sourceforge.net/dll32/libhamlib-4.dll
>
> http://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll
>
> Linux/Unix/Mac users need to compile the latest tar file from
> http://n0nb.users.sourceforge.net
> Note: If compiling on Unix-like systems please uninstall any Hamlib
> package you have before installing the new build
>
> #3 If you don't save directly you need to open a file browser and move the
> file that way.
>
> If you're not familiar with that here's a video on the file browser -
> https://www.youtube.com/watch?v=AyVqCJrs9dk
>
> Once installed on Linux do "ldconfig".
>
> rigctl --version should then show a relatively recent date of the download
>
> Mike W9MDB
>
>
>
>
>
> On Saturday, July 15, 2023 at 12:30:39 AM CDT, Björn Ekelund <
> bj...@ekelund.nu> wrote:
>
>
> 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 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 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.
>
> Björn SM7IUN
>
> On Wed, Jul 12, 2023 at 3:20 PM Black Michael via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> 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) <
> k7...@narundi.net> 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 Cores. 4 ; Threads. 4 ; Burst 2.70 GHz ; Processor Base 2.00
> GHz ; Cache. 4 MB).
>
> Regret I don't have comparable CPU data for 2.6.0 but will install it if
> that helps.
>
> 73,
> Roger (K7GXB)
>
> -Original Message-
> From: Black Michael via wsjt-devel
> Sent: Tuesday, July 11, 2023 20:47
> What rig do you have?
> Mike W9MDB
> ...
> 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
> ...
> ---
>
>
>
>
> ___
> 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] High CPU load with 2.7.0-rc2
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 save it directly in the appropriate WSJTX
directoryC:\WSJT\WSJTX\bin and replace the libhamlib-4.dll that is there.
http://n0nb.users.sourceforge.net/dll32/libhamlib-4.dll
http://n0nb.users.sourceforge.net/dll64/libhamlib-4.dll
Linux/Unix/Mac users need to compile the latest tar file from
http://n0nb.users.sourceforge.netNote: If compiling on Unix-like systems please
uninstall any Hamlib package you have before installing the new build
#3 If you don't save directly you need to open a file browser and move the file
that way.
If you're not familiar with that here's a video on the file browser -
https://www.youtube.com/watch?v=AyVqCJrs9dk
Once installed on Linux do "ldconfig".
rigctl --version should then show a relatively recent date of the download
Mike W9MDB
On Saturday, July 15, 2023 at 12:30:39 AM CDT, Björn Ekelund
wrote:
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
wrote:
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 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.
Björn SM7IUN
On Wed, Jul 12, 2023 at 3:20 PM Black Michael via wsjt-devel
wrote:
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 Cores. 4 ; Threads. 4 ; Burst 2.70 GHz ; Processor Base 2.00 GHz ;
Cache. 4 MB).
Regret I don't have comparable CPU data for 2.6.0 but will install it if that
helps.
73,
Roger (K7GXB)
-Original Message-
From: Black Michael via wsjt-devel
Sent: Tuesday, July 11, 2023 20:47
What rig do you have?
Mike W9MDB
...
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
...
---
___
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] High CPU load with 2.7.0-rc2
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 answers to the multiple-guess exam for their license. 73, Jim K9YC ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
