gpredict
gpredict copied to clipboard
csete
GPredict and IC-910 control ==> progress ==> help please
Hi,
Mike W9MDB has been very actively working on improving the functionality of HamLib. We have been testing software improvements for the GPredict to the Icom IC-910 using the rigctrl interface. The latest HamLib commit reflects these. Both duplex VFO A/B and satmode (main sub) are now working when split or satmodes are set on the rig. A GPredict user can also automatically change from split to satmode from within GPredict, but but not (yet) back.
We are asking the GPredict team to help adding a GPredict call feature in that upon “engage” to also request VFO split mode, i.e., S1 VFO B, or S1 VFO A, so this automation both ways may be realized.
It would be appreciated if one of the GPredict developers could contact Mike at mdblack98 at yahoo dot com to discuss.
Thanks! Bob N6RFM
Hi Bob, i think you have to clarify what you mean. when you press engage gpredict already sends a initial split request, in dependency of how you did setup the radio in the settings: when choosing Main ^ / Sub v gpredict will init with: S 1 Main when choosing Sub ^ / Main v gpredict will init with: S 1 Sub when choosing A ^ / B v gpredict will init with: S 1 VFOA when choosing B ^ / A v gpredict will init with: S 1 VFOB
so what exactly you are missing?
the following document i send to Mike in March 2020, so he is already aware of this intial sequence of gpredict: howGpredictUseHamlib.pdf
73 de DL7OAP, Andreas
Hi Andy,
Always good to hear from you! I'm not sure we are seeing all of those inits. We have been looking in debug mode. But, I've cc'd Mike so he may respond accurately. But appreciate your information a lot.
Stay Safe! And Thanks for reaching out.
Bob
On Thu, May 14, 2020 at 4:03 PM Andy [email protected] wrote:
Hi Bob, i think you have to clarify what you mean. when you press engage gpredict already sends a initial split request, in dependency of you did setup the radio in the settings: when choosing Main ^ / Sub v gpredict will init with: S 1 Main when choosing Sub ^ / Main v gpredict will init with: S 1 Sub when choosing A ^ / B v gpredict will init with: S 1 VFOA when choosing B ^ / A v gpredict will init with: S 1 VFOB
so what exactly you are missing? 73 de DL7OAP, Andreas
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/csete/gpredict/issues/217#issuecomment-628858030, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIYB25FMRBYBUM6A3B42KNDRRRE75ANCNFSM4NA5ZF7A .
What's missing is when you select a mode that requires split to be off it doesn't turn it off.I've made the modications in hamlib so that when "U VFOA 0" "U VFOB 0" are received the rigs will automatically switch between satellite and split modes. So if you switch to a full duplex mode you'll see "S 1 Sub" but when you switch to a simplex mode with split you do not see "S 0 VFOA" or "S 1 VFOB". I'll admit I'm not a gpredict users so may not be describing this completely accurate.
In the code setup_split is only called for duplex case RIG_TYPE_DUPLEX: /* set rig into SAT mode (hamlib needs it even if rig already in SAT) */ setup_split(ctrl); exec_duplex_cycle(ctrl); break; We need to have split set also for non-duplex mode. So I'm guessing this case RIG_TYPE_TRX: exec_trx_cycle(ctrl); break; Needs to be case RIG_TYPE_TRX: setup_split(ctrl); exec_trx_cycle(ctrl); break;
de Mike W9MDB
On Thursday, May 14, 2020, 03:49:42 PM CDT, Robert Mattaliano <[email protected]> wrote:
Hi Andy, Always good to hear from you! I'm not sure we are seeing all of those inits. We have been looking in debug mode. But, I've cc'd Mike so he may respond accurately. But appreciate your information a lot. Stay Safe! And Thanks for reaching out. Bob On Thu, May 14, 2020 at 4:03 PM Andy [email protected] wrote:
Hi Bob, i think you have to clarify what you mean. when you press engage gpredict already sends a initial split request, in dependency of you did setup the radio in the settings: when choosing Main ^ / Sub v gpredict will init with: S 1 Main when choosing Sub ^ / Main v gpredict will init with: S 1 Sub when choosing A ^ / B v gpredict will init with: S 1 VFOA when choosing B ^ / A v gpredict will init with: S 1 VFOB
so what exactly you are missing? 73 de DL7OAP, Andreas
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
ok, i get the point. so the plan ist to change gpredict like this?
when choosing Main ^ / Sub v gpredict will init with: S 0 Main when choosing Sub ^ / Main v gpredict will init with: S 0 Sub when choosing A ^ / B v gpredict will init with: S 1 VFOA when choosing B ^ / A v gpredict will init with: S 1 VFOB
this would be helpfull for IC9100 and IC9700 also. at the moment i prepare these switches, too, here manually with my IC9700.
Will this work, too, for Yaesu, Kenwood, etc.?
Bye DL7OAP, Andreas
https://www.dropbox.com/s/9hdg11g3tfy43xr/patch.txt?dl=0
This is Mike W9MDB -- we got gpredict working very well with the IC-910. The above patch allows switching the IC-910 between satellite mode and split mode and automatically sets either without the user having to touch the rig.
One thing noted....for the TRX type it seems that we always want to use split mode. So we forced TRX to be treated like DUPLEX. It was necessary to get gpredict to turn on split mode for the simplex case which part of the patch too. I think this is the behavior we want to see for all rigs. #1 When engaging the rig in TRX mode split will automatically be turned on. This is the latest hamlib code. #2 When switching to sat mode using gpredict the rig automatically switches to sat mode #3 When switching to simplex mode from satmode using gpredict the rig automatically switches to split mode. #4 When selecting TRX mode the VFO up/download is forced just like DUPLEX. Can't think of any reason one would NOT operate in split mode. Split mode should be required for any satellite ops. The only different is full duplex or half duplex.
Thanks for your consideration. Mike & Bob
Hi I tried everything, but no luck to run IC910 with gpredict. My current setup: Ubuntu 20.10 Hamlib 4.2~git , gpredict 2.3.103
Need some more info... There was a change a couple days ago that I need to know if you're version has this patch.So what version do you have?rigctl --version commit 7ea4fd17aa728555ea3b05b74dca0f5e8a7b4efeAuthor: Mike Black W9MDB @.***>Date: Thu Apr 8 22:37:36 2021 -0500 Fix icom.c default vfo to usa VFOA/Main as appropriate https://github.com/Hamlib/Hamlib/issues/654
Then...if you already have this patch I need debug info and whatever error is occurring.So add "-vvvvv -Z" to the rigctld line and send me the debug info. Mike W9MDB
On Saturday, April 10, 2021, 07:13:34 PM CDT, w6bvb ***@***.***> wrote:
Hi I tried everything, but no luck to run IC910 with gpredict. My current setup: Ubuntu 20.10 Hamlib 4.2~git , gpredict 2.3.103
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Thank you Mike for super fast response. Hamlib: rigctl --version commit rigctl Hamlib 4.2~git Sat Apr 10 19:22:53 2021 +0000 SHA=778758 IC910 settings: C1-bAud:19200; C1-trn: on; C1-Addr: 60 daemon start: rigctld -m 3044 -r /dev/ttyUSB0 --civaddr \0x60 -vvvvv -Z
gpredict inteface settings: Name: IC-910; Host: localhost; Port: 4532; Radio type: Full-duplex; PTT status: None; VFO Up/Down SUB Up/ MAIN Down; Signaling: both unchecked gpredict radio wiget:1. Device: IC-910; 2. Device: None; Cycle:1000
After "Engage" button is clicked, it went to the loop:
2021-04-11:04:46:42.598061: frame.c(119):icom_one_transaction entered
2021-04-11:04:46:42.598066: frame.c(56):make_cmd_frame entered
2021-04-11:04:46:42.598072: frame.c(90):make_cmd_frame return(6)
2021-04-11:04:46:42.598078: rig_flush: called for serial device
2021-04-11:04:46:42.598085: serial.c(629):serial_flush entered
2021-04-11:04:46:42.598091: tcflush
2021-04-11:04:46:42.598099: serial.c(661):serial_flush return(0)
2021-04-11:04:46:42.598105: write_block called
2021-04-11:04:46:42.598113: write_block(): TX 6 bytes
2021-04-11:04:46:42.598121: 0000 fe fe 60 e0 03 fd ..... 2021-04-11:04:46:42.598134: frame.c(375):read_icom_frame entered 2021-04-11:04:46:42.598141: read_string called, rxmax=80 2021-04-11:04:46:42.613812: read_string(): RX 6 characters 2021-04-11:04:46:42.613830: 0000 fe fe 60 e0 03 fd .....
2021-04-11:04:46:42.613840: frame.c(409):read_icom_frame return(6)
2021-04-11:04:46:42.613848: frame.c(375):read_icom_frame entered
2021-04-11:04:46:42.613855: read_string called, rxmax=80
2021-04-11:04:46:42.629925: read_string(): RX 11 characters
2021-04-11:04:46:42.629951: 0000 fe fe e0 60 03 00 90 94 36 04 fd ...`....6..
2021-04-11:04:46:42.629963: frame.c(409):read_icom_frame return(11)
2021-04-11:04:46:42.629977: icom_one_transaction: frm_len=11, frm_len-1=fd, frm_len-2=04
2021-04-11:04:46:42.629991: frame.c(303):icom_one_transaction return(0)
2021-04-11:04:46:42.630001: frame.c(355):icom_transaction return(0)
2021-04-11:04:46:42.630013: set_vfo_curr: vfo=Sub, curr_vfo=Sub
2021-04-11:04:46:42.630035: set_vfo_curr: curr_vfo now=Sub
2021-04-11:04:46:42.630052: icom.c(7822):set_vfo_curr return(0)
2021-04-11:04:46:42.630066: from_bcd called
2021-04-11:04:46:42.630080: icom_get_freq exit vfo=currVFO, curr_vfo=Sub
2021-04-11:04:46:42.630094: icom.c(1388):icom_get_freq return(0)
2021-04-11:04:46:42.630108: ic910_get_freq: vfo=Sub
2021-04-11:04:46:42.630121: icom_set_vfo called vfo=Sub
2021-04-11:04:46:42.630134: icom_set_vfo: VFO changing from Sub to SubA
2021-04-11:04:46:42.630148: icom_set_vfo: debug#2
2021-04-11:04:46:42.630160: icom_set_vfo: SubA/B logic
2021-04-11:04:46:42.630172: frame.c(325):icom_transaction entered
2021-04-11:04:46:42.630186: icom_transaction: cmd=0x07, subcmd=0xd1, payload_len=0
Let me know what else I can provide.
I don't see any error there or a loop. First thing to try is to turn off transceive. It's not supported yet and may cause some problems. Mike W9MDB
On Saturday, April 10, 2021, 11:51:54 PM CDT, w6bvb ***@***.***> wrote:
Thank you Mike for super fast response. Hamlib: rigctl --version commit rigctl Hamlib 4.2~git Sat Apr 10 19:22:53 2021 +0000 SHA=778758 IC910 settings: C1-bAud:19200; C1-trn: on; C1-Addr: 60 daemon start: rigctld -m 3044 -r /dev/ttyUSB0 --civaddr \0x60 -vvvvv -Z
gpredict inteface settings: Name: IC-910; Host: localhost; Port: 4532; Radio type: Full-duplex; PTT status: None; VFO Up/Down SUB Up/ MAIN Down; Signaling: both unchecked gpredict radio wiget:1. Device: IC-910; 2. Device: None; Cycle:1000
After "Engage" button is clicked, it went to the loop: 2021-04-11:04:46:42.598061: frame.c(119):icom_one_transaction entered 2021-04-11:04:46:42.598066: frame.c(56):make_cmd_frame entered 2021-04-11:04:46:42.598072: frame.c(90):make_cmd_frame return(6) 2021-04-11:04:46:42.598078: rig_flush: called for serial device 2021-04-11:04:46:42.598085: serial.c(629):serial_flush entered 2021-04-11:04:46:42.598091: tcflush 2021-04-11:04:46:42.598099: serial.c(661):serial_flush return(0) 2021-04-11:04:46:42.598105: write_block called 2021-04-11:04:46:42.598113: write_block(): TX 6 bytes 2021-04-11:04:46:42.598121: 0000 fe fe 60 e0 03 fd ..... 2021-04-11:04:46:42.598134: frame.c(375):read_icom_frame entered 2021-04-11:04:46:42.598141: read_string called, rxmax=80 2021-04-11:04:46:42.613812: read_string(): RX 6 characters 2021-04-11:04:46:42.613830: 0000 fe fe 60 e0 03 fd ..... 2021-04-11:04:46:42.613840: frame.c(409):read_icom_frame return(6) 2021-04-11:04:46:42.613848: frame.c(375):read_icom_frame entered 2021-04-11:04:46:42.613855: read_string called, rxmax=80 2021-04-11:04:46:42.629925: read_string(): RX 11 characters 2021-04-11:04:46:42.629951: 0000 fe fe e0 60 03 00 90 94 36 04 fd ...`....6.. 2021-04-11:04:46:42.629963: frame.c(409):read_icom_frame return(11) 2021-04-11:04:46:42.629977: icom_one_transaction: frm_len=11, frm_len-1=fd, frm_len-2=04 2021-04-11:04:46:42.629991: frame.c(303):icom_one_transaction return(0) 2021-04-11:04:46:42.630001: frame.c(355):icom_transaction return(0) 2021-04-11:04:46:42.630013: set_vfo_curr: vfo=Sub, curr_vfo=Sub 2021-04-11:04:46:42.630035: set_vfo_curr: curr_vfo now=Sub 2021-04-11:04:46:42.630052: icom.c(7822):set_vfo_curr return(0) 2021-04-11:04:46:42.630066: from_bcd called 2021-04-11:04:46:42.630080: icom_get_freq exit vfo=currVFO, curr_vfo=Sub 2021-04-11:04:46:42.630094: icom.c(1388):icom_get_freq return(0) 2021-04-11:04:46:42.630108: ic910_get_freq: vfo=Sub 2021-04-11:04:46:42.630121: icom_set_vfo called vfo=Sub 2021-04-11:04:46:42.630134: icom_set_vfo: VFO changing from Sub to SubA 2021-04-11:04:46:42.630148: icom_set_vfo: debug#2 2021-04-11:04:46:42.630160: icom_set_vfo: SubA/B logic 2021-04-11:04:46:42.630172: frame.c(325):icom_transaction entered 2021-04-11:04:46:42.630186: icom_transaction: cmd=0x07, subcmd=0xd1, payload_len=0 Let me know what else I can provide.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.