Thread: [Hamlib-developer] Problem with IC-9100
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: Marc H. - V. <vk...@wi...> - 2016-01-14 02:24:19
|
Hamlib rigctld 3.0.1
Rig model 368, 'IC-9100' Backend version 0.7 Status: Untested
I am using Gpredict and stated version of hamlib to control an IC-9100.
Below is the Windows 10 DOS command I use to start rigctld, and the
resulting diagnostics.
The Main VFO is being updated, but the Sub is not. IC-9100 is in Satellite
mode, VFO. Any clues?
Also, despite configuring itu_region=3, its reported value is 2. Why does
itu_region even matter?
----------------------------------------------------------------------------
------------------------------------------------------------------------
start "rigctld" rigctld -L -m 368 -r COM5 -s 9600 -c 0x7c -T 127.0.0.1 -t
4532 -C no_xchg=1,itu_region=3 -vvvvv :: IC-9100
rigctld, Hamlib 3.0.1
Report bugs to <ham...@li...>
rig:rig_init called
icom: _init called
rig_register (355)
rig_register (309)
rig_register (310)
rig_register (311)
rig_register (313)
rig_register (314)
rig_register (315)
rig_register (319)
rig_register (320)
rig_register (321)
rig_register (322)
rig_register (367)
rig_register (323)
rig_register (346)
rig_register (324)
rig_register (328)
rig_register (330)
rig_register (326)
rig_register (327)
rig_register (347)
rig_register (357)
rig_register (363)
rig_register (329)
rig_register (362)
rig_register (345)
rig_register (356)
rig_register (360)
rig_register (370)
rig_register (361)
rig_register (331)
rig_register (312)
rig_register (316)
rig_register (332)
rig_register (334)
rig_register (344)
rig_register (368)
rig_register (335)
rig_register (369)
rig_register (336)
rig_register (358)
rig_register (337)
rig_register (338)
rig_register (339)
rig_register (340)
rig_register (341)
rig_register (342)
rig_register (343)
rig_register (366)
rig_register (303)
rig_register (304)
rig_register (306)
rig_register (307)
rig_register (302)
rig_register (352)
rig_register (353)
rig_register (351)
rig_register (364)
rig_register (365)
rig_register (354)
rig_register (371)
rig_set_conf: no_xchg='1'
rig_set_conf: itu_region='3'
rig_set_conf: civaddr='0x7c'
rig_pathname: "Path name to the device file of the rig"
Default: /dev/rig, Value: COM5
String.
write_delay: "Delay in ms between each byte sent out"
Default: 0, Value: 0
Range: 0.0..1000.0, step 1.0
post_write_delay: "Delay in ms between each command sent out"
Default: 0, Value: 0
Range: 0.0..1000.0, step 1.0
timeout: "Timeout in ms"
Default: 0, Value: 1000
Range: 0.0..10000.0, step 1.0
retry: "Max number of retry"
Default: 0, Value: 3
Range: 0.0..10.0, step 1.0
itu_region: "ITU region this rig has been manufactured for (freq. band
plan)"
Default: 0, Value: 2
Range: 1.0..3.0, step 1.0
vfo_comp: "VFO compensation in ppm"
Default: 0, Value: 0.000000
Range: 0.0..1000.0, step 0.0
poll_interval: "Polling interval in millisecond for transceive emulation"
Default: 500, Value: 500
Range: 0.0..1000000.0, step 1.0
ptt_type: "Push-To-Talk interface type override"
Default: RIG, Value:
Combo: RIG, DTR, RTS, Parallel, CM108, None
ptt_pathname: "Path name to the device file of the Push-To-Talk"
Default: /dev/rig, Value:
String.
ptt_bitnum: "Push-To-Talk GPIO bit number"
Default: 2, Value:
Range: 0.0..7.0, step 1.0
dcd_type: "Data Carrier Detect (or squelch) interface type override"
Default: RIG, Value:
Combo: RIG, DSR, CTS, CD, Parallel, CM108, None
dcd_pathname: "Path name to the device file of the Data Carrier Detect (or
squelch)"
Default: /dev/rig, Value:
String.
serial_speed: "Serial port baud rate"
Default: 0, Value: 9600
Range: 300.0..115200.0, step 1.0
data_bits: "Serial port data bits"
Default: 8, Value: 8
Range: 5.0..8.0, step 1.0
stop_bits: "Serial port stop bits"
Default: 1, Value: 1
Range: 0.0..3.0, step 1.0
serial_parity: "Serial port parity"
Default: None, Value: None
Combo: None, Odd, Even, Mark, Space
serial_handshake: "Serial port handshake"
Default: None, Value: None
Combo: None, XONXOFF, Hardware
rts_state: "Serial port set state of RTS signal for external powering"
Default: Unset, Value: Unset
Combo: Unset, ON, OFF
dtr_state: "Serial port set state of DTR signal for external powering"
Default: Unset, Value: Unset
Combo: Unset, ON, OFF
civaddr: "Transceiver's CI-V address"
Default: 0, Value: 124
Range: 0.0..255.0, step 1.0
mode731: "CI-V operating frequency data length, needed for IC731 and IC735"
Default: 0, Value: 0
Check button.
no_xchg: "Don't Use VFO XCHG to set other VFO mode and Frequency"
Default: 0, Value: 1
Check button.
rig:rig_open called
Opened rig model 368, 'IC-9100'
Backend version: 0.7, Status: Untested
----------------------------------------------------------------------------
------------------------------------------------------------------------
___________________________________________________
Marc Hillman
VK3OHM
|
|
From: Nate B. <n0...@n0...> - 2016-01-15 17:10:29
|
* On 2016 13 Jan 20:27 -0600, Marc Hillman - VK3OHM wrote:
> Hamlib rigctld 3.0.1
>
> Rig model 368, 'IC-9100' Backend version 0.7 Status: Untested
>
>
>
> I am using Gpredict and stated version of hamlib to control an IC-9100.
> Below is the Windows 10 DOS command I use to start rigctld, and the
> resulting diagnostics.
>
>
>
> The Main VFO is being updated, but the Sub is not. IC-9100 is in Satellite
> mode, VFO. Any clues?
Hi Marc.
Welcome to Hamlib. I've been hoping someone familiar with the IC-9100
and its backend would reply. Hopefully they will.
> Also, despite configuring itu_region=3, its reported value is 2. Why does
> itu_region even matter?
I don't think it matters, so probably it is better to not pass the
option.
I think this harkens back to the earlier days when there may have been a
plan to include region specific frequency ranges for backends to check
that an out of band TX frequency is detected, for example. Personally,
my thought is that such decisions may be better left to applications or
operator knowledge.
> start "rigctld" rigctld -L -m 368 -r COM5 -s 9600 -c 0x7c -T 127.0.0.1 -t
> 4532 -C no_xchg=1,itu_region=3 -vvvvv :: IC-9100
I'm not certain that no_xchg is required or not. Here is what I glean
from the source:
$ git grep no_xchg
icom/icom.c:268: { TOK_NOXCHG, "no_xchg", "No VFO XCHG", "Don't
Use VFO XCHG to set other VFO mode and Frequency",
.
.
.
icom/icom.h:101: int no_xchg; /* Off: use VFO XCHG to set other
VFO, On: use set VFO to set other VFO */
icom/icom.h:120: int no_xchg; /* Off: use VFO XCHG to set other
VFO, On: use set VFO to set other VFO */
If I am guessing correctly, with no_xchg=1 it is up to Gpredict to set
the sub vfo directly. I hope someone more familiar with both the
IC-9100 backend and Gpredict with chime in.
73, Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://www.n0nb.us
|
|
From: Bill S. <g4...@cl...> - 2016-01-15 18:00:25
|
On 15/01/2016 17:10, Nate Bargmann wrote:
> I'm not certain that no_xchg is required or not. Here is what I glean
> from the source:
>
> $ git grep no_xchg
> icom/icom.c:268: { TOK_NOXCHG, "no_xchg", "No VFO XCHG", "Don't
> Use VFO XCHG to set other VFO mode and Frequency",
> .
> .
> .
> icom/icom.h:101: int no_xchg; /* Off: use VFO XCHG to set other
> VFO, On: use set VFO to set other VFO */
> icom/icom.h:120: int no_xchg; /* Off: use VFO XCHG to set other
> VFO, On: use set VFO to set other VFO */
>
> If I am guessing correctly, with no_xchg=1 it is up to Gpredict to set
> the sub vfo directly. I hope someone more familiar with both the
> IC-9100 backend and Gpredict with chime in.
Hi Nate & Marc,
I put the no_xchg config parameter in a while back to allow an
alternative way of setting the split TX frequency without glitching the
Rx. It is used by WSJT-X but other software may find it useful.
As for the IC-9100 SAT mode I don't have much to add, SAT mode on the
IC910 and IC9100 is very different from other Icom CAT philosophy and
not straight forward to control. Our project has no need for it. It is
possible it simply doesn't work correctly yet.
73
Bill
G4WJS.
|
|
From: Bill S. <g4...@cl...> - 2016-01-16 12:08:33
|
On 16/01/2016 12:02, Marc Hillman - VK3OHM wrote: > I am not a programmer, but I do have an IC-9100. Is there any standard test > harness I can run to give diagnostic information to the original developer? > > The no_xchg=1 bit is working. Without it both Rx and Tx glitch because of > continuous swapping. It looks to me like it's very close to working. I can > provide the diagnostics (CI-V exchanges) from rigctld if that helps. > > I guess my questions are: > 1. Who was the original developer? > 2. Is he interested in raising this from Untested to Alpha? > 3. Can I, and my IC-9100, help in any way? > > If the IC-9100 doesn't work, which appears to be the case, I will have to > ditch Gpredict, which would be a great shame as it's a great app. Hi Marc, does gpredict require the rig to be in SAT mode or is it trying to do all the tracking directly by CAT commands to the main and sub radios? 73 Bill G4WJS. |
|
From: Bill S. <g4...@cl...> - 2016-01-16 12:57:25
|
On 16/01/2016 12:49, Marc Hillman - VK3OHM wrote: > In Gpredict, I have set the Rig Type to Duplex TRX. Other choices are RX > only, TX only, Simplex TRX & FT817. None of these others can be right, so > Duplex TRX it is. Now "Duplex TRX" could mean two things on an IC-9100. > Gpredict allows me to specify Main as uplink or downlink, and Sub as > up/down. In SAT mode the Tx/Rx tracking are done by the rig so I would have though that Rx only makes sense. Gpredict only needs to send CAT commands to change the Rx VFO and the Tx tracks, either with or against depending on transponder mode. Trying to change both via CAT has to be done once at set up. Is Gpredict trying to do the set up part, the tracking part or both? 73 Bill G4WJS. |
|
From: Marc H. - V. <vk...@wi...> - 2016-01-16 12:02:28
|
I am not a programmer, but I do have an IC-9100. Is there any standard test
harness I can run to give diagnostic information to the original developer?
The no_xchg=1 bit is working. Without it both Rx and Tx glitch because of
continuous swapping. It looks to me like it's very close to working. I can
provide the diagnostics (CI-V exchanges) from rigctld if that helps.
I guess my questions are:
1. Who was the original developer?
2. Is he interested in raising this from Untested to Alpha?
3. Can I, and my IC-9100, help in any way?
If the IC-9100 doesn't work, which appears to be the case, I will have to
ditch Gpredict, which would be a great shame as it's a great app.
___________________________________________________
Marc Hillman
VK3OHM
-----Original Message-----
From: Bill Somerville [mailto:g4...@cl...]
Sent: Saturday, 16 January 2016 5:00
To: ham...@li...
Subject: Re: [Hamlib-developer] Problem with IC-9100
On 15/01/2016 17:10, Nate Bargmann wrote:
> I'm not certain that no_xchg is required or not. Here is what I glean
> from the source:
>
> $ git grep no_xchg
> icom/icom.c:268: { TOK_NOXCHG, "no_xchg", "No VFO XCHG", "Don't
> Use VFO XCHG to set other VFO mode and Frequency", .
> .
> .
> icom/icom.h:101: int no_xchg; /* Off: use VFO XCHG to set other
> VFO, On: use set VFO to set other VFO */
> icom/icom.h:120: int no_xchg; /* Off: use VFO XCHG to set other
> VFO, On: use set VFO to set other VFO */
>
> If I am guessing correctly, with no_xchg=1 it is up to Gpredict to set
> the sub vfo directly. I hope someone more familiar with both the
> IC-9100 backend and Gpredict with chime in.
Hi Nate & Marc,
I put the no_xchg config parameter in a while back to allow an alternative
way of setting the split TX frequency without glitching the Rx. It is used
by WSJT-X but other software may find it useful.
As for the IC-9100 SAT mode I don't have much to add, SAT mode on the
IC910 and IC9100 is very different from other Icom CAT philosophy and not
straight forward to control. Our project has no need for it. It is possible
it simply doesn't work correctly yet.
73
Bill
G4WJS.
----------------------------------------------------------------------------
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7294 / Virus Database: 4489/11406 - Release Date: 01/15/16
|
|
From: Marc H. - V. <vk...@wi...> - 2016-01-16 12:50:02
|
It's a bit complicated to explain. Because it uses hamlib, Gpredict lets
hamlib do all the heavy work. The IC-9100 is handled as a parametrised radio
interface.
In Gpredict, I have set the Rig Type to Duplex TRX. Other choices are RX
only, TX only, Simplex TRX & FT817. None of these others can be right, so
Duplex TRX it is. Now "Duplex TRX" could mean two things on an IC-9100.
Gpredict allows me to specify Main as uplink or downlink, and Sub as
up/down.
1. Not satellite mode. Main = uplink, Sub = downlink. In this mode, Main
just toggles rapidly between VFO A and B, ending up at A, which achieves
nothing.
2. Satellite mode. Main = downlink, Sub=uplink. In this mode the Main is
updated, but the Sub is not.
Below is the rigctld output with IC-9100 in Satellite mode. Main (downlink)
is 2m, Sub (uplink) is 70cm. Main only is updated. As you can see it's
trying to update both Main and Sub, but there are some NAK results from the
IC-9100. Sometimes it will run indefinitely, just updating the Main, but I
thought the scenario where it fails might be more revealing.
The first command is fe fe 7c e0 0f 01 fd This is set split mode on,
which implies we're trying not satellite mode. You can't do split in
satellite mode, hence the NAK.
rigctld, Hamlib 3.0.1
Report bugs to <ham...@li...>
rig:rig_init called
icom: _init called
rig_register (355)
rig_register (309)
rig_register (310)
rig_register (311)
rig_register (313)
rig_register (314)
rig_register (315)
rig_register (319)
rig_register (320)
rig_register (321)
rig_register (322)
rig_register (367)
rig_register (323)
rig_register (346)
rig_register (324)
rig_register (328)
rig_register (330)
rig_register (326)
rig_register (327)
rig_register (347)
rig_register (357)
rig_register (363)
rig_register (329)
rig_register (362)
rig_register (345)
rig_register (356)
rig_register (360)
rig_register (370)
rig_register (361)
rig_register (331)
rig_register (312)
rig_register (316)
rig_register (332)
rig_register (334)
rig_register (344)
rig_register (368)
rig_register (335)
rig_register (369)
rig_register (336)
rig_register (358)
rig_register (337)
rig_register (338)
rig_register (339)
rig_register (340)
rig_register (341)
rig_register (342)
rig_register (343)
rig_register (366)
rig_register (303)
rig_register (304)
rig_register (306)
rig_register (307)
rig_register (302)
rig_register (352)
rig_register (353)
rig_register (351)
rig_register (364)
rig_register (365)
rig_register (354)
rig_register (371)
rig_set_conf: no_xchg='1'
rig_set_conf: civaddr='0x7c'
rig_pathname: "Path name to the device file of the rig"
Default: /dev/rig, Value: COM5
String.
write_delay: "Delay in ms between each byte sent out"
Default: 0, Value: 0
Range: 0.0..1000.0, step 1.0
post_write_delay: "Delay in ms between each command sent out"
Default: 0, Value: 0
Range: 0.0..1000.0, step 1.0
timeout: "Timeout in ms"
Default: 0, Value: 1000
Range: 0.0..10000.0, step 1.0
retry: "Max number of retry"
Default: 0, Value: 3
Range: 0.0..10.0, step 1.0
itu_region: "ITU region this rig has been manufactured for (freq. band
plan)"
Default: 0, Value: 2
Range: 1.0..3.0, step 1.0
vfo_comp: "VFO compensation in ppm"
Default: 0, Value: 0.000000
Range: 0.0..1000.0, step 0.0
poll_interval: "Polling interval in millisecond for transceive emulation"
Default: 500, Value: 500
Range: 0.0..1000000.0, step 1.0
ptt_type: "Push-To-Talk interface type override"
Default: RIG, Value:
Combo: RIG, DTR, RTS, Parallel, CM108, None
ptt_pathname: "Path name to the device file of the Push-To-Talk"
Default: /dev/rig, Value:
String.
ptt_bitnum: "Push-To-Talk GPIO bit number"
Default: 2, Value:
Range: 0.0..7.0, step 1.0
dcd_type: "Data Carrier Detect (or squelch) interface type override"
Default: RIG, Value:
Combo: RIG, DSR, CTS, CD, Parallel, CM108, None
dcd_pathname: "Path name to the device file of the Data Carrier Detect (or
squelch)"
Default: /dev/rig, Value:
String.
serial_speed: "Serial port baud rate"
Default: 0, Value: 9600
Range: 300.0..115200.0, step 1.0
data_bits: "Serial port data bits"
Default: 8, Value: 8
Range: 5.0..8.0, step 1.0
stop_bits: "Serial port stop bits"
Default: 1, Value: 1
Range: 0.0..3.0, step 1.0
serial_parity: "Serial port parity"
Default: None, Value: None
Combo: None, Odd, Even, Mark, Space
serial_handshake: "Serial port handshake"
Default: None, Value: None
Combo: None, XONXOFF, Hardware
rts_state: "Serial port set state of RTS signal for external powering"
Default: Unset, Value: Unset
Combo: Unset, ON, OFF
dtr_state: "Serial port set state of DTR signal for external powering"
Default: Unset, Value: Unset
Combo: Unset, ON, OFF
civaddr: "Transceiver's CI-V address"
Default: 0, Value: 124
Range: 0.0..255.0, step 1.0
mode731: "CI-V operating frequency data length, needed for IC731 and IC735"
Default: 0, Value: 0
Check button.
no_xchg: "Don't Use VFO XCHG to set other VFO mode and Frequency"
Default: 0, Value: 1
Check button.
rig:rig_open called
Opened rig model 368, 'IC-9100'
Backend version: 0.7, Status: Untested
Connection opened from 127.0.0.1:63264
rigctl(d): S 'currVFO' '1' 'Sub' ''
write_block(): TX 7 bytes
0000 fe fe 7c e0 0f 01 fd ..|....
read_string(): RX 7 characters
0000 fe fe 7c e0 0f 01 fd ..|....
read_string(): RX 6 characters
0000 fe fe e0 7c fa fd ...|..
icom_set_split: ack NG (0xfa), len=1
rigctl(d): F 'currVFO' '145948926' '' ''
write_block(): TX 11 bytes
0000 fe fe 7c e0 05 26 89 94 45 01 fd ..|..&..E..
read_string(): RX 11 characters
0000 fe fe 7c e0 05 26 89 94 45 01 fd ..|..&..E..
read_string(): RX 6 characters
0000 fe fe e0 7c fa fd ...|..
icom_set_freq: ack NG (0xfa), len=1
rigctl(d): I 'currVFO' '432153181' '' ''
write_block(): TX 7 bytes
0000 fe fe 7c e0 07 01 fd ..|....
read_string(): RX 7 characters
0000 fe fe 7c e0 07 01 fd ..|....
read_string(): RX 6 characters
0000 fe fe e0 7c fa fd ...|..
icom_set_vfo: ack NG (0xfa), len=1
rigctl(d): F 'currVFO' '145948923' '' ''
write_block(): TX 11 bytes
0000 fe fe 7c e0 05 23 89 94 45 01 fd ..|..#..E..
read_string(): RX 11 characters
0000 fe fe 7c e0 05 23 89 94 45 01 fd ..|..#..E..
read_string(): RX 6 characters
0000 fe fe e0 7c fa fd ...|..
icom_set_freq: ack NG (0xfa), len=1
rigctl(d): I 'currVFO' '432153188' '' ''
write_block(): TX 7 bytes
0000 fe fe 7c e0 07 01 fd ..|....
read_string(): RX 7 characters
0000 fe fe 7c e0 07 01 fd ..|....
read_string(): RX 6 characters
0000 fe fe e0 7c fa fd ...|..
icom_set_vfo: ack NG (0xfa), len=1
rigctl(d): F 'currVFO' '145948920' '' ''
write_block(): TX 11 bytes
0000 fe fe 7c e0 05 20 89 94 45 01 fd ..|.. ..E..
read_string(): RX 11 characters
0000 fe fe 7c e0 05 20 89 94 45 01 fd ..|.. ..E..
read_string(): RX 6 characters
0000 fe fe e0 7c fa fd ...|..
icom_set_freq: ack NG (0xfa), len=1
rigctl(d): I 'currVFO' '432153198' '' ''
write_block(): TX 7 bytes
0000 fe fe 7c e0 07 01 fd ..|....
read_string(): RX 7 characters
0000 fe fe 7c e0 07 01 fd ..|....
read_string(): RX 6 characters
0000 fe fe e0 7c fa fd ...|..
icom_set_vfo: ack NG (0xfa), len=1
Connection closed from 127.0.0.1:63264
-----Original Message-----
From: Bill Somerville [mailto:g4...@cl...]
Sent: Saturday, 16 January 2016 23:08
To: ham...@li...
Subject: Re: [Hamlib-developer] Problem with IC-9100
On 16/01/2016 12:02, Marc Hillman - VK3OHM wrote:
> I am not a programmer, but I do have an IC-9100. Is there any standard
> test harness I can run to give diagnostic information to the original
developer?
>
> The no_xchg=1 bit is working. Without it both Rx and Tx glitch because
> of continuous swapping. It looks to me like it's very close to
> working. I can provide the diagnostics (CI-V exchanges) from rigctld if
that helps.
>
> I guess my questions are:
> 1. Who was the original developer?
> 2. Is he interested in raising this from Untested to Alpha?
> 3. Can I, and my IC-9100, help in any way?
>
> If the IC-9100 doesn't work, which appears to be the case, I will have
> to ditch Gpredict, which would be a great shame as it's a great app.
Hi Marc,
does gpredict require the rig to be in SAT mode or is it trying to do all
the tracking directly by CAT commands to the main and sub radios?
73
Bill
G4WJS.
----------------------------------------------------------------------------
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM +
Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor
end-to-end web transactions and take corrective actions now Troubleshoot
faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7294 / Virus Database: 4489/11410 - Release Date: 01/15/16
|
|
From: Marc H. - V. <vk...@wi...> - 2016-01-16 13:26:32
|
Thanks for all your help Bill - I'm beginning to suspect it's a Gpredict problem. When in Sat mode, turning the VFO knob changes both uplink and down link. It would appear though that when Main is changed by CI-V, Sub does not follow. I guess this makes sense. Unless, you have another theory, I think I need to approach Gpredict. -----Original Message----- From: Bill Somerville [mailto:g4...@cl...] Sent: Saturday, 16 January 2016 23:57 To: ham...@li... Subject: Re: [Hamlib-developer] Problem with IC-9100 On 16/01/2016 12:49, Marc Hillman - VK3OHM wrote: > In Gpredict, I have set the Rig Type to Duplex TRX. Other choices are > RX only, TX only, Simplex TRX & FT817. None of these others can be > right, so Duplex TRX it is. Now "Duplex TRX" could mean two things on an IC-9100. > Gpredict allows me to specify Main as uplink or downlink, and Sub as > up/down. In SAT mode the Tx/Rx tracking are done by the rig so I would have though that Rx only makes sense. Gpredict only needs to send CAT commands to change the Rx VFO and the Tx tracks, either with or against depending on transponder mode. Trying to change both via CAT has to be done once at set up. Is Gpredict trying to do the set up part, the tracking part or both? 73 Bill G4WJS. ---------------------------------------------------------------------------- -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Hamlib-developer mailing list Ham...@li... https://lists.sourceforge.net/lists/listinfo/hamlib-developer ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2016.0.7294 / Virus Database: 4489/11410 - Release Date: 01/15/16 |
|
From: Bill S. <g4...@cl...> - 2016-01-16 13:34:26
|
On 16/01/2016 13:26, Marc Hillman - VK3OHM wrote: > It would appear though that when Main is changed by CI-V, Sub does not > follow. I guess this makes sense. I believe the Icom philosophy is that you would use CAT commands to set the up and downlink frequencies but use the VFO knob to track. If Gpredict is expecting to do the set up and do the tracking then it doesn't need the rig in SAT mode at all. It may be that Gpredict is using the wrong commands to address the MAIN/SUB VFOs or it could be that Hamlib is addressing the wrong pair (MAIN/SUB vs. VFO A/B). It doesn't help that I know for sure that the CAT docs in the IC-910 and IC-9100 have some errors in this area. You need to know what Gpredict is trying to achieve before any of this can be addressed. 73 Bill G4WJS. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X