Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT

[Saku via wsjt-devel]

Good point Claude!

But I have at the moment only IC7300, WiFi Mouse and Hp laser printer 
connected to PC via USB.
I have several symlinks, even for gps (because of some tests years ago) 
But I do not have gpsd installed at the moment.


[saku@hamtpad ~]$ cat /etc/udev/rules.d/92-persistent-usb.rules

#own CI-V box
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="067b", 
ATTRS{idProduct}=="2303", ATTRS{product}=="USB 2.0 To COM Device", 
SYMLINK+="rig"

#IC7300
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", 
ATTRS{idProduct}=="ea60" ,ATTRS{serial}=="IC-7300 03003483", 
SYMLINK+="icom7300"
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", 
ATTRS{idProduct}=="6001", ATTRS{serial}=="A601VSBR", SYMLINK+="cwkeyer"
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="067b", 
ATTRS{idProduct}=="2303", ATTRS{product}=="USB-Serial Controller D", 
SYMLINK+="gps"

#ESP WiFi device via USB-TTL converter
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", 
ATTRS{idProduct}=="ea60" ,  ATTRS{serial}=="0001", SYMLINK+="ardu"

#Xduino UNO V
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="1a86", 
ATTRS{idProduct}=="7523", SYMLINK+="ardu"

#Arduino UNO V2
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", 
ATTRS{idProduct}=="0001", SYMLINK+="ardu"


Claude Frantz via wsjt-devel kirjoitti 4.9.2021 klo 15.47:

On 8/27/21 10:06 AM, Saku via wsjt-devel wrote:

Hi Saku & all,

I have noticed a similar problem when using a GPS mouse as time source 
for ntpd. The source of the problem is gpsd, especially when using the 
"-n" command line flag, which is necessary here, although this 
information is not included in the man page.


The solution was to set the "gpsd.service" as disabled with systemctl:
systemctl disable gpsd.service

At next, I have inserted the following line in 
/etc/udev/rules.d/99-hamlib.rules:


SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", 
ATTRS{serial}=="IC-7300 [0-9]*", TEST!="/dev/rigA", SYMLINK+="rigA"


Now, the IC-7300 appears as /dev/rigA. This was necessary because the 
GPS mouse includes the same chip.


Finally, I have created a file "/etc/modprobe.d/my-local.conf" with:

alias pps-ldisc  /dev/null
alias tty-ldisc-18  /dev/null

in order to avoid that gpsd try to use any tty device as PPS device.

When beginning, I plug in the XCVR and the GPS mouse on the USB 
sockets. Then I start rigctld on /dev/rigA. Then gpsd "systemctl start 
gpsd.service". I verify that gpsd is receiving data from the mouse 
"gpsmon". After some delay, I verify that ntpd is using the signal 
from gpsd via the shared memory: "ntpq -4p 127.0.0.1". Then I can 
start wsjtx.


Perhaps you have a similar interference with gpsd.

Best wishes,
Claude (DJ0OT) 


--
Saku
OH1KH



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

Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT

[Claude Frantz via wsjt-devel]

On 8/27/21 10:06 AM, Saku via wsjt-devel wrote:

Hi Saku & all,

I have noticed a similar problem when using a GPS mouse as time source 
for ntpd. The source of the problem is gpsd, especially when using the 
"-n" command line flag, which is necessary here, although this 
information is not included in the man page.


The solution was to set the "gpsd.service" as disabled with systemctl:
systemctl disable gpsd.service

At next, I have inserted the following line in 
/etc/udev/rules.d/99-hamlib.rules:


SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", 
ATTRS{serial}=="IC-7300 [0-9]*", TEST!="/dev/rigA", SYMLINK+="rigA"


Now, the IC-7300 appears as /dev/rigA. This was necessary because the 
GPS mouse includes the same chip.


Finally, I have created a file "/etc/modprobe.d/my-local.conf" with:

alias pps-ldisc  /dev/null
alias tty-ldisc-18  /dev/null

