[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: AO40rcv and the Kenwood TS-2000

Back in the late '70's, the commercial and recreational marine electronics
market saw this problem coming. The initial focus was to develop a standard
protocol to allow LORAN-C receivers to communicate with automatic pilots.
The task was turned over to the National Marine Electronics Association,
which consisted of manufacturers, dealers and distributors. This resulted in
the NMEA-0180 standard. This excersise was so successful, that a new
standard, NMEA-0183, was developed to encompass communications between a
wide variety of devices. This is the standard still used to communicate with
commercial GPS receivers today.

A universal protocol for remote control of ham equipment is long overdue. In
order for the movement to get off center, I believe it will require the
"mucsle" of the ARRL to at least endorse a sub-committee to address the
problem.  I don't think the problem will ever get the organized attention it
needs from the manufacturers until there is a clear mandate by the user
community. The best way to verbalize the need is through a national
association, such as the ARRL. Once the movement is started, all you need is
one manufacturer to join in and the others will have to follow. The market
is too small not to.

----- Original Message -----
From: "Timothy J. Salo" <salo@saloits.com>
To: <amsat-bb@AMSAT.Org>
Sent: Thursday, April 05, 2001 10:51 AM
Subject: Re: [amsat-bb] AO40rcv and the Kenwood TS-2000

> > Date: Thu, 05 Apr 2001 08:05:43 -0400
> > From: Margaret Leber <maggie@voicenet.com>
> > Subject: Re: [amsat-bb] AO40rcv and the Kenwood TS-2000
> >
> > Timothy J. Salo wrote:
> > > Well, sort of.  I wouldn't call them particularly open or
> >
> > They're open as all hell...the implementation details are published. For
> > "interoperable" we do have to ask "interoperable with what".
> Interoperable between independent implementations that wish to
> communicate with each other.  Again, I believe that the context of this
> discussions is protocols for connecting pieces of amateur
> radio-related software executing on different machines communicating
> over an IP network such as the Internet.
> The Java RMI protocol is tailored to the needs of the Java language.
> Of course, the protocol could be implemented in some other language.
> But, why use a protocol designed for a specific programming language?
> > > A group of us tried using the Java object serialization facility to
> > > transfer Java objects containing data between Java applications on
> > > different machines...
> >
> > Well, while that does sound like a good bit of fun, it's hard to
> > understand why it was thought to be A Good Thing for whatever practical
> > job you were trying to do. It certainly ensured *oodles* of overhead for
> > no particular obvious benefit, and the devil's own time in unplanned and
> > undesirable interactions between the environments. As you discovered.
> > Shipping serialized objects isn't the same as RMI, of course.
> Java Remote Method Invocation (RMI) uses object serialization to
> pass arguments and return values.
> > > Using Java RMI ...also pretty much assumes that the remote software is
> > > written in Java...
> >
> > Or uses an ORB.
> From "The Java Programming Language, Second Edition"
> "RMI is explicitly designed to take advantage of having both
> client and server in Java."
> Note that the spec also says that RMI requires that a security manager
> be installed...
> >  > ...A reasonable protocol would be language-independent.
> >
> > Well, "language-independence" is Microsoft's mantra whenever they're
> > Java-bashing, of course. I don't see anybody else in the software
> > industry getting all hyped up about it. MS also didn't get hyped about
> > it until they realized they weren't going to win fragmenting Java from
> > the inside, so it was time to start poisoning the well from the outside.
> >
> > Anybody who's written to Win32 in, say, COBOL or Fortran knows how
> > language-independant *that* is, of course. These days
> > "language-independance" seems to mostly be the battle cry of the C/C++
> > crowd.
> I don't think whining about Microsoft will assist us in understanding
> the requirements for an appropriate protocol for interconnecting
> amateur radio software.
> > Be that as it may, a message-based protocol would be Mostly Harmless.
> > And RMI is OK too, *if* you're using a Java-based framework and have
> > archtectural control at both ends. In many cases you don't, of course.
> Hence the use to the term "interoperable" (see above).
> > > However, for
> > > interconnecting amateur radio applications across a network, I
> > > that some simple (extensible) protocol be developed...
> I stand by my original assertion (if anyone hasn't guessed by now...).
> > I need to look at what the Internet Radio Linking Project people are
> > doing on this front too someday soon. http://www.irlp.net/
> The task of the IRLP project looks interesting.  However, I probably
> wouldn't use it as a model of protocol design.  If I understand correctly,
> they are encoding commands as ditigized DPMF audio tones and are using
> special (and proprietary) hardware (the function of which isn't clear to
> me).
> My sympathy (sort of) to all the electrical engineers on the list who
> thought that satellites and amateur radio were just about hardware...
> -tjs
> ----
> Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
> To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org

Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org