(Tried to post this to the mailing list, but it looks like it didn't get through, so I'm reposting here)

Please correct if I'm wrong, but it seems there are currently no tests for individual radio/rotator backends in Hamlib.

I'm seeing this as a big issue, since it is very easy to cause regressions in individual radio commands when refactoring and/or adding new functionality to an existing backend. I've experienced this multiple times during the last year when developing a web-based remote control UI that uses Hamlib to control radios. The basic commands (frequency, mode, VFO) work very well, but in case of controlling a remote station also the Hamlib function and level controls become very important.

I'd really like to take Hamlib "to the next level" in 2019 regarding reliability and completeness of backend command sets by introducing a testing framework for both radio backends and later also for rotator backends.

This framework would mock the normal serial/parallel/USB I/O routines (which is luckily possible because of the excellent I/O abstractions in Hamlib) and do the following:

1. Run a globally defined set of test cases, which would include every single Hamlib command with a predefined set of parameters
2. For each command, the mock routines would
   2.1. record the output of all write()-type commands for a particular command
   2.2. compare it to a backend-specific byte array for a specific test case
   2.3. offer a backend-specific byte array for a specific test case as a response for all read()-type commands
   2.4. check the expected return value of the Hamlib command executed

Every test case would naturally need a unique identifier so that the global test framework could search for valid test cases for each backend. Backend would need to register a data structure containing the test case expectations for the command output and return value and the device response to be offered to the backend.

In order to develop and to extend the set of test cases, a missing test case would not indicate a failure, but we could generate a HTML matrix similar to the rig command support matrix containing the test cases executed and present for each backend.

What I'd like to accomplish with this setup is:

A) When making changes to Hamlib code, we could verify that each and every Hamlib command still outputs the same device-specific command for a specific backend and that the backend interprets device responses, including errors, correctly. There have been cases where simple changes to, for example, fix compiler warnings have resulted in broken code (I saw one with IC-7300 backend last year).

B) When adding new functionality it would become more apparent when to branch code for a new model: e.g. Elecraft KX3/K3/K3s have many similar commands, but are not 100% compatible -- yet they share the backend code. There should always be a good reason to change the expected output of a test, so nothing would go unnoticed.

Adding test data for all backends is a huge task and will need a lot of effort from the whole Hamlib developer community, but I think automated testing is the only way forward if we wish to keep Hamlib usable and maintainable when we are making breaking changes (like now for 4.0 release). In addition, the list of supported hardware keeps on growing and radios are becoming more complex with wider sets of features, which certainly does not make Hamlib development easier :)

Please share your thoughts about this kind of effort. If you feel this change would be welcome, I can continue by posting more detailed design in GitHub.

73,
Mikael OH3BHX

Icom SDR rigs (7300, 7610, 9700, etc.) support sending waterfall data over USB for display on a PC. When the scope data output (command 27 subcommand 20) is enabled, the rig sends a constant stream of unsolicited scope data reports (command 27 subcommand 00), with raw binary payloads, between command responses. Their RS-BA1 remote control software and a few other third-party Windows programs support decoding and displaying it.

I want to make something similar but cross-platform, and of course I don't want my program to take sole ownership of the serial port; I want to have rigctld running and do other hamlib things at the same time. Practically speaking, this means that hamlib needs to be the one handling the scope data.

I don't care if hamlib interprets it, but what I would hope for would be

• For hamlib not to desync or show any behavior difference to uninterested clients, when connected to a rig with scope data output enabled.
• For a TCP client to have a way to subscribe to the scope data, receiving it as it comes in, with sensible framing (It could also be used for other kinds of transcieve data, e.g. Icoms will tell you about frequency changes and PTT toggles if you ask... but I don't care if it doesn't). I wouldn't mind if starting one of these subscriptions made the socket totally unable to issue other commands (to avoid framing problems).

I think this should be more or less possible with the existing event loop code in hamlib, and I'm willing to make an attempt at it myself, but I wanted to run the approach by someone first, and get some input, to increase the chances of actually getting a patch accepted.

together with @mdblack98 did some reasearch why the 'f' command fails on the hash rev 74718f9.

7851

get vfo
get_vfo: error = Feature not available
set Main
get freq
get_freq: error = Command rejected by the rig
set Sub
get freq
get_freq: error = Command rejected by the rig

And with the proposed and tested PR I made, the function works as supposed. It also does not break the 7300 and 9700 code.

7851

get vfo
get_vfo: error = Feature not available
set Main
get freq
14074000
set Sub
get freq
15273000

I

I am using Windows 10, RigCtl last version and GPredirect 2.3.37 as decribed here
http://w7hd.ddns.net/yaesu/ft991a/gpredict-ft991a.pdf
Everthing is fine as long as I run GPredirect in the background
But I want to set VFOA and VFOB without running GPredirect
https://www.systutorials.com/docs/linux/man/1-rigctl/

First I tried to set split operation with
"rigctl.exe -m 2 -r localhost:4532 V VFOA F 145620000 V VFOB F 434020000"
When I do that the 434Mhz is in VFO A, VFOB is unchanged
This command
rigctl.exe -m 2 -r localhost:4532 V VFOA F 145620000 I 434020000
is also not working, till I start GPRedict, than VFO A has 145... and VFO B 434

Any hints to make it without running GPRedict in the background or what I am doing wrong.
tnx 73 Alex, OE3JTB

EOM

The current data format of rigctld/rotctld responses is quite hard to parse -- especially the capabilities list is a bit of a nightmare. I've been thinking of introducing an alternate data format, e.g. JSON, for this purpose.

There are also some other issues with rig capabilities listings: currently they do not contain all of the information specified in the rig backends. At least TX/RX ranges and ext level definitions (numeric ranges / combo choices) are missing.

Now that the project is heading towards a new major release with possibility of breaking API/ABI, it could be a good time to introduce this kind of change. Obviously we would need a flag/option to specify which data format to use, so that the old one could be preserved for backwards-compatibility.

I'd just like to hear maintaners' opinions/ideas on this to decide whether it makes sense to proceed with implementation. Depending on the data format, we would need to add new dependencies, e.g. jansson for JSON.

$ rigctl-wsjtx -vvvvv -m 237 -r /dev/ttyUSB0
rigctl, Hamlib 3.1~git
Report bugs to [email protected]

rig:rig_init called
initrigs3_kenwood called
rig_register (213)
rig_register (201)
rig_register (225)
rig_register (203)
rig_register (204)
rig_register (216)
rig_register (224)
rig_register (205)
rig_register (207)
rig_register (209)
rig_register (210)
rig_register (222)
rig_register (214)
rig_register (230)
rig_register (221)
rig_register (229)
rig_register (238)
rig_register (202)
rig_register (211)
rig_register (206)
rig_register (208)
rig_register (215)
rig_register (226)
rig_register (217)
rig_register (233)
rig_register (220)
rig_register (223)
rig_register (227)
rig_register (234)
rig_register (231)
rig_register (239)
rig_register (237)
rig_register (228)
rig_register (219)
rig_register (232)
rig_register (236)
kenwood_init called
kenwood_init: if_len = 37
rig:rig_open called
kenwood_open called
kenwood_get_id called
kenwood_transaction called
kenwood_transaction: cmdstr = ID
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string(): RX 6 characters
0000 49 44 30 32 33 3b ID023;
kenwood_open: found match 023
kenwood_get_trn called
kenwood_safe_transaction called
kenwood_transaction called
kenwood_transaction: cmdstr = AI
write_block(): TX 3 bytes
0000 41 49 3b AI;
read_string(): RX 4 characters
0000 41 49 30 3b AI0;
kenwood_set_trn called
kenwood_transaction called
kenwood_transaction: cmdstr = AI0
write_block(): TX 4 bytes
0000 41 49 30 3b AI0;
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string(): RX 6 characters
0000 49 44 30 32 33 3b ID023;
kenwood_get_vfo_if called
kenwood_get_if called
kenwood_safe_transaction called
kenwood_transaction called
kenwood_transaction: cmdstr = IF
write_block(): TX 3 bytes
0000 49 46 3b IF;
read_string(): RX 38 characters
0000 49 46 30 30 30 30 30 31 39 38 30 30 30 20 20 20 IF00000198000
0010 20 20 20 30 30 30 30 30 30 30 31 30 30 31 30 30 0000000100100
0020 30 30 30 38 30 3b 00080;
Opened rig model 237, 'TS-590SG'
Backend version: 0.9.1, Status: Beta