in order to avoid that gpsd try to use any tty device as PPS device.

When beginning, I plug in the XCVR and the GPS mouse on the USB sockets. 
Then I start rigctld on /dev/rigA. Then gpsd "systemctl start 
gpsd.service". I verify that gpsd is receiving data from the mouse 
"gpsmon". After some delay, I verify that ntpd is using the signal from 
gpsd via the shared memory: "ntpq -4p 127.0.0.1". Then I can start wsjtx.


Perhaps you have a similar interference with gpsd.

Best wishes,
Claude (DJ0OT)


Now during few days I have noticed that calling cq with FT4 causes PTT 
to stay on during RX period. Nearly to end of it. Then small RX gap and 
TX starts again to next TX period (at proper time).

This happens at random times after started CQ calling.

When this starts to happen it may also cause error that rig is not 
responding. But not always. On other times it may just blink once the 
"green dot" besides band selector to yellow and back to green.


After some time of calling cq with these problems TX enable drops away, 
no errors, and no receiving any more. Waterfall stays blank while 
stations can be heard from speaker I.E. there is traffic.


Stopping and starting WSJTx does not help for long. If PTT problem has 
happened it soon continues after program restart. Rebooting PC helps and 
gives longer time until the PTT again stays on.


This does not happen with FT8.

It is a random problem, and so hard to reproduce but has happened now 
daily when I have started to use FT4 again with these versions of WSJTX 
and Hamlib.


I may also be a rigctld problem, it is not the very latest from Git.
Anyway it causes WSJTX to be unstable.



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

Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT

[Saku via wsjt-devel]

Hi Reino, Bill and Mike!

FYI

It looks like the PTT staying on was an RFI problem after all.

Nothing changed in station setup, but a wire from the rear chassis of 
IC7300 to a filter box that ICOM has in it's power cable was loosen 
(fully detached).

As it is at back side of rig it is not visible for operator.

Noticed it yesterday when a new problem started: During FT8 TX period 
the sound card was switched between ICOM's internal card and PC's sound 
card several times during a TX period. Because nothing was changed at 
PC's side I finally peeked the wires behind the rig.


I think this is now fixed, but the other problem still remains: When 
using self compiled binaries from latest versions of hamlib and wsjtx 
(4.3/2.5.0rc5)  the "split/rig" does not work leaving vfoB to previously 
used band when band is changed.
It should change to band of vfoA when first transmit period begins (or 
Tune), that it actually does for a second, but then reverts back to 
previously used band.

I did already sent a link (to Mike) to a short video that shows the problem.
https://drive.google.com/file/d/1wW3xr6d2NiN7sLTUj3WCU_aOKqOQ5z7l/view?usp=sharing

I have now reverted back to hamlib 4.1 and wsjtx 2.4.0, both installed 
from Fedora 34 packages. That combination works with "rig/split" while 
the latest versions need "rig/Fake it" to work properly.


Reino Talarmo via wsjt-devel kirjoitti 27.8.2021 klo 11.20:

Hi!

Now during few days I have noticed that calling cq with FT4 causes PTT to stay 
on during RX period. Nearly to end of it. Then small RX gap and TX starts again 
to next TX period (at proper time).
This happens at random times after started CQ calling.

When this starts to happen it may also cause error that rig is not responding. But not 
always. On other times it may just blink once the "green dot" besides band 
selector to yellow and back to green.

After some time of calling cq with these problems TX enable drops away, no 
errors, and no receiving any more. Waterfall stays blank while stations can be 
heard from speaker I.E. there is traffic.

Stopping and starting WSJTx does not help for long. If PTT problem has happened 
it soon continues after program restart. Rebooting PC helps and gives longer 
time until the PTT again stays on.

This does not happen with FT8.

It is a random problem, and so hard to reproduce but has happened now daily 
when I have started to use FT4 again with these versions of WSJTX and Hamlib.

I may also be a rigctld problem, it is not the very latest from Git.
Anyway it causes WSJTX to be unstable.


