fix: serial CAT keyed the radio on connect; Xiegu can key on RTS/DTR
Reported on a Xiegu G90. With the blue programming cable — three wires, no modem lines — CAT works perfectly. Behind a DE-19, which carries audio, CAT and PTT, the radio went into transmit the moment OpsLog connected and stayed there. Windows raises DTR and RTS when a serial port is opened, and the DE-19 reads them as PTT; Xiegu's own documentation asks for both low. The CI-V backend has dropped them since it was written, for the same reason on Icom rigs with USB SEND mapped to a line. Xiegu, Yaesu and Kenwood did not. They do now. The second half of the report: WSJT-X through OpsLog's rigctld decoded fine and never transmitted. Nothing was broken in that chain — set_ptt reaches the backend, which sends the CI-V PTT command, which a G90 ignores. That is why Xiegu keys on a hardware line instead. The backend can now do that: Settings → CAT → Xiegu → how the rig is keyed (CI-V / RTS / DTR). Untested here — no G90 in reach. The operator who reported it offered to try.
This commit is contained in:
@@ -1912,6 +1912,7 @@ export namespace main {
|
||||
xiegu_port: string;
|
||||
xiegu_baud: number;
|
||||
xiegu_addr: number;
|
||||
xiegu_ptt_line: string;
|
||||
yaesu_port: string;
|
||||
yaesu_baud: number;
|
||||
kenwood_host: string;
|
||||
@@ -1951,6 +1952,7 @@ export namespace main {
|
||||
this.xiegu_port = source["xiegu_port"];
|
||||
this.xiegu_baud = source["xiegu_baud"];
|
||||
this.xiegu_addr = source["xiegu_addr"];
|
||||
this.xiegu_ptt_line = source["xiegu_ptt_line"];
|
||||
this.yaesu_port = source["yaesu_port"];
|
||||
this.yaesu_baud = source["yaesu_baud"];
|
||||
this.kenwood_host = source["kenwood_host"];
|
||||
|
||||
Reference in New Issue
Block a user