[DXBase] Kenwood TS-2000 users.

2002年12月28日 23:23:14 -0500

I have tested the mode command being sent before and after the frequency
to the TS-2000 and it will work either way. This radio doesn't seem to care
73 de Tony, KD4K
My Weather Page
http://home.adelphia.net/~tonycash/
My Ham Radio Page
http://home.adelphia.net/~tonycash/kd4k/radio.html
Sawnee Mountain (WB4GQX 147.15 +.600) Repeater Page
http://home.adelphia.net/~tonycash/sawnee/index.html
----- Original Message -----
From: "Brendan Minish" <[email protected]>
To: "Jack" <[email protected]>; <[email protected]>
Sent: Saturday, December 28, 2002 6:39 PM
Subject: Re: [DXBase] Kenwood TS-2000 users.
> 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
>> _______________________________________________
> DXBase Reflector - Please visit us on the web at www.dxbase.com
> - - - - - - - - - - - - - - - - - - - - - - -
> To UNSUBSCRIBE please visit:
> http://mailman.qth.net/mailman/listinfo/dxbase
>