[DXBase] A Suggestion for improved radio support in future versions

[Brendan Minish]

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..