Rig command: l ?
Level: AF RF SQL CWPITCH RFPOWER AGC METER SWR ALC STRENGTH

Rig command: l STRENGTH
Level: kenwood_get_level called
kenwood_safe_transaction called
kenwood_transaction called
kenwood_transaction: cmdstr = SM
write_block(): TX 3 bytes
0000 53 4d 3b SM;
read_string(): RX 2 characters
0000 3f 3b ?;
kenwood_transaction: Unknown command or rig busy 'SM'
kenwood_transaction: Retrying shortly
kenwood_transaction: cmdstr = SM
write_block(): TX 3 bytes
0000 53 4d 3b SM;
read_string(): RX 2 characters
0000 3f 3b ?;
kenwood_transaction: Unknown command or rig busy 'SM'
kenwood_transaction: Retrying shortly
kenwood_transaction: cmdstr = SM
write_block(): TX 3 bytes
0000 53 4d 3b SM;
read_string(): RX 2 characters
0000 3f 3b ?;
kenwood_transaction: Unknown command or rig busy 'SM'
kenwood_transaction: Retrying shortly
kenwood_transaction: cmdstr = SM
write_block(): TX 3 bytes
0000 53 4d 3b SM;
read_string(): RX 2 characters
0000 3f 3b ?;
kenwood_transaction: Unknown command or rig busy 'SM'
kenwood_transaction: Retrying shortly
kenwood_transaction: cmdstr = SM
write_block(): TX 3 bytes
0000 53 4d 3b SM;
read_string(): RX 2 characters
0000 3f 3b ?;
kenwood_transaction: Unknown command or rig busy 'SM'
kenwood_transaction: Retrying shortly
kenwood_transaction: cmdstr = SM
write_block(): TX 3 bytes
0000 53 4d 3b SM;
read_string(): RX 2 characters
0000 3f 3b ?;
kenwood_transaction: Unknown command or rig busy 'SM'
kenwood_transaction: Retrying shortly
kenwood_transaction: cmdstr = SM
write_block(): TX 3 bytes
0000 53 4d 3b SM;
read_string(): RX 2 characters
0000 3f 3b ?;
kenwood_transaction: Unknown command or rig busy 'SM'
kenwood_transaction: Retrying shortly
kenwood_transaction: cmdstr = SM
write_block(): TX 3 bytes
0000 53 4d 3b SM;
read_string(): RX 2 characters
0000 3f 3b ?;
kenwood_transaction: Unknown command or rig busy 'SM'
kenwood_transaction: Retrying shortly
kenwood_transaction: cmdstr = SM
write_block(): TX 3 bytes
0000 53 4d 3b SM;
read_string(): RX 2 characters
0000 3f 3b ?;
kenwood_transaction: Unknown command or rig busy 'SM'
kenwood_transaction: Retrying shortly
kenwood_transaction: cmdstr = SM
write_block(): TX 3 bytes
0000 53 4d 3b SM;
read_string(): RX 2 characters
0000 3f 3b ?;
kenwood_transaction: Unknown command or rig busy 'SM'
kenwood_transaction: Retrying shortly
kenwood_transaction: cmdstr = SM
write_block(): TX 3 bytes
0000 53 4d 3b SM;
read_string(): RX 2 characters
0000 3f 3b ?;
kenwood_transaction: Unknown command or rig busy 'SM'
get_level: error = Command rejected by the rig

Rig command: l RAWSTR
Level: get_level: error = Invalid parameter

Rig command: m
kenwood_get_mode called
kenwood_safe_transaction called
kenwood_transaction called
kenwood_transaction: cmdstr = MD
write_block(): TX 3 bytes
0000 4d 44 3b MD;
read_string(): RX 4 characters
0000 4d 44 31 3b MD1;
kenwood2rmode called
kenwood_safe_transaction called
kenwood_transaction called
kenwood_transaction: cmdstr = DA
write_block(): TX 3 bytes
0000 44 41 3b DA;
read_string(): RX 4 characters
0000 44 41 30 3b DA0;
Mode: LSB
Passband: 2200

Rig command: f
kenwood_get_freq called
kenwood_safe_transaction called
kenwood_transaction called
kenwood_transaction: cmdstr = FA
write_block(): TX 3 bytes
0000 46 41 3b FA;
read_string(): RX 14 characters
0000 46 41 30 30 30 30 30 31 39 38 30 30 30 3b FA00000198000;
Frequency: 198000

Rig command: q
rig:rig_close called
kenwood_close called
kenwood_set_trn called
kenwood_transaction called
kenwood_transaction: cmdstr = AI0
write_block(): TX 4 bytes
0000 41 49 30 3b AI0;
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string(): RX 6 characters
0000 49 44 30 32 33 3b ID023;
rig:rig_cleanup called
kenwood_cleanup called

Using \set_powerstat 1 for the FT-950 takes about 30 seconds for the radio to respond. The 950 CAT manual states PS1 needs to be preceded by a dummy character, then the PS1 sent between 1 and 2 seconds later. This delay probably also occurs for the FT-450, FT991A, FTdx-1200, FTdx-3000 and perhaps the FTdx-101D/MP (not tested).

The log for the FT-950 is below.

--Howard W6HN

pi@rigpi4:~ $ rigctl -m 128 -s 38400 -r /dev/ttyUSB0 -vvvvv -Z \set_powerstat 1
2019-12-23:01:43:33.468039: rigctl, Hamlib 4.0~git
2019-12-23:01:43:33.468137: Report bugs to [email protected]

