Can't control IC-9700 - VFO swapping

[c-x-berger]

I'm having trouble controlling my (club's) IC-9700 with Gpredict. Whenever I click "Engage" on the radio control window, the rig goes in to satellite mode, swaps between the two VFOs(?) for a moment, and then the "Engage" button pops back out. There's no output from rigctld while this happens unless I use -vv. (Output from -vv here.)

I've configured the radio and GPredict as documented in doc/notes/ic-9700.txt. I'm using the latest version of gpredict-git and hamlib-git in the AUR (in other words, fresh builds from master of both.)

This seems similar to #181, but that thread would have me believe this issue's been solved...

[mpippins]

To see debug information in rigctld, you need -vvv (at least 3 v's). If you want a LOT of information, use 5 v's.
Use Hamlib 4.0. I can't get anything above 4.1 to work when the 9700 is in SAT mode. I have a ticket open with Hamlib.

[mdblack98]

What version of hamlib? rigctld --version Mike W9MDB

On Wednesday, April 13, 2022, 12:15:50 PM CDT, Caleb Xavier Berger ***@***.***> wrote:  

I'm having trouble controlling my (club's) IC-9700 with Gpredict. Whenever I click "Engage" on the radio control window, the rig goes in to satellite mode, swaps between the two VFOs(?) for a moment, and then the "Engage" button pops back out. There's no output from rigctld while this happens unless I use -vv. (Output from -vv here.)

I've configured the radio and GPredict as documented in doc/notes/ic-9700.txt. I'm using the latest version of gpredict-git and hamlib-git in the AUR (in other words, fresh builds from master of both.)

This seems similar to #181, but that thread would have me believe this issue's been solved...

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[c-x-berger]

rigctld --version:

rigctl Hamlib 4.4 Thu Dec 02 23:46:51 2021 +0000 SHA=5f8c4c

[KaComet]

This appears to be related to the compatibility problem that was introduced when Hamlib 4.1 switched to using SATMODE for radios that have a built in satellite mode. I have a pull request, #314, that corrects this issue (I use the fix practically every day.) If you're not feeling up to compiling my PR yourself, you can downgrade Hamlib to 4.0 and that should allow you to use your IC-9700.

[KaComet]

@mdblack98, I noticed that the latest commit of Hamlib works with the IC9700 and Gpredict. After some digging, I discovered that commit Hamlib cd2b73415076488f47821b705ff6e4cfc16eb3be corrects this issue. Assuming this fix works after Hamlib 4.5 is released, my PR #314 is unnecessary. So right now, the best fix might be to compile and install the latest commit of Hamlib.

[kareiva]

If I understand correctly, Gpredict actually tries to send an unsupported VFO string:

network.c(979):multicast address=0.0.0.0, port=4532
Connection opened from 127.0.0.1:48740
mutex_rigctld: client lock engaged
mutex_rigctld: client lock disengaged
mutex_rigctld: client lock engaged
mutex_rigctld: client lock disengaged
rig_parse_vfo called
rig_parse_vfo: '1' not found so vfo='None'

It should be somehow sent as "Main" and "Sub".

[kareiva]

@KaComet can you please share your working configuration and parameters passed to rigctld? Are you using the --vfo option?

[KaComet]

@kareiva, I am using the following: rigctld -m 3081 -s 115200 -vvv -r /dev/icom-9700-a

Gpredict and Hamlib were compiled and installed from the latest commit.

[mdblack98]

Add --vfo to the rigctld line.

And what version of hamlib do you have?

rigctl --version

Mike W9MDB

On Friday, November 4, 2022 at 04:45:04 PM CDT, KaComet @.***> wrote:

@kareiva, I am using the following: rigctld -m 3081 -s 115200 -vvv -r /dev/icom-9700-a

Gpredict and Hamlib were compiled and installed from the latest commit.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[KaComet]

@mdblack98, I'm not sure we are on the same page here. My Gpredict config works with the latest Hamlib commit. In fact, adding --vfo breaks the compatibility. As previously stated, I am using the latest commit of Hamlib.

[kareiva]

I have built gpredict and hamlib from git, as advised, gpredict is 2.3.115-0f3be and hamlib is 4.6~git.

Without the --vfo option, the frequencies go back from VHF to UFH (uplink to downlink) on the transceiver every period (1s) - is that normal? I can't switch the modulation on the rig and do anything else (subtones, etc) because of that quick blink.

[KaComet]

@kareiva, that's normal. When Hamlib sets the uplink frequency the IC-9700 will switch the selected VFO. Unfortunately, that's how Icom has setup the CAT interface. I would recommend setting the update timer to three seconds so that you can have time change modes. After you're done getting your RIT set up, you can lower it to one second.

