Re: [wsjt-devel] How to set up for WSJT-X development?

[Bill Somerville]

On 20/01/2020 20:05, Paul Kube wrote:


$ mkdir -p ~/wsjtx-prefix/build
$ cd ~/wsjtx-prefix
$ git clone git://git.code.sf.net/p/wsjt/wsjtx
 src
$ cd ~/wsjtx-prefix/build
$ cmake -D CMAKE_PREFIX_PATH=~/hamlib-prefix ../src
$ cmake --build .
$ cmake --build . --target install


The next to last line, cmake --build ., dies with those unresolved 
symbols in HamlibTransceiver.cpp. I've taken care not to have any 
other hamlib packages installed on this machine. So it seems to me 
that something in  git://git.code.sf.net/u/bsomervi/hamlib 
 
or  git://git.code.sf.net/p/wsjt/wsjtx 
 is wrong.


73, Paul K6PO


Hi Paul,

something is amiss for sure. Can you reply with the file 
~/wsjtx-prefix/build/CMakeCache.txt please? You should probably send 
that to me direct rather than via the list.


73
Bill
G4WJS.

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

Re: [wsjt-devel] decoding MSK144 on command line?

[Joe Taylor]

Hi Mario,

On 1/17/2020 4:26 AM, Mario Roessler DH5YM wrote:

For decoding FT8 and some other modes the JT9 binary from the WSJT-X 
package can be used. It can process WAV recordings.

Is there a possibility to do that for the MSK144 mode as well?
Background: The very nice openwebrx fork from dd5fjk can already monitor 
FT8 in the background and monitoring 144.360 in MSK144 would be a very 
useful thing.


The current structure of WSJT-X invokes a separate process jt9[.exe] to 
decode any of the "slow" modes.  Such decoding takes place at the end of 
a receive sequence.  In contrast MSK144, a "fast" mode, is decoded 
within the main wsjtx[.exe] process itself.


In principle there is no reason why a command-line program could not be 
written to decode MSK144 signals.  The necessary processing starts in 
Fortran subroutine mskrtd.f90.  This routine and all others required are 
available in the source-code tarball.


-- 73, Joe, K1JT


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

Re: [wsjt-devel] How to set up for WSJT-X development?

[Paul Kube]

Hi Bill --



On Mon, Jan 20, 2020 at 8:53 AM Bill Somerville 
wrote:

> You could use the tarball as a starting point for casual development but
> cloning the official public git repository is best for anything other than
> the simplest of development.
>

Sounds good to me, I'd like to get that working.

> The errors you show above are due to you not having a recent version of
> Hamlib built for use with WSJT-X, the versions of Hamlib in most (probably
> all) Linux repositiories are too old. You should be able to clone the
> official Hamlib git repo and build the master branch for use with WSJT-X.
> You should configure the Hamlib build to build a static library and its
> probably best to install that locally in your own directories using the
> --prefix option of configure. Once you have a locally installed Hamlib you
> can tell the WSJT-X CMake build script where to find it using the
> configuration variable CMAKE_PREFIX_PATH which should include the root
> directory of your locally install Hamlib package.
>
Bill, I did all that. As I said, I followed your
https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/INSTALL. To wit:

$ mkdir ~/hamlib-prefix
> $ cd ~/hamlib-prefix
> $ git clone git://git.code.sf.net/u/bsomervi/hamlib src
> $ cd src
> $ git checkout integration
> $ ./bootstrap
> $ mkdir ../build
> $ cd ../build
> $ ../src/configure --prefix=$HOME/hamlib-prefix \
>--disable-shared --enable-static \
>--without-cxx-binding --disable-winradio \
>CFLAGS="-g -O2 -fdata-sections -ffunction-sections" \
>LDFLAGS="-Wl,--gc-sections"
> $ make
> $ make install-strip
> $ mkdir -p ~/wsjtx-prefix/build
> $ cd ~/wsjtx-prefix
> $ git clone git://git.code.sf.net/p/wsjt/wsjtx src
> $ cd ~/wsjtx-prefix/build
> $ cmake -D CMAKE_PREFIX_PATH=~/hamlib-prefix ../src
> $ cmake --build .
> $ cmake --build . --target install


