HAM Radio 1

home *** CD-ROM | disk | FTP | other *** search

/ HAM Radio 1 / HamRadio.cdr / packet / packetcl / packet.tut < prev next >

Wrap

Text File | 1986-04-02 | 21.5 KB | 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.