Anybody seen this kind of problem with FT4 and 2.5.0rc5 ?


Setup:

Fedora 34
Self compiled WSJTX 2.5.0rc5 using Hamlib 4.3~git ti elo(Aug) 03
05:04:13 2021 + SHA=f29ee3 source

IC7300 / USB baud rate Auto (19200 in rigctld settings) /Link to [remote] /CI-V 
tranceive off rigctld   -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C 
auto_power_on=0

rigctld started from script with IC7300 settings, WSJTX uses Net Hamlib rigctld 
@ localhost:4532

Terve Saku,
Have you ever experienced RFI? Those symptoms do fit to that. Easiest quick 
check is to reduce output power and see, if any change. Experts may find 
another reason or reasons.
73, Reino OH3mA



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


--
Saku
OH1KH



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

Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT

[Saku via wsjt-devel]

Yep!

Yesterday I cleaned all, cloned again Hamlib from GitHub and WSJTX from 
sourceforge and then compiled.


What I found out first is that split/rig does not work, I thought this 
was fixed some time ago with IC7300.
Well, it is not. With latest sources it happens to work so that if 
setting is split/rig then if I start to work on 21Mc it works, but if I 
then change to 14Mc RX will go to 14Mc but TX at vfoB stays on 21Mc.

So I have to use split/fake it to make it work properly.

--
Saku
OH1KH

Black Michael kirjoitti 31.8.2021 klo 15.37:
Are you compiling with the latest hamlib?  Hamlib 4.3 release is 
rolling out very soon.

You can check out the current version...

git clone https://github.com/Hamlib/Hamlib.git 



Mike W9MDB




On Tuesday, August 31, 2021, 01:22:47 AM CDT, Saku via wsjt-devel 
 wrote:



There is no effect setting poll rate 1s, 2s or 5s. Always fails after a
while. I would say that shorter poll rate seems to raise problems faster.
I think I clean up everything and recompile all again.

--
Saku
OH1KH

Saku via wsjt-devel kirjoitti 30.8.2021 klo 17.27:


Black Michael via wsjt-devel kirjoitti 27.8.2021 klo 18.22:
> Those cache times are showing 10134ms = 10 seconds since the last time
> ptt was polled.  For FT4 that's not good.
>
> What is your polling rate in WSJT-X?
>
> Mike W9MDB

Hi MIke!

Poll rate is 5sec. Compared to FT4 period it is too long, but I expect
that every needed command is placed at time it should happen (not placed
in poll queue) and reply for sent command comes immediately and at all
other times (when not any special job to execute) rig is polled by poll
rate.

But if every rig cat command sent and responded go via poll queue then I
just wonder how it has worked this far from the beginning of FT4 mode.

I'll try next to minimize the poll rate and see what happens.




___
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] 2.5.0rc5 and FT4 PTT

[Black Michael via wsjt-devel]

Are you compiling with the latest hamlib?  Hamlib 4.3 release is rolling out 
very soon.You can check out the current version...
git clone https://github.com/Hamlib/Hamlib.git
Mike W9MDB

 

On Tuesday, August 31, 2021, 01:22:47 AM CDT, Saku via wsjt-devel 
 wrote:  
 
 There is no effect setting poll rate 1s, 2s or 5s. Always fails after a 
while. I would say that shorter poll rate seems to raise problems faster.
I think I clean up everything and recompile all again.

-- 
Saku
OH1KH

Saku via wsjt-devel kirjoitti 30.8.2021 klo 17.27:


Black Michael via wsjt-devel kirjoitti 27.8.2021 klo 18.22:
> Those cache times are showing 10134ms = 10 seconds since the last time 
> ptt was polled.  For FT4 that's not good.
>
> What is your polling rate in WSJT-X?
>
> Mike W9MDB

Hi MIke!

