[Dxbase] Dxbase Digest, Vol 86, Issue 17
ni3p at comcast.net
ni3p at comcast.net
Tue Jun 21 07:34:20 EDT 2011
Not that it will make anyone feel better, but standardization efforts do not happen because companies are interested in the betterment of mankind. Having spent 20 years in that field, I know that there are only a few reasons why otherwise competitive companies do standards. First, because they want their own proprietary stuff to become "the standard", which gives them a leg up in the marketplace - that's what happened with VHS/Beta. (Consider how likely it would be for any company to say "gee, our competitor's product is better than ours, so let's throw away all our investment and pay to license their patents"). Or second, when the product differentiation that results from their uniqueness provides no value added - and then money can be saved by essentially spreading the engineering costs across all the participants. In the case of 3D, the technology is changing very quickly, and there is therefore no reason to work for standardization because the one disadvantage of standardization is that it has the potential to freeze out future technology enhancements by being "good enough." (Think about the QWERTY keyboard). So bottom line, standardization takes place when the people directly involved believe it is their collective best interests, and not before.
Steve Oksala
NI3P
----- Original Message -----
From: dxbase-request at mailman.qth.net
To: dxbase at mailman.qth.net
Sent: Monday, June 20, 2011 1:35:33 PM
Subject: Dxbase Digest, Vol 86, Issue 17
Send Dxbase mailing list submissions to
dxbase at mailman.qth.net
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.qth.net/mailman/listinfo/dxbase
or, via email, send a message with subject or body 'help' to
dxbase-request at mailman.qth.net
You can reach the person managing the list at
dxbase-owner at mailman.qth.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dxbase digest..."
Today's Topics:
1. Re: DXe New Version (k8ztt at mho.com)
2. Re: DXe New Version (k8ztt at mho.com)
----------------------------------------------------------------------
Message: 1
Date: 2011年6月20日 10:35:06 -0700
From: "" <k8ztt at mho.com>
Subject: Re: [Dxbase] DXe New Version
To: <dxbase at mailman.qth.net>
Message-ID: <20110620103506.A115830C at resin07.mta.everyone.net>
Content-Type: text/plain; charset="UTF-8"
Jack certainly hit it on the head. The JA companies are nortoriously inept at "standardiztion"; besides cell phone chargers, two of the BIG ones were VHS/Beta and Blu-ray/ HD Disks. And of course now we have the same issues with 3D TV; no standarization with the transmission of data from the TV to the 3D Glasses(you buy a Panasonic, and only Panasonic glasses work).
In the end, we (the consumers) are left to "fight it out" and the losers end up with obsolete equipment; and it is not necessarily the best one wins (Beta lost to VHS).
There is absolutely no reason that manufactures can't standardize (even the mic connectors are different); they just don't have any incentive to do so. The only way we (the consumer) can fight back is with your check book.
Dick K8ZTT
--- lennoxj at bellsouth.net wrote:
From: "Jack" <lennoxj at bellsouth.net>
To: "Robert Raines" <r-raines at hotmail.com>, <cfwb at cox.net>, <dxbase at mailman.qth.net>
Subject: Re: [Dxbase] DXe New Version
Date: 2011年6月20日 08:49:26 -0400
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
----- Original Message -----
From: "Robert Raines" <r-raines at hotmail.com>
To: <cfwb at cox.net>; <dxbase at mailman.qth.net>
Sent: Sunday, June 19, 2011 8:28 PM
Subject: Re: [Dxbase] DXe New Version
Hi Carl,
I do not hide my call sign - as explained before, I do not have an amateur
license.
Way back in the DOS dark ages (yep, we have used it that long also), it was
discovered that DXBase did an excellent at tracking some transmissions sent
and received by small governement agencies and contractors. Jack made
customization easy for us though the database interface, other than updating
the band information, initially it was used almost straight off the
diskette. A lot of the fields are not used, or
have a unique tuning in the DB.
Our main concern is the RADIO INI files. Instead of fighting them each time
a new commercial radio is installed, it would be nice to have a RADIO
customization interface in the new version. This is all we have been asking
for. It would benefit all parties involved, not just amateurs.
You guys saw the issue with the amateur TenTec OMNI VII and other rigs, and
we have seen it with the government versions of new radios.
I will go away for a while now and let the flames come my way for asking for
something that I have asked for before. And by the way, my name is Robert -
not Bob.
From: cfwb at cox.net
To: r-raines at hotmail.com
Subject: Re: [Dxbase] DXe New Version
Date: 2011年6月19日 19:21:30 -0400
Hi Bob,
Remember we all march to a different drummer. I for one am happy
with DXbase2007.
It does all I need it to do. With that said I don't think it does any of us
any good to put
pressure on Neal for a new version...NOW. First of all we should be glad he
bought DXbase.
I think Jack was about to let it go by the wayside, which in that case we'd
all be out on a limb.
It is my belief that the "buggy versions" of DXbase you speak of, came out
because of pressure
from guys like you for Neal to come out with "something". Just too much
pressure on the guy which
does not help any of us.
I learned long ago not to jump to "upgrades", so I'm still at version .07 .
I think at this time you know what I'm going to say next...go to some other
logging program if you
don't like DXbase. For me, I'll stick around with DXbase since I have since
the first DOS version
came out around 1990.
I for one will send Neal a private email, like this one to you, suggesting
Neal take his time, disregard
the pressure, and at his own pace, come out with a new great version of
DXbase.
So Bob if you?re a ham, as I don't see a call sign, best 73,
Carl - K8AV
P.S. It's a shame you feel you must "hide" your call sign. I can only guess
why.
It sure is funny you can't be found in the USA call book.
Maybe you work for a competing logging program ?
From: Robert Raines
Sent: Sunday, June 19, 2011 5:46 PM
To: dxbase at mailman.qth.net
Subject: [Dxbase] DXe New Version
Well over a year ago everyone came down on me hard for asking Neal when we
would see some screen shots and a project draft of the new version of
DXBase.
Now that over a year has passed, was I so aweful for asking?
Every update attempt he has tried to do is full of bugs.
Looks like someone needs to step up and ask what the currect users can
expect in the future and when.
______________________________________________________________
Dxbase mailing list
Home: http://mailman.qth.net/mailman/listinfo/dxbase
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Dxbase at mailman.qth.net
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:Dxbase at mailman.qth.net
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:Dxbase at mailman.qth.net
This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
------------------------------
Message: 2
Date: 2011年6月20日 10:35:14 -0700
From: "" <k8ztt at mho.com>
Subject: Re: [Dxbase] DXe New Version
To: <dxbase at mailman.qth.net>
Message-ID: <20110620103514.A115830B at resin07.mta.everyone.net>
Content-Type: text/plain; charset="UTF-8"
Jack certainly hit it on the head. The JA companies are nortoriously inept at "standardiztion"; besides cell phone chargers, two of the BIG ones were VHS/Beta and Blu-ray/ HD Disks. And of course now we have the same issues with 3D TV; no standarization with the transmission of data from the TV to the 3D Glasses(you buy a Panasonic, and only Panasonic glasses work).
In the end, we (the consumers) are left to "fight it out" and the losers end up with obsolete equipment; and it is not necessarily the best one wins (Beta lost to VHS).
There is absolutely no reason that manufactures can't standardize (even the mic connectors are different); they just don't have any incentive to do so. The only way we (the consumer) can fight back is with your check book.
Dick K8ZTT
--- lennoxj at bellsouth.net wrote:
From: "Jack" <lennoxj at bellsouth.net>
To: "Robert Raines" <r-raines at hotmail.com>, <cfwb at cox.net>, <dxbase at mailman.qth.net>
Subject: Re: [Dxbase] DXe New Version
Date: 2011年6月20日 08:49:26 -0400
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
----- Original Message -----
From: "Robert Raines" <r-raines at hotmail.com>
To: <cfwb at cox.net>; <dxbase at mailman.qth.net>
Sent: Sunday, June 19, 2011 8:28 PM
Subject: Re: [Dxbase] DXe New Version
Hi Carl,
I do not hide my call sign - as explained before, I do not have an amateur
license.
Way back in the DOS dark ages (yep, we have used it that long also), it was
discovered that DXBase did an excellent at tracking some transmissions sent
and received by small governement agencies and contractors. Jack made
customization easy for us though the database interface, other than updating
the band information, initially it was used almost straight off the
diskette. A lot of the fields are not used, or
have a unique tuning in the DB.
Our main concern is the RADIO INI files. Instead of fighting them each time
a new commercial radio is installed, it would be nice to have a RADIO
customization interface in the new version. This is all we have been asking
for. It would benefit all parties involved, not just amateurs.
You guys saw the issue with the amateur TenTec OMNI VII and other rigs, and
we have seen it with the government versions of new radios.
I will go away for a while now and let the flames come my way for asking for
something that I have asked for before. And by the way, my name is Robert -
not Bob.
From: cfwb at cox.net
To: r-raines at hotmail.com
Subject: Re: [Dxbase] DXe New Version
Date: 2011年6月19日 19:21:30 -0400
Hi Bob,
Remember we all march to a different drummer. I for one am happy
with DXbase2007.
It does all I need it to do. With that said I don't think it does any of us
any good to put
pressure on Neal for a new version...NOW. First of all we should be glad he
bought DXbase.
I think Jack was about to let it go by the wayside, which in that case we'd
all be out on a limb.
It is my belief that the "buggy versions" of DXbase you speak of, came out
because of pressure
from guys like you for Neal to come out with "something". Just too much
pressure on the guy which
does not help any of us.
I learned long ago not to jump to "upgrades", so I'm still at version .07 .
I think at this time you know what I'm going to say next...go to some other
logging program if you
don't like DXbase. For me, I'll stick around with DXbase since I have since
the first DOS version
came out around 1990.
I for one will send Neal a private email, like this one to you, suggesting
Neal take his time, disregard
the pressure, and at his own pace, come out with a new great version of
DXbase.
So Bob if you?re a ham, as I don't see a call sign, best 73,
Carl - K8AV
P.S. It's a shame you feel you must "hide" your call sign. I can only guess
why.
It sure is funny you can't be found in the USA call book.
Maybe you work for a competing logging program ?
From: Robert Raines
Sent: Sunday, June 19, 2011 5:46 PM
To: dxbase at mailman.qth.net
Subject: [Dxbase] DXe New Version
Well over a year ago everyone came down on me hard for asking Neal when we
would see some screen shots and a project draft of the new version of
DXBase.
Now that over a year has passed, was I so aweful for asking?
Every update attempt he has tried to do is full of bugs.
Looks like someone needs to step up and ask what the currect users can
expect in the future and when.
______________________________________________________________
Dxbase mailing list
Home: http://mailman.qth.net/mailman/listinfo/dxbase
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Dxbase at mailman.qth.net
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:Dxbase at mailman.qth.net
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:Dxbase at mailman.qth.net
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:Dxbase at mailman.qth.net
End of Dxbase Digest, Vol 86, Issue 17
**************************************
More information about the Dxbase
mailing list