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
