World of Ham Radio 1997/WOHR97_AmSoft_(1997-02-01).iso/packet/docs/packet_a.doc

Text File | 1997-02-01 | 22KB | 411 lines

                 HamNet Packet Radio Tutorial - Part One
                 ---------------------------------------

                        by Scott Loftesness W3VS
                           CompuServe 76703,407

Now that your SYSOP has begun experimenting in the exciting new world of
Packet Radio, I thought it might be interesting to others here on HamNet
to begin sharing a bit more of this new technology.
.
.   Recently, I've uploaded a couple of news items which have highlighted
commercial applications of packet radio techniques: the Genstar system
being developed by Gerard O'Neil of Princeton University and the recently
announced Motorola Portable Communications Terminal. I believe these
to be just the first of many announcements we will see in the coming years
as the packet radio form of digital communications finds even more
commercial applications.
.
.   In the meantime, we amateurs are blazing many new trails in this
technology - from the simple TNC idea to the elegant PACSAT orbiting
bulletin board system. Most of the success of the amateur radio packet
efforts is due to a group of true enthusiasts scattered across the
United States. Leading the way were our Canadian friends to the north who
developed the original "Terminal Node Controller". Doug Lockhart and his
friends in Vancouver developed an 8085-based TNC in the late '70's and
its popularity spread quickly as they made available the PC board and
parts kits.
.
.   Pockets of packet interest rapidly developed in the Washington, DC,
Tucson, AZ, and San Francisco Bay Area - to be quickly followed by
new groups in St. Louis, New Jersey, and Southern California. The first
ARRL Packet Radio Conference was held in October, 1981 in Gaithersburg,
Maryland - and provided the first truly international amateur packet
get together. Plans were reviewed - and ideas shared. One of the
attendees, Den Connors, KD2S, moved off to Tucson to join a rapidly
growing group of friends and formed Tucson Amateur Packet Radio. This
energetic group began the creation of a completely new, "second generation"
TNC - building on the best of the original work done in Vancouver.
.
.   While the Tucson group was developing the hardware for a TNC, a group
led by Tom Clark, W3IWI, became concerned about the lack of any kind
of amateur standard as far as packet radio protocols were concerned.
The original Vancouver protocol worked fine for a small group in a
single geographic area - but clearly would not support the kind of
growth in packet radio enthusiasts that was expected. In addition, the
onset of the Phase IIIB amateur satellite and its packet radio repeater
possibilites added impetus to the need to develop a new standard.
.
.   Meeting in October, 1982, this group developed a new amateur standard
called AX.25. The standard was completed just in time - it was incorporated
into the original version of the Tucson (TAPR) TNC board in late 1982.
Approximately 200 of the TAPR boards have been distributed nationwide -
for extensive field testing of the hardware/software combination. This
board has become a real hit - it worked beyond anyone's expectations and
has created a tremendous additional interest in packet radio. The test
phase is nearly complete - and will be followed by availability of a
parts kit later this year for general distribution through the amateur
community. By this time in 1984, amateur packet activities will have
grown dramatically from the several hundred current experimenters to
many more amateurs - and with exciting implications for new applications
using the new technology.
.
.   The TAPR TNC is a remarkable piece of equipment - and a truly elegant
hardware/software design. We'll spend some time describing some of the
details of this TNC. Much of this material is directly from the
excellent manual which accompanied the beta test boards - and which is
available from TAPR for $15 (PO Box 22888, Tucson, AZ 85734).
.
.   The TAPR TNC is the result of a tremendous design effort by many
people including Mark Baker, Marc Chamberlin WA7PXW, Pete Eaton WB9FLW,
Chuck Green N0ADI, Dave Henderson KD4NL, Lyle Johnson WA7GXD, Dave
McClain N7AIG, Dan Morrison KV7B, Margaret Morrison KV7D, and Harold
Price NK6K, along with Den Connors.
.
.   Very few terminals or home computers contain the hardware and
software necessary to attach to, and control, an amateur radio.
Compatibility between such systems could obviously be a problem.
Because of this, extensive testing and use of packet radio without some
additional tool would be very difficult, if not impossible.
.
.   The TNC is that tool. It is connected between your terminal (or
computer) and your amateur radio. Just what is it that the TAPR TNC
provides? Between the interfaces to your terminal or computer and
your radio is a complete microcomputer with memory and input/output
devices. This microcomputer with appropriate software is used to
implement the packet radio protocols. Thus any computer can be interfaced
to any other computer via amateur radio using the TNC.
.
.   The TAPR TNC connects to an RS-232-C interface, found on most terminals
and home computers. A parallel interface is also provided, although not
supported for terminal interfacing in the initial software release. The
necessary connections exist to interface the TNC to your amateur radio
equipment. These connections include lines to your external speaker
(or earphone) jack and the microphone jack (both for microphone audio
and for push-to-talk control).
.
.   Also included is a complete modem used to convert the digital
information coming from the computer or terminal into an analog
signal (a set of audio tones) which your radio can transmit. It
also performs the reverse function, converting analog signals from
your receiver to digital data. Because of the bandpass characteristics
of many amateur radios, an active audio filter is also included in the
TNC. Passive filters proved inadequate to support transmission rates
of 1200 baud - a design objective.
.
.   Power for the electronics on the board required four different
voltages: +5, -5, +12, and -12 volts. The TNC includes on board power
supplies for these voltages and uses a custom wound power transformer
designed specifically for TAPR and included with the board.
.
.   But hardware is only part of the TNC. Software is equally (if not
more) important, for it's the software which makes this hardware useful
in handling packet radio protocols.
.
.   The TAPR software was designed to support two interfacing requirements.
The first interface is to the computer or terminal and involves
processing commands and assembling data into packets. Also, packets
received must be processed and formatted for display back to the
computer or terminal. The second interface is the radio interface
which provides two different packet communications protocols (AX.25
and the original Vancouver protocols), keying the radio, and sending
proper Morse code identification using your call sign. The protocol
involves accessing the shared radio channel, formatting and sending
packets, receiving and deciphering packets, and filtering out packets
not intended for your station.
.
.   The software is implemented on the TAPR board in read only ¡emories
(ROM's). 24K of ROM is provided on the board for this purpose, along
with 6K of on-board random access memory (RAM).
.
.   The TAPR TNC beta test version sold for $200 - a very low price
for such an incredibly well-designed and engineered unit! As mentioned
earlier, the initial tests using this board have been most impressive.
I'll provide a more detailed description of both the hardware and
software components in forthcoming tutorial messages.



                 HamNet Packet Radio Tutorial - Part Two
                 ---------------------------------------

                        by Scott Loftesness W3VS
                           CompuServe 76703,407

.
.   We'll continue our tutorial on packet radio by reviewing in more
detail the hardware and software implemented on the Tucson Amateur
Packet Radio (TAPR) Terminal Node Controller (TNC).
.
.   The TAPR TNC is a self-contained, microprocessor-based device intended
to act as an intelligent interface between a user's ASCII communcations
system (terminal or computer) and radio-based packet communications.
.
.   A 6809 microprocessor acts as the system CPU in the TAPR TNC. The
6809 is readily available and widely accepted for application in
dedicated function controllers as well as general purpose low-end
computers. It executes the software stored in the system's EPROM's.
.
.   The 6809 has an internal 2-phase clock generator and provides
control, address, and data bus input/output for family peripheral
devices. It has capabilities for position-independent code and is
designed to support multiple stacks, making it very efficient for
executing block structured high level languages such as Pascal and
Forth. Information on the 6809 architecture is available in Motorola,
Hitachi, and AMI literature - and in several books which are widely
available in the computer sections of most bookstores.
.
.   The serial port is designed to provide a full-duplex RS-232-C
interface for the user's terminal or personal computer. Full baud
rate selection from 50 baud to 19.2 kilobaud is supported by the
port. EIA RS-232-C levels and transition rates are implemented as
well. The serial port is controlled by a 6551 LSI UART which contains
an internal, software-controlled baud-rate generator. The transmitter
and receiver are double-buffered and capable of interrupt-driven
operation. The 6551 supports hardware flow control - allowing the
terminal or computer to pace input and output from the TNC. 1488 and
1489A devices are used to translate the TTL levels from the 6551 to
RS-232-C levels for the port itself.
.
.   A parallel port is also included on the TAPR board. Although not
used for terminal support in the initial releases of the supporting
software, it is used for certain status indications. A 6820 is used
to provide two 8-bit TTL-level handshaking ports.
.
.  The system port interfaces to other devices on the TNC itself.
These include a non-volatile RAM chip used to store certain of the
system parameters across power-downs, DIP switches used for certain
reset options, the HDLC controller chip, and an indicator driver
interface for a variety of LED-monitored system functions. Implemented
using a 6522, the system port also includes timing functions used
for HDLC baud rate generation, software timing functions, the CW
identification, and on-board calibration of the modem frequencies.
The 6522 is a very powerful LSI chip which incorporates a pair of 8-bit
programmable I/O ports, four control lines (for handshaking), two
16-bit programmable timers/counters, and an 8-bit shift register.
The non-volatile RAM is used to store system parameters that are not
normally changed such as call sign, terminal attributes, and timing
parameters, but which remain user alterable. This allows configuration
changes for a given session only, or on a "permanent" basis. The system
port also handles the interface to the radio push-to-talk circuitry.
.
.  A Western Digital WD1933B HDLC controller is used to implement
the HDLC standard bit oriented protocol including CRC check sum and
zero bit insertion. The HDLC controller interfaces to an on-board
1200 baud modem providing phase-coherent AFSK modulation (with Bell
202 compatibility) using the EXAR 2206/2211 chips. Also included
is the necessary impedance matching circuitry for interface to
most popular amateur radio equipment. A 14-second hardware "watchdog"
timer is inserted in series with the transmitter push-to-talk line
to prevent accidental RF channel lockout which might be caused by
a software error.
.
.  A unique feature of the TNC is the capability for on-board
calibration of the modem tone frequencies. This is accomplished
using jumpers which allow for the modem to be disconnected from
the HDLC chip.
.
.  The on-board memory bank consists of six JEDEC-standard 28-pin
"byte-wide" sockets. Three of these sockets are mapped for 2K
static RAM's. The other three sockets are mapped as 8K EPROM or
static RAM sites. The configuration supports 2716, 2732 and
2764-type EPROM's. A custom memory map PROM is included which
provides the address decode for the ROM and RAM chips.
.
.  Also included on the TAPR TNC board is a user wire-wrap area -
primarily to allow custom interfaces to be developed to support
unusual radio interface requirements. Power busses are included
in the area so that active devices may be added directly onto the
TNC board itself as may be required by the user.
.
.  This completes the hardware description of the TAPR TNC. As you
can see, it's a very complete design using the latest in LSI
chip technology.



                 HamNet Packet Radio Tutorial - Part Three
                 -----------------------------------------

                        by Scott Loftesness W3VS
                           CompuServe 76703,407

I'm going to continue this series by describing the operation of the
Tucson Amateur Packet Radio (TAPR) Terminal Node Controller (TNC) -
and the tremendous function which has been implemented in the TNC
software will become readily apparent!
.
.       The TAPR TNC operates in one of three modes:
.               Command Mode
.               Converse Mode
.               Transparent Mode
.
.       Command mode is used to modify various software operating
parameters. Converse mode and Transparent mode are both data transfer
modes - supporting transmission and reception of packets across the
radio link.
.
.       Command mode is automatically entered upon power-up or reset of
the TNC. It can also be entered from one of the other modes by sending
an appropriate control sequence from the terminal to the TNC. For
example, if I'm running in Converse mode, I can get to command mode by
simply entering a control-C. I can they make any operating mode
parameter changes I need to, and return to Converse mode by using the
CONVERS command. The flexibility the TNC provides in this regard is
really outstanding. You can switch into and out of Command mode very
easily - and not lose any data coming across the link.
.
.       Many of the parameters which can be altered in Command mode
are saved in the NOVRAM chip mentioned earlier in this series. This
chip is an electrically erasable read-only memory - and permits me,
for example, to save away my call-sign (which becomes my address
in the AX.25 protocol) so that I need not reset it every time I power
up. The NOVRAM really helps make the TNC startup procedure extremely
simple - since most all of the parameters I have tailored have been
tucked away into the NOVRAM.
.
.       In addition to the NOVRAM, the ROM contains a set of default
operating parameters which can be invoked to completely reset the
NOVRAM values. This is helpful after experimenting with a number
of parameters - and deciding to start over from the ground up!
.
.       To give an example of how simple it is to get the TNC "on-the-air",
the following sequence of commands will take the TNC from power-up to
Converse mode:
.               MYCALL W3VS   - Sets my callsign into the address field.
.                               (Only necessary once!)
.               PERM       - Save my callsign into the NOVRAM.
.
.               CONVERS       - Enter Converse mode.
.
.               Hello Test    - Sends an unaddressed packet with the text
.                               "Hello Test".
.
.               Ctrl-C        - Returns to command mode.
.
.               CONNECT K8MMO - Requests that I be connected to K8MMO.
.                               Automatically enters Converse mode if
.                               K8MMO acknowledges my CONNECT request.
.
.               Hello Dave    - Sends an addressed packet to K8MMO with
.                               the text "Hello Dave".
.
.               Ctrl-C       - Returns to command mode.
.
.               DISCONNECT    - Disconnect from K8MMO.
.
.       As you can see, operating the TNC is really a breeze. In fact,
from power-up to being on the air is typically a matter of a few seconds.
.
.       Among the parameters which can be altered in Command mode are
several which determine how the TNC responds to what it hears on the
radio link. For example, I can tell the TNC to monitor all packets it
hears - including those not specifically addressed to me. This is obviously
useful for "reading the mail" on the channel! In fact, I can tell it to
monitor all activity, or just activity either TO or FROM a specific
station. In addition, I can tell the TNC whether I want it to become a
digipeater - a digital repeater which repeats what packets addressed
to another station but containing my callsign as a repeater address.
(It's interesting to note that the default is digipeat on - it's so
automatic that I really don't know (other than by hearing my radio
got on and off) that I'm being used as a digipeater!
.
.       I can also define the specific operating parameters for the
link. Items such as the length of a packet (default of 128 bytes),
whether it should send a packet when it sees a specific character
(default is carriage return) or send a packet after so many seconds
of inactivity from my terminal. I can also cause the TNC to automatically
send a beacon every so many seconds or send it after so many seconds of
no activity on the packet channel.
.
.       I've just shown a few of the features available in Command
mode on the TAPR TNC. The software is extremely well done - and using
the TNC is a pleasure! You immediately sense that this box was put
together by folks who really understand both the hardware and the
software aspects of microcomputing and communications!
.
.       Let's talk now about Converse mode. As shown in my example, I
can cause the TNC to enter Converse mode by entering the CONVERS
command and also by connecting with another station. The TNC will
also automatically enter Converse mode whenever another station
requests a connect with me! In this case, it prints out a message
saying:
.
.       Connected to K8MMO
.
.and enters Converse mode. From that point on, whatever I type is
sent to the other station.
.
.       If I'm not connected to another station but enter Converse
mode using the CONVERS command, my packets will be "unaddressed" and
only can be copied by other stations which are monitoring all
packets on the channel. This is the technique used to say "CQ" on a
packet channel. For example, on my TRS-80 Model 100, I have created
a CQ file which I transmit containing my name, address, callsign,
station equipment, phase of the moon, etc.! To say CQ, I simply send
this packet. If others are around, typically one will connect with
me and our QSO has begun!
.
.       Earlier, I mentioned the digipeating mode. I can cause my
packets to automatically be sent via a repeater. I simply say:
.
.       CONNECT K8MMO VIA WB4JFI-1
.
.WB4JFI-1 is a local AMRAD repeater run by Terry Fox which is available
24 hours per day. In this case, my station sends its packets to WB4JFI-1
which verifies that they are valid packets (i.e. frame check sequence
is valid) and then retransmits them to K8MMO. Neat!
.
.       Well, we've covered Command and Converse modes pretty thoroughly.
Let's now talk about Transparent mode. Transparent mode allows you to
effectively turn the TNC into a modem - i.e. it will not locally echo
characters, will ignore command/control character sequences, etc. The
advantage of this mode is in transferring files which might contain
any of those characters. In Transparent mode, it's possible to transmit
a binary file to another station. With the built-in error detection and
correction of the AX.25 protocol, error-free transmission is guaranteed!
It's possible to exit from Transparent mode to Command mode by sending a
very specific sequence of characters (default is three control-C's sent
with no other data for one second before and after). Obviously, the odds
of this sequence occuring in normal transmission is very, very low - which
is just what's wanted in Transparent mode.
.
.       Another use of transparent mode is in running a computer system
at the other guy's station. For example, I have run the CP/M system at
K1HTV in this manner - and run BASIC programs, CP/M commands such as
DIR to get a file directory listing, etc. It's just like sitting at the
console of that other system - with the addition of a time delay
required for transmission of the packets at 1200 baud!
.
.       Well, we've pretty well covered the operational aspects of the
TAPR TNC. As you've seen, it's an extremely versatile device - and
provides nearly all of the functions you'd want!
.
.       You are probably a bit curious (I know I was) about the
software package used in the TAPR TNC. This excellent package was
written in a combination of Pascal and 6809 assembler by Harold Price
NK6K, Dave Henderson KD4NL, and Margaret Morrison KV7D. The bulk of
the code was written in Pascal while assembler was used for the
interrupt handling and data buffering routines. The Pascal code
effectively relies on the assembler code as device drivers for the
hardware interfaces present on the TNC. The combined package is over
20K of code - stored in the ROM of the TNC.
.
.       This concludes this section of the packet radio tutorial.
Next, we'll describe some of the activites underway in the Washington,
DC area with packet radio - and some of our plans for the future.