Poll rate is 5sec. Compared to FT4 period it is too long, but I expect 
that every needed command is placed at time it should happen (not placed 
in poll queue) and reply for sent command comes immediately and at all 
other times (when not any special job to execute) rig is polled by poll 
rate.

But if every rig cat command sent and responded go via poll queue then I 
just wonder how it has worked this far from the beginning of FT4 mode.

I'll try next to minimize the poll rate and see what happens.




___
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] 2.5.0rc5 and FT4 PTT

[Bill Somerville via wsjt-devel]

On 31/08/2021 07:17, Saku via wsjt-devel wrote:
There is no effect setting poll rate 1s, 2s or 5s. Always fails after 
a while. I would say that shorter poll rate seems to raise problems 
faster.

I think I clean up everything and recompile all again.

--
Saku
OH1KH


Hi Saku,

the WSJT-X rig polling rate really only affects the responsiveness of 
WSJT-X to changes made via the rig's front panel. If the serial rate is 
very slow then an in-progress polling sequence may occasionally impact 
responsiveness of CAT commands, but since the fastest polling rate is a 
rather slow once per second, even that is unlikely.


73
Bill
G4WJS.



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

Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT

[Saku via wsjt-devel]

There is no effect setting poll rate 1s, 2s or 5s. Always fails after a 
while. I would say that shorter poll rate seems to raise problems faster.

I think I clean up everything and recompile all again.

--
Saku
OH1KH

Saku via wsjt-devel kirjoitti 30.8.2021 klo 17.27:


Black Michael via wsjt-devel kirjoitti 27.8.2021 klo 18.22:
Those cache times are showing 10134ms = 10 seconds since the last time 
ptt was polled.  For FT4 that's not good.


What is your polling rate in WSJT-X?

Mike W9MDB


Hi MIke!

Poll rate is 5sec. Compared to FT4 period it is too long, but I expect 
that every needed command is placed at time it should happen (not placed 
in poll queue) and reply for sent command comes immediately and at all 
other times (when not any special job to execute) rig is polled by poll 
rate.


But if every rig cat command sent and responded go via poll queue then I 
just wonder how it has worked this far from the beginning of FT4 mode.


I'll try next to minimize the poll rate and see what happens.




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

Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT

[Saku via wsjt-devel]

Black Michael via wsjt-devel kirjoitti 27.8.2021 klo 18.22:
Those cache times are showing 10134ms = 10 seconds since the last time 
ptt was polled.  For FT4 that's not good.


What is your polling rate in WSJT-X?

Mike W9MDB


Hi MIke!

Poll rate is 5sec. Compared to FT4 period it is too long, but I expect 
that every needed command is placed at time it should happen (not placed 
in poll queue) and reply for sent command comes immediately and at all 
other times (when not any special job to execute) rig is polled by poll 
rate.


But if every rig cat command sent and responded go via poll queue then I 
just wonder how it has worked this far from the beginning of FT4 mode.


I'll try next to minimize the poll rate and see what happens.


--
Saku
OH1KH



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

Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT

[Black Michael via wsjt-devel]

Those cache times are showing 10134ms = 10 seconds since the last time ptt was 
polled.  For FT4 that's not good.
What is your polling rate in WSJT-X?
Mike W9MDB


 

On Friday, August 27, 2021, 10:12:57 AM CDT, Saku via wsjt-devel 
 wrote:  
 
 Thanks Bill!

Pulled last Hamlib from GItHub, compiled and installed.

Then cloned wsjt-x from sourceforge, made CMAKE_PREFIX_PATH to point 
that cloned Hamlib directory and compiled.

Now I have running version that again has same problem than some time ago:
     If I use 17m, then change to 20m to work there then rig's vfoB does 
not change transmitting still on 17m and receiving on 20m with vfoA

I think it is now time to restore previously compiled version (that did 
not have this error) and then take weekend without any programming.

Have nice weekend!

