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 >