2019-12-23:01:43:33.468237: rig_init called
2019-12-23:01:43:33.468448: yaesu: initrigs4_yaesu called
2019-12-23:01:43:33.468546: rig_register called
2019-12-23:01:43:33.468600: rig_register: rig_register (121)
2019-12-23:01:43:33.468641: rig_register called
2019-12-23:01:43:33.468677: rig_register: rig_register (127)
2019-12-23:01:43:33.468711: rig_register called
2019-12-23:01:43:33.468743: rig_register: rig_register (110)
2019-12-23:01:43:33.468773: rig_register called
2019-12-23:01:43:33.468803: rig_register: rig_register (105)
2019-12-23:01:43:33.468835: rig_register called
2019-12-23:01:43:33.468867: rig_register: rig_register (106)
2019-12-23:01:43:33.468897: rig_register called
2019-12-23:01:43:33.468927: rig_register: rig_register (107)
2019-12-23:01:43:33.468963: rig_register called
2019-12-23:01:43:33.468996: rig_register: rig_register (139)
2019-12-23:01:43:33.469027: rig_register called
2019-12-23:01:43:33.469057: rig_register: rig_register (109)
2019-12-23:01:43:33.469087: rig_register called
2019-12-23:01:43:33.469118: rig_register: rig_register (120)
2019-12-23:01:43:33.469148: rig_register called
2019-12-23:01:43:33.469180: rig_register: rig_register (101)
2019-12-23:01:43:33.469210: rig_register called
2019-12-23:01:43:33.469242: rig_register: rig_register (122)
2019-12-23:01:43:33.469276: rig_register called
2019-12-23:01:43:33.469317: rig_register: rig_register (123)
2019-12-23:01:43:33.469353: rig_register called
2019-12-23:01:43:33.469383: rig_register: rig_register (111)
2019-12-23:01:43:33.469413: rig_register called
2019-12-23:01:43:33.469444: rig_register: rig_register (115)
2019-12-23:01:43:33.469474: rig_register called
2019-12-23:01:43:33.469504: rig_register: rig_register (113)
2019-12-23:01:43:33.469537: rig_register called
2019-12-23:01:43:33.469567: rig_register: rig_register (114)
2019-12-23:01:43:33.469598: rig_register called
2019-12-23:01:43:33.469631: rig_register: rig_register (128)
2019-12-23:01:43:33.469661: rig_register called
2019-12-23:01:43:33.469691: rig_register: rig_register (131)
2019-12-23:01:43:33.469721: rig_register called
2019-12-23:01:43:33.469751: rig_register: rig_register (116)
2019-12-23:01:43:33.469781: rig_register called
2019-12-23:01:43:33.469813: rig_register: rig_register (103)
2019-12-23:01:43:33.469847: rig_register called
2019-12-23:01:43:33.469877: rig_register: rig_register (124)
2019-12-23:01:43:33.469910: rig_register called
2019-12-23:01:43:33.469940: rig_register: rig_register (104)
2019-12-23:01:43:33.469974: rig_register called
2019-12-23:01:43:33.470009: rig_register: rig_register (125)
2019-12-23:01:43:33.470040: rig_register called
2019-12-23:01:43:33.470071: rig_register: rig_register (129)
2019-12-23:01:43:33.470105: rig_register called
2019-12-23:01:43:33.470138: rig_register: rig_register (137)
2019-12-23:01:43:33.470169: rig_register called
2019-12-23:01:43:33.470199: rig_register: rig_register (132)
2019-12-23:01:43:33.470230: rig_register called
2019-12-23:01:43:33.470259: rig_register: rig_register (130)
2019-12-23:01:43:33.470289: rig_register called
2019-12-23:01:43:33.470319: rig_register: rig_register (117)
2019-12-23:01:43:33.470352: rig_register called
2019-12-23:01:43:33.470381: rig_register: rig_register (119)
2019-12-23:01:43:33.470413: rig_register called
2019-12-23:01:43:33.470447: rig_register: rig_register (118)
2019-12-23:01:43:33.470477: rig_register called
2019-12-23:01:43:33.470507: rig_register: rig_register (126)
2019-12-23:01:43:33.470537: rig_register called
2019-12-23:01:43:33.470567: rig_register: rig_register (133)
2019-12-23:01:43:33.470598: rig_register called
2019-12-23:01:43:33.470628: rig_register: rig_register (134)
2019-12-23:01:43:33.470658: rig_register called
2019-12-23:01:43:33.470691: rig_register: rig_register (135)
2019-12-23:01:43:33.470721: rig_register called
2019-12-23:01:43:33.470750: rig_register: rig_register (136)
2019-12-23:01:43:33.470786: rig_register called
2019-12-23:01:43:33.470816: rig_register: rig_register (138)
2019-12-23:01:43:33.470846: rig_register called
2019-12-23:01:43:33.470876: rig_register: rig_register (140)
2019-12-23:01:43:33.471061: newcat_init called
2019-12-23:01:43:33.471133: rig_open called
2019-12-23:01:43:33.471168: port_open called
2019-12-23:01:43:33.471208: serial_open called
2019-12-23:01:43:33.474284: serial_setup called
2019-12-23:01:43:33.477292: serial_flush called
2019-12-23:01:43:33.477339: serial_flush: tcflush
2019-12-23:01:43:33.477387: newcat_open called
2019-12-23:01:43:33.477475: newcat_open: write_delay = 0 msec
2019-12-23:01:43:33.477512: newcat_open: post_write_delay = 0 msec
2019-12-23:01:43:33.477547: newcat_get_trn called
2019-12-23:01:43:33.477589: newcat_valid_command called
2019-12-23:01:43:33.477620: newcat_valid_command AI
2019-12-23:01:43:33.477657: cmd_str = AI;
2019-12-23:01:43:33.477740: write_block called
2019-12-23:01:43:33.477837: write_block(): TX 3 bytes
2019-12-23:01:43:33.477922: 0000 41 49 3b AI;
2019-12-23:01:43:33.478007: read_string called
2019-12-23:01:43:35.489770: read_string(): RX 1 characters
2019-12-23:01:43:35.489840: 0000 00 .
2019-12-23:01:43:35.489876: newcat_get_cmd: read count = 1, ret_data =
2019-12-23:01:43:35.489922: newcat_get_cmd: wrong reply for command AI
2019-12-23:01:43:35.489956: read_string called
2019-12-23:01:43:38.480894: read_string(): RX 1 characters
2019-12-23:01:43:38.480962: 0000 00 .
2019-12-23:01:43:38.480999: newcat_get_cmd: read count = 1, ret_data =
2019-12-23:01:43:38.481034: newcat_get_cmd: wrong reply for command AI
2019-12-23:01:43:38.481068: read_string called
2019-12-23:01:43:40.483165: read_string(): Timed out 2.2050 seconds after 0 chars
2019-12-23:01:43:40.483228: cmd_str = AI;
2019-12-23:01:43:40.483262: write_block called
2019-12-23:01:43:40.483321: write_block(): TX 3 bytes
2019-12-23:01:43:40.483361: 0000 41 49 3b AI;
2019-12-23:01:43:40.483394: read_string called
2019-12-23:01:43:42.485490: read_string(): Timed out 2.2049 seconds after 0 chars
2019-12-23:01:43:42.485565: newcat_set_trn called
2019-12-23:01:43:42.485599: newcat_valid_command called
2019-12-23:01:43:42.485630: newcat_valid_command AI
2019-12-23:01:43:42.485664: cmd_str = AI0;
2019-12-23:01:43:42.485698: serial_flush called
2019-12-23:01:43:42.485728: serial_flush: tcflush
2019-12-23:01:43:42.485765: cmd_str = AI0;
2019-12-23:01:43:42.485799: write_block called
2019-12-23:01:43:42.485858: write_block(): TX 4 bytes
2019-12-23:01:43:42.485897: 0000 41 49 30 3b AI0;
2019-12-23:01:43:42.485929: cmd_str = ID;
2019-12-23:01:43:42.485959: write_block called
2019-12-23:01:43:42.486008: write_block(): TX 3 bytes
2019-12-23:01:43:42.486044: 0000 49 44 3b ID;
2019-12-23:01:43:42.486076: read_string called
2019-12-23:01:43:44.488172: read_string(): Timed out 2.2049 seconds after 0 chars
2019-12-23:01:43:44.488235: serial_flush called
2019-12-23:01:43:44.488346: serial_flush: tcflush
2019-12-23:01:43:44.488405: cmd_str = AI0;
2019-12-23:01:43:44.488458: write_block called
2019-12-23:01:43:44.488538: write_block(): TX 4 bytes
2019-12-23:01:43:44.488581: 0000 41 49 30 3b AI0;
2019-12-23:01:43:44.488625: cmd_str = ID;
2019-12-23:01:43:44.488655: write_block called
2019-12-23:01:43:44.488706: write_block(): TX 3 bytes
2019-12-23:01:43:44.488745: 0000 49 44 3b ID;
2019-12-23:01:43:44.488779: read_string called
2019-12-23:01:43:46.490879: read_string(): Timed out 2.2049 seconds after 0 chars
2019-12-23:01:43:46.490951: serial_flush called
2019-12-23:01:43:46.490987: serial_flush: tcflush
2019-12-23:01:43:46.491046: cmd_str = AI0;
2019-12-23:01:43:46.491099: write_block called
2019-12-23:01:43:46.491178: write_block(): TX 4 bytes
2019-12-23:01:43:46.491220: 0000 41 49 30 3b AI0;
2019-12-23:01:43:46.491260: cmd_str = ID;
2019-12-23:01:43:46.491290: write_block called
2019-12-23:01:43:46.491341: write_block(): TX 3 bytes
2019-12-23:01:43:46.491379: 0000 49 44 3b ID;
2019-12-23:01:43:46.491414: read_string called
2019-12-23:01:43:48.491709: read_string(): Timed out 2.247 seconds after 0 chars
2019-12-23:01:43:48.491771: serial_flush called
2019-12-23:01:43:48.491807: serial_flush: tcflush
2019-12-23:01:43:48.491845: cmd_str = AI0;
2019-12-23:01:43:48.491880: write_block called
2019-12-23:01:43:48.491938: write_block(): TX 4 bytes
2019-12-23:01:43:48.491976: 0000 41 49 30 3b AI0;
2019-12-23:01:43:48.492013: cmd_str = ID;
2019-12-23:01:43:48.492042: write_block called
2019-12-23:01:43:48.492092: write_block(): TX 3 bytes
2019-12-23:01:43:48.492128: 0000 49 44 3b ID;
2019-12-23:01:43:48.492160: read_string called
2019-12-23:01:43:50.494259: read_string(): Timed out 2.2052 seconds after 0 chars
2019-12-23:01:43:50.494326: newcat_get_rigid called
2019-12-23:01:43:50.494374: newcat_get_info called
2019-12-23:01:43:50.494407: newcat_get_info: cmd_str = ID;
2019-12-23:01:43:50.494439: cmd_str = ID;
2019-12-23:01:43:50.494470: write_block called
2019-12-23:01:43:50.494538: write_block(): TX 3 bytes
2019-12-23:01:43:50.494649: 0000 49 44 3b ID;
2019-12-23:01:43:50.494711: read_string called
2019-12-23:01:43:52.496808: read_string(): Timed out 2.2049 seconds after 0 chars
2019-12-23:01:43:52.496871: cmd_str = ID;
2019-12-23:01:43:52.496913: write_block called
2019-12-23:01:43:52.496976: write_block(): TX 3 bytes
2019-12-23:01:43:52.497018: 0000 49 44 3b ID;
2019-12-23:01:43:52.497050: read_string called
2019-12-23:01:43:54.499146: read_string(): Timed out 2.2049 seconds after 0 chars
2019-12-23:01:43:54.499207: cmd_str = ID;
2019-12-23:01:43:54.499248: write_block called
2019-12-23:01:43:54.499311: write_block(): TX 3 bytes
2019-12-23:01:43:54.499351: 0000 49 44 3b ID;
2019-12-23:01:43:54.499384: read_string called
2019-12-23:01:43:56.501391: read_string(): Timed out 2.1953 seconds after 0 chars
2019-12-23:01:43:56.501456: cmd_str = ID;
2019-12-23:01:43:56.501489: write_block called
2019-12-23:01:43:56.501550: write_block(): TX 3 bytes
2019-12-23:01:43:56.501590: 0000 49 44 3b ID;
2019-12-23:01:43:56.501622: read_string called
2019-12-23:01:43:58.502179: read_string(): Timed out 2.510 seconds after 0 chars
2019-12-23:01:43:58.502248: rig_id = 0, *s = (null)
2019-12-23:01:43:58.502292: rig_get_vfo called
2019-12-23:01:43:58.502324: newcat_get_vfo called
2019-12-23:01:43:58.502354: newcat_valid_command called
2019-12-23:01:43:58.502385: newcat_valid_command VS
2019-12-23:01:43:58.502419: newcat_get_vfo: cmd_str = VS;
2019-12-23:01:43:58.502451: cmd_str = VS;
2019-12-23:01:43:58.502481: write_block called
2019-12-23:01:43:58.502543: write_block(): TX 3 bytes
2019-12-23:01:43:58.502582: 0000 56 53 3b VS;
2019-12-23:01:43:58.502615: read_string called
2019-12-23:01:44:00.503609: read_string(): Timed out 2.945 seconds after 0 chars
2019-12-23:01:44:00.503675: cmd_str = VS;
2019-12-23:01:44:00.503708: write_block called
2019-12-23:01:44:00.503770: write_block(): TX 3 bytes
2019-12-23:01:44:00.503810: 0000 56 53 3b VS;
2019-12-23:01:44:00.503842: read_string called
2019-12-23:01:44:02.505941: read_string(): Timed out 2.2051 seconds after 0 chars
2019-12-23:01:44:02.506007: cmd_str = VS;
2019-12-23:01:44:02.506040: write_block called
2019-12-23:01:44:02.506099: write_block(): TX 3 bytes
2019-12-23:01:44:02.506140: 0000 56 53 3b VS;
2019-12-23:01:44:02.506172: read_string called
2019-12-23:01:44:04.508002: read_string(): Timed out 2.1784 seconds after 0 chars
2019-12-23:01:44:04.508067: cmd_str = VS;
2019-12-23:01:44:04.508101: write_block called
2019-12-23:01:44:04.508160: write_block(): TX 3 bytes
2019-12-23:01:44:04.508200: 0000 56 53 3b VS;
2019-12-23:01:44:04.508232: read_string called
2019-12-23:01:44:06.509567: read_string(): Timed out 2.1287 seconds after 0 chars
Opened rig model 128, 'FT-950'
2019-12-23:01:44:06.509714: rig_strstatus called
2019-12-23:01:44:06.509782: rig_strstatus called
2019-12-23:01:44:06.509826: Backend version: 0.24.2, Status: Stable
2019-12-23:01:44:06.509887: rigctl_parse: debug1
2019-12-23:01:44:06.509922: rigctl_parse: debug3
2019-12-23:01:44:06.509955: rigctl_parse: debug5
2019-12-23:01:44:06.509988: rigctl_parse: debug10
2019-12-23:01:44:06.510093: rig_set_powerstat called
2019-12-23:01:44:06.510132: newcat_set_powerstat called
2019-12-23:01:44:06.510166: newcat_valid_command called
2019-12-23:01:44:06.510200: newcat_valid_command PS
2019-12-23:01:44:06.510241: write_block called
2019-12-23:01:44:06.510303: write_block(): TX 4 bytes
2019-12-23:01:44:06.510344: 0000 50 53 31 3b PS1;
2019-12-23:01:44:08.010555: write_block called
2019-12-23:01:44:08.010653: write_block(): TX 4 bytes
2019-12-23:01:44:08.010697: 0000 50 53 31 3b PS1;
2019-12-23:01:44:08.010793: rig_close called
2019-12-23:01:44:08.010826: newcat_close called
2019-12-23:01:44:08.010884: port_close called
2019-12-23:01:44:08.010922: ser_close called
2019-12-23:01:44:08.010992: ser_close: restoring options
2019-12-23:01:44:08.015034: rig_cleanup called
2019-12-23:01:44:08.015095: newcat_cleanup called

