[South Florida DX Association] DXBase New Version

[Bill]

I have been a user of DXBase since the beginning in 1990 and still do. 
It works great for me.

Posted today, this is a most enlightening inside look at problems facing 
programmers writing logging programs and others in today's environment. 
Programmers in today's world face challenges from impatient and 
demanding, customers, and unknown to us is the lack of standards from 
Manufacturers. Most programs written for Hams do not make a profit, and 
are mostly a labor of love. I sympathize with the programmers trying to 
keep up, regardless of what program or radio you use.
Bill Marx W2CQ

"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 course 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.  After all, 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 develop 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 dilemma 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?"