RadioBanter - View Single Post

Paul W. Schleck[_3_] · November 2nd 07, 09:49 PM posted to rec.radio.amateur.moderated

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In . com writes:

On Nov 2, 12:27?am, Steve Bonine wrote:
Jack VK2CJC wrote:

Today's ham equipment has plenty of computing
capacity to be able to
handle band edges, sub-bands, and band plans.
These rigs can be
connected to a PC and programmed using software specific to the
equipment.

It would be an easy programming effort to do the same
kind of thing for
HF.

I don't know how 'easy' it would be, but it could be done. 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.

Let the owner pick a starting place, perhaps by ITU region, and
modify it based on license class and/or personal preference.
Essentially I'm asking for the capability to program the details of
band
plans into the rig and to easily change this information as desired.

Or, 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.

- 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.

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.

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?

Besides. I wouldn't buy a radio that was restrictively
programmed in a
manner I wasn't able to undo. Just for the principle of it.

No, neither would I (except that I've bought rigs that won't transmit
outside of amateur allocations, presumably something that I could
undo
given proper motivation). But that's not at all what I am suggesting.

Ultimately you'd want the ability to defeat the feature, in case the
rig were sold or loaned to someone with a higher license class, or the
rules changed, or you traveled somewhere with different rules.

For those of you who are upset with me as an "appliance
operator", I
don't see anything wrong with using available technology to keep me from doing something stupid.

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.

73 de Jim, N2EY

I think that's the important distinction. It's also related to a
classic conundrum in developing safety systems in other fields. 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.

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.
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.

- - --
73, Paul W. Schleck, K3FU

http://www.novia.net/~pschleck/
Finger for PGP Public Key

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (SunOS)

iD8DBQFHK5SL6Pj0az779o4RAqO+AJ9xxoDtAggjbx5/2VFmBJSHqmiibgCgxP/K
RCO/Au67cS5M2dwZJsV0TUg=
=Fvin
-----END PGP SIGNATURE-----