Using this command with a TS-590S:

rigctl -m 231 -r /dev/ttyUSB0 -s 115200 \set_powerstat 1

fails with a communications timed out error. \set_powerstat 0 works fine once the radio is on. \set_powerstat 1 works when used from 'Rig command:'.

Changing the radio model to TS-950SDX, 213, works for power on with the 590S. If the 950SDX power on code could be moved to the 950S it should fix the problem.

This is with the Linux build on a Raspberry Pi. It does not work on earlier versions back to 3.3.

--Howard

icom_set_mode_with_data calls icom_set_mode, passing the filter width through, and then does a data mode (1A 06, except on IC-7200) call to set data mode to 0 or 1 depending on whether the mode was a PKT one.

The problem is that (at least on the 7300 and 7610, and probably on most newer rigs), the filter width passed to the "set mode" command only affects the non-data filter width, and to change the data filter width, one must pass a filter width to the 1A 06 command. Since hamlib omits this parameter, the width is never changed for packet modes.

It seems easy enough to drag a call to rig2icom_mode/r2i_mode into icom_set_mode_with_data to get the proper width and then pass it along to the datamode command, but perhaps a refactor is in order — should there be one function which outputs icmode/icmode_ext/datamode/datamode_ext and the whole sequence keyed off of those?

Also, to research: are there rigs that support 1A 06, but where it doesn't have a second byte for filter width?

When I run ./configure it can not interpret the output of gcc v7.3.0 correctly.
Below is from configure.log

configure:3617: checking for C compiler version
configure:3626: gcc --version >&5
gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3637: $? = 0
configure:3626: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-27ubuntu118.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu118.04)
configure:3637: $? = 0
configure:3626: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3637: $? = 1
configure:3626: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'; did you mean '--version'?
gcc: fatal error: no input files
compilation terminated.

A user on the Raspberry-Pi-for-HAMs list is trying to use the Qsstv program on a Raspberry Pi. He'd like to use one of the GPIO pins for PTT instead of say the RTS line on a serial port which seems like a good idea. Qsstv doesn't support GPIO pins natively but it DOES support hamlib. My question or request to the group is if GPIO pin control could be added into Hamlib. I think this could be pretty valuable to do various controls of both:

• INPUT: Get status of things like DCD, position, whatever

• OUTPUT: PTT, automate rotators turning

Seems like a good automation interface to me. Possible?

--David

I am trying to use rigmem to save/change the memory of IC-746Pro on macOS 10.14. The radio is marked as stable in documentation therefore this function should work.

I am using the latest commit on master and the following OS
macOS 10.14.6 18G87
Xcode 10.3 10G8

Command

./tests/rigmem -m 346 -r /dev/cu.usbserial-14120 -a save test.csv -vvvvvv -c 0x66

• rigmem_log.txt contains the log of the above command
• mem_read_bin.txt contains a binary serial dump of a program that works correctly reading all memory from the radio

At requests I can do more tests or test patches.

Thanks for the great work that you have done in these years!

why don't release a new version?
thanks

Is the FT-818 expected to work with hamlib-3.3? I figured it'd be similar enough to the FT-817 that it'd just work, but my brief testing on the command line didn't give any positive results. I was unable to get/set the frequency, for instance. I have the hardware, free time, and coding ability to work on this if needed. I'd just need some pointers for how to get started. Thanks!

Yaesu chose to change the way the PC command works. On the FT-450 the range is 000-255.
On the FT-450D the range is 005-100 (the actual power in watts). There may be other changes,
but I haven't found any yet.

The two rigs can be distinguished by what the ID command returns:
FT-450: 0241
FT-450D: 0244

Question: Should we create an entirely new rig for the 450D, or
should we just check which is which in newcat.c and handle the quirk there?

Brian W9BGL

