Could you please collect some debug demonstrating this? I think I may know
what's happening.When you change frequency while transmitting does VFOA or VFOB
change frequency?
$mypath$myrigctld -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C
auto_power_on=0 $myvfo >/tmp/log.txt 2>&1 &
Mike W9MDB
On Tuesday, May 31, 2022, 12:27:15 PM CDT, Saku via wsjt-devel
<wsjt-devel@lists.sourceforge.net> wrote:
Hi Mike!
I have been using version that I have downloaded from Git on 2022-03-18 It has
a problem that seems to be also in this latest version.
Fedora 35 linux
Wsjt-x v2.5.4 d28164-dirty
Icom Ic 7300
I am starting rigctld from script with:
mypath=/usr/local/bin/
myrigctld=rigctld
myvfo='--vfo'
start_rig (){
start_rig1
start_rig2
}
start_rig1 (){
echo -n "IC7300 start " >> /tmp/start.log
/usr/bin/date >> /tmp/start.log
$mypath$myrigctld -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C
auto_power_on=0 $myvfo &
Then at WSTX settings I use rig Net Hamlib rigctld localhost:4532, split rig.
Everything seems to work ok (as earlier version) except that if wsjtx has
started TX period and then I move tx frequency with Shift+left mouse it moves
ok but when RX period comes back rig's vfoA stays on TX frequency and does not
come back to RX frequency.
This happens only if you are a bit too late moving TX frequency I.E. TX period
has already started. If you do it before TX period starts it moves ok and RX
vfoA stays on rx frequency as should.
I have not bothered to report that because it is a marginal bug and can be
avoided by not moving TX when transmit is on, or return right RX frequency
right after TX period ends (if TX frequency was moved) using band selector.
This is only "split rig" problem, and there only then when TX frequency differs
from RX (I.E. on both ends of band slot)
Black Michael via wsjt-devel kirjoitti 31.5.2022 klo 19.04:
I need everyone to test the latest Hamlib Testing in Rig Split and Fake It
would be appreciated. Successes/Failures please report.
New hamlib for installation directions
#1 Shut down WSJTX/JTDX
#2 Download either the 32-bit or 64-bit DLL matching the 32/64-bit version of
WSJTX/JTDX -- 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 \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/
#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
Mike W9MDB
_______________________________________________
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
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
