Jack I certainly agree with your comments and feelings. It is sorta like the federal and state governments continually changing the testing requirements for the public schools, and then publishing the poor results to prove the schools are doing a bad job!
BUT: The bad part of all this is that most of us DO NOT understand what it takes to do the changes when a new radio comes out. We assume that it is a small matter to "whip up" some little addition that will make the radio interface work. I remember when I first bought my new FT2000. I just assumed that a radio like this that had been out for a year would be supported. It wasn't. I guess that since I had been using the FT1000 for some time and it was supported that the 2000 would be too. Somebody was kind enough to provide me with the interface protocol and I am a happy trooper...it was the same with the K3. It seems like you are caught between irresponsible manufacturers and (mostly) illogical users. The fact is that I love DXBase and always have...and I hope that I don't change radios anytime soon (they cost too much now anyway). To many of us, the interface is an important part of the logging program. I hope that either Neil is able to continue support for new radios or some of the smart guys that are on reflector are able to continue to provide that kind of help. You mentioned that some manufacturers were creating this kind of problem and that we should refrain from buying their radios. You might let us know who they are? Bill W5VX -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jack Sent: Monday, June 20, 2011 7:49 AM To: Robert Raines; [email protected]; [email protected] Subject: Re: [Dxbase] DXe New Version I want to address the comment regarding a "radio interface" module. Like most posts on public forums, take it or leave it, but here goes: The assumption here seems to be that it should be within the logging programs ability to provide a simple to use module that will forever more let the user tweak or modify the core programming of the logging program so that whatever changes a radio manufacturer makes can readily be handled by the logging program's user by simply making some changes. And of coures as evidenced here, when a logging program doesn't provide this capability, the charge seems to be that the programmer of the logging software is somehow just lazy, or dumb, or doesn't care, or whatever other reason the original poster might have in mind. Well, let's talk about this. When DXbase was first created, my partner and I sought some of the most brilliant minds in software rs232 communication around. Together we developed the radios.ini concept and at the time it was first introduced, it handled nearly every radio on the market. We interacted with the tech groups of most major radio manufacturers and gained their support that our approach should serve amateurs for a very long time to come. Life was good. Then, without warning and with no rhyme or reason for the changes nearly every radio manufacturer introduced new radios and yes, every one of them contained changes that our INI file approach couldn't handle. We were po'd to say the least and the more we investigated, the more irritated we became. You see, the changes made by the manufacturers added absolutely no additional functionality. None! The only thing they did was change things. We contacted each manufacturer ourselves. We had some of our customer's in Japan arrange personal meetings with the companies. Our desire was to understand why did they do this. We basically got no good answer and their attitude was simply to blow us off. Afterall, they are the big corporate giants and we were just the little old back room programmers. One of the manufacturers was so arrogant, that we decided to press further through some rather high powered members of the ham community. We finally got a response that said the rs232 interface provided on a radio is not intended as a radio feature for the user. It is developed individually for each radio based on the engineer's design and is used solely for automatic testing of the new radio. It is left in the radio since it does no harm and if a user wants to use it for their own purposes, they can write software themselves or they can contact the maker of their logging software to obtain the changes necessary. Standards? There are none! Concern for the purchasers of radios.. Hell no! Manufacturers simply kick the problem down the road to the logging software developers. The simple "technical" fact is that it is impossible to predict what changes a radio manufacturer might make in their interface such that you can develope a module within a logging program to handle whatever comes down the road. One day you read a full character to interpret a command, then you have to just read a bit out of the character, but wait, now you have to read the bits in reverse order, but wait, now you have to read the previous command to know what special handling the next command needs, this radio had no ability to identify split status, this radio changes the filters whenever you set a new frequency, this one doesn't. The list goes on and on and never stops. Having been involved with this dilemna for well over 20 years, I can tell you it is the most frustrating issue we ever faced. And it hasn't changed. For anyone who thinks a programmer can predict what a radio will do in the future, you're dreaming. Sure, there are some who have tried, and they have had varying degrees of success. But whatever success they might have had, it was pure luck, and personally I don't know of any software that hasn't required some fundamental core programming change to deal with new radios from time to time. The answer today is the same one that was needed when the first rs232 radio was sold. The makers of radios need to stop the BS, establish a standard, and stick with that standard. It is absolute stupidity to continue this madness and then expect logging programs to just through hoops every time a new radio comes about. But without an uproar from the buyers of radios, this will never change. And we are doomed to have disgruntled hams blaming logging software because their new shiny radio isn't supported "yet". And of course, those same people will be the ones blasting the reflectors about how "uncaring" the authors of their logging software are because they didn't jump through hoops in a day or two to make their new shiny radio work. Stupidity is when we continue to do the same things over and over, and expect a different outcome. I challenge every single ham to stop buying radios when the rs232 interface is suddenly changed for no good reason, its not backward compatible, and thus doesn't work with your logging software. Who has the guts to place the blame squarely where it belongs? Who has the courage to write a letter to their favorite radio makers and tell them to stop the madness? Who has the conviction to stop buying products from manufacturers who don't care? OK, sorry for the rant. But this issue is personal because I and many others have invested so much effort into this one and still nothing has changed. Jack ______________________________________________________________ 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