If you prefer a more simple solution, I am working on a version that includes changing both the RIT and the TX/RX modes from Gpredict. It works for the IC-9700, but I am still yet to test it with some of the other radio types. I you want, I can go ahead and push the commit to my fork of Gpredict. From there you would only have to compile from my testing branch.

[kareiva]

I kind of felt it like almost "normal" because one can actually operate and navigate across the spectrum. For some satellites this is not even relevant, as the rig itself can track the main/sub vfo pretty nicely. I was concerned that this operation mode would temporarily swap main with sub vfo and then I might end up transmitting on the downlink, but this doesn't seem to be the case.

Combined with iCom's wfvew, I can handle gpredict remotely and so far it looks good, although a bit quirky. I might be interested in contributing to the ongoing work you've mentioned.

So @KaComet - thanks for sorting this out for me and, I hope, for some other icom users. Much appreciated.

[KaComet]

@kareiva, Glad I could help. Gpredict is kinda old. So contributions and bug fixes are always helpful.

[mdblack98]

This should work with the --vfo option which doesn't do the VFO swap to read the VFO. Otherwise you will see VFO flashing on both the rig and grpedict. I'll have to check what Hamlib does for this since transmitting likely changes the active VFO in this case.

[kareiva]

@mdblack98 it might work if gpredict would be capable of sending the VFO string for this particular rig properly. Now rigctld gets '1' instead of 'Main' [1] and kind of hangs. Simple rigctl works just fine:

$ rigctl -m 3081 -r /dev/ttyUSB0 --civaddr A2 -s 19200 --vfo

Rig command: f
VFO: M
Frequency: 436803806

Rig command: f
VFO: Sub
Frequency: 145847060

Rig command: f
VFO: S
Frequency: 436803806

[1] - See the rigctld debug output above at https://github.com/csete/gpredict/issues/287#issuecomment-1303980325

[kareiva]

The way it works is still weird to me. Here's the output of some of my interactions with rigctl --vfo -vvvv ...: https://gist.github.com/kareiva/e990df39c45d292a878d35eb4e7c8535

[mdblack98]

Can you please describe what "weird" means? Mike W9MDB

On Saturday, November 5, 2022 at 09:08:42 AM CDT, Simonas ***@***.***> wrote:  

The way it works is still weird to me. Here's the output of some of my interactions with rigctl --vfo -vvvv ...: https://gist.github.com/kareiva/e990df39c45d292a878d35eb4e7c8535

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[KaComet]

@mdblack98, adding the --vfo flag currently appears breaks compatibility with Gpredict. When rigctrl is passed --vfo, some commands require a VFO be specified. GPredict does not pass VFOs when reading and writing. Instead, it simply uses the f and i commands. While I would normally be tempted to do PR for this, I don't see a reason. The default rigctrl setting work and changing Gpredict might break compatablity with other radios.

What @kareiva is describing is the VFO selection cursor moving to the TX VFO for a split second while reading the transmit frequency (moving the cursor, not switching the VFOs themselves.) I have experimented with this for a while and have yet to find a way to silently read the TX frequency. It appears that Icom in their infinite wisdom forgot to add a silent read command.

[mdblack98]

They do have a  "silent" command -- 0x25 -- that's what the --vfo implements. The "f" command is one that can take the vfo argument and will not cause the flashing of the vfo. Without the vfo argument there's no way to know what's being asked. Log4OM, for example, includes a vfo checkbox to turn it on.  If an app wants to show both VFOs it should implement the --vfo argument.  I had thought that was already done. Mike W9MDB

On Saturday, November 5, 2022 at 08:39:07 PM CDT, KaComet ***@***.***> wrote:  

@mdblack98, adding the --vfo flag currently appears breaks compatibility with Gpredict. When rigctrl is passed --vfo, some commands require a VFO be specified. GPredict does not pass VFOs when reading and writing. Instead, it simply uses the f and i commands. While I would normally be tempted to do PR for this, I don't see a reason. The default rigctrl setting work and changing Gpredict might break compatablity with other radios.

What @kareiva is describing is the VFO selection cursor moving to the TX VFO for a split second while reading the transmit frequency (moving the cursor, not switching the VFOs themselves.) I have experimented with this for a while and have yet to find a way to silently read the TX frequency. It appears that Icom in their infinite wisdom forgot to add a silent read command.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[kareiva]

Can you please describe what "weird" means? @mdblack98

