Thread: [Hamlib-developer] rigctl send_cmd
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: Jere S. <k4...@gm...> - 2018-02-03 19:32:26
|
I am trying to use the send_cmd to load the memories in my FT-991A, however, when I do "w FA" to read frequency, 0 bytes are sent, the 'f' command works ok, see below: rigctl -m 135 -r /dev/tty.SLAB_USBtoUART -s 9600 -t';' -vvvvv rigctl, Hamlib 3.0.1 Report bugs to <ham...@li...> rig:rig_init called yaesu: initrigs3_yaesu called rig_register (121) rig_register (127) rig_register (110) rig_register (105) rig_register (106) rig_register (107) rig_register (109) rig_register (120) rig_register (101) rig_register (122) rig_register (123) rig_register (111) rig_register (115) rig_register (113) rig_register (114) rig_register (128) rig_register (131) rig_register (116) rig_register (103) rig_register (124) rig_register (104) rig_register (125) rig_register (129) rig_register (132) rig_register (130) rig_register (117) rig_register (119) rig_register (118) rig_register (126) rig_register (133) rig_register (134) rig_register (135) ft991_init called, version 0.22.4 newcat_init called rig:rig_open called newcat_open called newcat_open: write_delay = 0 msec newcat_open: post_write_delay = 50 msec newcat_set_trn called newcat_valid_command called newcat_valid_command AI cmd_str = AI0; cmd_str = AI0; write_block(): TX 4 bytes 0000 41 49 30 3b AI0; cmd_str = ID; write_block(): TX 3 bytes 0000 49 44 3b ID; read_string(): RX 7 characters 0000 49 44 30 36 37 30 3b ID0670; newcat_set_cmd: read count = 7, ret_data = ID0670; newcat_get_vfo called newcat_valid_command called newcat_valid_command VS newcat_valid_command: 'FT-991' command 'VS' not supported Opened rig model 135, 'FT-991' Backend version: 0.22.4, Status: Beta Rig command: w rigctl_parse: input_line: w Cmd: fa write_block(): TX 0 bytes read_string(): Timed out 2.6782 seconds after 0 chars Reply: Rig command: f rigctl_parse: input_line: f newcat_get_freq called newcat_get_freq: passed vfo = 0x20000000 newcat_valid_command called newcat_valid_command FA newcat_set_vfo_from_alias: alias vfo = 0x20000000 newcat_valid_command called newcat_valid_command FA cmd_str = FA; cmd_str = FA; write_block(): TX 3 bytes 0000 46 41 3b FA; read_string(): RX 12 characters 0000 46 41 30 30 37 30 37 34 30 30 30 3b FA007074000; newcat_get_cmd: read count = 12, ret_data = FA007074000; newcat_get_freq: freq = 7074000.000000 Hz for vfo 0x01 Frequency: 7074000 Jere Sandidge k4...@gm... |
|
From: Nate B. <n0...@n0...> - 2018-02-03 22:28:05
Attachments:
signature.asc
|
* On 2018 03 Feb 13:34 -0600, Jere Sandidge wrote: > I am trying to use the send_cmd to load the memories in my FT-991A, however, when I do "w FA" to read frequency, 0 bytes are sent, the 'f' command works ok, see below: > Rig command: w > rigctl_parse: input_line: w > Cmd: fa > write_block(): TX 0 bytes > read_string(): Timed out 2.6782 seconds after 0 chars > Reply: Did you also try it with the terminating ';' as well? Here is what I get with an Elecraft K3 when the semicolon is not a part of the string that uses a similar command set: Rig command: w rigctl_parse: input_line: w Cmd: fa serial_flush called write_block called write_block(): TX 3 bytes 0000 66 61 0d fa. read_string called read_string(): Timed out 1.1045 seconds after 0 chars Reply: And with the semicolon: Rig command: w rigctl_parse: input_line: w Cmd: fa; serial_flush called write_block called write_block(): TX 4 bytes 0000 66 61 3b 0d fa;. read_string called read_string(): RX 14 characters 0000 46 41 30 30 30 30 37 31 31 34 30 30 30 3b FA00007114000; Reply: FA00007114000; read_string called read_string(): Timed out 1.1047 seconds after 0 chars Rig command: In this case, it is possible that the Yaesu backend doesn't send anything out when the semicolon is missing while the Kenwood backend does (while both work with radios using similar command sets, they are independent implementations and don't share code). HTH, 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: Nate B. <n0...@n0...> - 2018-02-04 00:00:16
Attachments:
signature.asc
|
Also CC'ing the list in reply, please do so. :-) * On 2018 03 Feb 16:37 -0600, Jere Sandidge wrote: > Yes, I tried with with and without the ';'; I think the problem is the > program is not writing any bytes out: > > Rig command: w > rigctl_parse: input_line: w > Cmd: FA > write_block(): TX 0 bytes HERE TX 0 bytes... > read_string(): Timed out 2.6242 seconds after 0 chars > Reply: > Rig command: q I agree this is some sort of bug as the 'send_cmd' function actually bypasses the backend. The only thing I can figure is that either the FT-991 backend or the newcat portion is not populating the rig_state structure correctly. If anyone with another newer Yaesu radio that uses Newcat please test this command so it can be narrowed a bit further. 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: Nate B. <n0...@n0...> - 2018-02-05 17:56:32
Attachments:
signature.asc
|
CC'ing the mailing list. * On 2018 05 Feb 11:39 -0600, Lisa R. Nelson wrote: > I'm making some progress on this. What is the location of the > development source code? I've found a couple, want to make sure I'm > working with the latest one. The official one is at Source Forge: https://sourceforge.net/p/hamlib/code/ci/master/tree/ I also maintain a repository at GitHub which I keep in sync with the SF one. I prefer working with GitHub, though the latest SF changes have improved it greatly: https://github.com/N0NB/hamlib > I see there's a TM-V7 model in the list, but in my testing, it fails on > my TM-V71A radio. Says invalid model. I've found there's a bunch of > files that need modifications for a new model. Is there a list of these > somewhere? Section 3 of README.developer should document almost everything needed: https://github.com/N0NB/hamlib/blob/master/README.developer Let me know how I can improve this documentation. 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: Jere S. <k4...@gm...> - 2018-02-06 02:25:41
Attachments:
signature.asc
|
Nate, I have been looking at the source code and I don't see any send_cmd functions in the Yaesu ft991.c code, however these functions are in the ft897.c file. Unless I am wrong, this might be why 'send_cmd FA;' outputs zero bytes. I will have to study the ft897.c file to see if I can modify the ft991.c source to include these functions. 73, Jere k4...@gm... > On Feb 5, 2018, at 12:56 PM, Nate Bargmann <n0...@n0...> wrote: > > CC'ing the mailing list. > > * On 2018 05 Feb 11:39 -0600, Lisa R. Nelson wrote: >> I'm making some progress on this. What is the location of the >> development source code? I've found a couple, want to make sure I'm >> working with the latest one. > > The official one is at Source Forge: > > https://sourceforge.net/p/hamlib/code/ci/master/tree/ > > I also maintain a repository at GitHub which I keep in sync with the SF > one. I prefer working with GitHub, though the latest SF changes have > improved it greatly: > > https://github.com/N0NB/hamlib > >> I see there's a TM-V7 model in the list, but in my testing, it fails on >> my TM-V71A radio. Says invalid model. I've found there's a bunch of >> files that need modifications for a new model. Is there a list of these >> somewhere? > > Section 3 of README.developer should document almost everything needed: > > https://github.com/N0NB/hamlib/blob/master/README.developer > > Let me know how I can improve this documentation. > > 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 > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Bill S. <g4...@cl...> - 2018-02-06 09:45:59
|
On 06/02/2018 02:26, Jere Sandidge wrote: > I have been looking at the source code and I don't see any send_cmd functions in the Yaesu ft991.c code, however these functions are in the ft897.c file. Unless I am wrong, this might be why 'send_cmd FA;' outputs zero bytes. I will have to study the ft897.c file to see if I can modify the ft991.c source to include these functions. Hi Jere, the send command functionality is handled directly in the input parser (test/rigctl_parse.c) not by the individual back ends. It only makes sense for some rigs, others have binary protocols with fixed format input and output parameters. Only rigs with ASCII CAT protocols like the latest Yaesu and most Kenwood rigs can be used with the generic send_cmd (w) command. The code you see in the yaesu/ft897.c source is unrelated, it is just an internal function to send the low level commands used by the higher level back end implementations. 73 Bill G4WJS. |
|
From: Jere S. <k4...@gm...> - 2018-02-06 14:04:24
|
Bill, Thank you for the info, do you have any suggestions on where to look in the rigctl code to determine why I see this? Rig command: w FA; rigctl_parse: input_line: w FA; write_block(): TX 0 bytes read_string(): Timed out 2.3858 seconds after 0 chars Reply: Rig command: This works ok: Rig command: f rigctl_parse: input_line: f newcat_get_freq called newcat_get_freq: passed vfo = 0x20000000 newcat_valid_command called newcat_valid_command FA newcat_set_vfo_from_alias: alias vfo = 0x20000000 newcat_valid_command called newcat_valid_command FA cmd_str = FA; cmd_str = FA; write_block(): TX 3 bytes 0000 46 41 3b FA; read_string(): RX 12 characters 0000 46 41 30 30 37 30 37 34 30 30 30 3b FA007074000; newcat_get_cmd: read count = 12, ret_data = FA007074000; newcat_get_freq: freq = 7074000.000000 Hz for vfo 0x01 Frequency: 7074000 Rig command: 73, Jere K4FUM > On Feb 6, 2018, at 4:45 AM, Bill Somerville <g4...@cl...> wrote: > > On 06/02/2018 02:26, Jere Sandidge wrote: >> I have been looking at the source code and I don't see any send_cmd functions in the Yaesu ft991.c code, however these functions are in the ft897.c file. Unless I am wrong, this might be why 'send_cmd FA;' outputs zero bytes. I will have to study the ft897.c file to see if I can modify the ft991.c source to include these functions. > > Hi Jere, > > the send command functionality is handled directly in the input parser (test/rigctl_parse.c) not by the individual back ends. It only makes sense for some rigs, others have binary protocols with fixed format input and output parameters. Only rigs with ASCII CAT protocols like the latest Yaesu and most Kenwood rigs can be used with the generic send_cmd (w) command. > > The code you see in the yaesu/ft897.c source is unrelated, it is just an internal function to send the low level commands used by the higher level back end implementations. > > 73 > Bill > G4WJS. > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Bill S. <g4...@cl...> - 2018-02-06 14:25:31
|
On 06/02/2018 14:04, Jere Sandidge wrote: > Thank you for the info, do you have any suggestions on where to look in the rigctl code to determine why I see this? Hi Jere, in the file I mentioned, test/rigctl_parse.c, look at the handler for the send_cmd token. 73 Bill G4WJS. |
|
From: Nate B. <n0...@n0...> - 2018-02-06 17:41:35
Attachments:
signature.asc
|
* On 2018 06 Feb 08:26 -0600, Bill Somerville wrote: > On 06/02/2018 14:04, Jere Sandidge wrote: > >Thank you for the info, do you have any suggestions on where to look in the rigctl code to determine why I see this? > > Hi Jere, > > in the file I mentioned, test/rigctl_parse.c, look at the handler for the > send_cmd token. That section of code queries the rig_state structure. I'm wondering if the backend is not populating the structure correctly, or at all? 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...> - 2018-02-06 18:03:29
|
On 06/02/2018 17:41, Nate Bargmann wrote: > * On 2018 06 Feb 08:26 -0600, Bill Somerville wrote: >> On 06/02/2018 14:04, Jere Sandidge wrote: >>> Thank you for the info, do you have any suggestions on where to look in the rigctl code to determine why I see this? >> Hi Jere, >> >> in the file I mentioned, test/rigctl_parse.c, look at the handler for the >> send_cmd token. > That section of code queries the rig_state structure. I'm wondering if > the backend is not populating the structure correctly, or at all? > > 73, Nate Hi Nate, looks ok to me. I think that the important part is the correct command terminator must be set with the rigctl -t command line option, something like (untested and may need more options for serial port): rigctl -m135 -t\; w FA 73 Bill G4WJS. |
|
From: Jere S. <k4...@gm...> - 2018-02-07 00:01:18
|
Bill, See below: rigctl -m 135 -r /dev/tty.SLAB_USBtoUART -s 9600 -t\; w FA -vvvvv rigctl, Hamlib 3.0.1 Report bugs to <ham...@li...> rig:rig_init called yaesu: initrigs3_yaesu called rig_register (121) rig_register (127) rig_register (110) rig_register (105) rig_register (106) rig_register (107) rig_register (109) rig_register (120) rig_register (101) rig_register (122) rig_register (123) rig_register (111) rig_register (115) rig_register (113) rig_register (114) rig_register (128) rig_register (131) rig_register (116) rig_register (103) rig_register (124) rig_register (104) rig_register (125) rig_register (129) rig_register (132) rig_register (130) rig_register (117) rig_register (119) rig_register (118) rig_register (126) rig_register (133) rig_register (134) rig_register (135) ft991_init called, version 0.22.4 newcat_init called rig:rig_open called newcat_open called newcat_open: write_delay = 0 msec newcat_open: post_write_delay = 50 msec newcat_set_trn called newcat_valid_command called newcat_valid_command AI cmd_str = AI0; cmd_str = AI0; write_block(): TX 4 bytes 0000 41 49 30 3b AI0; cmd_str = ID; write_block(): TX 3 bytes 0000 49 44 3b ID; read_string(): RX 7 characters 0000 49 44 30 36 37 30 3b ID0670; newcat_set_cmd: read count = 7, ret_data = ID0670; newcat_get_vfo called newcat_valid_command called newcat_valid_command VS newcat_valid_command: 'FT-991' command 'VS' not supported Opened rig model 135, 'FT-991' Backend version: 0.22.4, Status: Beta write_block(): TX 0 bytes read_string(): Timed out 2.1470 seconds after 0 chars rig:rig_close called newcat_close called rig:rig_cleanup called newcat_cleanup called Jere > On Feb 6, 2018, at 1:03 PM, Bill Somerville <g4...@cl...> wrote: > > On 06/02/2018 17:41, Nate Bargmann wrote: >> * On 2018 06 Feb 08:26 -0600, Bill Somerville wrote: >>> On 06/02/2018 14:04, Jere Sandidge wrote: >>>> Thank you for the info, do you have any suggestions on where to look in the rigctl code to determine why I see this? >>> Hi Jere, >>> >>> in the file I mentioned, test/rigctl_parse.c, look at the handler for the >>> send_cmd token. >> That section of code queries the rig_state structure. I'm wondering if >> the backend is not populating the structure correctly, or at all? >> >> 73, Nate > Hi Nate, > > looks ok to me. I think that the important part is the correct command terminator must be set with the rigctl -t command line option, something like (untested and may need more options for serial port): > > rigctl -m135 -t\; w FA > > 73 > Bill > G4WJS. > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Bill S. <g4...@cl...> - 2018-02-07 00:19:03
|
On 07/02/2018 00:01, Jere Sandidge wrote: > Bill, > See below: > > rigctl -m 135 -r /dev/tty.SLAB_USBtoUART -s 9600 -t\; w FA -vvvvv > rigctl, Hamlib 3.0.1 > Report bugs to <ham...@li... > <mailto:ham...@li...>> > > rig:rig_init called > yaesu: initrigs3_yaesu called > rig_register (121) > rig_register (127) > rig_register (110) > rig_register (105) > rig_register (106) > rig_register (107) > rig_register (109) > rig_register (120) > rig_register (101) > rig_register (122) > rig_register (123) > rig_register (111) > rig_register (115) > rig_register (113) > rig_register (114) > rig_register (128) > rig_register (131) > rig_register (116) > rig_register (103) > rig_register (124) > rig_register (104) > rig_register (125) > rig_register (129) > rig_register (132) > rig_register (130) > rig_register (117) > rig_register (119) > rig_register (118) > rig_register (126) > rig_register (133) > rig_register (134) > rig_register (135) > ft991_init called, version 0.22.4 > newcat_init called > rig:rig_open called > newcat_open called > newcat_open: write_delay = 0 msec > newcat_open: post_write_delay = 50 msec > newcat_set_trn called > newcat_valid_command called > newcat_valid_command AI > cmd_str = AI0; > cmd_str = AI0; > write_block(): TX 4 bytes > 0000 41 49 30 3b AI0; > cmd_str = ID; > write_block(): TX 3 bytes > 0000 49 44 3b ID; > read_string(): RX 7 characters > 0000 49 44 30 36 37 30 3b ID0670; > newcat_set_cmd: read count = 7, ret_data = ID0670; > newcat_get_vfo called > newcat_valid_command called > newcat_valid_command VS > newcat_valid_command: 'FT-991' command 'VS' not supported > Opened rig model 135, 'FT-991' > Backend version: 0.22.4, Status: Beta > write_block(): TX 0 bytes > read_string(): Timed out 2.1470 seconds after 0 chars > rig:rig_close called > newcat_close called > rig:rig_cleanup called > newcat_cleanup called > > Jere Hi Jere, I believe commands have to be after all command line options, try this: rigctl -m 135 -r /dev/tty.SLAB_USBtoUART -s 9600 -t\; -vvvvv w FA BTW the VS command not supported message is bogus and can be ignored, the latest master branch code does not try and invoke a VS; command on the FT-991(A). 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