im no programmer, i just want to get wsjt working with the ft757gx.

i see the patch by mike but i have totally NO IDEA what to do with it or how to use it.

can anyone help with DUMMY instructions?

I tried following the install guide and it just didnt work.

Hi Folks,

I am testing the latest beta code and have run into a problem with the get_level function on the TS-590S. This problem does not exist on version 3.3. Hamlib was built on a Raspberry Pi Buster. A segmentation fault results for STRENGTH and SQL (at least).

Here is a debug dump:

pi@rigpi4:~ $ rigctl -m 231 -r /dev/ttyUSB0 -s 115200 -vvvvv
rigctl, Hamlib 4.0~git
Report bugs to [email protected]

rig_init called
initrigs4_kenwood called
rig_register called
rig_register: rig_register (213)
rig_register called
rig_register: rig_register (201)
rig_register called
rig_register: rig_register (225)
rig_register called
rig_register: rig_register (203)
rig_register called
rig_register: rig_register (204)
rig_register called
rig_register: rig_register (216)
rig_register called
rig_register: rig_register (224)
rig_register called
rig_register: rig_register (205)
rig_register called
rig_register: rig_register (207)
rig_register called
rig_register: rig_register (209)
rig_register called
rig_register: rig_register (210)
rig_register called
rig_register: rig_register (222)
rig_register called
rig_register: rig_register (214)
rig_register called
rig_register: rig_register (230)
rig_register called
rig_register: rig_register (221)
rig_register called
rig_register: rig_register (229)
rig_register called
rig_register: rig_register (243)
rig_register called
rig_register: rig_register (244)
rig_register called
rig_register: rig_register (245)
rig_register called
rig_register: rig_register (238)
rig_register called
rig_register: rig_register (202)
rig_register called
rig_register: rig_register (211)
rig_register called
rig_register: rig_register (206)
rig_register called
rig_register: rig_register (208)
rig_register called
rig_register: rig_register (215)
rig_register called
rig_register: rig_register (226)
rig_register called
rig_register: rig_register (217)
rig_register called
rig_register: rig_register (233)
rig_register called
rig_register: rig_register (242)
rig_register called
rig_register: rig_register (220)
rig_register called
rig_register: rig_register (223)
rig_register called
rig_register: rig_register (227)
rig_register called
rig_register: rig_register (234)
rig_register called
rig_register: rig_register (231)
rig_register called
rig_register: rig_register (239)
rig_register called
rig_register: rig_register (237)
rig_register called
rig_register: rig_register (228)
rig_register called
rig_register: rig_register (219)
rig_register called
rig_register: rig_register (232)
rig_register called
rig_register: rig_register (236)
rig_register called
rig_register: rig_register (240)
rig_register called
rig_register: rig_register (241)
kenwood_init called, version 1.3
kenwood_init: if_len = 37
rig_open called
port_open called
serial_open called
serial_setup called
serial_flush called
serial_flush: tcflush
kenwood_open called
kenwood_transaction called
kenwood_transaction: cmdstr = FV
serial_flush called
serial_flush: tcflush
write_block called
write_block(): TX 3 bytes
0000 46 56 3b FV;
read_string called
read_string(): RX 7 characters
0000 46 56 32 2e 30 34 3b FV2.04;
kenwood_open: found f/w version 2.04
kenwood_get_id called
kenwood_transaction called
kenwood_transaction: cmdstr = ID
serial_flush called
serial_flush: tcflush
write_block called
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string called
read_string(): RX 6 characters
0000 49 44 30 32 31 3b ID021;
kenwood_open: found match 021
kenwood_get_trn called
kenwood_safe_transaction called
kenwood_transaction called
kenwood_transaction: cmdstr = AI
serial_flush called
serial_flush: tcflush
write_block called
write_block(): TX 3 bytes
0000 41 49 3b AI;
read_string called
read_string(): RX 4 characters
0000 41 49 30 3b AI0;
kenwood_set_trn called
kenwood_transaction called
kenwood_transaction: cmdstr = AI0
serial_flush called
serial_flush: tcflush
write_block called
write_block(): TX 4 bytes
0000 41 49 30 3b AI0;
write_block called
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string called
read_string(): RX 6 characters
0000 49 44 30 32 31 3b ID021;
kenwood_get_split_vfo_if called
kenwood_get_if called
kenwood_safe_transaction called
kenwood_transaction called
kenwood_transaction: cmdstr = IF
serial_flush called
serial_flush: tcflush
write_block called
write_block(): TX 3 bytes
0000 49 46 3b IF;
read_string called
read_string(): RX 38 characters
0000 49 46 30 30 30 30 37 31 39 30 39 39 30 20 20 20 IF00007190990
0010 20 20 20 30 30 30 30 30 30 30 30 32 30 31 30 30 0000000020100
0020 30 30 30 38 30 3b 00080;
rig_strvfo called
rig_strvfo called
kenwood_get_split_vfo_if: priv->tx_vfo=VFOA
rig_strvfo called
rig_strvfo called
kenwood_open: priv->tx_vfo=VFOA
rig_get_vfo called
kenwood_get_vfo_if called
kenwood_get_if called
kenwood_safe_transaction called
kenwood_transaction called
kenwood_transaction: cmdstr = IF
serial_flush called
serial_flush: tcflush
write_block called
write_block(): TX 3 bytes
0000 49 46 3b IF;
read_string called
read_string(): RX 38 characters
0000 49 46 30 30 30 30 37 31 39 30 39 39 30 20 20 20 IF00007190990
0010 20 20 20 30 30 30 30 30 30 30 30 32 30 31 30 30 0000000020100
0020 30 30 30 38 30 3b 00080;
rig_strvfo called
rig_strvfo called
kenwood_get_vfo_if: priv->tx_vfo=VFOA
Opened rig model 231, 'TS-590S'
rig_strstatus called
rig_strstatus called
Backend version: 1.3.2, Status: Stable
Rig command: \get_level
Level: STRENGTH
rig_parse_level called
rig_has_get_level called
rig_get_level called
rig_has_get_level called
ts590_get_level called
rig_get_level called
rig_has_get_level called

.....several hundred more repetitions....

Segmentation fault
pi@rigpi4:~ $

Thanks for your help! Looking forward to official release.

Howard W6HN

I get different values of signal strength when I run from command line and different with rigctl cli
Example:
dimitris@dimitris:~ radio$ rigctl -m 2 -r localhost l STRENGTH
16
dimitris@dimitris:~ radio$ rigctl

Rig command: l STRENGTH
Level Value: -28

I use a yaesu ft-857d and Ubuntu 18.04 with rigctl, Hamlib 3.1

With the FT-950 tuned to 7.125 MHz LSB, rigctl m command returns USB. The debug log shows MD01; which should be LSB. Here is the debug log:

Radio is set to 7.251MHz LSB

Rig command: m
rigctl_parse: debug1
rigctl_parse: debug5
rigctl_parse: debug10
rig_get_mode called
newcat_get_mode called
newcat_valid_command called
newcat_valid_command MD
rig_strvfo called
rig_strvfo called
newcat_set_vfo_from_alias: alias vfo = currVFO
newcat_get_mode: cmd_str = MD0;
cmd_str = MD0;
write_block called
write_block(): TX 4 bytes
0000 4d 44 30 3b MD0;
read_string called
read_string(): RX 5 characters
0000 4d 44 30 31 3b MD01;
newcat_get_cmd: read count = 5, ret_data = MD01;
rig_passband_normal called
newcat_get_rx_bandwidth called
newcat_valid_command called
newcat_valid_command SH
rig_strvfo called
rig_strvfo called
newcat_set_vfo_from_alias: alias vfo = currVFO
cmd_str = SH0;
write_block called
write_block(): TX 4 bytes
0000 53 48 30 3b SH0;
read_string called
read_string(): RX 6 characters
0000 53 48 30 31 33 3b SH013;
newcat_get_cmd: read count = 6, ret_data = SH013;
Mode: USB
Passband: 2400

Giving the Rig command w \0x4d\0x44\0x30\0x32\0x3b to change to USB, according to the CAT manual, I get:

