Jtdx 2.2.160 Download

3,751 views
Skip to first unread message

Xena Donovan

unread,
Jul 24, 2024, 7:07:01 PM7/24/24
to cuuswadelli

The best source of help is the jtdx-improved-community mailing list. You will find this to be an active forum for communication among users of jtdx_improved.The chances are good that someone with similar interests and equipment has already solved your problem and will be happy to help. To post messages there you will need to subcribe.

I think most of its duty can be reach with combination of cqrlog's CQ monitor (displays worked/unworked Grids and does alerts) and Pskreporter web page (displays activity of own station rx and tx and also public activity by bands).

jtdx 2.2.160 download


Download File ⇒⇒⇒ https://tlniurl.com/2zLvMC



If you like to use cqrlog's wsjt-x remote with WSJT-X or JTDX and another program that needs UDP messages from those you have to use multicast UDP addressing.
Otherwise cqrlog or the other program (ex. GridTracker) will "eat" all UDP frames depending what program is started first.

How ever if you have from package installed cqrlog it does not usually support UDP multicast (package is too old), you must compile newer version from current GitHub source.
Easy way to check multicast support is to look at cqrlog help: "NewQSO/Help/Help index/Quick start/wsjt-x interface" if you find there a chapter that talks about multicast then cqrlog supports it.

It would be nice to know is this relaying working for two directions?
If not, in that case user is not able to initiate new qso from cqrlog/Cq-monitor by double clicking a decoded callsign line.
Also other similar things, like stop TX if someone else gets qso with called station or "colorback" to wsjt-x display by cqrlog's worked qsos, do not work then.

Then in cqrlog select NewQSO/file/remote for wsjt. If CQ-monitor window is not open open it from NewQSO/Window/WSJTX monitor. You can not see this selection unless "remote for wsjt" is active.
Now when wsjt-x(jtdx) will decode a period you will see all CQs in CQ-monitor colored by your log information (right click on CQ-monitor opens color settings).

When you see a wanted station calling CQ you can double left click on that line on CQ-monitor. That will start wsjt-x calling that station. That needs the UDP frame going to reverse direction from cqrlog to wsjtx.

Other example: When CQ-monitor is open check the Map checkbox. CQ monior will turn to map mode where all decoded messages are colored by your log information. At the botton of window there is ColorBackCQs if that is checked cqrlog will send the same color information to wsjtx so that all CQ lines at "Band activity" window of wsjtx are colored same way as in CQ-monitor. This also needs the UDP frames going to reverse direction.

Does this build in a clean chroot? You're using unzip in the build function, but I don't think that would be installed?
The unzip should be in the prepare function.
You should quote any variables that you don't control, as they could contain a space. You have instances of $srcdir and $pkgdir unquoted.
Why are you executing ../jtdx?
Not wrong, but the install commands can be drastically simplified. You can specify multiple files at once, or even just *.wav, then give the target directory with -t.
Why are you skipping man pages and docs? And if you do skip them, do you still need texinfo/asciidoc/asciidoctor at build time?

Thanks for the reply. I will move the unzip function to prepare. Thanks for the suggestions for quoting, I will make that change as well. I was unaware of the proper use of install in PKGBUILDs. ../jtdx is part of the cmake command, pointing to the dir where cmake files are. Will make these changes and update for review.

This also removes use of bsdtar as makepkg will automatically extract the zip archive listed in the source array. If you follow CMake_package_guidelines you can skip creating the directory build and use of $srcdir.
The package still built for me with git removed from makedepends. What is using it?

We built the jtdxhamlib package statically, while does not link to INDI dynamically in jtdx... Either upstream need to fix the static link issue, or we need to build jtdxhamlib without indi support.Quick fix: add --without-indi to jtdxhamlib PKGBUILD

gcc9 is no loner available in the official repos, but in the archive, but jtdx does not compile with it. But somehow or other the PKGBUILD also does not export the compilers. Either you add the compiler edition with

4a15465005
Reply all
Reply to author
Forward
0 new messages