PS.
FT4 problem still existed also with this version, too.
2021-08-27 14:33:15.401025][00:00:58.757069][RIGCTRL:trace] rig_get_ptt: 
cache miss age=10134ms
There are similar with get_mode, get_vfo and get_split_vfo with 
ages/widths with times from 23ms to 52460ms



-- 
Saku
OH1KH



___
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] 2.5.0rc5 and FT4 PTT

[Saku via wsjt-devel]

Thanks Bill!

Pulled last Hamlib from GItHub, compiled and installed.

Then cloned wsjt-x from sourceforge, made CMAKE_PREFIX_PATH to point 
that cloned Hamlib directory and compiled.


Now I have running version that again has same problem than some time ago:
    If I use 17m, then change to 20m to work there then rig's vfoB does 
not change transmitting still on 17m and receiving on 20m with vfoA


I think it is now time to restore previously compiled version (that did 
not have this error) and then take weekend without any programming.


Have nice weekend!

PS.
FT4 problem still existed also with this version, too.
2021-08-27 14:33:15.401025][00:00:58.757069][RIGCTRL:trace] rig_get_ptt: 
cache miss age=10134ms
There are similar with get_mode, get_vfo and get_split_vfo with 
ages/widths with times from 23ms to 52460ms




--
Saku
OH1KH



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

Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT

[Bill Somerville via wsjt-devel]

On 27/08/2021 14:03, Saku via wsjt-devel wrote:


Bill Somerville via wsjt-devel kirjoitti 27.8.2021 klo 14.05:
if you are not going to use the bundled Hamlib sources then there is 
little point in starting with the WSJT-X sources tarball we provide. 
That tarball is specifically set up to build WSJT-X using that 
bundled Hamlib. You would be better to simply clone the WSJT-X git 
source repository f


I think a while ago I told (might be just in mail to Mike, not to 
dev-list) how I tar and checksum Git-hamlib clone with names of Hamlib 
in wsjt-x tarball, replace the original files and then do build. I 
think it is not clever (at least not easiest) way and asked is there a 
proper way.


