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: [email protected] To: [email protected] Sent: Monday, June 20, 2011 1:35:33 PM Subject: Dxbase Digest, Vol 86, Issue 17 Send Dxbase mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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 ([email protected]) 2. Re: DXe New Version ([email protected]) ---------------------------------------------------------------------- Message: 1 Date: Mon, 20 Jun 2011 10:35:06 -0700 From: "" <[email protected]> Subject: Re: [Dxbase] DXe New Version To: <[email protected]> Message-ID: <[email protected]> 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 --- [email protected] wrote: From: "Jack" <[email protected]> To: "Robert Raines" <[email protected]>, <[email protected]>, <[email protected]> Subject: Re: [Dxbase] DXe New Version Date: Mon, 20 Jun 2011 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" <[email protected]> To: <[email protected]>; <[email protected]> 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: [email protected] To: [email protected] Subject: Re: [Dxbase] DXe New Version Date: Sun, 19 Jun 2011 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: [email protected] 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:[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 ______________________________________________________________ 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 ------------------------------ Message: 2 Date: Mon, 20 Jun 2011 10:35:14 -0700 From: "" <[email protected]> Subject: Re: [Dxbase] DXe New Version To: <[email protected]> Message-ID: <[email protected]> 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 --- [email protected] wrote: From: "Jack" <[email protected]> To: "Robert Raines" <[email protected]>, <[email protected]>, <[email protected]> Subject: Re: [Dxbase] DXe New Version Date: Mon, 20 Jun 2011 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" <[email protected]> To: <[email protected]>; <[email protected]> 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: [email protected] To: [email protected] Subject: Re: [Dxbase] DXe New Version Date: Sun, 19 Jun 2011 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: [email protected] 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:[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 ______________________________________________________________ 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] End of Dxbase Digest, Vol 86, Issue 17 ************************************** ______________________________________________________________ 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