Rig command: m
rigctl_parse: debug1
rigctl_parse: debug5
rigctl_parse: debug10
rig_get_mode called
newcat_get_mode called
newcat_valid_command called
newcat_valid_command MD
rig_strvfo called
rig_strvfo called
newcat_set_vfo_from_alias: alias vfo = currVFO
newcat_get_mode: cmd_str = MD0;
cmd_str = MD0;
write_block called
write_block(): TX 4 bytes
0000 4d 44 30 3b MD0;
read_string called
read_string(): RX 5 characters
0000 4d 44 30 32 3b MD02;
newcat_get_cmd: read count = 5, ret_data = MD02;
rig_passband_normal called
newcat_get_rx_bandwidth called
newcat_valid_command called
newcat_valid_command SH
rig_strvfo called
rig_strvfo called
newcat_set_vfo_from_alias: alias vfo = currVFO
cmd_str = SH0;
write_block called
write_block(): TX 4 bytes
0000 53 48 30 3b SH0;
read_string called
read_string(): RX 6 characters
0000 53 48 30 31 33 3b SH013;
newcat_get_cmd: read count = 6, ret_data = SH013;
Mode: LSB
Passband: 2400

Thanks!

--Howard W6HN

I cannot continue a connection to my TS-2000 (using -m 214) because of a communication timeout. HamLib seems to initially connect and the PC connection indicator comes on my TS-2000. Then it goes away after a brief time (the rigctl also disconnects and returns the command line with the error text). There is no such problem when I use the TS-440 description with rigctl (even though I am using a TS-2000). I can control the TS-2000 using the TS-440 device description (e.g. change frequency), staying connected indefinitely. However, I want to use this on VHF/UHF where the TS-440 doesn't go, There is an error if I try to commanded it to 435MHz using the TS-440 device description. I have no communication problems with Omnirig, WSJT-x or Ham Radio Deluxe. The problem seems unique to HamLib and I don't remember having this problem with an older version of HamLib. Is there a problem with the TS-2000 definition?

Hello!
I m using RQUAD USB Interface Rotor Card with Yaesu G450A rotator.
http://www.quad.ru/production/rotator.php
602 Yaesu/Kenpro GS-232

Look this:

r0au@rpi3:~$ rotctl --model=602 --rot-file=/dev/rotator --serial-speed=9600 -C serial_handshake=Hardware,post_write_delay=10,timeout=1000,retry=0 -vvvvv
rotctl, Hamlib 3.2
Report bugs to [email protected]

rot_init called
initrots3_gs232a called
rot_register (601)
rot_register (603)
rot_register (602)
rot_register (604)
rot_token_lookup called
rot_confparam_lookup called
rot_set_conf called
rot_confparam_lookup called
rot_set_conf: serial_handshake='Hardware'
frontrot_set_conf called
rot_token_lookup called
rot_confparam_lookup called
rot_set_conf called
rot_confparam_lookup called
rot_set_conf: post_write_delay='10'
frontrot_set_conf called
rot_token_lookup called
rot_confparam_lookup called
rot_set_conf called
rot_confparam_lookup called
rot_set_conf: timeout='1000'
frontrot_set_conf called
rot_token_lookup called
rot_confparam_lookup called
rot_set_conf called
rot_confparam_lookup called
rot_set_conf: retry='0'
frontrot_set_conf called
rot_open called
serial_open called
serial_setup called
Opened rot model 602, 'GS-232'
rig_strstatus called
Backend version: 0.1, Status: Beta

Rotator command: p
rot_get_position called
gs232_rot_get_position called
serial_flush called
write_block called
write_block(): TX 3 bytes
0000 43 32 0d C2.
read_string called
read_string(): RX 6 characters
0000 2b 30 31 33 36 0d +0136.
Azimuth: 163242760729689631064600000529361272832.000000

=============================================
RX 6 Charaster - +0136 - it is normal real azimuth.
But in Azimuth - error )
I think, error in parsing in gs232.c

Can you fix it?
Thanks!
73 de R0AU
mailto [email protected]

Hello,
I would love to see support for Yaesus new FTDX11D.

73

Since two days I get errors after starting WSJT-X (version 2.1.0) running on my Win10 PC which is connected to my FT-991A.
I am using this configuration already since 2 months without any problems. The mentioned problem started last sunday after I made a QSO in the mode C4FM. I tried to start WSJT-X again but got a error message HAMLib could not read the mode. In the first place I was not aware the this probably had to do with the C4FM-mode I selected on my FT-991a. So after some try and error I reset my config in WSJT-X and reconfigured it. Still the same error message refering to HAMLib. So I decided to remove HamLib and reinstalled it with version 3.3.

All com-ports and as well as the audio interface work properly. And are not reinstalled. Als Windows does not show any disconnection of the comports. No hardware has been changed. USB cable is OK and provided with several RF beads MIX31.

I googled and found more same problems that rever to this HamLib IO error.
Please help!
73's PA3VOS

Running rigctl for IC7100 (rig 341), the ci-v address output is not the value in priv_caps. If I use the -c switch with the correct value, that works OK. If I edit the value in ic7100.c, it still outputs the same wrong value. FYI, 0x88 is the correct value - 0x34 is the value that is output.

My fork is synced with the latest mdblack fork.

Good afternoon;

I am receiving an error when attempting to configure a Yaesu FT-900 in WSJT-X.

My settings are as follows:

• Baud: 4800
• Data Bits: 8
• Stop Bits: Two
• Handshake: None
• PTT Method: CAT
• Mode: USB
• Split Operation: None
• Polling Interval: 1s

The error I am receiving is:
"Rig failure. Hamlib error: Invalid parameter while testing getting current VFO"

I am seeing the "CAT" indicator appearing on screen, which at least indicates that the radio is seeing the DTR signal, but I don't have any other information beyond that.

I attempted to run rigctl with the FT-900 (radio ID 113) and received this:

> .\rigctl -m 113 -r COM11 -s 4800 f m t
get_freq: error = Invalid parameter
get_mode: error = Communication timed out
0

Note that during the first part (i.e. "get_freq"), the "CAT" indicator on the FT-900 lit up, suggesting that it recognized a command.

With the many changes taking place I thought it would be time to test the bindings. So far I have tested Perl with success. Next in line was Python and the build went fine but now I'm seeing the following run time error:

$ python pytest.py 
Traceback (most recent call last):
  File "pytest.py", line 11, in <module>
    import Hamlib
  File "/home/nate/local/lib/python2.7/site-packages/Hamlib.py", line 17, in <module>
    _Hamlib = swig_import_helper()
  File "/home/nate/local/lib/python2.7/site-packages/Hamlib.py", line 16, in swig_import_helper
    return importlib.import_module('_Hamlib')
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
ImportError: /home/nate/local/lib/python2.7/site-packages/_Hamlib.so: undefined symbol: rig_mem_count

Looking for rig_mem_count I see it occurs in only two places in the current master branch:

$ git grep rig_mem_count
rig.swg:449:            return rig_mem_count(self->rig);
rig.swg:563:    int nb_chans = rig_mem_count(self->rig);

Oddly, these are also the only references to rig_mem_count in the Hamlib-3.2 and Hamlib-3.3 branches. So far as I know, the Python binding worked in those releases.

Just to be sure, I recompiled for a system installation in /usr/local and get the same error:

$ python pytest.py 
Traceback (most recent call last):
  File "pytest.py", line 11, in <module>
    import Hamlib
  File "/usr/local/lib/python2.7/dist-packages/Hamlib.py", line 17, in <module>
    _Hamlib = swig_import_helper()
  File "/usr/local/lib/python2.7/dist-packages/Hamlib.py", line 16, in swig_import_helper
    return importlib.import_module('_Hamlib')
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
ImportError: /usr/local/lib/python2.7/dist-packages/_Hamlib.so: undefined symbol: rig_mem_count

Hi Folks,
I have a G-5500 rotator and GS-232B controller. I am driving the controller through a USB->RS232 converter (Prolific pl2303 converter) from a raspberry pi.

When I try driving the rotator with rotctl, the rotator moves, but stutters (i.e. what should be a single drive to the new az/el is broken up). When I drive the rotator directly via the GS-232B (using screen /dev/ttyUSB0 to directly use the serial port), there is no such problem.

the output of rotctl is below:

mypi:~/Hamlib/tests $ ./rotctl -m 603 -r /dev/ttyUSB0 -vvvvv
rotctl, Hamlib 4.0~git
Report bugs to <[email protected]>

rot_init called
initrots4_gs232a called
rot_register (601)
rot_register (602)
rot_register (603)
rot_register (604)
rot_register (605)
rot_register (606)
rot_register (607)
rot_register (608)
rot_open called
serial_open called
serial_setup called
serial_flush called
Opened rot model 603, 'GS-232B'
rig_strstatus called
Backend version: 0.4, Status: Beta

