First, WSJTX is running fine Standalone without Errors.
After starting it remote, i got the old Error with kvasd and kvasd.dat about permissions or not installed.
wsjtx and kvasd are in /usr/bin
kvasd.dat is in several places:
$home
$home/.wsjtx
$home/.local/share/wsjtx
(Try and Error)
After placing kvasd.dat in /usr/bin and made it writeable, no more Errors appeared with the remote start of WSJTX out of CQRLOG.
I think, placing kvasd.dat in /usr/bin is not the real Linux way. But what's the difference between starting WSJTX Standalone and starting it remote?
73 de Heinz-Juergen
DO1YHJ
I'm sorry, I don't know anything about WSJTX. Please ask Saku, OH1KH (oh1kh@sral.fi). He could help.
73 Petr
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Not sure if i understand what you are referring to but, here is a web site with more info about wjstx on Linux, you can download and install the decoder as well as the PPA for the software, I think the new version 16.0 will not require the decoder anymore, you can even download the new version if you wish. de Tom K8WDX
https://launchpad.net/~ki7mt
Tom K8WDX
You must install and configure KVASD Installer via ppa KI7MT.
KVASD Installer is a set of scripts used to Install, Remove or Test KVASD binary, used by WSJT, WSJT-X and MAP65
INSTALLATION
------------
Add PPA .......: sudo add-apt-repository ppa:ki7mt/kvasd-installer
Update ........: sudo apt-get update
Install .......: sudo apt-get install kvasd-installer
TO RUN
-------
- Open A terminal and type: kvasd-installer
- Then, select Install decoder from the menu.
73 Julien
Hi!
First of all you should have WSJTX working smoothly on it's own.
As I understood it is, then ...
Remotely means that you start WSJTX by selecting WSJTX remote from CQRLOG and
it will then start as a child process of CQRLOG, I think.
There is some differences between Petr's version and mine. I have not tested
Petr's one for longer period, but been rather happy to my own one.
If you can compile it with Lazarus you can find it from GitHub as one branch
of Petr's code (or use keywords: OH1KH cqrlog).
I think kvasd should not effect UDP messaging of WSJTX in any way. So there must
be something wrong with WSJTX itself.
I'm using 1.5.0 version here.
There is a rc-version of 1.6.0 but it has not been tested with cqrlog (at least I do not know).
There should not be big differences in UDP communication, but at least 1.6.0 carries out new modes that might cause false results on cqrlog that does have those modes on
it's mode list.
I'm going to start testing later with 1.6.0, but it might go as long as it is issued as stabile, not rc-version.
BTW
I run WSJTX always so that it is started as it's own. After it is running I select remote wsjtx from cqrlog.
If for any reason cqrlog crashes WSJTX is still running as it it it's own process.
Specially good if this happens in the middle of qso. You can carry it to end and
log it afterwards to cqrlog after restarting it,
AT least OH1MRR has reported to me that WSJTX has some decoding problems in his setup. It seems to be related to Fedora releases, as he is running newer release than I. But his problems are "inside" WSJTX. I have understood.
73
Saku
OH1KH
--
Saku
OH1KH
I'm using Fedora22 now, and problems was some library related. Now after some updates wsjtx seem to work, at least one jt65 qso kept :)
Worked smoothly in remote mode. First started wsjtx and then remote mode..
<p>Jarmo</p>
WSJTX runs smoothly on its own without problems. KVASD is installed and does his job.
Starting it remotely as a Child process out of CQRLOG causes the error in WSJTX with not finding or missing permissions for KVASD or kvasd.dat
I fixed it with placing kvasd.dat in /usr/bin.
My OS is Mint 17.2 (64bit).
The only little problem is Radio Control. WSJTX doesn’t like sharing Radio Control with CQRLOG.
73 de Heinz-Juergen
DO1YHJ
Ok.
Fine that you have found solution with /usr/bin. Other way could maybe be changing PATH so that kvasd.dat could be found along PATH directories.
There should be no problem with radio control sharing if you select "RIG" at wsjtx/settings to be "Hamlib NET rigctl" pollrate 1s
There are no other settings to make if you have default values in cqrlog (Host 127.0.0.1 port 4532) and it is working there.
I recommend to use Hamlib that comes with WSJTX rather than the one (maybe older) that you may have from cqrlog or some install pagage.
There are many fixes done in that code. Just symlink rigctld to point the one that comes with WSJTX so every instance starts with that instead of "original".
Rigctld can share rig to multiple instances. When you have cqrlog and wsjtx running you can sill telnet localhost:4532 and command/read your rig from there, too.
Check also that you have /etc/hosts line:
127.0.0.1 localhost localhost.localdomain
And if you do not need IPV6 anywhere comment out (with #) line:
#::1 localhost localhost.localdomain
if it is there.
73
Saku
OH1KH
--
Saku
OH1KH
TNX for the tip with Hamlib Net rigctl. I should read more manpages HI HI. :-)
73 de Heinz-Juergen
DO1YHJ