[Dxbase] DXe New Version

[Bill Parry]

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: dxbase-bounces at mailman.qth.net [mailto:dxbase-bounces at mailman.qth.net]
On Behalf Of Jack
Sent: Monday, June 20, 2011 7:49 AM
To: Robert Raines; cfwb at cox.net; dxbase at mailman.qth.net
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