Rotator command: p
rot_get_position called
gs232b_rot_get_position called
serial_flush called
write_block called
write_block(): TX 3 bytes
0000    43 32 0d                                            C2.             
read_string called
read_string(): RX 15 characters
0000    41 5a 3d 31 38 30 20 20 45 4c 3d 30 39 30 0d        AZ=180  EL=090. 
gs232b_rot_get_position: (az, el) = (180.0, 90.0)
Azimuth: 180.000000
Elevation: 90.000000

Rotator command: P 180 100
Azimuth: Elevation: rot_set_position called
gs232b_rot_set_position called: 180.000000 100.000000
serial_flush called
write_block called
write_block(): TX 9 bytes
0000    57 31 38 30 20 31 30 30 0d                          W180 100.       
read_string called
read_string(): Timed out 0.400488 seconds after 0 chars
serial_flush called
write_block called
write_block(): TX 9 bytes
0000    57 31 38 30 20 31 30 30 0d                          W180 100.       
read_string called
read_string(): Timed out 0.400471 seconds after 0 chars
serial_flush called
write_block called
write_block(): TX 9 bytes
0000    57 31 38 30 20 31 30 30 0d                          W180 100.       
read_string called
read_string(): Timed out 0.400485 seconds after 0 chars
serial_flush called
write_block called
write_block(): TX 9 bytes
0000    57 31 38 30 20 31 30 30 0d                          W180 100.       
read_string called
read_string(): Timed out 0.400513 seconds after 0 chars
set_pos: error = Communication timed out

Rotator command: q
rot_close called
ser_close called
ser_close: restoring options
rot_cleanup called

Having looked through the code a bit, the core of the command seems to be the gs232b_transaction() function, which writes a command then waits for a reply. The problem, as far as I can tell, is that the GS-232B does not reply at all when given a pointing command, it only replies when it is given a "get" type command. (This can be easily verified by using the direct serial console.) Each time the wait for the reply times out, it does a serial flush and re-issues the command, which makes the controller stutter.

So question is: have I missed something in the use of rotctl here? Or maybe something has changed in the behaviour of the GS-232B compared to the past?

Thanks,
Randall

If I have rigctld running against a USB port on Linux and I then disconnect the radio from that USB port. When I then go to query rigctld via netcat it returns some kind of cached data. I would expect it to return an error indication back to the client code at the very least. I notice the server side daemon does notice somethings a miss on it's verbose output.

The FT-991 S-meter needs help.

S-0 = -54 (correct)
S-9 = 1280 (not correct)
S-9+25 = 1620 (not correct)

Thanks!

--Howard W6HN

Is it possible to add a command to read received signal level in dBm ?
There is a command to read in dBm in the manual,
but i don't know how to implement it.

I'm using rigctl 3.3 and I realize the TH-D72a driver is ALPHA but I was doing some testing for an upcoming project things didn't get off to a good start.

I start things off with:
rigctld -m 233 -r /dev/ttyUSB0 -s9600 -vvvvv

that seems to start ok, and I'm seeing the typical calls go by and no error indications.

Then I launch gpredict, where I have the radio configured in preferences as Duplex TRX, PTT Status=none, and VFO up/down is MAIN up/SUB down.

When I bring up the GPredict Radio Control panel and click Engage, it connects to rigctld but after several attempts and some errors, it fails and disconnects from rigctld.

Thanks
rigctld_output.txt

I have found that Hamlib (and indeed other software) does not handle FT-900 CAT commands properly.

The FT-900 will always return the command you send it as the first 5 bytes of the output.

For example, the following command (note reversed order, in hex): 00 00 00 03 10
will yield the following in my case:

00 00 00 03 10 06 16 20 76 00 00 01 04 02 04 0B BF D0 00 00 00 04 00

Note that the first five bytes are equivalent to the command I sent, and is followed with 18 additional bytes containing the VFO data, totaling 23 bytes.

For your development purposes, this is the radio configuration I had at the time:

VFO-A = 14.50102 MHz USB
VFO-B = 7.70000 MHz LSB

