Hi Brendan There isn't much in your note to disagree with. It correctly highlights the areas I have seen that needs to be addressed.
I am not aware of a Windows-based Hamlib implementation and I know that Hamlib has suffered from some of the problems as the logging programs and that is that as changes in the protocols evolved the programs put "patching" in place to address them rather than re-architecting the interface. There is a famous maxim that any code older than 7 years should be thrown out and completely re-written. In reality the rig manufacturers are hung in neutral also in that each model seems to be slightly different and they are limited by a physical transport layer that has disappeared (eg RS-232). I am sure that rig interfacing is the least favorite piece of code in almost everyone's program as well as the area of most complaints. I haven't decided my priorities yet nor an architecture for the CAT interface. I do want to ensure that more capable radios like PowerSDR/Flex, Icom 7800, K3 and the FtDX9000 Yaesu's are fully exploited so their second RX can utilize the second radio interface. I would like to adopt a "standard" interfacing language for defining the rig protocols (like Omnirig's). I know there is an open-source library that uses a more thoroughly defined protocol in XML so there is a lot to look at. I can almost guarantee that I will not solve the CAT issue with the first release of DXBase 2010 but know its pretty close to the top architectural problem in priority. 73 Neal Campbell Abroham Neal Software www.dxbase.com www.abrohamnealsoftware.com www.sdrsystems.com (540) 242 0911 Amateur Radio: K3NC Blog: http://www.abrohamnealsoftware.com/blog/ DXBase bug reports: email to [email protected] Abroham Neal forums: http:/www.abrohamnealsoftware.com/community/ DX Cluster: dxc.k3nc.com port 23 On Sun, Oct 4, 2009 at 8:05 AM, Brendan Minish <[email protected]>wrote: > 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 > ______________________________________________________________ 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
