Order Tray | Contact Us | Home | SIG Lists

[aprssig] TNC command formats

Scott Miller scott at opentrac.org
Wed Mar 16 18:54:45 UTC 2005


My TNC's command interpreter is now up and running, and I'm pondering the
best way to proceed with the command set.

So far I've been following the TNC-2 style commands, with an interface
modeled on the one used by Kantronics, with some minor differences.  For
example, a Kantronics TNC will use the first matching command from its list
that matches a partial command, while mine will accept a partial only if
there's a single, unambiguous match.  Error responses, help screens, and
that sort of thing are different, but my intent is to provide some
compatibility with existing software, and reduce the learning curve for the
user.

There are some things I don't like about the Kantronics style, though - in
particular the multi-port handling.  They have you use a / to separate
options for each port, thus:

HBAUD 1200/9600

I don't like this, and I don't think it scales well to devices with more
ports.  It's unwieldy, at the least.  Plus, my device supports multiple
console connections - even in the current prototype, you can have a command
session open on both the RS-232 port and USB COM port, and be entering
commands both places.  This means that commands that affect the console
connections need to be multi-port as well, with some port/option pairs (like
baud rate for USB) being invalid.

I'm leaning more toward a command structure like that used in Cisco's IOS
(see <http://www.cisco.com/warp/public/710/lst/IOStutorial.htm>).  In config
mode, you tell it to configure an interface, and all setup commands after
that apply to the specified interface.  So rather than HBAUD 1200/9600,
you'd use something like:

CONFIG PORT 1
HBAUD 1200
CONFIG PORT 2
HBAUD 9600

Or maybe abandon the TNC-2 style altogether...

configure
 interface serial 1
  baud 19200
 interface radio 1
  baud 1200
 interface radio 2
  baud 9600

Though that's going to mean a steeper learning curve (at least, for those
not used to IOS) and lack of backward compatibility.

Keep in mind that the TNC has a file system, and will be able to load its
configuration from a named file - so the command format needs to make sense
both in the context of the command line and a configuration file.  And
remember, it should still work when expanded to an arbitrary number of
(possibly dissimilar) ports and interfaces.

I'm leaning toward my first example, with the TNC-2 / IOS sort of hybrid.
If you've got any suggestions on what you'd like to see, speak now or
forever forfeit your right to bitch about it in the future - or at least,
forfeit your right to have me care about your bitching about it.  =]

Scott
N1VG





More information about the aprssig mailing list