The next to last line, cmake --build ., dies with those unresolved symbols
in HamlibTransceiver.cpp. I've taken care not to have any other hamlib
packages installed on this machine. So it seems to me that something
in  git://git.code.sf.net/u/bsomervi/hamlib or  git://
git.code.sf.net/p/wsjt/wsjtx is wrong.

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

Re: [wsjt-devel] possible anomaly in type 2 udp messages

[Roger Rehr W3SZ]

Thanks Bill!

I very much appreciate the explanation!

The current situation is not a problem for me;  I had been doing very 
tight error checking at my end, being unaware of the extra text included 
in the message, and so error flags popped up at this end when messages 
with the appended AP information arrived.  I had not previously seen the 
error messages because previously I had not been running the AP decode 
option.


After seeing the error messages here on Saturday I loosened my error 
checking and all has been well here since :)


Thanks again Bill for the explanation and for all that you do!

Have a great week and 73,

Roger
W3SZ

On 1/20/2020 11:38 AM, Bill Somerville wrote:

On 20/01/2020 00:25, Roger Rehr W3SZ wrote:
Today I noticed a very occasional variation in type 2 UDP network 
messages sent by WSJTX version 2.1.2.  The issue of variation is that 
the length of the text message as specified in the UDP message is 
longer than the "correct" text message length, and in fact the "text 
message" portion of the UDP message consists of the "correct" text 
message followed by a number of spaces, followed sometimes other 
character and finally followed by "a1" before the Low Confidence and 
Off air bits of the message are given (in their correct position 
based on the specified "text message" length).


Hi Roger,

thanks for reporting this. The decoded message appendages are an 
artefact of some rather messy internal implementation details of 
WSJT-X. The decoder appends some statistical information about decode 
quality when the decoded message is passed to the user interface part 
of WSJT-X, the reason for this is historical and the information 
should be passed as separate fields or arguments but it was simpler to 
append the text at the time. The extra text should be trimmed off 
before exporting via the UDP messages although the current content 
does reflect exactly what is printed on the WSJT-X UI, so it is not 
technically incorrect. I note also that the "Low confidence" marker is 
not being set correctly, it should have a true value when there is a 
'?' character near the end of the message.


I will fix this for the next release of WSJT-X.

73
Bill
G4WJS.



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




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

Re: [wsjt-devel] possible anomaly in type 2 udp messages

[Roger Rehr W3SZ]

Thanks Joe,

That fits perfectly and explains exactly what I was seeing.

I very much appreciate the info!

Thanks again and thanks for all that you do!

73,

Roger
W3SZ

On 1/20/2020 11:04 AM, Joe Taylor wrote:

Hi Roger,

You will probably get a better answer to your query from Bill, G4WJS. 
But it seems that the messages you are flagging as "bad" are simply 
the ones resulting from successful "a priori" decoding.  This is 
described in the Section 12.1 of the WSJT-X 2.1 User Guide:


http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.1.2.html#_ap_decoding 



-- 73, Joe, K1JT

On 1/19/2020 7:25 PM, Roger Rehr W3SZ wrote:
This message is informational only, for the developers.  The issue 
raised does not represent an operational problem for me as the issue 
is simple to handle in code at the receiving end.  But I thought that 
you should be made aware of the behavior in case it is unintended.  
It may well be intended, and in that I case I apologize for missing 
the memo and creating unnecessary bandwidth :)


Today I noticed a very occasional variation in type 2 UDP network 
messages sent by WSJTX version 2.1.2.  The issue of variation is that 
the length of the text message as specified in the UDP message is 
longer than the "correct" text message length, and in fact the "text 
message" portion of the UDP message consists of the "correct" text 
message followed by a number of spaces, followed sometimes other 
character and finally followed by "a1" before the Low Confidence and 
Off air bits of the message are given (in their correct position 
based on the specified "text message" length).


I don't think that this represents mangling of the UDP packet in 
transit because the size of the text message as specified in the 
message is correct for the included data, and as just noted the Low 
Confidence and Off air bits appear at their expected positions given 
the specified text message length.  If the observed anomaly were a 
result of mangling of the message in transit, there would not be this 
congruity.


Below are print outs of a couple of examples of this anomaly, and 
then of a "good" message.  The "0 Array" is the entire network UDP 
message. "1 Array" thru "11 array" represent the corresponding 
message parts as specified in NETWORK_MESSAGE_HPP. I used 3 carets 
and then 3 percentage markers to bracket the text message in the 
first line so that, when analyzing this, I could tell where the text 
message actually began and ended if there were non printing 
characters present.


