The radios.ini file has served us very well however it has a number of limitations, is undocumented, broken in one area (Ten tec binary ENcodes in the opposite byte order) and needs a revamp there is also a lot of cruft in there left over from older dos versions of DXbase
I would propose that the principle of a user editable rig control file be continued however rather than text based this could be XML based and hierarchical. It should be possible to define the command strings required to read / set the radio and then what order they are sent in. For example, the current protocol ALWAYS sends mode data before frequency, this may have been required in the pre-band stacking register days but it breaks things with modern radios, they change mode on the old frequency then change band based on the spot.. it should be possible to configure the allowable port speeds and settings for radios where known, this will help prevent user error. For example the K2 only supports 4800bd 8N1 It should be possible to define what happens if a command fails (a retry or 2 instead of just disabling the port etc) Disabled ports should not require you to dig though several layers of menu just to turn a rig back on Polling should be an option (but not the norm) for some radios as is done with contesting software the port could be freed up for other applications when the selected radio is not actively in use A software pass-though port should be in there for other applications wishing to control the radio Support for omnirig (& possibly hamlib) The whole area of pacing, EOC etc needs a revisited as many of the values seem wildly inappropriate for modern PC's and most modern radios don't need a delay inserted between commands. I have yet to meet a radio where pacing (extra spacing between the serial port characters) is required, surely the serial port driver will just handle this now that dos is long behind us? Ten-tec moved the goalposts by adding ethernet to the Omni-7, this should be supported but since the Ten-tec protocol will not be the standard that others use (or even tentec in future models, if past performance is anything to go by..) then the way in which the commands etc are defined needs to be flexible enough to be able to grow in future versions of dxbase 73's Brendan Cross posted to the mailing list since this is where most of the users of the software are -- 73 Brendan EI6IZ ______________________________________________________________ Dxbase mailing list Home: http://mailman.qth.net/mailman/listinfo/dxbase Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[email protected] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
