Description of problem: Hamlib fails to set a split VFO. Can be seen with rigctl, WSJSTX, and JS8Call. This is a regression from hamlib-4.0-0.9.fc33.20200615git779cd69287.x86_64. Version-Release number of selected component (if applicable): hamlib-4.0-0.13.20201126gitd8be93350f.fc33.x86_64 hamlib-4.0-2.fc33.x86_64 How reproducible: Configure WSJSTX and configure to use Elecraft KX3 and click on tune button. Or run rigctl using Kx3 for the rig. Steps to Reproduce with JS8Call: 1. Start JS8Call in a terminal window 2. Configure to use Elecraft KX3 for rig control. 3. press the "Tune" button Actual results: Enters tuning mode for brief moment and returns These lines are printed to the console: 20-12-29T21:14:03.042Z: Hamlib: kenwood_set_split_vfo: unsupported VFO Sub 20-12-29T21:14:03.665Z: Hamlib: kenwood_set_split_vfo: unsupported VFO Sub Expected results: cat control should set radio to split mode and start transmitting. This does work in version in hamlib-4.0-0.9.fc33.20200615git779cd69287.x86_64 Additional info: Output of rigctl with set_split_vfo and get_split_vfo using hamlib-4.0-2.fc33.x86_64: rigctl -m 2045 -r /dev/ttyUSB0 -s 38400 -vvvvvv rigctl Hamlib 4.0 Last commit was Fri Dec 25 02:30:30 2020 +0000 SHA=519f82 Report bugs to <hamlib-developer.net> rig_init called initrigs4_kenwood called rig_register called rig_register: rig_register (2012) rig_register called rig_register: rig_register (2013) rig_register called rig_register: rig_register (2001) rig_register called rig_register: rig_register (2025) rig_register called rig_register: rig_register (2003) rig_register called rig_register: rig_register (2004) rig_register called rig_register: rig_register (2016) rig_register called rig_register: rig_register (2024) rig_register called rig_register: rig_register (2005) rig_register called rig_register: rig_register (2007) rig_register called rig_register: rig_register (2009) rig_register called rig_register: rig_register (2010) rig_register called rig_register: rig_register (2022) rig_register called rig_register: rig_register (2014) rig_register called rig_register: rig_register (2030) rig_register called rig_register: rig_register (2021) rig_register called rig_register: rig_register (2029) rig_register called rig_register: rig_register (2043) rig_register called rig_register: rig_register (2044) rig_register called rig_register: rig_register (2045) rig_register called rig_register: rig_register (2047) rig_register called rig_register: rig_register (2038) rig_register called rig_register: rig_register (2002) rig_register called rig_register: rig_register (2011) rig_register called rig_register: rig_register (2006) rig_register called rig_register: rig_register (2008) rig_register called rig_register: rig_register (2015) rig_register called rig_register: rig_register (2026) rig_register called rig_register: rig_register (2017) rig_register called rig_register: rig_register (2033) rig_register called rig_register: rig_register (2042) rig_register called rig_register: rig_register (2020) rig_register called rig_register: rig_register (2023) rig_register called rig_register: rig_register (2027) rig_register called rig_register: rig_register (2034) rig_register called rig_register: rig_register (2031) rig_register called rig_register: rig_register (2039) rig_register called rig_register: rig_register (2037) rig_register called rig_register: rig_register (2028) rig_register called rig_register: rig_register (2019) rig_register called rig_register: rig_register (2032) rig_register called rig_register: rig_register (2036) rig_register called rig_register: rig_register (2048) rig_register called rig_register: rig_register (2040) rig_register called rig_register: rig_register (2041) rig_register called rig_register: rig_register (2046) kenwood_init called, version 20201214/20201214.2 kenwood_init: if_len = 37 rig_open called port_open called serial_open called serial_setup called serial_setup: tcgetattr serial_setup: cfmakeraw serial_setup: cfsetispeed=38400,0x000f serial_setup: cfsetospeed=38400,0x000f serial_setup: data_bits=8 serial_setup: parity=0 serial_setup: tcsetattr TCSANOW serial_flush called tcflush elecraft_open called, rig version=20201214.2 elecraft_open: rig_model=2045,2038 verify_kenwood_id called kenwood_get_id called kenwood_transaction called kenwood_transaction: cmdstr = ID rig_flush: called for serial device serial_flush called tcflush write_block called write_block(): TX 3 bytes 0000 49 44 3b ID; read_string called, rxmax=128 read_string(): RX 6 characters 0000 49 44 30 31 37 3b ID017; kenwood_transaction: read_string(len=6)='ID017;' kenwood_transaction: returning RIG_OK, retval=0 kenwood_transaction: returning retval=0 verify_kenwood_id: Rig ID is ID017 kenwood_safe_transaction called kenwood_transaction called kenwood_transaction: cmdstr = OM rig_flush: called for serial device serial_flush called tcflush write_block called write_block(): TX 3 bytes 0000 4f 4d 3b OM; read_string called, rxmax=128 read_string(): RX 16 characters 0000 4f 4d 20 41 50 46 2d 2d 2d 54 42 58 2d 30 32 3b OM APF---TBX-02; kenwood_transaction: read_string(len=16)='OM APF---TBX-02;' kenwood_transaction: returning RIG_OK, retval=0 kenwood_transaction: returning retval=0 elecraft_open: OM=OM APF---TBX-02 elecraft_open: model=KX3, kpa31 elecraft_get_extension_level called kenwood_safe_transaction called kenwood_transaction called kenwood_transaction: cmdstr = K2 rig_flush: called for serial device serial_flush called tcflush write_block called write_block(): TX 3 bytes 0000 4b 32 3b K2; read_string called, rxmax=128 read_string(): RX 4 characters 0000 4b 32 30 3b K20; kenwood_transaction: read_string(len=4)='K20;' kenwood_transaction: returning RIG_OK, retval=0 kenwood_transaction: returning retval=0 elecraft_get_extension_level: K2 extension level is 0, K20 elecraft_open: K2 level is 0, K20 elecraft_get_extension_level called kenwood_safe_transaction called kenwood_transaction called kenwood_transaction: cmdstr = K3 rig_flush: called for serial device serial_flush called tcflush write_block called write_block(): TX 3 bytes 0000 4b 33 3b K3; read_string called, rxmax=128 read_string(): RX 4 characters 0000 4b 33 30 3b K30; kenwood_transaction: read_string(len=4)='K30;' kenwood_transaction: returning RIG_OK, retval=0 kenwood_transaction: returning retval=0 elecraft_get_extension_level: K3 extension level is 4, K30 elecraft_open: K3 level is 4, K30 elecraft_get_firmware_revision_level called kenwood_transaction called kenwood_transaction: cache invalidated kenwood_transaction: cmdstr = RVM rig_flush: called for serial device serial_flush called tcflush write_block called write_block(): TX 4 bytes 0000 52 56 4d 3b RVM; read_string called, rxmax=128 read_string(): RX 9 characters 0000 52 56 4d 30 32 2e 37 30 3b RVM02.70; kenwood_transaction: read_string(len=9)='RVM02.70;' kenwood_transaction: returning RIG_OK, retval=0 kenwood_transaction: returning retval=0 elecraft_get_firmware_revision_level: Elecraft firmware revision is 2.70 kenwood_get_trn called kenwood_safe_transaction called kenwood_transaction called kenwood_transaction: cmdstr = AI rig_flush: called for serial device serial_flush called tcflush write_block called write_block(): TX 3 bytes 0000 41 49 3b AI; read_string called, rxmax=7 read_string(): RX 4 characters 0000 41 49 30 3b AI0; kenwood_transaction: read_string(len=4)='AI0;' kenwood_transaction: returning RIG_OK, retval=0 kenwood_transaction: returning retval=0 kenwood_set_trn called kenwood_transaction called kenwood_transaction: cache invalidated kenwood_transaction: cmdstr = AI0 rig_flush: called for serial device serial_flush called tcflush write_block called write_block(): TX 4 bytes 0000 41 49 30 3b AI0; write_block called write_block(): TX 3 bytes 0000 49 44 3b ID; read_string called, rxmax=35 read_string(): RX 6 characters 0000 49 44 30 31 37 3b ID017; kenwood_transaction: read_string(len=6)='ID017;' kenwood_transaction: No data expected, checking ID; in ID017; kenwood_transaction: returning RIG_OK, retval=0 kenwood_transaction: returning retval=0 rig_get_vfo called elapsed_ms: start = 0,0 rig_get_vfo: cache check age=1000000ms rig_get_vfo: cache miss age=1000000ms kenwood_get_vfo_if called kenwood_get_if called kenwood_safe_transaction called kenwood_transaction called kenwood_transaction: cmdstr = IF rig_flush: called for serial device serial_flush called tcflush write_block called write_block(): TX 3 bytes 0000 49 46 3b IF; read_string called, rxmax=128 read_string(): RX 38 characters 0000 49 46 30 30 30 30 37 30 37 37 39 36 30 20 20 20 IF00007077960 0010 20 20 2d 30 30 30 30 30 30 20 30 30 30 36 30 30 -000000 000600 0020 31 30 30 31 20 3b 1001 ; kenwood_transaction: read_string(len=38)='IF00007077960 -000000 0006001001 ;' kenwood_transaction: returning RIG_OK, retval=0 elapsed_ms: start = 0,0 elapsed_ms: after gettime, start = 1609276597,481720790 kenwood_transaction: returning retval=0 kenwood_get_vfo_if: priv->tx_vfo=VFOB elapsed_ms: start = 0,0 elapsed_ms: after gettime, start = 1609276597,481743188 Opened rig model 2045, 'KX3' Backend version: 20201214.2, Status: Beta rigctl_parse: called, interactive=1 Rig command: s rigctl_parse: cmd=s(73) rigctl_parse: cmd==0x73 rigctl_parse: vfo_opt=0 rigctl_parse: debug1 rigctl_parse: debug5 rigctl_parse: debug10 rigctl_parse: vfo_opt=0 rig_get_split_vfo called elapsed_ms: start = 0,0 rig_get_split_vfo: cache check age=1000000ms rig_get_split_vfo: cache miss age=1000000ms kenwood_get_split_vfo_if called kenwood_get_if called kenwood_safe_transaction called kenwood_transaction called elapsed_ms: start = 1609276773,779516654 elapsed_ms: elapsed_msecs=3843 kenwood_transaction: cmdstr = IF rig_flush: called for serial device serial_flush called tcflush write_block called write_block(): TX 3 bytes 0000 49 46 3b IF; read_string called, rxmax=128 read_string(): RX 38 characters 0000 49 46 30 30 30 30 37 30 37 37 39 36 30 20 20 20 IF00007077960 0010 20 20 2d 30 30 30 30 30 30 20 30 30 30 36 30 30 -000000 000600 0020 31 30 30 31 20 3b 1001 ; kenwood_transaction: read_string(len=38)='IF00007077960 -000000 0006001001 ;' kenwood_transaction: returning RIG_OK, retval=0 elapsed_ms: start = 0,0 elapsed_ms: after gettime, start = 1609276777,680150351 kenwood_transaction: returning retval=0 kenwood_get_split_vfo_if: priv->tx_vfo=VFOB elapsed_ms: start = 0,0 elapsed_ms: after gettime, start = 1609276777,680196446 Split: 1 TX VFO: VFOB rigctl_parse: vfo_opt=0 rigctl_parse: retcode=0 rigctl_parse: called, interactive=1 Rig command: rigctl_parse: cmd==0x0a <ENTER> rigctl_parse: cmd==0x0a ? for help, q to quit. Rig command: rigctl_parse: called, interactive=1 Rig command: <Enter S> rigctl_parse: cmd=S(53) rigctl_parse: cmd==0x53 rigctl_parse: vfo_opt=0 rigctl_parse: debug1 rigctl_parse: debug3 rigctl_parse: debug4 c=0a Split: <0 ENTER> rigctl_parse: debug5 rigctl_parse: debug6 rigctl_parse: debug7 <ENTER> <ENTER> <ENTER> <VFOA ENTER> rigctl_parse: debug10 rigctl_parse: vfo_opt=0 rig_parse_vfo called rig_set_split_vfo called vfo_fixup: vfo=currVFO vfo_fixup: Leaving currVFO alone kenwood_set_split_vfo called rig_get_vfo called elapsed_ms: start = 1609276773,779553610 elapsed_ms: elapsed_msecs=235087 rig_get_vfo: cache check age=235086ms rig_get_vfo: cache miss age=235086ms kenwood_get_vfo_if called kenwood_get_if called kenwood_safe_transaction called kenwood_transaction called elapsed_ms: start = 1609276777,680150351 elapsed_ms: elapsed_msecs=231186 kenwood_transaction: cmdstr = IF rig_flush: called for serial device serial_flush called tcflush write_block called write_block(): TX 3 bytes 0000 49 46 3b IF; read_string called, rxmax=128 read_string(): RX 38 characters 0000 49 46 30 30 30 30 37 30 37 37 39 36 30 20 20 20 IF00007077960 0010 20 20 2d 30 30 30 30 30 30 20 30 30 30 36 30 30 -000000 000600 0020 31 30 30 31 20 3b 1001 ; kenwood_transaction: read_string(len=38)='IF00007077960 -000000 0006001001 ;' kenwood_transaction: returning RIG_OK, retval=0 elapsed_ms: start = 0,0 elapsed_ms: after gettime, start = 1609277008,927861621 kenwood_transaction: returning retval=0 kenwood_get_vfo_if: priv->tx_vfo=VFOB elapsed_ms: start = 0,0 elapsed_ms: after gettime, start = 1609277008,927878554 kenwood_transaction called kenwood_transaction: cache invalidated kenwood_transaction: cmdstr = FT0 rig_flush: called for serial device serial_flush called tcflush write_block called write_block(): TX 4 bytes 0000 46 54 30 3b FT0; write_block called write_block(): TX 3 bytes 0000 49 44 3b ID; read_string called, rxmax=35 read_string(): RX 6 characters 0000 49 44 30 31 37 3b ID017; kenwood_transaction: read_string(len=6)='ID017;' kenwood_transaction: No data expected, checking ID; in ID017; kenwood_transaction: returning RIG_OK, retval=0 kenwood_transaction: returning retval=0 elapsed_ms: start = 0,0 elapsed_ms: after gettime, start = 1609277009,135683667 rigctl_parse: vfo_opt=0 rigctl_parse: retcode=0 rigctl_parse: called, interactive=1 Rig command: rigctl_parse: cmd==0x0a <ENTER> rigctl_parse: cmd==0x0a ? for help, q to quit. Rig command: rigctl_parse: called, interactive=1 Rig command:
That doesn't show split being set. Please do "S 0" and "S 1" I'm unable to reproduce this problem Did you do an "ldconfig"? Did you recompile WSJT-X after installing the new hamlib? This may be a problem with shared library compatibility...not sure... Mike W9MDB
tl;dr If I rebuild wsjtx and js8call with "rpmbuild --rebuild" the locally built and installed packages run as expected. The official rpms likely need to be rebuilt with the newer version of hamlib. Otherwise: Maybe there is more than one issue for me, so for the moment forget about rigctl. With hamlib-4.0-2.fc33.x86_64 installed from updates-testing and wsjtx and js8call installed from the fedora 33 repository neither can set the KX3 to split. Here's what happens with wsjtx (js8call is almost exactly the same): 1. Install wsjtx from fedora 33 repository 2. Start wsjts in a terminal window 3. Check that rig is KX3 and settings are correct 4. click on "Tune" button What happens: 1. "Tune" and "TX" buttons flash red for a moment. 2. These lines are printed to the terminal window: 1. Sometimes nothing or most times pop up notification window with: "Rig Control Error Do you want to reconfigure the radio interface?" 2. These lines are printed to the terminal window: Hamlib: kenwood_set_split_vfo: unsupported VFO Sub Hamlib: kenwood_set_split_vfo: unsupported VFO Sub Hamlib: kenwood_set_split_vfo: unsupported VFO Sub Hamlib: kenwood_set_split_vfo: unsupported VFO Sub What I expect to happen: 1. "Tune" and "TX" buttons turn red 2. Set split mode on KX3 if not previously settings 3. Set KX3 to transmit test tone Two points: 1. If hamlib is downgraded to hamlib-4.0-0.9.fc33.20200615git779cd69287.x86_64 both wjstx and js8call work as expected and are able to set the KX3 to split mode. 2. If set up an rpmbuild environment and run "rpmbuild --rebuild wsjtx" the locally rebuilt rpm works as expected and can set the KX3 to split mode. The same is try with a locally rebuilt js8call. As far as rigctl -- I was not using it properly, however with a better understanding of it, the version in hamlib-4.0-2.fc33.x86_64 still doesn't seem to work as expected, but perhaps that is a different issue
I can't quite tell from what you said if you recompiled WSJT_X with hamlib-4.0-2.fc33.x86_64 and if it works or not. Mike W9MDB
Yes the packages were rebuilt with hamlib-4.0-2.fc33.x86_64. These locally rebuilt rpms work for me.
Ok, I just got back from BSA winter camp so I'm wiped for today but I'll look at rebuilding dependencies soon. There were not supposed to be any API/ABI changes but apparently they snuck in.
I think to prevent future problems you should build WSJT-X with the static hamlib and not rely on the shared library. WSJT-X uses structure references which are fragile and not guaranteed -- so always should be built with whatever hamlib is desired, It's not really an ABI change. But references inside rig->caps to things likerig->caps->vfo_list aren't guaranteed to remain the same. Mike W9MDB
My understanding of this is rudimentary, but if that is the case then wouldn't you need to bulid all packages requiring hamlib statically? For me there is also an issue with JS8Call, and I'll bet with fldiji as well. On the otherhand the KX3, it is listed by rigctl as being beta (as are several other Elecraft rigs) and as mdblack98 wrote likely to be in flux.
I created an issue for hamlib that will allow programs like WSJT-X, JSCall, JTDX, and others to avoid having to refer to data structures. You're correct that all those apps would require static linking for now but I think Redhat's policy disallows statically linked binaries. So this will be fixed over the next few months. Meanwhile will try to avoid any changes that impacts the shared library compatibility. Mike W9MDB
For now it sounds like the quick fix is to rebuild wsjtx and js8call but I'll either need to wait until hamlib goes stable or setup buildroot overrides.
FEDORA-2021-8f2cdbcc1d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8f2cdbcc1d
FEDORA-2021-22ba74af32 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-22ba74af32
FEDORA-EPEL-2021-e28aa9eec8 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e28aa9eec8
FEDORA-2021-8f2cdbcc1d has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8f2cdbcc1d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8f2cdbcc1d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-e28aa9eec8 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e28aa9eec8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-22ba74af32 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-22ba74af32` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-22ba74af32 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I'll be able to try out the new rpm tomorrow morning.
(In reply to Fedora Update System from comment #15) > FEDORA-2021-22ba74af32 has been pushed to the Fedora 33 testing repository. > Soon you'll be able to install the update with the following command: > `sudo dnf upgrade --enablerepo=updates-testing > --advisory=FEDORA-2021-22ba74af32` > You can provide feedback for this update here: > https://bodhi.fedoraproject.org/updates/FEDORA-2021-22ba74af32 > > See also https://fedoraproject.org/wiki/QA:Updates_Testing for more > information on how to test updates. It works for me. It's not yet available in the repo -- istalled the packeage on bodhi. Will there be an update for JS8Call as well?
Yes, it's already built but the update system is having some issues right now. You can download/install directly from koji though: https://koji.fedoraproject.org/koji/buildinfo?buildID=1663750 Assuming x86_64: $ sudo dnf update https://kojipkgs.fedoraproject.org//packages/js8call/2.2.0/5.fc33/x86_64/js8call-2.2.0-5.fc33.x86_64.rpm
I found when this problem was introduced. It was an addition to the hamlib_port structure which is defined very early in the rig_caps structure. So it changed the offset of all things after it. A patch has been submitted to WSJT-X to remove all such dependencies. And in 5.0 the structure will be changed to pointers so this won't happen again. Mike W9MDB
FEDORA-2021-22ba74af32 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-8f2cdbcc1d has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2021-e28aa9eec8 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.