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

Re: AO40rcv and the Kenwood TS-2000

I agree that this kind of protocol is the way to go for talking to the physical 
devices.  However,  trying to get Kenwood, Yaesu, Icon, ... to change their 
current interface will be the bigger challenge than designing the protocol ;-)  
Another problem is that they do not currently have all the front panel 
functionality using the RS-232 interface.  An example is the Icom 821 which 
needs to be setup manually as the CI-V interace does not have the commands to 
set it up correctly. 

The problem that I was trying to expand on was to be able to have applications 
communicating with each other.

Currently,  the only supported/defined interface is the WiSP DDE interface that 
is being used to drive external applications to control radios and rotors.  Of 
course that is not too much of a problem as most satellite operators are using 
the WiSP software.

My own satellite station runs on a Sun Ultra 1 running Solaris (it could also 
run on Linux and Windows).  I cannot plug a KCT into the box,  so I am 
restricted to using something like a TrakBox as it has a serial interface.  
However,  I can have the KCT in an old cheap 486 box running Linux with the KCT 
driver and have the Sun box send requests to the tracking box to move the 
rotors.  This is the kind of communications protocol that I was alluding to in 
my previous mailing.

-- John Melton  n6lyt/g0orx

> X-Exmh-Isig-CompType: repl
> X-Exmh-Isig-Folder: inbox/amsat
> To: Paul Williamson <kb5mu@AMSAT.Org>
> cc: "Timothy J. Salo" <salo@saloits.com>, amsat-bb@AMSAT.Org
> X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg
> Subject: Re: [amsat-bb] AO40rcv and the Kenwood TS-2000 
> Mime-Version: 1.0
> 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
> remarks..
> > 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 
> > 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.
> louie
> wa3ymh
> ----
> Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
> To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org

-- John Melton

                Principal Systems Software Engineer
        ((      Sun Microsystems,
      (|~~|     Solaris House, Guillemont Park,
       `--'     Minley Road, Blackwater,
                Camberley, Surrey GU17 9QG, England
       JAVA     Phone: +44 1252 421708  (internal ext 21708)
                Email: john.melton@uk.sun.com

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