Since it would appear that support for new radios is actually added in most cases by the users, not Scientific solutions and the protocols used by various radios constantly changing when new models come out, It Seems to me that future versions of DXB could do more to make the job of adding support for future radios easier to do and allow for some improvements to existing radios.
Here are my suggestions for some improvements, most of these appeared initially as part of the TS2000 thread 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) Ability to code in some of the serial port parameters I.e some radios only support certain baud rates (or even have 1 fixed baud rate) and require certain parity and stop bit settings, obviously the com port # need not be coded into the .ini file! this would make it easier for the end user it would provide less room for error by removing the settings that won't work. If there are no com port parameters set then all possible options are available like now PORT_SPEED = 4800,9600,19200 (means that user can only select from these values) PORT_PARITY= NONE (or EVEN ODD etc) PORT_BIT= 8 (or 7 etc) PORT_STOP=1 (or 0,1,2 etc ) PORT_HANDSHAKE = Hard (or NONE or CWKEY (to allow the same com port for CW keying by means of the RTS or DTR lines) ) 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 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 ) Therefore it should be possible to add these new features breaking ay existing ones 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 ) In the absence of any of these new features from a particular entry in the INI file DXB could assume the current default behavior to ensure 100% backward compatibility with older radios.ini files. The DXB help file would need more information added on how the radios.ini file works as well..