This matches the data provided on page 46 of the FT-900 manual (reference http://biara.org/wp-content/uploads/2017/08/2D-FT-900.pdf)

I don't believe that this is being handled in /yaesu/FT900.c -- ft900_get_update_data doesn't handle it at all.

In particular, reference ft900.c line 508: It explicitly sets the count as FT900_VFO_DATA_LENGTH, defined here. On line 528, ft900_get_update_data is called, which is defined on line 1639. The bug exists on line 1662 and beyond: read_block only reads the number of octets defined under the parameter rl, which we saw before was defined as 18. In this instance, the resultant decoded frequency will always be incorrect, since the data read starts with 00 00 00 03 10 -- as the code stands, the routine will decode bytes 1-3, 00 00 03 = 30 Hz. Since this is outside of the RX and TX under rx_range_listN and tx_range_listN, this will ALWAYS generate an error.

I don't see anywhere in the manual where this is referenced, but this is the behavior of my own FT-900 as it stands. Perhaps for safety, only read the 18 bytes and check whether the first 5 match the command that was just sent, and if so, read an extra 5 bytes?

Please let me know if you need any testing with the FT-900. I am happy to help.

Hi,

Is it possible to send multiple commands in one request? I have had some success doing so by seperating commands with a space however it doesn't like if you then mix in commands that require an argument. The verbose debug output of rigctld says unknown command a few times.

I tried looking at the manpages for any delim char for multiple arguments but there wasn't anything I could find.

Maybe this just isn't intended functionallity and I should stick to single commands at a time when querying rigctld using netcat?

Hello,

Is there a simple way for setting an offset in the azimuth? (for a case where an existing antena/rotor is installed with a misalignment).

Mechanically fixing would be better, but considering that it can not be done, how could I fix this in software?

I intend to use Gpredict + hamlib to control the rotator, so if I could configure one of them, without writing new code, would be preferable. Or at least make a patch/upstream, so no extra software module need to be maintained.

Thank you,

Mario

Hi!

Noticed that the hamlib with ts-590 is not reporting the split frequency via cat when transmitting. If you press TF-SET on the rig, the frequency is reported correctly.

Omnirig and dx commander are reporting the frequency correctly when transmitting, so maybe it's just a simple definition file issue. Hamlib is used in RF-KIT ampliler for cat following, so the split is not reported for the atu etc.

Thanks in advance if someone has time to take a look.

Linux Mint Mate 19.3 64
Latest hamlib 3.3 compiled installed fresh.
Together with WSJT-X, JTDX no cat possible
(both have problems with the interface - altough I set same parameter like in FLDigi - FLDigi runs UFB)

says only: Hamlib error: Communication timed out while getting current VFO frequency

btw - same issue on WIN10

73 Erich

cannot use WSJT software due to "hamlib error switching vfo's" message with FT-897. can anyone suggest a fix for this? i have justed tried to install version 3.3 for win64 but get errors trying to install .dll files. i cannot find any Hamlib folder/files on the PC to even look at them. Please any suggestions would be gratefully welcomed otherwise there will be a radio on sale soon.

very frustrated,
Colin G0ODR

I'm in the process of fixing implementation of many Icom CI-V commands that currently either do not work at all or work incorrectly when compared to the Hamlib API spec.

However, there's one particular command that is difficult to implement with Icom radios and that is the manual notch frequency (RIG_LEVEL_NOTCHF). Based on Icom radio manuals I've read (and I've checked most of the modern ones >= IC-7000), the scale for adjusting manual notch frequency is simply 0 to 255 without any indication of the actual frequency.

After all, the Hamlib API specifies RIG_LEVEL_NOTCHF as:

    RIG_LEVEL_NOTCHF =      (1 << 15),      /*!< \c NOTCHF -- Notch Freq., arg int (Hz) */

indicating that the argument should be the frequency in Hz.

I'm wondering if anyone knows better whether the notch frequency value for Icom rigs actually corresponds to a specific frequency or if it is relative to, for example, the filter width currently selected?

Hello, I am very involved in many educational projects with the
International Space Station.

In these projects, I need to use "rigctld" to control my receiver and
correct Doppler effects.

I use the ICOM PCR-100 model with GPredict software. However, with this
receiver, when you take control of it with HAMLib, the volume of the
output sound is too low.

To control the receiver, I use this command on linux :

rigctld -v -m 402 -r /dev/ttyUSB0 -s 38400 -t 4532 -C stop_bits=1

And a kind of this one on Windows :

"C:Program Files\HAMLib\rigctld.exe" -v -m 402 -r /dev/ttyUSB0 -s 38400
-t 4532 -C stop_bits=1

To increase the output volume on Linux, the only way I've found is to
open a second terminal window and to use this command to set up the volume to the maximum :

echo 'L AF 1' | nc localhost 4532

But I didn't find any way to do the same on Windows.

So here are my questions : How can we take control of the receiver with
the output volume set to the maximum without having to open a second terminal window and using another command line ? If there is no way to do that, how can I use the same command on Windows to set the volume at its maximum ?

Thanks for the answer.

Best regards, David.

Testing build of current master I hit a format-security error.
This is in Mageia (dev) branch. I could normally patch these errors for printf but since the fix would extend the string then I have no idea how to handle this for snprintf() - I'm not a programmer, just the package maintainer ;)

`rotctl_parse.c:1012:13: error: format not a string literal and no format arguments [-Werror=format-security]
1012 | snprintf(cmd_name, sizeof(cmd_name), parsed_input[0] + 1);

Thanks,
Barry

I merged the latest upstream with my fork & rebuilt. Now I get "rig_open: error = Invalid parameter" when I run rigctl.

Attached is my console output showing the previous rigctl startup, the rebuild and then the resulting rigctl startup.
hamlib console log.zip

Yaesu FT920 does not respond correctly when controlled by a combo of N1MM+ and WSJT-X. WSJT-X uses HAMLIB data for radio control.

When using MSK144 mode of WSJT-X and operating in SPLIT mode (CQing on the default MSK144 frequency and listening elsewhere) the FT920 switches frequency properly only once and then remains on the receive frequency. This is not new - I first noticed this behavior when WSJT was in V1.9.

Also, when 'running' stations on FT8, radio will randomly switch to some 2 MHz frequency. and crash WSJT-X.

I will supply any further data as needed - tell me what you need.

Jay W9RM

Hi nice team,
would it ever planned that setting CTCSS with rigctl is possible. WIth 3.3 message not supported appears
would be nice for sat op
tnx
73 Alex, OE3JTB

Using the latest branch, Raspberry Pi 3B+ and 4B, Buster. Rigctl or rigctld.

Thanks!

--Howard W6HN

rig_init called
initrigs4_icom: _init called
rig_register called
rig_register: rig_register (355)
rig_register called
rig_register: rig_register (309)
rig_register called
rig_register: rig_register (310)
rig_register called
rig_register: rig_register (311)
rig_register called
rig_register: rig_register (313)
rig_register called
rig_register: rig_register (314)
rig_register called
rig_register: rig_register (315)
rig_register called
rig_register: rig_register (319)
rig_register called
rig_register: rig_register (320)
rig_register called
rig_register: rig_register (321)
rig_register called
rig_register: rig_register (322)
rig_register called
rig_register: rig_register (367)
rig_register called
rig_register: rig_register (323)
rig_register called
rig_register: rig_register (346)
rig_register called
rig_register: rig_register (324)
rig_register called
rig_register: rig_register (328)
rig_register called
rig_register: rig_register (330)
rig_register called
rig_register: rig_register (326)
rig_register called
rig_register: rig_register (327)
rig_register called
rig_register: rig_register (347)
rig_register called
rig_register: rig_register (357)
rig_register called
rig_register: rig_register (363)
rig_register called
rig_register: rig_register (329)
rig_register called
rig_register: rig_register (362)
rig_register called
rig_register: rig_register (345)
rig_register called
rig_register: rig_register (356)
rig_register called
rig_register: rig_register (375)
rig_register called
rig_register: rig_register (360)
rig_register called
rig_register: rig_register (370)
rig_register called
rig_register: rig_register (361)
rig_register called
rig_register: rig_register (373)
rig_register called
rig_register: rig_register (378)
rig_register called
rig_register: rig_register (331)
rig_register called
rig_register: rig_register (312)
rig_register called
rig_register: rig_register (316)
rig_register called
rig_register: rig_register (332)
rig_register called
rig_register: rig_register (334)
rig_register called
rig_register: rig_register (344)
rig_register called
rig_register: rig_register (368)
rig_register called
rig_register: rig_register (335)
rig_register called
rig_register: rig_register (381)
rig_register called
rig_register: rig_register (369)
rig_register called
rig_register: rig_register (377)
rig_register called
rig_register: rig_register (336)
rig_register called
rig_register: rig_register (358)
rig_register called
rig_register: rig_register (380)
rig_register called
rig_register: rig_register (337)
rig_register called
rig_register: rig_register (338)
rig_register called
rig_register: rig_register (339)
rig_register called
rig_register: rig_register (340)
rig_register called
rig_register: rig_register (341)
rig_register called
rig_register: rig_register (342)
rig_register called
rig_register: rig_register (379)
rig_register called
rig_register: rig_register (343)
rig_register called
rig_register: rig_register (366)
rig_register called
rig_register: rig_register (303)
rig_register called
rig_register: rig_register (304)
rig_register called
rig_register: rig_register (306)
rig_register called
rig_register: rig_register (307)
rig_register called
rig_register: rig_register (302)
rig_register called
rig_register: rig_register (352)
rig_register called
rig_register: rig_register (353)
rig_register called
rig_register: rig_register (351)
rig_register called
rig_register: rig_register (364)
rig_register called
rig_register: rig_register (365)
rig_register called
rig_register: rig_register (354)
rig_register called
rig_register: rig_register (383)
rig_register called
rig_register: rig_register (384)
rig_register called
rig_register: rig_register (382)
rig_register called
rig_register: rig_register (371)
rig_register called
rig_register: rig_register (372)
rig_register called
rig_register: rig_register (374)
rig_register called
rig_register: rig_register (376)
icom_init called
Segmentation fault

My Kenwood TS-590 seems to support the modes RIG_MODE_PKTFM, RIG_MODE_PKTLSB and RIG_MODE_PKTUSB. However, these modes are not defined in kenwood/ts590.c

#define TS590_ALL_MODES (RIG_MODE_AM|RIG_MODE_CW|RIG_MODE_CWR|RIG_MODE_SSB|RIG_MODE_FM|RIG_MODE_RTTY|RIG_MODE_RTTYR)

Should the PKT modes be added to this line or am I missing something?

Hello
The NET rigctl doesn't work on last git version (783ba3e).

Steps to reproduce the behavior:

1. run rigctld -vvvv -m1
2. run rigctl -vvvvv -m2 -r127.0.0.1:4532

It appears the TS-480 needs a TX1 command instead of TX to ensure PTT is keyed from the data port. I need to confirm this so this is a placeholder for this bug.
WSJT-X needs to use VOX (via SignaLink) to key the 480 where CAT should also work.

Hi (my first issue). I'm on Windows trying to build a HamLib.pdf using Cygwin's tool
texi2any and MikTeX with this command in doc.

/bin/texi2any --pdf hamlib.texi

(yes, I have created a doc/version.texi first). But is errors with:

hamlib.texi:52: @menu seen before first @node
hamlib.texi:52: perhaps your @top node should be wrapped in @ifnottex rather than @ifinfo?

But with this simple patch, the HamLib.pdf was created just fine:

--- a/doc/hamlib.texi 2019-10-10 18:09:37
+++ b/doc/hamlib.texi 2019-10-11 08:14:06
@@ -47,7 +47,6 @@

 This manual is for Ham Radio Control Libraries (Hamlib) (version @value{VERSION},
 @value{UPDATED}).
-@end ifnottex

 @menu
 * Copying and Redistribution::
@@ -59,6 +58,7 @@
 * List of Figures::
 * Concept Index::
 @end menu
+@end ifnottex

Does this makes sense?

• GPIO support is left out of man pages
• use examples of how to use hamlib with GPIO pins for PTT do not exist in documentation
• no raspberry pi specific build instructions in the wiki's documentation (nor in the install documentation for compiling for use on a pi)

Reason for update: many hams are turning to Pi's for cheap shack computers. Also many hams do not have the ability to control their rig through a cable (most HT's, older rigs and DIY kits) or otherwise do not want the added overhead (might be backpacking and every extra cable adds weight and a fail point). Most Digital Station setups (see the NW Digital Radio's DRAW/UDRC boards and WB7FHC's Nexus Board for examples) require the use of a GPIO pin to control the PTT on a radio (or radios). I would love to use wspr modes with my pi, but due to the lack of documentation I cannot figure out how to use hamlib to key the rig through a GPIO pin. Also with no steps in recompiling the library for use on the pi I have no way of testing to see if it works.

I'd be happy to help with testing and examples (application specific as well) if you need it.

73
Art - KC7SDA