If I search GitHub with "wsjt-x" I get 57 repositories.  Then there is 
SourceForge. To tell the truth I have difficulties to know where is 
the latest official source (elsewhere than tarball@Joe's web page). 
Mainly because I am not Git guru and I can do just some basic things 
there.


Hamlib is easy to find from GItHub. It is just "hamlib" and can be 
found as first hit of search.


--
Saku
OH1KH


Hi Saku,

WSJT-X is not on GitHub. GitHub and SourceForge are two examples of Open 
Source project hosting sites, there are many more. WSJT-X happens to use 
SourceForge as it has, or had, usefull facilities at the time it was 
chosen as a hosting site.


The git repository is just like those of other projects hosted there and 
on other hosting sites. It has a web source browsing interface here: 
https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/


73
Bill
G4WJS.

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

Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT

[Saku via wsjt-devel]

Bill Somerville via wsjt-devel kirjoitti 27.8.2021 klo 14.05:
if you are not going to use the bundled Hamlib sources then there is 
little point in starting with the WSJT-X sources tarball we provide. 
That tarball is specifically set up to build WSJT-X using that bundled 
Hamlib. You would be better to simply clone the WSJT-X git source 
repository f


I think a while ago I told (might be just in mail to Mike, not to 
dev-list) how I tar and checksum Git-hamlib clone with names of Hamlib 
in wsjt-x tarball, replace the original files and then do build. I think 
it is not clever (at least not easiest) way and asked is there a proper way.


If I search GitHub with "wsjt-x" I get 57 repositories.  Then there is 
SourceForge. To tell the truth I have difficulties to know where is the 
latest official source (elsewhere than tarball@Joe's web page). Mainly 
because I am not Git guru and I can do just some basic things there.


Hamlib is easy to find from GItHub. It is just "hamlib" and can be found 
as first hit of search.


--
Saku
OH1KH



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

Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT

[Bill Somerville via wsjt-devel]

On 27/08/2021 11:29, Saku via wsjt-devel wrote:


Bill Somerville via wsjt-devel kirjoitti 27.8.2021 klo 11.42:

Hi Saku,

have you tried using the rigctld-wsjtx that is bundled with WSJT-X, 
or the one built with the Hamlib package you linked WSJT-X with?


73
Bill
G4WJS. 



HI Bill!

No, not tested with rigctld-wsjtx.
But when extracted wsjtx source I removed the hamlib part and replaced 
it with this Git source I mentioned. So there is only one version of 
Hamlib in this PC.


On directly compiled and installed from Git clone source and that same 
source is transferred to wsjtx build. So there should not be any lib 
conflicts.


I may try to do Git pull again and recompile to get very latest Hamlib 
when time permits. I also try to find if there is any clue how to 
reproduce this problem.


And to Reino:
If there has not been RF problems before, and when FT8 works ok also 
now, I suspect that is not RF problem with FT4. But I can test it also 
with reduced power.



--
Saku
OH1KH


Hi Saku,

if you are not going to use the bundled Hamlib sources then there is 
little point in starting with the WSJT-X sources tarball we provide. 
That tarball is specifically set up to build WSJT-X using that bundled 
Hamlib. You would be better to simply clone the WSJT-X git source 
repository from SourceForge and checkout the tag that matches the 
version you wish to build, or the master branch which is normally at the 
same point as the latest released RC or GA version, whichever is most 
recent.


If you are using any rigctld process then you can turn on diagnostics 
for it by adding between one and five -v flags, five bieng the most 
verbose. To get diagnostics from the rigctl client built into WSJT-X, 
includng the Hamlib NET rigctl client, you can place the attached file 
into the WSJT-X configuration files directory (~/.config on Linux 
systems), then restart WSJT-X to have it create a trace log file on your 
Desktop called WSJT-X_RigControl.log. Oe or both of those trace files 
should have all that is needed to work out what is happening.


73
Bill
G4WJS.

[Sinks.SYSLOG]
Destination=TextFile
Asynchronous=true
AutoFlush=false
FileName="${AppLocalDataLocation}/wsjtx_syslog.log"
TargetFileName="${AppLocalDataLocation}/logs/wsjtx_syslog_%Y-%m.log"
RotationTimePoint="01 00:00:00"
Append=true
EnableFinalRotation=false
MaxSize=41943040
MinFreeSpace=1073741824
MaxFiles=12
Target="${AppLocalDataLocation}/logs"
ScanForFiles="Matching"
Format="[%Channel%][%TimeStamp(format=\"%Y-%m-%d 
%H:%M:%S.%f\")%][%Uptime(format=\"%O:%M:%S.%f\")%][%Severity%] %Message%"
Filter="%Severity% >= info"

[Sinks.RIGCTRL]
Destination=TextFile
Asynchronous=true
AutoFlush=true
FileName="${DesktopLocation}/WSJT-X_RigControl.log"
Append=true
Format="[%TimeStamp(format=\"%Y-%m-%d 
%H:%M:%S.%f\")%][%Uptime(format=\"%O:%M:%S.%f\")%][%Channel%:%Severity%] 
%Message%"
Filter="%Channel% matches \"SYSLOG\" | %Channel% matches \"RIGCTRL\""
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT

[Saku via wsjt-devel]

Bill Somerville via wsjt-devel kirjoitti 27.8.2021 klo 11.42:

Hi Saku,

have you tried using the rigctld-wsjtx that is bundled with WSJT-X, or 
the one built with the Hamlib package you linked WSJT-X with?


73
Bill
G4WJS. 



HI Bill!

No, not tested with rigctld-wsjtx.
But when extracted wsjtx source I removed the hamlib part and replaced 
it with this Git source I mentioned. So there is only one version of 
Hamlib in this PC.


On directly compiled and installed from Git clone source and that same 
source is transferred to wsjtx build. So there should not be any lib 
conflicts.


I may try to do Git pull again and recompile to get very latest Hamlib 
when time permits. I also try to find if there is any clue how to 
reproduce this problem.


And to Reino:
If there has not been RF problems before, and when FT8 works ok also 
now, I suspect that is not RF problem with FT4. But I can test it also 
with reduced power.



--
Saku
OH1KH



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

Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT

[Bill Somerville via wsjt-devel]

On 27/08/2021 09:06, Saku via wsjt-devel wrote:

Hi!

Now during few days I have noticed that calling cq with FT4 causes PTT 
to stay on during RX period. Nearly to end of it. Then small RX gap 
and TX starts again to next TX period (at proper time).

This happens at random times after started CQ calling.

When this starts to happen it may also cause error that rig is not 
responding. But not always. On other times it may just blink once the 
"green dot" besides band selector to yellow and back to green.


After some time of calling cq with these problems TX enable drops 
away, no errors, and no receiving any more. Waterfall stays blank 
while stations can be heard from speaker I.E. there is traffic.


Stopping and starting WSJTx does not help for long. If PTT problem has 
happened it soon continues after program restart. Rebooting PC helps 
and gives longer time until the PTT again stays on.


This does not happen with FT8.

It is a random problem, and so hard to reproduce but has happened now 
daily when I have started to use FT4 again with these versions of 
WSJTX and Hamlib.


I may also be a rigctld problem, it is not the very latest from Git.
Anyway it causes WSJTX to be unstable.


Anybody seen this kind of problem with FT4 and 2.5.0rc5 ?


Setup:

Fedora 34
Self compiled WSJTX 2.5.0rc5 using Hamlib 4.3~git ti elo(Aug) 03 
05:04:13 2021 + SHA=f29ee3 source


IC7300 / USB baud rate Auto (19200 in rigctld settings) /Link to 
[remote] /CI-V tranceive off

rigctld   -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C auto_power_on=0

rigctld started from script with IC7300 settings, WSJTX uses Net 
Hamlib rigctld @ localhost:4532


--
Saku
OH1KH


Hi Saku,

have you tried using the rigctld-wsjtx that is bundled with WSJT-X, or 
the one built with the Hamlib package you linked WSJT-X with?


73
Bill
G4WJS.



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

Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT

[Reino Talarmo via wsjt-devel]

Hi!

Now during few days I have noticed that calling cq with FT4 causes PTT to stay 
on during RX period. Nearly to end of it. Then small RX gap and TX starts again 
to next TX period (at proper time).
This happens at random times after started CQ calling.

When this starts to happen it may also cause error that rig is not responding. 
But not always. On other times it may just blink once the "green dot" besides 
band selector to yellow and back to green.

After some time of calling cq with these problems TX enable drops away, no 
errors, and no receiving any more. Waterfall stays blank while stations can be 
heard from speaker I.E. there is traffic.

Stopping and starting WSJTx does not help for long. If PTT problem has happened 
it soon continues after program restart. Rebooting PC helps and gives longer 
time until the PTT again stays on.

This does not happen with FT8.

It is a random problem, and so hard to reproduce but has happened now daily 
when I have started to use FT4 again with these versions of WSJTX and Hamlib.

I may also be a rigctld problem, it is not the very latest from Git.
Anyway it causes WSJTX to be unstable.


Anybody seen this kind of problem with FT4 and 2.5.0rc5 ?


Setup:

Fedora 34
Self compiled WSJTX 2.5.0rc5 using Hamlib 4.3~git ti elo(Aug) 03
05:04:13 2021 + SHA=f29ee3 source

IC7300 / USB baud rate Auto (19200 in rigctld settings) /Link to [remote] /CI-V 
tranceive off rigctld   -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C 
auto_power_on=0

rigctld started from script with IC7300 settings, WSJTX uses Net Hamlib rigctld 
@ localhost:4532

Terve Saku,
Have you ever experienced RFI? Those symptoms do fit to that. Easiest quick 
check is to reduce output power and see, if any change. Experts may find 
another reason or reasons. 
73, Reino OH3mA



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