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

Re: AO40rcv and the Kenwood TS-2000



> Date: Fri, 06 Apr 2001 10:03:30 -0700
> From: Paul Williamson <kb5mu@amsat.org>
> Subject: Re: [amsat-bb] AO40rcv and the Kenwood TS-2000
> 
> 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
> 
> where "Flag" is a unique value, and the other fields are byte-escaped to
> prevent that value from appearing literally.
> 
> CRC calculations are NOT very hard, but they take up about 300 bytes of
> code space (a 256-byte table and a little bit of code). If your target is
> really  a PIC with only 2K of program space, as somebody suggested, then you
> might wish to use a checksum instead. Of course, if this is your target, the
> command set is going to have to be tiny too.

I agree with your observation about the requirements for a reliable
link-level mechanism, but I would probably implement it differently.

If I were doing this, I would create two, layered protocols.  The upper
layer protocol would be the end-to-end application protocol that has
been discussed.  Under that, I would probably have several optional
reliable transport mechanism.  On serial likes one could use the framing
and CRC mechanism you describe.  On the Internet, one could use TCP
(_instead_ of the framing and CRC mechanism you describe).  Pictorially:

On unreliable serial links:

  Amateur             -------------------------
  Radio               | Type | Length | Value |
  Protocol            -------------------------

  Reliable    ----------------------------------------
  Link        | Flag ||     data (above)      || CRC |
  Protocol    ----------------------------------------

On Internet links:

  Amateur             -------------------------
  Radio               | Type | Length | Value |
  Protocol            -------------------------

              ---------------------------------
  TCP         | TCP  ||     data (above)      |
              ---------------------------------

On packet links:

  Amateur             -------------------------
  Radio               | Type | Length | Value |
  Protocol            -------------------------

              ----------------------------------------
  AX.25       |AX.25 ||     data (above)      || CRC |
              ----------------------------------------

> Another possibility would be to take the framing and Type byte from the
> KISS TNC protocol (http://people.qualcomm.com/karn/papers/kiss.html).
> Another possibility would be to take the framing and Type byte from the
> KISS TNC protocol (http://people.qualcomm.com/karn/papers/kiss.html).
> If you do that, and choose Type bytes that are not used by KISS, it's
> possible that a single serial port could be shared between a KISS TNC
> and a transceiver controller.

Again, I wouldn't add the framing and CRC on links that don't needed it.
If you loose your place on a TCP connection, I would reset the
connection rather than trying to figure out where the framing is.
AX.25 inherently provides framing (via packet boundaries).

> Another design issue for this type of thing is addressing. One of the
> well-loved features of the Icom transceiver control system is that multiple
> rigs can be connected on the same wire. It would be worth adding an
> address field in the format to accommodate this feature.

I would either use two TLVs (one to specify the rig, another to specify
the command) or two TLVs within the Value portion of the TLV.  Either
way, this preserves the TLV structure, in the sense that it can be
parsed by a library routine that doesn't have to know about the values
of the Type field  (e.g., the generalized parsing routine doesn't have
to know that if the Type equals some value, that special processing is
required).  Again, this provides a layering of software by function.
(See the Java Parameter class for an example of a nice generalized
routine for processing parameters.)

-tjs

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



AMSAT Top AMSAT Home