Well, one I have already mentioned is the '0' and '1' that are sent to rigctld instead of 'Main'/'Sub' and rigctld actually hangs when it gets the '1' (doesn't crash). In the interactive rigctl everything that doesn't equal 'Sub', defaults to main VFO (including the '1'). Thirdly, I can't remember gpredict reliably switching modes from FM to SSB and vice versa, so I have some raw code snippets that handle the mode for me in rigctld (sent directly over external python/telnet to port 4532), especially when some FM birds want the CTCSS codes, example:

V Main
M FM 0
V Sub
M FM 0
C 670

[mdblack98]

Are you able to build gpredict yourself? You running Windows or Linux?

The "1" is coming from gpredict try to set split mode S 1 Sub

I can update gpredict to use the --vfo option

Mike W9MDB

On Sunday, November 6, 2022 at 03:47:41 AM CST, Simonas @.***> wrote:

   Can you please describe what "weird" means? @mdblack98

Well, one I have already mentioned is the '0' and '1' that are sent to rigctld instead of 'Main'/'Sub' and rigctld actually hangs when it gets the '1' (doesn't crash). In the interactive rigctl everything that doesn't equal 'Sub', defaults to main VFO (including the '1'). Thirdly, I can't remember gpredict reliably switching modes from FM to SSB and vice versa, so I have some raw code snippets that handle the mode for me in rigctld (sent directly over external python/telnet to port 4532), especially when some FM birds want the CTCSS codes, example: V Main M FM 0 V Sub M FM 0 C 670

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[KaComet]

@mdblack98, I've made some changes to gtk-rig-ctrl.c so that it supports --vfo. Yes, it does work, but is there a reason that --vfo absolutely has to be implemented? Yes, some changes are needed to setup_split. However, the addition of --vfo might confuse new users who are not aware of the specifics of how Gpredict and rigctrl talk. Wouldn't sticking to the default options in rigctrl be better?

Also, switching to --vfo does not appear to silently read the uplink VFO. See below commands needed to test. I can provide video proof if necessary.

$rigctl -m 3081 -s 115200 -r /dev/icom-9700-a -v --vfo (radio is already in SATMODE)
Opened rig model 3081, 'IC-9700'

Rig command: f VFOA
Frequency: 145948036

Rig command: f VFOB
Frequency: 432155813  (Cursor moved to uplink VFO for split second)

rigctl Hamlib 4.6~git Fri Nov 04 18:26:52 2022 +0000 SHA=bf22bc

[mdblack98]

No it wouldn't be better -- vfo mode is superior in many ways for all rigs.  I'm doing all the changes needed to support it either way.And it will automatically turn on vfo mode if available so users don't need to know anything.  Older hamlib's will still use the old method. Mike W9MDB

On Sunday, November 6, 2022 at 09:47:52 AM CST, KaComet ***@***.***> wrote:  

@mdblack98, I've make some changes to gtk-rig-ctrl.c so that it supports --vfo. Yes, it does work, but is there a reason that --vfo absolutely has to be implemented? Yes, some changes are needed to setup_split. However, the addition of --vfo might confuse new users who are not aware of the specifics of how Gpredict and rigctrl talk. Wouldn't sticking to the default options in rigctrl be better?

Also, switching to --vfo does not appear to silently read the uplink VFO. See below commands needed to test. I can provide video proof if necessary. $rigctl -m 3081 -s 115200 -r /dev/icom-9700-a -v --vfo (radio is already in SATMODE) Opened rig model 3081, 'IC-9700'

Rig command: f VFOA Frequency: 145948036

Rig command: f VFOB Frequency: 432155813 (Cursor moved to uplink VFO for split second)

rigctl Hamlib 4.6~git Fri Nov 04 18:26:52 2022 +0000 SHA=bf22bc

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[KaComet]

@mdblack98, well that's cool. It's a very simple job to switch Gpredict over to supporting --vfo. The version I made last night only had five differences to implement it for the full duplex, RX, and TX modes. I don't have a rig to test the 817 modes, so I don't have a way to implement and test a fix for them.

[kareiva]

Are you able to build gpredict yourself? You running Windows or Linux?

I am able to write some code myself, so before diving into a complex code base, just asking around to understand what's cooking and possibly avoid any double work. Yesterday I've built both gpredict and hamlib from git on Fedora without issues.

[mdblack98]

VFOs cannot be abbreviated.
This is how you would change modes without a bandwidth change with the --vfo switch M Main FM -1 M Sub FM -1 C Main 670 (note that for most rigs the VFO doesn't matter as it's just one tone for the rig). When you put a bad VFO it will assume the current VFO (Usually VFOA/Main). Perhaps I should make it return an error.

[mdblack98]

Please try my fork and see if it works for you.  It should automatically turn on vfo_opt in rigctld if rigctld supports it. https://github.com/mdblack98?tab=repositories

Mike W9MDB Message ID: @.***>

[KaComet]

@mdblack98, I have commented some testing data on the PR you submitted. I would request that we continue any conversation relating to the support of the --vfo flag there.