Here is an example of a "bad" message:

 From handleMsg2 Routine msg is ^^^CQ TEST N2CG 
FN20   ? a1%%%  CQ2 is --- Grid is FN20 Call is N2CG
The 0 Array is AD BC CB DA 00 00 00 02 00 00 00 02 00 00 00 10 57 53 
4A 54 2D 58 20 2D 20 4D 61 69 6E 32 31 30 01 04 CE ED 30 FF FF FF EF 
3F F1 99 99 A0 00 00 00 00 00 06 60 00 00 00 01 7E 00 00 00 28 43 51 
20 54 45 53 54 20 4E 32 43 47 20 46 4E 32 30 20 20 20 20 20 20 20 20 
20 20 20 20 20 20 20 20 20 20 20 3F 20 61 31 00 00

The 1 Array is AD BC CB DA 00 00 00 02 00 00 00 02 00 00 00
The 2 Array is 57 53 4A 54 2D 58 20 2D 20 4D 61 69 6E 32 31 30
The 3 Array is 01
The 4 Array is 04 CE ED 30
The 5 Array is EF FF FF FF
The 6 Array is 00 00 00 A0 99 99 F1 3F
The 7 Array is 60 06 00 00
The 8 Array is 7E 01
The 9 Array is 43 51 20 54 45 53 54 20 4E 32 43 47 20 46 4E 32 30 20 
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 3F 20 61 31

The 10 Array is 00
The 11 Array is 00
2 ID SIZE is 16
2 Rig Name is WSJT-X - Main210
3 IsNew is 1
5 snr is -17
6 Delta time is 1.1002384186
7 Delta freq is 1632
8 Mode is FT8
9 message is is CQ TEST N2CG FN20   ? a1
10 Low confidence is 0
11 Off Air is 0
--end of Bad Type 2 message

Here is another example of a Bad Type 2 message:

 From handleMsg2 Routine msg is ^^^CQ TEST N4HB FM17 a1%%%  CQ2 is 
--- Grid is FM17 Call is N4HB
The 0 Array is AD BC CB DA 00 00 00 02 00 00 00 02 00 00 00 10 57 53 
4A 54 2D 58 20 2D 20 4D 61 69 6E 32 31 30 01 04 CF D7 90 FF FF FF E9 
3F F6 66 66 60 00 00 00 00 00 04 41 00 00 00 01 7E 00 00 00 28 43 51 
20 54 45 53 54 20 4E 34 48 42 20 46 4D 31 37 20 20 20 20 20 20 20 20 
20 20 20 20 20 20 20 20 20 20 20 20 20 61 31 00 00

The 1 Array is AD BC CB DA 00 00 00 02 00 00 00 02 00 00 00
The 2 Array is 57 53 4A 54 2D 58 20 2D 20 4D 61 69 6E 32 31 30
The 3 Array is 01
The 4 Array is 04 CF D7 90
The 5 Array is E9 FF FF FF
The 6 Array is 00 00 00 60 66 66 F6 3F
The 7 Array is 41 04 00 00
The 8 Array is 7E 01
The 9 Array is 43 51 20 54 45 53 54 20 4E 34 48 42 20 46 4D 31 37 20 
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 61 31

The 10 Array is 00
The 11 Array is 00
2 ID SIZE is 16
2 Rig Name is WSJT-X - Main210
3 IsNew is 1
5 snr is -23
6 Delta time is 1.3997615814
7 Delta freq is 1089
8 Mode is FT8
9 message is is CQ TEST N4HB FM17 a1
10 Low confidence is 0
11 Off Air is 0
--end of Bad Type 2 message

Re: [wsjt-devel] How to set up for WSJT-X development?

[Bill Somerville]

On 20/01/2020 08:24, Paul Kube wrote:
A simple question: Suppose I want to do a little WSJT-X development... 
experimenting with new features, bug fixing, submitting the occasional 
patch. I'll be coding on Linux, but will want to compile for Windows 
as well as Linux for testing. (Not particularly interested in building 
my own source tarball.) What's the best way to do this now?


