View Single Post
  #86   Report Post  
Old November 5th 07, 02:23 AM posted to rec.radio.amateur.moderated
[email protected] N2EY@AOL.COM is offline
external usenet poster
 
First recorded activity by RadioBanter: Jul 2006
Posts: 877
Default Forty Years Licensed

On Nov 2, 4:49?pm, Paul W. Schleck " wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In . com writes:
The classic
'bell-the-cat' question is: who will do the actual work?


Another angle on the same challenge would be who would be motivated to
develop a vendor-independent standard, that would actually be widely
adopted by vendors, to implement this? Witness the various permutations
of DC power connectors (with amateur radio emergency groups driven to
distraction trying to establish at least local standards). Witness the
inability to develop working, vendor-independent, interoperable
standards for high-speed radio modems (9600 baud and above) that could
be found in commonly-available commercial amateur radio gear. Amateur
radio equipment manufacturers appear to prefer to differentiate their
products by unique, and unfortunately incompatible, means of interfacing
and control, with few economic incentives to standardize with other
brands.


I think there are a couple of reasons for that:

1) The relatively-small amateur market won't support the cost of
standardization. IOW, it would add too much to the cost of a rig.

2) The rigmakers don't want any more interoperability, because it
means less sales

the rigmakers could offer downloadable firmware options. When
the rules change, download an update. Some rigmakers, like TenTec and
Elecraft, do this already.


Will your amateur radio that is programmed to recognize band edges and
allowed modes be able to be modified via reasonably available tools and
techniques for the indefinite future? Examples that may cause me to
think otherwise include:

- Most amateur radio equipment in the past couple of decades, for
economic reasons, tends to use custom bit-masked EEPROM's to
implement their internal programming, something that would not be
economical to duplicate by third-party manufacturers. Though amateur
radio equipment would seem to be covered by the Magnuson Moss Act
(i.e., availability of parts on the open market for some period of
time after the end of manufacture, preservation of warranty even if
third party parts and service are used, etc.), I also recall letters
to QST complaining about repair depots simply being unable to fix
amateur radio equipment, some of which was less than 10 years old.


Isn't that true of almost any consumer electronics?

We hams are the exception that proves the rule. We tend to keep rigs
in working order for a very long time, compared to, say, VCRs,
computers or TV sets.

Note also that hams like N4PY have come up with aftermarket software
improvements for rigs like Ten Tec.

- I recall a legal dust-up from some years ago, discussed on the
newsgroups, where Motorola was cracking down on efforts to
reverse-engineer radio interfaces and the software that is used to
modify the configurations of their radios. Regardless of whether
Motorola was taking a legally defensible position, if the software is
proprietary, or unable to run on current computers, or otherwise
unavailable or unusable in some way, you may be left holding the bag.


The idea is that you're either supposed to pay Motorola prices, or
replace the radios.

Consider the problem with VCR's and the recent change in the start of
Daylight Savings Time in the U.S., and no way to modify them.


That reminds me, I have a bunch of things to reset....

Another approach is that as SDRs become more popular, the feature
would be part of the user interface.


This would appear to offer more promise of future compatibility and
programmability, though might still run afoul of legal problems with
regard to reverse engineering or otherwise developing openly-published
specifications and third-party software tools. Whether or not these
positions would be legally defensible might not prevent manufacturers
from attempting to chill the open market for these tools via
intimidation tactics. Also, how long would it take for software-defined
radios to propagate out to the amateur radio community in significant
enough numbers to make a meaningful impact?


Good point! But the ability to add and change filters by firmware/
software methods is a major reason to go SDR.

I think it depends on the intent.
It's one thing to build in features that prevent problems. For
example, the power supplies of my non-QRP homebrew rigs built since
1980 have built-in time delay protection so that the high voltage
cannot be applied until the final amplifier and rectifier tubes have
had 60 seconds to warm up, and the bias supply is operating.
That protection is not essential to the operation of the rig, but it
has probably saved me from a few problems along the way.
It's quite a different thing, IMHO, to build in features with the
intent that the features remove the need for the licensed operator to
know things, like the subband edges.
IOW, the feature is a backup, not primary protection.


I think that's the important distinction. It's also related to a
classic conundrum in developing safety systems in other fields.


Yup - been there, done that.

I would
welcome an amateur radio that had fault protection to keep me from
blowing the finals if I accidentally transmitted into no load or an
infinite load. I'm not so sure about an amateur radio that would keep
me from transmitting out of band or in an unauthorized mode if
assumptions about what constituted "out of band" or "authorized mode"
changes, or if I find myself in a true, bona-fide, communications
emergency.


One way to implement such protection is to have an override switch
that must be activated for each exception. Or just a "feature off"
switch.

The Usenet newsgroup comp.risks (aka, "Risks Digest") has touched on
many of these types of issues. For example, while a rev-limiter on a
motor would increase safety by preventing a blown engine, putting speed
limiters on automobiles to keep them within speed limits may increase
accidents by denying the necessary amount of power to get you out of a
reasonably unanticipated emergency situation while passing or merging.


I can't think of a reasonable real-world situation where an RPM
limiter would cause problems.

Speed limiters, though, have practical problems. The max speed would
have to be set higher than the highest legal speed limit in the
country, so we're talking about 80-85 MPH. Since the car doesn't know
if it's on a superhighway or in a school zone, the practical effect
would be rather small.

An airplane whose controls would keep you from overstressing the
airframe, or flying into restricted airspace, might also keep you from
making appropriate emergency maneuvers, where landing alive with your
crew and passengers, but with an airframe you have just end-of-lifed, or
under fighter escort to be whisked off to a friendly interview with the
authorities, might be far preferable to the alternatives.

There's also the problem of what happens if the protection system
fails.

It seems to me that the best implementation for ham rigs would be a
firmware feature that you could turn off, and update as needed by
downloads.

73 de Jim, N2EY