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

Re: AO40rcv and the Kenwood TS-2000

I would like to echo Tim's remarks about designing a protocol to talk
to radios by their representation on the wire.  And just a few more

> At 08:24 AM 4/6/2001 -0500, Timothy J. Salo wrote:
> >If I were developing this protocol, I would use type/length/value
> >tuples (TLVs).  Each message would be composed of one or more TLVs.
> >Each TLV would like:
> >
> >          -------------------------
> >          | Type | Length | Value |
> >          -------------------------
> This encoding is only good on error-protected links, and preferably ones
> with inherent framing. On an unprotected byte-stream link (like a serial port)
> you can get out of sync and be screwed.
> Something like this would be more robust:
> Flag | Type | Length | Value | CRC

I think Tim was trying to describe a way to encode parameters and
values which would be sent to the radio.  I think there's a huge, huge
advantage to describing such a protocol in terms of the data elements
being moved back and forth, and then describe mappings onto specific
transport mechanisms and media.

If you approach it in that fashion, then it much easier to move to
different media (IR, Ethernet, multi-dropped serial, point-to-point
serial, etc.)  We should keep in mind that the hard part of this
effort isn't going to be re-inventing Yet Another Serial Link
protocol, but getting a good set of commands defined which have half a
chance of being portable between differnt radios and manufacturers.

I suggested once that perhaps we approach this problem as a data
modeling excercise, rather than a primarily a protocol problem.  We
should look at the success that SNMP has had in the network management
world; there are a set of standard MIB (management informantion base)
definitions which vendors of devices of all types are expected to
implement.  Perhaps there are proprietary extensions in the absense of
a standard MIB for some new capability, or a unique feature of a
particular box.

In the network management world, you don't monitor your Cisco router
with different protocols and mechansims that you would your Juniper
router; the customer wouldn't stand for it.  At least for simple
things, like fetching counters for traffic usage.  You expect and
demand the standard management interfaces for the standard things you
need to monitor and control on a platform.

In a similar fashion, we ought to be able to come up with an abstract
MIB (or set of MIBs) which contain well understood objects.  Like a
"VFO" which you can set the frequncy of, or a receiver, which can be
put in various modes, etc.  Once this done, it's a simple matter of
bookkeeping to assign well-known values for these things, and then
mapping the transport of "SET" or "GET" operations with an associated
set of MIB variables onto a specific transport and media.

Clearly, you might have different transports over different physical
media, but this is rarely the hardest part of the problem faced by
someone building an application to control a device/radio.

You might wonder why SNMP over UDP/IP wouldn't be adequate, but I
guess that won't fit into a PIC.  Perhaps we could have management
object which can be mapped into SNMP as well as into some
lighter-weight transport and media?

I know only enough to be dangerous about doing MIB architecture and
definitions; in some sense, it's more like a database modelling
problem to represent the object you're trying to manage and control in
a well-formed way.  I firmly believe that unless this sort of work is
done, you really won't have done very much to solve the
interoperability problem of controlling radios.

I do know about designing communication protocols, and they are not as
simple as you might see at first blush.  There are common blunders
which have been reinvented over the years, and a well-known set of
idioms which can be employed to solve common problems.  But, as I said
above, I think this is the easy part of the problem, and we should
strive to keep the details of the transport out of the hard part of
the problem, which is the control of the radio by a well-defined set
of management abstractions.


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