Closed mdblack98 closed 9 months ago
Testing with an IC-9700 connected via USB and hamlib --version (rigctl Hamlib 4.6~git Fri Nov 04 18:26:52 2022 +0000 SHA=bf22bc) yields the following results.
For all tests the below two rigctrl commands were used. This allows for the --vfo option and non-vfo options to be evaluated. rigctld -m 3081 -s 115200 -r /dev/icom-9700-a -vvv rigctld -m 3081 -s 115200 -r /dev/icom-9700-a -vvv --vfo
RX only radio mode: Works as intended with both the --vfo and non-vfo options.
TX only radio mode:
Full Duplex radio mode non-vfo option: (rigctld -m 3081 -s 115200 -r /dev/icom-9700-a -vvv)
Full Duplex radio mode --vfo option: (rigctld -m 3081 -s 115200 -r /dev/icom-9700-a -vvv --vfo)
When not initially in satellite mode, the radio enters split mode (repeater split.) The RX frequency is set and the TX frequency is not set. The rigctrl loop hangs after one update cycle (frequency updates stop.)
When initially in satellite mode, the radio exits satellite mode and enters split mode (repeater split.) The RX frequency is set and the TX frequency is not set. The rigctrl loop hangs after one update cycle (frequency updates stop.)
Rigctrl output shown in the following file. Full duplex rigctrl output.txt
Other Rigctrl outputs will be provided on request.
Two things I noticed from the PR:
$rigctl -m 3081 -s 115200 -r /dev/icom-9700-a -vvv --vfo
Rig command: F curVFO 145000000
rig_parse_vfo: 'curVFO' not found so vfo='None'
icom_set_freq: set freq failed: vfo_fixup:(from rig_get_freq:1964) vfo=currVFO, vfo_curr=VFOA, split=1
vfo_fixup: Leaving currVFO alone
rig.c(1966) vfo=currVFO, curr_vfo=VFOA
rig_get_freq(1988): freqMainA=145825080, modeMainA=USB, widthMainA=2400
rig_get_freq(1988): freqMainB=432155816, modeMainB=, widthMainB=0
rig_get_freq(1988): freqSubA=0, modeSubA=, widthSubA=0
rig_get_freq(1988): freqSubB=0, modeSubB=, widthSubB=0
rig_get_cache(258): vfo=VFOA, current_vfo=VFOA
rig_get_cache(434): vfo=VFOA, freq=145825080, mode=USB, width=2400
rig_get_freq(2022): freqMainA=145825080, modeMainA=USB, widthMainA=2400
rig_get_freq(2022): freqMainB=432155816, modeMainB=, widthMainB=0
rig_get_freq(2022): freqSubA=0, modeSubA=, widthSubA=0
rig_get_freq(2022): freqSubB=0, modeSubB=, widthSubB=0
rig_get_freq: VFOA cache hit age=55ms, freq=145825080, use_cached_freq=0
1:rig_get_freq: elapsed=0ms
icom_band_changing: lastfreq=1, thisfreq=1
icom_band_changing: Band change not detected
icom.c(1264):icom_band_changing returning2(0)
Command rejected by the rig
Command rejected by the rig
set_freq: error = rig_get_cache(258): vfo=VFOA, current_vfo=VFOA rig_get_cache(434): vfo=VFOA, freq=145825080, mode=USB, width=2400 rig_get_freq(2022): freqMainA=145825080, modeMainA=USB, widthMainA=2400 rig_get_freq(2022): freqMainB=432155816, modeMainB=, widthMainB=0 rig_get_freq(2022): freqSubA=0, modeSubA=, widthSubA=0 rig_get_freq(2022): freqSubB=0, modeSubB=, widthSubB=0 rig_get_freq: VFOA cache hit age=55ms, freq=145825080, use_cached_freq=0 1:rig_get_freq: elapsed=0ms icom_band_changing: lastfreq=1, thisfreq=1 icom_band_changing: Band change not detected icom.c(1264):icom_band_changing returning2(0) Command rejected by the rig
icom.c(1417):icom_set_freq returning2(-9) Command rejected by the rig
1:rig.c(1796):rig_set_freq returning(-9) Command rejected by the rig
0:rigctl_parse.c(2073):rigctl_set_freq returning(-9) Command rejected by the rig
Command rejected by the rig
Your command is wrong -- you missed an "r" F currVFO 1450000000 I don't see where gpredict tries to set the rig mode at all. The "U" command is not referenced. If you start with the rig in SATMODE does it change?
On Sunday, November 6, 2022 at 05:08:41 PM CST, KaComet ***@***.***> wrote:
Two things I noticed from the PR:
set_freq: error = rig_get_cache(258): vfo=VFOA, current_vfo=VFOA rig_get_cache(434): vfo=VFOA, freq=145825080, mode=USB, width=2400 rig_get_freq(2022): freqMainA=145825080, modeMainA=USB, widthMainA=2400 rig_get_freq(2022): freqMainB=432155816, modeMainB=, widthMainB=0 rig_get_freq(2022): freqSubA=0, modeSubA=, widthSubA=0 rig_get_freq(2022): freqSubB=0, modeSubB=, widthSubB=0 rig_get_freq: VFOA cache hit age=55ms, freq=145825080, use_cached_freq=0 1:rig_get_freq: elapsed=0ms icom_band_changing: lastfreq=1, thisfreq=1 icom_band_changing: Band change not detected icom.c(1264):icom_band_changing returning2(0) Command rejected by the rig
icom.c(1417):icom_set_freq returning2(-9) Command rejected by the rig
1:rig.c(1796):rig_set_freq returning(-9) Command rejected by the rig
0:rigctl_parse.c(2073):rigctl_set_freq returning(-9) Command rejected by the rig
Command rejected by the rig
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
Whoops, currVFO does work.
"I don't see where Gpredict tries to set the rig mode at all. The "U" command is not referenced."
Line 1502 of gtk-rig-ctrl.c: buff = g_strdup("S VFOB 1 VFOA\x0a");
This is what I was referencing. Running this line results in the following:
You cannot operate on crossband satellites when the radio is in this mode. Additionally, I think you missed a spot around line 2416 in gtk-rig-ctrl.c
@mdblack98, are you testing this code with one of your own radios? If not, I could always submit some PRs to your fork while I'm ironing out the bugs. I have been working on a some code that adds support to changing the RIT and the TX/RX mode, with the intention of submitting a PR. However, If rigctrl is moving in the direction of --vfo then this needs to be done first.
I'm using a 9700 emulator that is not fully capable. The 9700 is fairly unique.
On Sunday, November 6, 2022 at 05:49:31 PM CST, KaComet ***@***.***> wrote:
@mdblack98, are you testing this code with one of your own radios? If not, I could always submit some PRs to your fork while I'm ironing out the bugs. I have been working on a some code that adds support to changing the RIT and the TX/RX mode, with the intention of submitting a PR. However, If rigctrl is moving in the direction of --vfo then this needs to be done first.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Change that line to this:buff = g_strdup("S Sub 1 Main\x0a");
On Sunday, November 6, 2022 at 05:42:40 PM CST, KaComet ***@***.***> wrote:
Whoops, currVFO does work.
"I don't see where Gpredict tries to set the rig mode at all. The "U" command is not referenced." Line 1502 of gtk-rig-ctrl.c: buff = g_strdup("S VFOB 1 VFOA\x0a"); This is what I was referencing. Running this line results in the following:
You cannot operate on crossband satellites when the radio is in this mode. Additionally, I think you missed a spot around line 2416 in gtk-rig-ctrl.c
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
@mdblack98, don't need to change anything. That specific line of code already exists at line 1516. I've tried all the configurations of the VFO Up/Down selector. It's a bit crazy to continue this back and forth testing style. I own a, FT-991A, IC-9700, and FT-736R. I will submit my own PR which I will test with my own radios to minimize the chance I'm breaking compatibility with existing radios.
Please test to ensure this sets satmode in rigctl for the 9700. If not this requires a hamlib change. You should NOT use the "U" command to do this. S Sub 1 Main Mike
On Monday, November 7, 2022 at 03:41:58 AM CST, KaComet ***@***.***> wrote:
@mdblack98, don't need to change anything. That specific line of code already exists at line 1516. I've tried all the configurations of the VFO Up/Down selector. It's a bit crazy to continue this back and forth testing style. I own a, FT-991A, IC-9700, and FT-736R. I will submit my own PR which I will test with my own radios to minimize the chance I'm breaking compatibility with existing radios.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
@mdblack98, After some experimentation, I have a working version of Gpredict that uses --vfo. There were a few less than obvious snags with getting it setup. I should have a PR up soon. Just need to drag out the 991A to ensure I'm not breaking compatibility with the PTT modes.
Thanks for the fix @mdblack98.
strncpy can produce "truncated" warnings and can be easily replaced by memcpy and ensuring the string is null terminated.