[Hamlib-developer] Hamlib error: Protocol error while setting PTT off

[DK6OV]

Hello hamlib developers,

I am running a SunSDR2 Pro at a Linux-computer. The Linux-software for
the SDR supports rig-control with Kenwood TS-480 commands. I often use
the program wsjt-x, that controls the rig via hamlib. I connect both
programs via “virtual serial cable” (socat).
Most things works well, but setting ptt on and off via cat-command
interrupts the program with "Hamlib error: Protocol error while setting
PTT off".

I made some tests with rigctrl:

./rigctl -vvvvv -m 228 -r /dev/ttyUSB9

rigctl, Hamlib 3.1~git
Report bugs to <hamlib-***@lists.sourceforge.net>

Opened rig model 228, 'TS-480'
Backend version: 0.9.5, Status: Untested

Rig command: T 1
rigctl_parse: input_line: T 1
kenwood_set_ptt called
kenwood_transaction called
kenwood_transaction: cmdstr = TX
write_block(): TX 3 bytes
0000 54 58 3b TX;
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string(): RX 6 characters
0000 49 44 30 32 30 3b ID020;

Rig command: T 0
rigctl_parse: input_line: T 0
kenwood_set_ptt called
kenwood_transaction called
kenwood_transaction: cmdstr = RX
write_block(): TX 3 bytes
0000 52 58 3b RX;
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string(): RX 4 characters
0000 52 58 30 3b RX0;
kenwood_transaction: wrong reply RX for command verification ID
kenwood_transaction: cmdstr = RX
write_block(): TX 3 bytes
0000 52 58 3b RX;
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string(): RX 6 characters
0000 49 44 30 32 30 3b ID020;

As you can see, when changing ptt back to RX, the reply RX0 appears
instead of ID020.

I have a look at the hamlib software an found the reason for that in the
file kenwood.c.

At top of the function kenwood_transaction you wrote:
* data: Buffer for reply string. Can be NULL, indicating that no reply
* is needed and will return with RIG_OK after command was sent.

When switching ptt on and off, the function is called with data=NULL.
But the correct reply from the rig is causing an error.

I deleted the else-part, from line 369 to 387 in kenwood.c.
After recompiling hamlib and wsjt-x there are no more errors when
setting ptt on and off.

Perhaps you can find a better change in the hamlib software, to avoid
that error.

Best regards
Dieter, DK6OV

[Bill Somerville]

Post by DK6OV
0000 52 58 3b RX;
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string(): RX 4 characters
0000 52 58 30 3b RX0;
kenwood_transaction: wrong reply RX for command verification ID
kenwood_transaction: cmdstr = RX

Hi Dieter,

that is defect in the Kenwood emulation. Real Kenwood rigs do not reply
to set commands like "Rx;".

You probably need to raise a defect report with the authors of the SDR
software CAT interface. If it is open source then I can have a quick
look and see why it does that.

BTW most SDR software with Kenwood emulation works best with TS2000 mode
and for some the TS2000 Hamlib backend has special code to support their
quirks.

73
Bill
G4WJS.

[Dieter Röver]

This post might be inappropriate. Click to display it.

[Bill Somerville]

Post by Dieter Röver
Hi Bill,

Post by Bill Somerville
that is defect in the Kenwood emulation. Real Kenwood rigs do not
reply to set commands like "Rx;".

I am confused by that, as I found a description of “PC CONTROL COMMANDS
http://www.radiomanual.info/schemi/TS480_pc_instr.pdf
In this document it looks like the commands for TX and RX replay with an
answer string as my SDR do. So I think I can't ask the developers of the
ExpertSDR2 software to change the cat commands in their program, as they
have done everything correct.
I also tested you advice to use TS2000 for rig control. But that does
not work at all with the SunSDR2 Pro.
73
Dieter
DK6OV

Hi Dieter,

that document is incorrect. The answers to commands like RX; and TX; are
only sent by the rig when the rig is in auto information mode. Hamlib
sends a AI0; command when it first connects to ensure that auto
information mode is turned off.

73
Bill
G4WJS.

------------------------------------------------------------------------------

[Bill Somerville]

Post by Bill Somerville
that document is incorrect.

Actually not incorrect but it neglects to mention that auto info mode
only gives those answer messages. In other Kenwood CAT documentation for
other rigs it is a little clearer but never explicit. What is important
is that the rigs do not provide an answer to RX and TX commands unless
auto info is on. With auto info on the answers are provided unsolicited
when the rig changes between Rx and Tx as well.

73
Bill
G4WJS.

------------------------------------------------------------------------------

[Nate Bargmann]

Post by Bill Somerville
that document is incorrect. The answers to commands like RX; and TX; are
only sent by the rig when the rig is in auto information mode. Hamlib
sends a AI0; command when it first connects to ensure that auto
information mode is turned off.