I can build from 
https://sourceforge.net/projects/wsjt/files/wsjtx-2.1.2/wsjtx-2.1.2.tgz 
 just 
fine; but I've seen email saying the repository has moved to git, so 
I'm not sure that tarball is up to date. On the other hand, following 
the git-centric instructions at 
https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/INSTALL, the 
build dies with errors like:


wsjtx-prefix/src/HamlibTransceiver.cpp:590:66: error: 
‘RIG_PASSBAND_NOCHANGE’ was not declared in this scope
           rig_set_mode (rig_.data (), RIG_VFO_CURR, dummy_mode_, 
RIG_PASSBAND_NOCHANGE);


wsjtx-prefix/src/HamlibTransceiver.cpp:811:32: error: 
‘rig_set_split_freq_mode’ was not declared in this scope
                   error_check (rig_set_split_freq_mode (rig_.data (), 
RIG_VFO_CURR, tx, new_mode, RIG_PASSBAND_NOCHANGE), tr ("setting split 
TX frequency and mode"));



Hi Paul,

building on MS Windows is considerably more complicated than on Linux 
due to the lack of sensible third-party package management on that 
platform, if you are comfortable with working from a Linux terminal 
command line then that is probably your best choice for WSJT-X 
development. You only need install git and a program editor of your 
choice over and above the prerequisites for building WSJT-X and Hamlib 
from the official release tarball. You could use the tarball as a 
starting point for casual development but cloning the official public 
git repository is best for anything other than the simplest of development.


The errors you show above are due to you not having a recent version of 
Hamlib built for use with WSJT-X, the versions of Hamlib in most 
(probably all) Linux repositiories are too old. You should be able to 
clone the official Hamlib git repo and build the master branch for use 
with WSJT-X. You should configure the Hamlib build to build a static 
library and its probably best to install that locally in your own 
directories using the --prefix option of configure. Once you have a 
locally installed Hamlib you can tell the WSJT-X CMake build script 
where to find it using the configuration variable CMAKE_PREFIX_PATH 
which should include the root directory of your locally install Hamlib 
package.


73
Bill
G4WJS.

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

Re: [wsjt-devel] possible anomaly in type 2 udp messages

[Bill Somerville]

On 20/01/2020 00:25, Roger Rehr W3SZ wrote:
Today I noticed a very occasional variation in type 2 UDP network 
messages sent by WSJTX version 2.1.2.  The issue of variation is that 
the length of the text message as specified in the UDP message is 
longer than the "correct" text message length, and in fact the "text 
message" portion of the UDP message consists of the "correct" text 
message followed by a number of spaces, followed sometimes other 
character and finally followed by "a1" before the Low Confidence and 
Off air bits of the message are given (in their correct position based 
on the specified "text message" length).


Hi Roger,

thanks for reporting this. The decoded message appendages are an 
artefact of some rather messy internal implementation details of WSJT-X. 
The decoder appends some statistical information about decode quality 
when the decoded message is passed to the user interface part of WSJT-X, 
the reason for this is historical and the information should be passed 
as separate fields or arguments but it was simpler to append the text at 
the time. The extra text should be trimmed off before exporting via the 
UDP messages although the current content does reflect exactly what is 
printed on the WSJT-X UI, so it is not technically incorrect. I note 
also that the "Low confidence" marker is not being set correctly, it 
should have a true value when there is a '?' character near the end of 
the message.


I will fix this for the next release of WSJT-X.

73
Bill
G4WJS.



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

Re: [wsjt-devel] How to set up for WSJT-X development?

[Joe Taylor]

Hi Paul,

On 1/20/2020 3:24 AM, Paul Kube L6PO wrote:
A simple question: Suppose I want to do a little WSJT-X development... 
experimenting with new features, bug fixing, submitting the occasional 
patch. I'll be coding on Linux, but will want to compile for Windows as 
well as Linux for testing. (Not particularly interested in building my 
own source tarball.)  What's the best way to do this now?


I can build from 
https://sourceforge.net/projects/wsjt/files/wsjtx-2.1.2/wsjtx-2.1.2.tgz 
 just 
fine; but I've seen email saying the repository has moved to git, so I'm 
not sure that tarball is up to date. 


All new revisions of WSJT-X include a tarball including the code from 
which they were built.  The tarball posted at the SourceForge link you 
quote (and also on the WSJT web site here
http://physics.princeton.edu/pulsar/k1jt/wsjtx-2.1.2.tgz ) is, indeed, 
the latest source code that has been released.


In the past, experimental and developmental code that might (or might 
not) become part of a future release was also made publicly available. 
This led to significant problems: for example, another developer copying 
our work in progress and releasing it before it was finished.


You may confidently treat the published tarball as the latest 
source-code release.


-- 73, Joe, K1JT


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

Re: [wsjt-devel] possible anomaly in type 2 udp messages

[Joe Taylor]

Hi Roger,

You will probably get a better answer to your query from Bill, G4WJS. 
But it seems that the messages you are flagging as "bad" are simply the 
ones resulting from successful "a priori" decoding.  This is described 
in the Section 12.1 of the WSJT-X 2.1 User Guide:


http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.1.2.html#_ap_decoding

-- 73, Joe, K1JT

On 1/19/2020 7:25 PM, Roger Rehr W3SZ wrote:
This message is informational only, for the developers.  The issue 
raised does not represent an operational problem for me as the issue is 
simple to handle in code at the receiving end.  But I thought that you 
should be made aware of the behavior in case it is unintended.  It may 
well be intended, and in that I case I apologize for missing the memo 
and creating unnecessary bandwidth :)


Today I noticed a very occasional variation in type 2 UDP network 
messages sent by WSJTX version 2.1.2.  The issue of variation is that 
the length of the text message as specified in the UDP message is longer 
than the "correct" text message length, and in fact the "text message" 
portion of the UDP message consists of the "correct" text message 
followed by a number of spaces, followed sometimes other character and 
finally followed by "a1" before the Low Confidence and Off air bits of 
the message are given (in their correct position based on the specified 
"text message" length).


I don't think that this represents mangling of the UDP packet in transit 
because the size of the text message as specified in the message is 
correct for the included data, and as just noted the Low Confidence and 
Off air bits appear at their expected positions given the specified text 
message length.  If the observed anomaly were a result of mangling of 
the message in transit, there would not be this congruity.


Below are print outs of a couple of examples of this anomaly, and then 
of a "good" message.  The "0 Array" is the entire network UDP message. 
"1 Array" thru "11 array" represent the corresponding message parts as 
specified in NETWORK_MESSAGE_HPP. I used 3 carets and then 3 percentage 
markers to bracket the text message in the first line so that, when 
analyzing this, I could tell where the text message actually began and 
ended if there were non printing characters present.


Here is an example of a "bad" message:

 From handleMsg2 Routine msg is ^^^CQ TEST N2CG FN20   ? 
a1%%%  CQ2 is --- Grid is FN20 Call is N2CG
The 0 Array is AD BC CB DA 00 00 00 02 00 00 00 02 00 00 00 10 57 53 4A 
54 2D 58 20 2D 20 4D 61 69 6E 32 31 30 01 04 CE ED 30 FF FF FF EF 3F F1 
99 99 A0 00 00 00 00 00 06 60 00 00 00 01 7E 00 00 00 28 43 51 20 54 45 
53 54 20 4E 32 43 47 20 46 4E 32 30 20 20 20 20 20 20 20 20 20 20 20 20 
20 20 20 20 20 20 20 3F 20 61 31 00 00

The 1 Array is AD BC CB DA 00 00 00 02 00 00 00 02 00 00 00
The 2 Array is 57 53 4A 54 2D 58 20 2D 20 4D 61 69 6E 32 31 30
The 3 Array is 01
The 4 Array is 04 CE ED 30
The 5 Array is EF FF FF FF
The 6 Array is 00 00 00 A0 99 99 F1 3F
The 7 Array is 60 06 00 00
The 8 Array is 7E 01
The 9 Array is 43 51 20 54 45 53 54 20 4E 32 43 47 20 46 4E 32 30 20 20 
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 3F 20 61 31

The 10 Array is 00
The 11 Array is 00
2 ID SIZE is 16
2 Rig Name is WSJT-X - Main210
3 IsNew is 1
5 snr is -17
6 Delta time is 1.1002384186
7 Delta freq is 1632
8 Mode is FT8
9 message is is CQ TEST N2CG FN20   ? a1
10 Low confidence is 0
11 Off Air is 0
--end of Bad Type 2 message

Here is another example of a Bad Type 2 message:

 From handleMsg2 Routine msg is ^^^CQ TEST N4HB FM17 a1%%%  CQ2 is --- 
Grid is FM17 Call is N4HB
The 0 Array is AD BC CB DA 00 00 00 02 00 00 00 02 00 00 00 10 57 53 4A 
54 2D 58 20 2D 20 4D 61 69 6E 32 31 30 01 04 CF D7 90 FF FF FF E9 3F F6 
66 66 60 00 00 00 00 00 04 41 00 00 00 01 7E 00 00 00 28 43 51 20 54 45 
53 54 20 4E 34 48 42 20 46 4D 31 37 20 20 20 20 20 20 20 20 20 20 20 20 
20 20 20 20 20 20 20 20 20 61 31 00 00

The 1 Array is AD BC CB DA 00 00 00 02 00 00 00 02 00 00 00
The 2 Array is 57 53 4A 54 2D 58 20 2D 20 4D 61 69 6E 32 31 30
The 3 Array is 01
The 4 Array is 04 CF D7 90
The 5 Array is E9 FF FF FF
The 6 Array is 00 00 00 60 66 66 F6 3F
The 7 Array is 41 04 00 00
The 8 Array is 7E 01
The 9 Array is 43 51 20 54 45 53 54 20 4E 34 48 42 20 46 4D 31 37 20 20 
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 61 31

The 10 Array is 00
The 11 Array is 00
2 ID SIZE is 16
2 Rig Name is WSJT-X - Main210
3 IsNew is 1
5 snr is -23
6 Delta time is 1.3997615814
7 Delta freq is 1089
8 Mode is FT8
9 message is is CQ TEST N4HB FM17 a1
10 Low confidence is 0
11 Off Air is 0
--end of Bad Type 2 message

Here is a Good Type 2 message:

 From handleMsg2 Routine msg is ^^^CQ TEST N4HB FM17%%%  CQ2 is --- Grid 
is FM17 Call is N4HB
The 0 Array is AD BC CB DA 00 00 00 02 00 00 00 02 00 00 00 10 57 53 4A 
54 2D 58 20 

[wsjt-devel] How to set up for WSJT-X development?

[Paul Kube]

A simple question: Suppose I want to do a little WSJT-X development...
experimenting with new features, bug fixing, submitting the occasional
patch. I'll be coding on Linux, but will want to compile for Windows as
well as Linux for testing. (Not particularly interested in building my own
source tarball.)  What's the best way to do this now?

I can build from
https://sourceforge.net/projects/wsjt/files/wsjtx-2.1.2/wsjtx-2.1.2.tgz

just
fine; but I've seen email saying the repository has moved to git, so I'm
not sure that tarball is up to date. On the other hand, following the
git-centric instructions at
https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/INSTALL, the build dies
with errors like:

wsjtx-prefix/src/HamlibTransceiver.cpp:590:66: error:
‘RIG_PASSBAND_NOCHANGE’ was not declared in this scope
   rig_set_mode (rig_.data (), RIG_VFO_CURR, dummy_mode_,
RIG_PASSBAND_NOCHANGE);

wsjtx-prefix/src/HamlibTransceiver.cpp:811:32: error:
‘rig_set_split_freq_mode’ was not declared in this scope
   error_check (rig_set_split_freq_mode (rig_.data (),
RIG_VFO_CURR, tx, new_mode, RIG_PASSBAND_NOCHANGE), tr ("setting split TX
frequency and mode"));

[BTW: Attempting to answer my question with a web search turns up the
promising looking WSJT Developers Guide
https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/dev-guide-main.html,
but that begins with a notice that it's obsolete, and to use
https://sourceforge.net/projects/jtsdk/ instead. OK fine, I go there, and
from there to https://sourceforge.net/projects/jtsdk/files/linux/ for the
Linux version, which page tells me the repository has been moved to github
at https://github.com/KI7MT/jtsdk-nix. There I see the announcement that
"This project is no longer under active development", "Those wishing to use
JTSDK should follow the JTSDK .Net Core cross-patform project instead."
Right, OK, but the page https://github.com/KI7MT/jtsdk-tools for that
project only says "Linux - Coming Soon!" A dead end.]

Thanks for any help,

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