[DXBase] Kenwood TS-2000 users.

[Brendan Minish]

At 12:33 28/12/2002 -0500, Jack wrote:
>I'm curious about something:
>
>Is there anyone who has written to any of the makers of radios to complain
>to them about their lack of maintaining a standard RS232 interface set of
>commands, sequence, and structure?  If so, what response did you get?


I have raised it verbally with Icom on one occasion however the main issue 
for me with the pro (&pro 2 ) is the missing commands and in particular the 
inability to read the USB_D and LSB-D modes.
The lack of handshaking on the C-IV interface has NOT been an issue with 
ANY software I have tried with any of the Icom radios I have used 
(including commercial marine ones)

The K2 interface does not really handshake either.
One of the K2's designers ( cant remember if Wayne or Eric ) is a DXB user 
so i should imagine that you would have a sympathetic ear there.


>Has anyone complained to them about the constant changing of the RS232
>interface for no good reason except change itself, whenever a new radio is
>introduced?  If so, what response did you get?

Icom don't change much between radios but some features continue to be 
missing, the same basic commands work with my 706 and my 728.

Since radios started remembering the mode separately for each band ( a 
useful feature BTW!) it is only reasonable to expect problems with some 
rigs when the mode command is sent before the frequency data. Luckily it is 
possible to turn this around in the radios.ini file.

Sending the mode before the frequency seems plain wrong to me.


>Has anyone complained to the makers of radios that you are tired of having
>to obtain software changes to the programs that you use every time you
>decide to purchase one of these new radios only to find that the RS232
>interface is different than how it was in previous radios?

DXB does a better job than most with the radios.ini file approach and I am 
happy to write a new entry if I am the first user with a particular radio 
as I have done with the K2. I am also happy to share this file with other 
users.

What I would like to see from the software authors is more control over 
what one can do in the radios.ini file.
Such as.

Error handling (for radio OR software errors)

An option to force DXB to write a logfile of all data sent to and from the 
radio for debugging when making changes to the radios.ini file

Support for extended modes (I.e CW-R etc) which simply would involve DXB 
accepting more than one value as a response for a mode query.

Ability (where available ) to make use of  information concerning which VFO 
is active.

An understanding of Dual watch as well as split. (optionally treat the same 
as split )

The ability (where the radio supports it ) to key CW by sending the 
appropriate ASCII strings to the radio (kenwood TS2000, elecraft K2 and 
probably other recent kenwoods ) along with other support required for for 
this feature.

It would be important to be able to specify the order in which commands are 
used. These changes would require the radios.ini file to undergo an overall 
rewrite. but since most radio files work as they are this would be a fairly 
trivial issue of adding a generic extra bit to each of the existing 
entries. (or even just assuming a generic order where not otherwise defined )

I propose that the radios.ini format continues to define each command 
EXACTLY as is now done and adds support for any user defined commands that 
may be required in the future or to handle certain special features.

After the commands are defined, the strings sent (action definitions) along 
with any additional pauses for replies etc for each action in DXB can be 
defined.

Action definitions should only allow use of the predefined commands (to 
stop things getting messy, don't forget the support for user defined 
commands!) and the built in timing commands such as eoc(100)

CLICKSPOT = GETvfoa, GETmodeA, GETvfob, GETModeB,GetSplit, GetActiveVFO, 
SETVFOA, SETmodeA, SETVFOB, SETmodeB, SETsplit

READ_LOG = GETvfoa, GETmodeA, GETvfob, GETModeB,GetSplit, GetActiveVFO

you get the idea

followed by error handling entries

retries = 3 <-how many retries before annoying the user with an error 
message WHATEVER the cause of the error.
retry_wait = 200  <-how many msec to wait before repeating the command when 
retrying

followed by the debug options
error_log = 0
0= no log, 1 only log errors or retires (including the previously sent 
string), 3 log everything in from rig, 4 log everything out, 5 log all 
commands
put an extra <CR> after each response from the radio to make things easier 
to read

logformat = HEX (or ASCII )

logfilename = whatever.txt (saved in the DXB directory )


Of course the DXB help file would need more information added on how the 
radios.ini file works as well..

>Does anyone plan to write a letter of complaint to the makers of radios
>about this topic?  If not, why?

No, because I don't think it will do any good whatsoever.

Why don't all the major software authors get together and try to define 
some universal standards that they would like to see manufacturers adopt 
and then contact the manufacturers, with new interface protocols on the 
horizon (USB?) now is the time to do this.


>Do you think that it is the obligation of the makers of software to
>constantly modify their code each time a new radio comes out that requires a
>different RS232 interface?  If so, are you willing to pay for this service?
>How much, $30, $50?

lets make this software's use of the radios.ini file more flexible THEN we 
users can do it for ourselves and the designers can get back to designing 
software AND the software will be more future proof.

DXB already does a wonderful job of supporting user defined lists and 
labels why not extend some of this to the rig control side of things in the 
next version.

the first USB radios will probably just emulate seral ports for backwards 
compatibility anyway.
I would rather see an ethernet interface with tcp/ip support on radios than 
USB but that's probably just me..


>Have you ever posted a review for any of these radios such as on eHam and
>mentioned a complaint about the fact that this new radio might be the
>greatest thing since sliced bread, but it has a deficient RS232 interface
>and therefore you don't recommend it for others?

I don't currently post reviews on E-ham and asked for my old reviews to be 
removed since E-ham stated using the user reviews sections for paid product 
placement of rival companies products which is a practise I deplore.

73
Brendan EI6IZ