On that note, last week Wayne, N6KR, started a thread on the Elecraft
Programmers list requesting that programs save the state of AI, then
reset it upon closing the communications channel. The rationale being
that other devices utilize the AI1 setting for their own uses (SteppIR
may be one). It's likely that we should take care to read and save the
setting of AI upon opening the rig and then restore it later. Of
course, a crash of some sort that doesn't allow proper closing of the
rig may leave AI in an undesired state, but that's how it goes.

73, Nate

[Bill Somerville]

Post by Nate Bargmann

Post by Bill Somerville
that document is incorrect. The answers to commands like RX; and TX; are
only sent by the rig when the rig is in auto information mode. Hamlib
sends a AI0; command when it first connects to ensure that auto
information mode is turned off.

On that note, last week Wayne, N6KR, started a thread on the Elecraft
Programmers list requesting that programs save the state of AI, then
reset it upon closing the communications channel. The rationale being
that other devices utilize the AI1 setting for their own uses (SteppIR
may be one). It's likely that we should take care to read and save the
setting of AI upon opening the rig and then restore it later. Of
course, a crash of some sort that doesn't allow proper closing of the
rig may leave AI in an undesired state, but that's how it goes.

Also the rig doesn't save the state either, turning the rig off and on
turns off AI mode.

Given that you cannot expect to keep an application running on the CAT
serial port while another uses it, this request is not reasonable. Any
software that wants AI on should turn it on at start up and any other
software should ensure it is off by turning off at start up. End of story!

Post by Nate Bargmann
73, Nate

73
Bill
G4WJS.

------------------------------------------------------------------------------

[Nate Bargmann]

Post by Bill Somerville
Also the rig doesn't save the state either, turning the rig off and on
turns off AI mode.
Given that you cannot expect to keep an application running on the CAT
serial port while another uses it, this request is not reasonable. Any
software that wants AI on should turn it on at start up and any other
software should ensure it is off by turning off at start up. End of story!

Bill and Patrick,

I am merely passing along the request. Here it is in full:

Date: Thu, 19 Nov 2015 12:51:41 -0800
From: Wayne Burdick <***@elecraft.com>
To: "***@elecraft.com" <***@elecraft.com>
Subject: [Dev] K3/K3S-compatible apps should restore user's "AI" setting
on
exit
X-Mailer: Apple Mail (2.1510)

Hi gang,

The Elecraft K3 and K3S have a CONFIG menu entry called "AUTOINF" that
allows the user to manual assert AI1 for purposes of controlling an
external SteppIR antenna or other device. To do this, the user sets the
menu entry to "AUTO 1". (On a KX3, the setting is "ANT CTRL".)

Some customers who use this feature are finding that specific apps,
including HRD and N1MM, are leaving the radio in AI0 mode on exit.

If possible, apps should check the AI setting of the radio on start-up
and, on exit, restore it. This behavior could be optional, under user
control.

Thanks,
Wayne
N6KR


I did not comment in the thread as my presumption was that Hamlib sets
the K3 to AI0 and left it there.

73, Nate

[Bill Somerville]

Post by Nate Bargmann

Post by Bill Somerville
that document is incorrect. The answers to commands like RX; and TX; are
only sent by the rig when the rig is in auto information mode. Hamlib
sends a AI0; command when it first connects to ensure that auto
information mode is turned off.

On that note, last week Wayne, N6KR, started a thread on the Elecraft
Programmers list requesting that programs save the state of AI, then
reset it upon closing the communications channel. The rationale being
that other devices utilize the AI1 setting for their own uses (SteppIR
may be one). It's likely that we should take care to read and save the
setting of AI upon opening the rig and then restore it later. Of
course, a crash of some sort that doesn't allow proper closing of the
rig may leave AI in an undesired state, but that's how it goes.
73, Nate

I believe applications and devices that monitor CAT traffic will work
just fine watching polling traffic as well as unsolicited AI traffic. I
guess Wayne's request is for that purpose, perhaps he should be talking
to Kenwood about how to change the rig default such that AI is on by
default ( I think the Elecraft rigs do have that). I suppose that a well
behaved monitor device should only have RxD connected and therefore
cannot send an AI1; command itself.

I am happy to code a change to the Kenwood driver to restore AI state
but we should stop at that. For example we (the WSJT-X developers) have
had requests to restore SPLIT, VFO, MODE, ... the list is potentially
large and I don't see good reason for any of them except for AI related
to passive devices.

73
Bill
G4WJS.

------------------------------------------------------------------------------

[Deacon Patrick Ouellette]

If a program is going to depend upon a given configuration, it should set up that configuration to start with or at least verify the proper inital conditions have been set. 
Assuming programs will save and restore changeable parameters in a rig on entey/exit is a recipe for problems. It may be a good practice to save and restore the rig state but no program should depend on it.
73,
Pat NE4PO

[Bill Somerville]

This post might be inappropriate. Click to display it.

[Nate Bargmann]

Good explanation, Bill.

I don't have any of those devices at the moment so cannot test, but
hopefully someone can give some feedback.

Everything looks good with the patch and I'll be pushing it out
momentarily. I think that we can plan this to be a part of the 3.1
release since it is a bit experimental at the moment.

Thanks much!

73, Nate