A Ham Radio Operator: Is he unreasonable?

Read more articles on ham radio

With acknowledgment to Tony Lonsdale, VK2DHU, we reproduce below the introductory article of the manual he has provided with the shareware version of his PACKET RADIO communication software (Paket6). Hams interested in digital communication may  wish to go through it!

RTTY AMTOR PACTOR Software

PART I - INTRODUCTION
Welcome to paKet.
paKet is one of the world's most popular programs for amateur radio communications and if this is your first look at paKet I hope you will soon agree it IS "the best Packet Radio software in the world". paKet is a communications program developed especially for use with Packet Radio, although it can be used for other modes with the appropriate equipment. It is designed to run on any IBM compatible computer system and to communicate through a standard TAPR-compatible Terminal Node Controller (TNC).The program is very easy to use, even for newcomers to this field. As you gain experience with the system, you can explore some of the more sophisticated features which are provided to meet the needs of even the most demanding packet operators. It is simple if that is what you want; and it is sophisticated if that is what you want. The modern trend is towards Graphical Environments with the likes of Windows, or OS/2. paKet is written to run as a plain DOS program so if you have an old XT with a CGA or even a Mono display system gathering dust in the corner, paKet will run on that just fine. Packet radio is an excellent application for the older systems that are not much use for anything else nowadays, so it is quite feasible to dedicate an older system to running paKet 24 hours per day. What else do we do with those older systems now? We used to give them to the wife or children to use as a Word Processor, play games, etc but many modern Word Processors need at least 4MB RAM, 10 to 20 MB of disk, 80386, etc... The good games are not much better. Thank Goodness for packet radio! If you are running Windows, OS/2, DESQview, etc you will find paKet runs quite happily in the background as a simple DOS task. In addition to providing the usual Terminal Mode where you can send and receive data via the TNC, the program provides many features and facilities to enhance the operation of your Packet Radio system. Such features include: Full Personal Message System with automatic Mail Forwarding to the BBS Flashback feature to review earlier communications Disk and/or printer logging ASCII text file transfers Exchange computer programs and other disk files with: paKet-Protocol, an advanced Binary File Transfer protocol YAPP Binary File transfer protoco BayCom Binary File transfers (Digicom supported too) Full online TNC help for your TNC commands Online Manual - this entire Manual is available in a pop-up window Interrupt driven communications, so you don't lose anything even when paKet is running in a Multi Tasking environment. Runs on COM1, COM2, COM3 or COM4 Both Hardware and Software Handshaking supported Multiple windows for up to 10 simultaneous connections REMOTE Mode - (unattended access) Access to DOS, your favourite editor, and file LISTer from within paKet Automatic Script processing.............. etc etc etc paKet is fully configurable so you can customise a system especially to suit yourself. Setting up your system is but a matter of a few keystrokes - see the Configuration Windows section of this Manual for details. paKet uses the standard Command Mode (sometimes called Terminal Mode) of the TNC. Some other programs require HOST Mode or KISS Mode and so they will often run only on specific TNCs. But paKet will run with any TAPR-compatible TNC and that includes just about all TNCs on the market today. paKet is a sophisticated communications system and it may take you a while to become familiar with all its features, especially if this is your first look at paKet, but it is designed to be "friendly" and as easy to use as possible. You do not need to use all its features if you would rather keep it simple to start with. Help is always available at the touch of the <F1> key if you forget what key to press. However, you really should read through the entire Manual to get the most from the paKet system. In the remainder of this Introductory section I would like to talk a little about computers and where they fit into the scene. And I will cover packet radio principles generally, especially for those who are new to this mode of operation. I will also cover some other digital modes because we often find the same equipment used for packet can alsobe used on some other modes as well. The remaining chapters of the Manual are a reference for the paKet program, explaining the various part of the system and helping you to get the most out of it. This Manual has been fully revised, so if you are upgrading from an earlier version of paKet you should scan through the entire Manual. Some of it was found to be still relevant and has been retained without change; where necessary, sections have been edited to accommodate improvements in version 6; and some sections have been significantly rewritten. I hope you like paKet and find it adds to your pleasure when operating your equipment in this exciting new generation of radio communications.
Tony Lonsdale, VK2DHU
Computers - how it all began
From the mail I have received over the years, I gather there are many paKet users who might be experienced with radio and electronics, but are relatively new to Computers. So I though it would be worthwhile toprovide a brief introduction to Computing. In this section I will give you a bit of background and history so you can see how it all came into being and how we got to where we are today. Although computers are commonplace now in Amateur Radio shacks, it is a relatively new technology and there are a large number of Amateur Radio operators who are embracing this technology for the first time when they explore the world of digital communications, such as packet radio. It was during the 1970s that we saw the dawning of this new Computer Age. Until then, computers were the exclusive domain of the Scientific Community and Large Business or Government organisations. To have a computer in the home was unheard of, even in the early 70s. Some amateurs who also happened to be computer enthusiasts, might have been involved from the beginning, but for most it is only since the mid 80s that computers have made their presence felt. Actually it all started back in the 1940s. That is, if we don't count the "calculating machines" designed by people like Leonardo da Vinci (circa 1500), Blaise Pascal (1653), Gottfried Leibnitz (1673) or Charles Babbage (1820). But in was in England in the early 1940s that a group of scientists and mathematicians developed a series of special-purpose computers including the "Colossus", to crack the secret message codes being used by the Germans during the War. The first ones used lots of electromechanical relays and occupied vast rooms, generating lots of noise and heat. They were relatively slow too.

Then came the development of the Valve or Tube. Remember the old radios and TVs that had to warm up before they came on? (You are showing your age if you do!) This technology enabled technicians to get rid of the slow and noisy relay switches and build a much faster and more reliable computing machine. This was the real beginning of Electronic Computing as we know it today. In 1944 at Harvard University in the USA the first general purpose PROGRAMMABLE digital computer was produced using both relays and tubes. It was called the "Mark I". In 1946 ENIAC, the first fully electronic computer with about 18,000 valves/tubes arrived on the scene. It weighed around 30 tons, covered 150 square yards of floor space (they didn't use the metric system), and needed its own power sub-station as it used 150 KILOWATTS! This like "Mark I" was programmed by hard wiring. That is, to change the program, you had to rewire the computer! ENIAC is reported to have cost $600,000 which was a lot of money in 1946. The first stored- program computers, EDSDAC and BINAC, arrived a few years later. The first commercially available stored-program computer, the UNIVAC-1,became available in 1951 and was used to process the voting for the 1952 Presidential elections. It announced President Eisenhower as the winner less than an hour after voting closed. The transistor was discovered in 1947 and its potential was realised as it began to appear in all types of electronic devices from the portable radio (the "Trannie") to a new generation of computers. These "solid state" computers, known as the Second Generation of Computers, appeared in the early 1960s and were faster and smaller than their predecessors and even more reliable. In 1958 Texas Instruments developed the first Integrated Circuit or "IC", sometimes called a chip because it is manufactured on a chip of

silicon. These miniature circuits whose detail can be seen only with the aid of microscope, can contain many thousands of transistors and other components in a circuit smaller than the size of a small finger nail. With this technology, more computing power could be built in a smaller space with not only cost savings but also with lower power requirements meaning less heat and less cooling requirements. Things were really happening now! These computers were known as the Third Generation. In more recent times we have seen the development of the VLSI (Very Large Scale Integration), and ASIC (Application Specific Integrated Circuit). These chips pack even more electronic circuitry into a smaller space than before and one wonders how far we can go with this miniaturisation. It is getting to the stage where we have to build the components smaller so the electric current doesn't have so far to travel - the closer they are, the less time the electricity takes to get there. In other words, the computer can be held up by the Speed of Light!!!
Computers - Personal Computers
The computers developed up to the mid sixties were not really classified into big and small computers. They were all BIG, some bigger than others. But in 1965 Digital Equipment Corporation (DEC) announced the first Mini-Computer, the PDP-8. This was a much smaller computer with less computing power but it sold for less than $20,000. It became one of the Computer Industry's biggest success stories. At last ordinary scientists and engineers could get access to computers, not just for calculations but for controlling and monitoring lab experiments. In 1973 the first Micro Processor was developed. Most of the parts for the processor section of a computer were reduced to the size of a single chip. Developing technology enabled the cost of these chips to be reduced from hundreds of dollars to around twenty five dollars within a few years. The same technology developments produced higher density memory chips whose prices were also falling dramatically. It was now possible to produce a general purpose Micro Computer that was even more powerful than the first Mini Computers for less than $1,000. It took a little while for the world to appreciate the potential of these little Micro Processors. It was the enthusiasts, the hobbyists, the amateurs, who started to build their own Micro Computer around the mid seventies. Note, they had to BUILD it; there was nowhere to BUY one of these things at that time. Of course, in those days there was no software for these computers so any program had to be fed manually into memory via the front panel switches. But these WERE enthusiasts! Around this time, it started to take off. There were several events that I believe triggered the whole Personal Computer Industry. In the mid seventies IBM were promoting the use of a diskette (8 inches diameter, single sided, 128KB capacity) in some of their business machines. A Mr. Gary Kildall, who worked for Intel Corporation, the manufacturers of the Micro Processor chips, saw the potential of these diskette storage devices and developed some software to connect them to his Micro Processor at Intel. It was far superior to the Cassette Tape storage medium used until then. He asked the company to support him in this software development. They didn't agree so he left and formed his own company to develop and market this software. That company became known as Digital Research Inc. and the software, CP/M, was the most popular operating system for Personal Computers for many years and one of the early success stories. Digital Research was a rival to Microsoft in the early 80s and almost established its domination of the Personal Computer Operating System market. If just a couple of phone calls and hurried meetings with IBM had gone differently, Bill Gates might not be the wealthy man he is today. Anyway, in the late 70s and early 80s, CP/M was the dominant system and, because CP/M was available on a variety of computer systems, it established a standard that software developers could use when developing their software. In 1977 there were some other success stories, the development and marketing of the Apple Personal Computer and the Tandy TRS-80 Personal Computer. Here we saw the first of the consumer-targetted Personal Computers. You just bought it, plugged it in, and used it. There was still not a lot of software available for these things but at least you didn't have to build it! For the first time we saw computers that didn't have front panel switches, flashing lights or spinning wheels.They didn't look like the computers Science Fiction fans knew so well. By now some good software was being developed for these machines and the better software generated more interest in the computers so the market grew which meant more software development which meant... etc. The next big event in the development of the Personal Computer was in 1981 when IBM, the giant of the Computer Industry, introduced their own version of the Personal Computer. In fact it was called the "PC" and that term is now used interchangeably with any Personal Computer. With IBM involved, the business world took a closer look at what was often regarded as a toy or games machine. The potential was once again realised and as the Personal Computers began to find their way into Businesses, we saw the development of more sophisticated software. Everyone has been struggling to keep up ever since. Because of the enormous size of IBM, their established presence in the Computer world, and the prestige associated with the name, everyone sat up and took notice of the IBM PC. The design and the technology they implemented for their PC was rather conservative, but it was "IBM"! When the system was released, IBM also released full technical details of the system, including details of the hardware and the firmware. Some pundits saw this as a foolish move, thinking IBM failed to appreciate the significance of this "little home computer". (I am sure the pundits were correct in that IBM did fail to appreciate that significance). But perhaps, unwittingly, releasing the technical information proved to be a very successful move, at least for us, the computer users and for the industry generally. As a result of this information being freely available (in the Public Domain if you like) and with the instant success of the IBM model, we began to see other manufacturers building computers that were based on the original IBM design. They called them "clones" but those of you who experienced some of those early clones will remember they were not exactly clones at all - many of them bore little resemblance to the IBM machine. But it was the start of an industry within an industry. Nowadays the clones have taken over to the point where we tend to use the term "Industry Standard" or "Intel machines" (because Intel have a stranglehold on the "IBM clone" market). To many people a "PC" is any model of any IBM Compatible computer. Some even refer to these systems as "DOS" machines because of the most popular operating system running on these computers. The degree of compatibility is no longer a problem and all modern IBM-compatible clones conform to the evolving industry standards. In some ways, IBM's own PS/2 range are the only ones not entirely "IBM Compatible!". paKet requires an IBM Compatible computer, but I am happy to say it will run on a IBM PS/2 as well. There are other types of Personal Computer. The biggest competitor to the IBM clone models is the Apple Macintosh. This is a very nice machine with a Graphic/Mouse interface that "Mac" users claim is an easier way to use the computer. The Mac uses a Motorola processor which is different to the Intel (or compatible) processor used in the IBM clones. So the Mac programs do not run on the IBM and the IBM programs (including paKet) do not run on the Mac. It is possible to add some optional equipment to the Mac to allow it to run IBM software but if that is your aim, you would probably be better off to get an IBM Compatible maachine to start with. Other computers include the Amiga which again has lots of nice features but unless you buy some added equipment, they too will not run IBM compatible programs. There is still a very loyal band of Commodore 64/128 users. This is perhaps the cheapest way into packet radio, but these systems are beginning to show their age as they generally offer fewer facilities than we get from more powerful systems such as an IBM Compatible computer running paKet. The quality, availability, performance and value for money of modern Personal Computer systems are constantly improving so that the humble PC is now widely used in business of all sizes, in schools and Universities, in homes, and of course in radio shacks all over the world. Welcome to the world of computing. You are certainly not alone!
Digital Communications
Digital Communication is not new. Other Modes such as Morse Code, RTTY and AMTOR have been around for years. But the newer modes, Packet Radio and PACTOR offer some significant improvements, perhaps the most significant is Error Free communications. Let's have a brief look at these modes. Morse Code. Morse Code is the original Digital Mode dating back to the last Century! Today, while the debate rages over Morse Code licensing requirements, more and more stations using this mode have replaced their hand key and their electronic keyer with a Computer keyboard and display. The technology is good but even today, no machine can beat the trained human ear for copying hand sent Morse Code under varying conditions. The keyboard is a more efficient Sending device though, for most people. Perhaps the one advantage of Morse over Packet and the others, is that a human operator can decode the Morse Code transmissions by ear!

RTTY R

DIGITAL MODES OF COMMUNICATION


RTTY or RadioTeletype is a direct machine to machine communications mode using the Baudot (or Murray) code. This mode became popular with many amateurs when surplus TTY machines became available at a reasonable cost after World War II. These mechanical monsters provided a keyboard for Input and a paper roll for printed Output. They were also useful to help hold the house down in times of hurricane winds - they must weigh a ton. Video displays were still too exotic and expensive in those days. It was not until the mid 1970s that we began to see the Video Display come into more widespread use. (By the way, have you ever wondered why early Program Languages like BASIC use the command PRINT to display their output?) When transmitting Morse Code, the transmitter is switched on and off to make the dits and dahs. When sending Teletype however the transmitter runs continuously, sending either of two frequencies conventionally known as Mark and Space (a reference to paper tape reception of telegraphy). The early pioneers found on-off keying was not all that successful for Teletype signals because of interference from static. They experimented with FSK, or Frequency Shift Keying and found it performed much better. With FSK, the transmitter is shifted up in frequency every time a Mark is to be sent, reverting to the lower frequency for a Space. The amount of the shift is usually 170 Hz for Amateur Radio use although many commercial Teletype signals use other shifts, notably 425 Hz and 850 Hz. Many systems use AFSK or Audio Frequency Shift Keying. When this is used, the transmitting station generates the Mark and Space audio tones and feeds them into the transmitter's microphone input. The result at the receiving end is that the same audio tones are heard and processed, whether the transmitting station used FSK or AFSK. When listening to a teletype signal off air, you will soon get to recognise the familiar warble of Mark and Space tones. In the amateur shack the TTY machine is usually connected to an HF receiver or transceiver which the operator tunes so that the received audio is just the right pitch or audio frequency to trigger the demodulator's Mark and Space resonators. If the receiver is slightly off the correct frequency the tones vary and the text becomes garbled or even lost altogether. To help the other station tune the receiver correctly, a RTTY operator can send a string of alternate R and Y characters viz: RYRYRYRYRY. This pattern is chosen as it produces the most frequent and almost symmetrical alternation of Mark and Space tones, giving the receiving operator the best chance to tune the receiver before the "real" message starts. However, even if the signal is accurately tuned, the information can become garbled or completely lost due to interference, fading, or noise. Often, it is possible to make sense of the message even with parts missing, but RTTY is by NO means an error free mode! I should point out that similar problems exist for other modes including Packet. While information can still fail to get through on the more sophisticated modes the Error Detecting capability of some, especially Packet and PACTOR, ensure that the operator will receive either accurate information or nothing at all. Usually, where "nothing at all" is received, the information will automatically be retransmitted when the radio is retuned, or the interference stops, (etc) and nothing is lost. The Baudot code is a 5 bit code and those of you who are familiar with Binary Notation will know that the maximum number of values we can have with 5 bits is 32. That means that each unit of transmission, one keystroke if you like, can contain any one of 32 possible values. If you look up a table of Baudot codes you will see there are 32 values listed, one code for each letter of the alphabet plus a few other codes for other things such as a space and a Carriage Return. But, what if we want to send a number such as "9" or a question mark? These are not mentioned in that table because all 32 codes are already used. The solution is rather similar to the Typewriter or Computer Keyboard where we have the Shift key to get various additional codes from the keyboard. Most keys will produce a different result if we hold down the Shift key as we type. Well, one of those original 32 codes is a special code known as FIGS (for Figures Shift). The convention is that when we want to send a number or some other special character such as a punctuation mark, we can do that by firstly transmitting a FIGS code. Then instead of using that original table of 32 codes, we have a second table of codes to use, and that second table includes all ten numeric digits and various punctuation marks. Provided both sides of the conversation observe the convention, the sender can send a FIGS and start using the second table; the receiver will see the FIGS code and it too will interpret all data that follows from the second table. With just 5 bits of data we then have almost 64 different codes we can send and receive. (I say almost because there is some duplication in the two tables, including a space and a Carriage Return but that is not important here). Even that many codes is not enough to handle all 26 letters of the alphabet in both UPPER and lower case, so RTTY systems always operate in upper case only. If we wanted to type a big number (say "13579") we don't have to send FIGS before every digit. We send that code only once and the receiver then will take EVERYTHING we type from now as if it belongs in the second table. When we want to revert to the normal alphabetic table of codes we can send another special code, this one called LTRS (for Letters Shift). Then everything goes back to normal, using the original alphabetic table of codes. Normally we don't have to concern ourselves with these FIGS and LTRS codes. Our computing equipment will take care of those things for us. We just type away and rely on the system to generate and send those codes when necessary. As I mentioned earlier, it is quite possible to lose bits here and there when receiving a RTTY signal, whether it be because of fading, interference, frequency drift, or whatever. One of the big problems with lost data is the possible loss of a FIGS or LTRS code! Say we had sent "13579" and then typed "HAPPY BIRTHDAY". Our equipment would have sent a LTRS code before the first "H" but what if the receiver did not copy the LTRS code we sent? Can you imagine what happens? As far as the receiver is concerned we are still sending numbers or other codes from the numeric table! So our "HAPPY BIRTHDAY" is going to come out looking something like "#-006 ?845#$-6". And EVERYTHING we type from then on is going to look just as strange until we happen to send another LTRS code later. It is for this reason that many systems include an option to "Un-shift on space". If you have a multi mode TNC capable of handling RTTY, you will probably have this option in your TNC. If that option is ON then your receiving system will imply a LTRS code every time it receives a space. So if you seem to be copying lots of funny numbers from a strong, well tuned signal, try setting that option ON. We can overcome some of these problems by using ASCII instead of using the Baudot code. With ASCII we can have 128 different codes so we do not need the FIGS/LTRS codes. All Personal Computers use ASCII as their native "language" so it would be a reasonable thing to use. Although not part of the defined ASCII standard, it has become an almost de-facto standard in the computer world that an additional 128 characters are available, often called Extended ASCII. But, despite these benefits, Baudot continues to rule the airwaves for Amateur and Commercial Teletype transmissions. Today, RTTY is still a popular mode especially on the HF bands, and the advent of the "Glass Terminal", firstly the Dumb Terminal and now the Personal Computer, has brought this mode to even more operators the world over. Many specialised RTTY systems were developed for the Amateur enthusiasts but have been superseded now by the Personal Computer with one of the Multi Mode TNCs which handle RTTY and many other modes besides. The latest Computerised RTTY equipment generally allows us to use the mode better, quieter, more efficiently, using less power and occupying less space than the old TTY machines, but the limitations of the mode remain.

AMTORAM

DIGITAL MODES OF SOMMUNICATION

Experiment Oriented Hams


AMTOR is a specialised form of RTTY. The term is an acronym for AMateur Teleprinting Over Radio and is derived from the commercial SITOR system (Simplex Telex Over radio) developed primarily for Maritime use in the 1970s. In the early 1980's, Peter Martinez, G3PLX, made several minor changes to the SITOR protocol and called it AMTOR. AMTOR improves on RTTY by incorporating a simple Error Detection technique. The system remains relatively uncomplicated but AMTOR performs well even in poor HF conditions. While there can still be many errors in AMTOR data, the Error Detection helps a lot and the result is quite tolerable for normal text mode conversations because of the high redundancy in plain language text. Certainly much better than RTTY. But for more critical data such as program code, or even some technical information messages, NO errors can be tolerated. There are two modes used in Amtor: ARQ and FEC.
ARQ
This mode is a little different in that it is a Synchronous protocol, which means both stations are synchronised to each other's signals. In ARQ mode (Automatic Repeat Query), sometimes called Mode A, data is sent in groups of 3 characters. Although each character is only 5 bits (same as for RTTY), two additional control bits make it up to 7 bits per "character" and they are set so there are always 4 marks and three spaces in every transmitted character. If the receiving station gets some other combination it knows an error has occurred. The 40 percent overhead is considered worthwhile to get some error detection. This technique can identify a lot of errors that might occur but is not as thorough as the methods used in PACTOR and Packet which we look at later. The receiver responds to each 3 character group by sending either an ACK (ACKnowledge) code (if OK) or a NAK (Negative AcKnowledge). Each time the transmitting station gets a NAK, that 3 character group is sent again. If you listen around on the HF bands in the recognised Data Segments of the bands, you might hear a chirp-chirp sound that identifies an ARQ transmission. Even when there is no data actually being transmitted, the transmitting station continues to send idle "chirps" to maintain the link. Your AMTOR equipment probably supports a Listen Mode too and that allows you to monitor another ARQ session even though you are not participating in the session with the usual acknowledgements. Of course that means you don't get the opportunity to say "NAK" if you don't copy something properly!
FEC
In FEC mode (Forward Error Correcting), sometimes called Mode B, the sending station sends each character twice so this mode provides a means of transmitting to several stations at once. The receiving station does not acknowledge the data received. If a receiving station matches both instances of a character, that character will be printed, otherwise some error symbol is printed. This mode does not provide for the receiver to ask for the missing data to be retransmitted. An FEC transmission sounds more like a Baudot RTTY signal. The two stations need to keep in phase with each other so each FEC transmission is started with several sets of "phasing pairs" and these are sent at regular intervals even while there is no data being transmitted. FEC Mode is still better than ordinary RTTY but its error detection is not as reliable as that in the ARQ Mode. AMTOR systems are still limited to the technology of the 60s with limitations such as the character set and the maximum transmission rate (100 baud) geared to the mechanical teleprinter. The Error Detection technique provides improved accuracy over the "vanilla" RTTY mode, but is still not entirely reliable. It is perhaps better termed Error Reduction than Error Detection and has limited application for critical data.

PACTORPA

DIGITAL MODES OF COMMUNICATION

Eeperiment Oriented Hams


Amateur Packet Radio has been in use since the early 80s and is used extensively on both HF and VHF/UHF. But it is better suited to the VHF/UHF bands. It was found AMTOR would often perform better than Packet on the HF bands and so despite the limitations of AMTOR, a large number of HF operators preferred AMTOR to Packet Radio. As computerised systems became more popular, amateurs began to explore more sophisticated options for AMTOR. Various alternatives were tried but every time, AMTOR's poor error handling prevented any significant breakthrough. And as AMTOR did not handle the standard ASCII code, a new Protocol was called for. In 1987 two German amateurs, Hans-Peter Helfert (DL6MAA) and Ulrich Strate (KF4KV) began work on a new Protocol which they called PACTOR. Although this new system incorporated the basic structure of AMTOR with its fixed interval data blocks and corresponding acknowledgements, PACTOR also combines important characteristics of Packet Radio. PACTOR is designed especially for HF operations. There is no reason why it could not be used on VHF/UHF, but it does not offer significant advantages over Packet Radio on those bands. It is on HF that the new protocol shines. The block length of PACTOR is fixed at 1.44 seconds with significantly lower overheads than those of AMTOR. This was found to be the most suitable compromise for HF operations with the relatively short block having a better chance of survival through difficult conditions and allowing short break-in times. The protocol provides for automatic adjustments to the baud rate too, so when the going gets really tough it will reduce the speed; and when things improve it will increase the speed to improve the throughput again. Huffman data compression is used in PACTOR and that adds to the effective performance. The Huffman code is based on the assumption that in plain language text there is a high content of frequently occurring letters such as E, A, etc. It has been found that a block of normal ASCII text can often be compressed to half its original size without any loss of data at all. PACTOR offers high quality error detection, which overcomes the main weakness of AMTOR. PACTOR uses a longer acknowledgement signal as well as the CRC checksum code used in Packet Radio to detect errors in the transmission. I will discuss Error Free Communications with CRC checksums in the next section on Packet Radio, so we'll have a look at that in a moment. The comments there apply to both PACTOR and Packet. Other features of PACTOR include an improved error correction system which has become known as "Memory ARQ". I won't go into the full detail here, but in summary it improves the performance of the receiving system in weak or noisy conditions. For example in any digital system, a signal is reduced to a series of bits which are either a binary 1 or 0, but this does not distinguish between an input signal of a millivolt or 10 volts! So long as the analog input signal is above the threshold, the digital output data is the same! The Memory ARQ system remembers not only the binary 1s and 0s, but also the incoming analog values, so if the received block reveals errors, the analog values from the repeated blocks can be combined into a "sum" block and subjected to another CRC error check. While this system is not perfect it can provide error free communications in conditions that other modes, including Packet, could not handle Packet Radio (AX.25) Perhaps the most important feature of Packet Radio is the Error Detection system it uses to give us Error Free communications. PACTOR is the only other mode that offers such data integrity but Packet offers other advantages that even the new PACTOR does not support. Packet offers simultaneous frequency sharing by several stations, multiple repeater operation ("digipeating") for longer distance communications, and Networking. Error Free Communications. The Error Detection (and Correction) is perhaps the major benefit of Packet Radio over the older modes. (The newer PACTOR mode shares this feature). With Packet Radio using HDLC and the AX.25 protocol, data is checked and verified before being accepted by the receiver's TNC. HDLC (High-level Data Link Control) is a procedure defined by ISO, the International Organisation for Standardisation, for the handling of Error Free frames of information over a communications link. AX.25 is a set of rules defining the format and content of packets and how they are handled. It is not the only Protocol for data communications but is the recognised standard in the world of Amateur Packet Radio. Fortunately we don't have to know the details of either HDLC or AX.25 to use Packet Radio. (I read the AX.25 Protocol Specifications and am still not too sure what it said!) The hard work is done in a special device called a TNC (Terminal Node Controller) which is a small computer in itself, programmed to perform the HDLC Error Handling and many AX.25 functions to make it easy for us. The Error Detection, similar to that used in PACTOR, is much more sophisticated than that used in AMTOR so the result is significantly more reliable. Each block of data (packet) contains various control information including a CRC checksum.(CRC is Cyclical Redundancy Check - true!) This checksum is a value calculated by the sending station based on the content of the data contained in this packet. When the receiving station receives that packet, it performs the same calculation on the data it received and it compares its result with the checksum it received. If there was something wrong with the received data, the checksums will not match and the receiver knows there is something wrong with this block of data. The chance of an undetected error getting through is less than one in a many millions. So, for all practical purposes Packet Radio and PACTOR are considered completely error free. If any data comes through the system to your computer (to paKet in your case) you can be sure that what you see is exactly what the other station sent.

TOP

Frequency Sharing

Packet Radio, like the commercial X.25 Packet Switched systems, allows several simultaneous point to point connections to share the same frequency. In Packet Radio whenever we send a message to another station, our TNC builds a Packet, like an envelope, around our message adding details such as the callsign of the station this message is addressed to. Then, if the frequency is clear, the Packet is transmitted into the airwaves. Our TNC listens to the audio coming from the radio receiver and if there are any other Packet Radio stations using the frequency, it waits until there is a lull in the transmissions before transmitting our Packet. At first, you might wonder how long it has to wait, thinking the other stations might be going for hours! However, in practice, a Packet might take only a fraction of a second to transmit - a relatively short burst of time compared to the time it takes us to type a message. Unless the frequency is really busy, you might not even notice the delay! The Packet Radio frequency in use also carries messages for many people at the same time. When receiving, your TNC looks at every Packet received, checks the address on each Packet and identifies any Packets addressed to you. Any Packets not intended for you may be ignored by your TNC so you see on your screen only those messages addressed to you. This way you need not concern yourself with all the other information flowing around on the frequency, and are free to concentrate on your contact with the other station. If you wish, you can ask your TNC to display everything it receives. This is called Monitoring. Every Packet contains the AX.25 Header ("envelope") which identifies the station who sent it and the station it is addressed to. The Header contains other information too but we won't get into that just now. When monitoring, your TNC will send to the Computer the Headers as well as the contents of the messages so you can see who sent what to whom. Then you will see how the AX.25 system is able to handle lots of different conversations on the frequency at the same time. The other modes do not offer this capability. Multiple Repeater Operation. When we want to establish contact with some station within range we issue a CONNECT command using that station's callsign, and provided that other station hears our call, it will acknowledge and we can simply type messages to each other (or exchange files, etc). To illustrate, I'll use a callsign of ZZ1FRD for the other station, and for these illustrations, the "messages" that I put inside brackets are internally generated, not typed:

Our Fred

System------------------ ZZ1FRD

CONN ZZ1FRD

(Connect command)-->

<--(ACKnowledge)

(*** CONNECTED to ZZ1FRD)

Hi there Fred.-->

<--(ACKnowledge)

If the station we wish to communicate with is outside radio range, we may establish the connection via one or more intermediate stations which act as repeaters. A station providing this repeater function is commonly called a Digipeater ("Digital Repeater"). It is part of the AX.25 design that any TNC may be used as a Digipeater so, unless you deactivate this facility in your TNC, your system too can be used as a Digipeater. Say we are trying to establish a connection with our friend Fred who is out of radio range.

Our Fred

System ----------- (too far away) ------------ ZZ1FRD

CONN ZZ1FRD

(Connect command)-->

(no response)

There might be another station in between who can "hear" both ZZ1FRD and us. So, we can call ZZ1FRD "via" the intermediate station. Our TNC, using the AX.25 logic, will transmit a "Connect" message with both those callsigns; the intermediate station will see its callsign used as a Digipeater so it will capture the message, store it in its memory for the time being, and when the frequency is clear it will retransmit that same message. This time ZZ1FRD will hear it and will respond, again "via" the Digipeater station. Let's have a look at that situation with an illustration:

Our Digi Fred

System-------------- --------------- ZZ1FRD

XY4DIG

 

CONN ZZ1FRD via XY4DIG

(Connect command)-->

(Connect command)-->

<--(ACKnowledge)

<--(ACKnowledge)

(*** CONNECTED to ZZ1FRD)

Hi there Fred.-->

(Hi there Fred.)-->

<--(ACKnowledge)

<--(ACKnowledge)

So, we now have a point to point connection with Fred as if it were a local contact. It just takes a little longer because each message is transmitted twice. The AX.25 Protocol provides for up to eight Digipeaters to be used for a single point to point connection. So for a more distant destination, we could call that station via two or more intermediate stations. Each of those Digipeaters will store our message and retransmit it as soon as the frequency is clear. This allows distances of hundreds, maybe thousands, of kilometers (even miles!) on VHF or UHF frequencies. Note the Digipeater does no intelligent processing with the messages - it simply retransmits whatever it receives from either station.

Networks

Following on from the previous discussion on Digipeating, I should mention Networks The term "Network" is often used in different ways but I want to mention just two of those here. Firstly the term is used to describe an advanced form of Digipeating where we can make contact with distant stations without necessarily knowing what intermediate stations are retransmitting our messages. The idea is like our telephone Network where we make a call by dialling the number of the person we wish to speak to. We don't know nor care how the call is routed, whether it goes via cable or via satellite, or how many telephone exchanges it goes through. We are simply interested in getting our call through to the other person, no matter how it gets there! Networking systems in use in the field of Amateur Packet Radio include TCP/IP, NET/ROM, and ROSE. Unlike the widespread acceptance of the AX.25 Protocol, we do not have any one Networking system preferred over all others in use. There is still lots of healthy debate going on and developments continuing. It may be that we will have to wait for a new generation of Networking System before a single, global system is implemented.

 

TCP/IP

TCP/IP is a set of protocols developed to allow communications across a network. TCP (Transmission Control Protocol, but often called Transport Control Protocol) is that part of the system which is responsible for getting our data from one place to the next. It will re-send anything that did not get through and it will divide large amounts of data into smaller, more manageable packets, or "datagrams" and make sure they all arrive safely. IP (Internet Protocol) establishes various rules for formatting, routing and processing our data. The various protocols in the TCP/IP family include: - FTP (File Transfer Protocol). This is used to exchange files with another FTP user elsewhere on the Network. Any kind of data may be transferred using FTP, including programs and other Binary Files. paKet uses the standard YAPP (or the advanced pP) protocol for Binary File transfers. FTP is not currently supported, but you can use the TCP/IP Network to exchange files with another station running paKet or one that supports standard YAPP protocol. - TELNET. This facility allows you to conduct a person-to-person chat with another user on the Network. It allows Remote Login which means you can log in on any other computer system on the Network. While connected to that station, anything you type will be sent to that screen and anything the other guy types will appear on your screen. As far as paKet is concerned, once the connection is established, it is a one-to-one connection and it does not matter whether the other station is using TELNET, paKet, or any other Terminal Emulation program. This mode is simply for the exchange of plain text information. - SMTP (Simple Mail Transfer Protocol). This allows you to send messages to other TCP/IP users on the Network. The idea is to leave a message in your own system and the SMTP will automatically feed it into the Network for Forwarding to the destination. Although paKet is not a TCP/IP implementation, it does perform a similar function using the BBS Network (discussed below).Leave a message in paKet's Mailbox and it will be automatically sent to the BBS Network for onward forwarding to the destination.

 

- POP (Post Office Protocol)

This is a variant of the SMTP mail handling facility where you may nominate some other system as your "Post Office" so that any mail addressed to you will be stored there for you. Then, when you run POP, your mail will be automatically Forwarded to you from the Post Office station. paKet will do this automatically for you, not with a TCP/IP "Post Office" but with your local BBS. This is discussed in the section on paKet's Personal Message System.

- PING (Packet INternet Groper)

A PING allows you to put out a feeler to see if some particular station is on the air. If that station is there, you will get a response, telling you the time it took for the round trip. There are lots of other protocols used in the TCP/IP family but this should give you an idea of the complexity and sophistication of this advanced system. TCP/IP is widely used on the Internet, a world wide network of computers. In fact it is a collection of networks, all of which are connected to each other. I heard there were over 20 million people in 125 countries with access to Internet. Of course I am talking about the telephone subscribers with their landline modems, not Amateur Radio operators, but it is a huge system by any standards. Users can chat, exchange programs and files, conduct research, explore the world, play games, or just engage in some meaningful conversation with another user on Internet - some have even been seen courting and proposing! It is much the same as we can do on Amateur Radio but on a wider scale. (Must admit though I have not seen much courting going on around here lately - not on air anyway!) Each TCP/IP user is allocated a station address which consists of a four part number. For example, my TCP/IP address is 44.136.56.3. This number is not just a random number but is carefully managed and allocated by IP Address Coordinators all over the world. The first part is 44 which is the number allocated to Amateur radio stations. The second part, 136 for me, identifies the Country (or a State in the USA), the third part identifies a region or area and the last part is one station within that region. In Amateur Radio the program mostly used to access the TCP/IP system is NOS developed by Phil Karn, KA9Q although a variant called GRINOS has been developed by Gerard van der Grinten, PA0GRI. paKet can be used to access a TCP/IP system but it does not currently implement the various TCP/IP protocols mentioned here.

 

NET/ROM

NET/ROM is Networking Protocol that is used to link a number of stations together and to provide routing services for users connected to the Network. TCP/IP often uses NET/ROM to move its data from one place to another. The NET/ROM system is somewhat automatic because it works out for itself what other NET/ROM stations are available and so it can establish its own message routing without human intervention. It does this by broadcasting coded messages at regular intervals for the purpose of announcing itself to other NET/ROM stations within range.Then all NET/ROM stations, called Nodes, can listen on air to determine what other Nodes are available. Each one builds and maintains its own listing of other Nodes. If we wish to connect to our friend Fred, a distant station, where there is NET/ROM Network available, we could issue a connect command to a NET/ROM Node within reach. Once connected to that Node, we usually are presented with a menu which includes (among other things) a Node Command. If we type "N" that system will send to us a listing of all the Nodes it currently knows about. It is also possible to get a list of the various Routes this system can use to get to another Node in the list. This includes a "Quality Factor" which gives us an idea of the quality and therefore the reliability of the radio links from one place to the next. While we are connected to this Node, we can then give a Connect command to the Node, asking it to make a call to another station or Node it knows about. Let's illustrate, assuming there is a NET/ROM Node with a callsign of N0DE within range.

Our NETROM Fred

System -------------- Node -----------ZZ1FRD

N0DE

CONN N0DE

(Connect command)-->

<--(ACKnowledge)

(*** CONNECTED to N0DE)

CONN 1 ZZ1FRD-->

<--(ACKnowledge)

(Connect command)-->

<--(ACKnowledge)

(*** CONNECTED to ZZ1FRD)

(*** CONNECTED to ZZ1FRD)

Hi there Fred.-->

<--(ACKnowledge)

(Hi there Fred.)-->

<--(ACKnowledge)

All that just to say Hi to Fred? It is not so bad really. Let's have a look at that. Firstly we send a connect command to the NET/ROM Node (N0DE) and when that acknowledges, we have established connection with that station. Then we send "CONN 1 ZZ1FRD" to the Node. Although this looks similar to the connect command we just issued, that string not processed here as a command - it is just a string of characters that is sent to the Node. That string asks the Node to issue a connect to Fred. The Node often has more than one port (that is more than one radio channel) available so we must tell it which port to use. Some Nodes even have HF ports available for convenient DXing. Note the usual protocol is for a station to acknowledge anything it receives correctly. If not copied accurately, it will ask for it to be sent again. In this case the Node is doing more than just plain Digipeating - it is acknowledging each and every packet before re-transmitting it. Fred's system hears the Node's call and establishes the connection with the Node. The Node then connects us to Fred, just like a telephone switchboard operator, and from now everything sent to or received from Fred, will be transmitted via the Node. This example uses just one Node between Fred and us, but it could be much more complex than that with several Nodes involved in a multi hop link. With this simple example, it is rather similar to the Digipeater example we saw earlier (using XY4DIG). Note however, that when we send anything to the Node it acknowledges each transmission immediately it is received. Compare this with the Digipeater connection. There the acknowledgements were not issued by the digipeater - it simply RELAYS all messages including Fred's acknowledgement.

Imagine a multi hop link:

 

Our NETROM NETROM Fred

System --------- Node -------- Node ------- ZZ1FRD

N0DE S0FAR

Hi there Fred.-->

<--(ACKnowledge)

(Hi there Fred.)-->

<--(ACKnowledge)

(Hi there Fred.)-->

<--(NAK)

(Hi there Fred.)-->

<--(ACKnowledge)

I won't illustrate all the connecting dialog, but just assume we had connected to N0DE, then asked it to connect to a second Node, say S0FAR, then asked that second Node to connect to Fred. Now, each message we send to N0DE is sent to S0FAR which in turn sends it on to ZZ1FRD. If Fred's system copped some interference and failed to copy our message correctly, we don't need to know about it because the last link in the chain (S0FAR - ZZ1FRD) will look after it by retransmitting the message. If we were using simple digipeaters here, and we failed to receive Fred's acknowledgement, we would have to retransmit the message to N0DE which would have to send it again to S0FAR which would have to send it again to ZZ1FRD! The Network method is much better: it is more reliable and involves less traffic. In this last example it may be the S0FAR Node is in some far away place, maybe in some overseas country! Provided the NET/ROM Network knows about that Node, we do not concern ourselves with that detail. Let the Network worry about that. If it is in the Nodes list we can simply issue a connect command and wait for it to establish the connection! And once we are connected to that far-away Node, we can ask it for ITS Node list then connect to some other exotic place from there! It's exciting stuff.

ROSE

ROSE is an acronym for "RATS Open System Environment". No, no, RATS has nothing to do with the Mouse used on the Macintosh - RATS is another acronym. RATS is the Radio Amateur Telecommunications Society of New Jersey. They must work for IBM, with all these acronyms. Members of this Society include Tom Moulton (W2VY) who is credited with writing the ROSE code, and Gordon Beattie (N2DSY). These guys and others developed the ROSE system and today it is widely accepted and gaining acceptance all over the world. Some say it is more advanced than the well established NET/ROM systems. ROSE uses Node to Node packet acknowledgements, similar to that used in NET/ROM, as illustrated above. In fact, there are many similarities between ROSE and NET/ROM. The differences that concern us are in the way we access it. With ROSE we do not need to know the callsigns on various Nodes we want (or need) to use. We simply need to know the callsign of our local ROSE Node, which is where we enter the Network, and the remote station's network address, which is where we leave the Network The network address is a number, based loosely on the telephone area code and local dialling prefix. So to establish contact with a distant user, let's say it is still our friend Fred who now has access to the ROSE network. We need to know the Network Address of Fred's local ROSE Node. That's all. The rest is up to the ROSE Network and the people who set it up for us. I think we need another illustration. I have shown below a diagram of a ROSE Network with four Nodes showing. Each of these four Nodes has a Network Address which is a 6 digit number. We are within range of our local Node, shown with a callsign of AA1NET and a Network Address of 658300. Fred, ZZ1FRD, can access the ROSE Network via his Node, shown with a callsign of XY2LOC and a Network Address of 675200. The other Nodes do not concern us here - I just included them to indicate there can be lots of entry points in the Network.

Node Node

Our 658300 ROSE 675200 Fred

System --------O O--------- ZZ1FRD

AA1NET Network XY2LOC

Node O O Node other

other 598550 / \ 476250 user

user--------- / \ --------

If we wish to call Fred, we need to know the callsign of our own Node and Fred's Network address. So to make that connection we enter the following command:

CONNECT ZZ1FRD v AA1NET, 675200

The dialog might go something like this:

OUR SYSTEM OUR ROSE NODE (AA1NET)

---------- ----------------------

CONNECT ZZ1FRD v AA1NET, 675200 -->

<--(ACKnowledge)

(*** CONNECTED to ZZ1FRD via AA1NET,675200)

(Call being Setup)

 

*** delay in here while ROSE make the call through to Fred ***

(Call Complete to ZZ1FRD-0 @ 5050675200)

Hi there Fred.-->

<--(ACKnowledge)

(Hi there Fred.)-->

 

The first part of the connect command is similar to any other connect command with the callsign of the station we want to talk to and another callsign of a station we want to digipeat our call. However in this case the AA1NET is not just another packet radio digipeater: this one is a ROSE Node and it behaves a little differently. It accepts our call and responds immediately with a CONNECTED message and tells us our call is being processed. The ROSE system knows about all the other Nodes in the Network so it knows how to get to 675200. We just have to wait while it does the job. ROSE can automatically attempt alternative paths to that destination if one path is not working properly. It does not matter if Fred is right next door, across the other side of the Country, or even overseas. Provided we both have access to the same ROSE Network, the connect command is the same! We do not need to know what happens inside "The Network" - there might be one hop to get to his Node or there might be a dozen hops. Once Fred's system acknowledges our call, our ROSE Node tells us the Call is Complete and connects us "directly" to Fred. Now we can talk to Fred as if it were a simple, local contact. For this connection we do not use our own Network Address (658300) but we might like to tell Fred what it is because he will need that number if he wants to call us via the ROSE Network. The Network routes that are used within the ROSE Network are defined by various ROSE Network Managers each of whom have accepted responsibility for their own Nodes in the Network. So if some path is bad or if some other new Node is installed, the Network paths can be changed and we, the users, need never know about it. NET/ROM systems can accommodate changes in the Network too and they achieve this automatically by broadcasting those coded messages we talked about earlier. That is good, but in some situations people complain at that added activity on a busy frequency! (Some people complain about anything though). Both ROSE and NET/ROM have advantages and I do not wish to get involved in the debate as to which might be better. Maybe one day, someone will create a new generation of Network system that accommodates the advantages of both, as well as enhancing functionality?

 

The BBS Network and Mail Forwarding

The other meaning of "Network" I want to mention is the BBS (Bulletin Board System) Network which provides a Global Electronic Mail Service for us all. A BBS, sometimes referred to as a PBBS (Packet-radio BBS), is a computer based Packet Radio system, probably run by some generous local enthusiast or the local club, which provides unattended (usually 24 hours per day) access for the purpose of storing and forwarding messages. They are often used as a central store for data files too so we can transfer programs and other files to or from the BBS. Telephone BBS systems have been around for years, before Packet Radio came into being, so you might be familiar with those. The concept is the same, but we use radio as the medium instead of the telephone. The main role of the BBS now is to provide a Mailbox service for local users. We could call up the BBS, ask it to display any messages it was holding, read any messages addressed to us and maybe leave a reply to someone. This is very useful for sending messages to friends whether they are currently in their shack or not. The BBS mailbox allows us to leave a message addressed to another station and when that other station connects to the BBS they will be able to read our message. Why not just send that message directly to that "someone"? Well, for one thing, they might not be around at the time. They might not have their system switched on. They might be out of range or it might be simply more convenient to leave the message for them on the BBS and let them read it later when they check the BBS. The Mailbox facility became so popular that most TNCs now offer a private mailbox. paKet too has a Mailbox (I called it the Personal Message System - PMS for short) similar to that in the BBS, so you and others can send and receive messages without needing the BBS to store those messages. So the role of the BBS is changing. But it still has a significant role to play as part of a Global "Network" of similar BBS systems.

Mail Forwarding

It all started when Hank Oredson (W0RLI) developed an automatic Forwarding system between PBBS systems. Then we could leave a message on our local BBS and if that message was addressed to someone in an adjoining area the BBS would, at regular intervals in the day or night, automatically send our message to that other BBS. As the "Network" developed, our mail would move to our neighbouring system and that system would then Forward it to its neighbour and so on. This Automatic Forwarding system has been implemented on all Packet Radio BBS systems now and, although some have added some enhancements,they are all based on Hank's original standard. paKet's PMS conforms to this standard and can participate in the Forwarding with the BBS Network. So you can simply leave a message in your paKet PMS and it will be automatically sent to any packet destination anywhere in the world. And paKet can accept any incoming Mail directly into your PMS without any action on your part. It will just appear there! However, I see paKet as a PERSONAL system and as such does not belong in the BBS Network as a link in the Forwarding chain.

The role of the BBS and where paKet fits in

The BBS has a vital role to play as a part of the BBS Network. It is the role of your local BBS to participate in the automatic Forwarding of messages, managing the flow of Mail via the BBS Network to and from other participating BBS systems. Each BBS that forms a link in the chain will receive Mail from an adjoining station, and then will Forward that Mail on to the next link in the chain. That way, the Mail can find its way all around the country and all around the world. Personal Mail addressed to a particular BBS will hop from one BBS to the next until it eventually arrives at its destination. Every BBS in the Network has the opportunity to store those messages so all local users of that BBS can access them at their leisure. Of course, what is STORED on your BBS is entirely up to the owner of that system. Some BBS Sysops like to be selective as to what messages are kept, so you might find some messages "missing" from your local BBS. But if the BBS is participating as a link in the Forwarding Network it should be expected to Forward EVERYTHING on to the next link in the chain, including any messages that might not be stored for its local users. Although paKet supports the standard Mail Forwarding protocol, its role as a PERSONAL system is to manage YOUR Mail, interfacing only with your local BBS and not with the Network generally. So any mail you want to send through the Network or any mail you receive from the Network, will be channelled through your local BBS.

 

 

Bulletins

A Bulletin is a general message that is broadcast to anyone and everyone rather than a personal message addressed to one particular station. Bulletins may be "addressed" to some topic such as IBM or HUMOUR or HELP or MORSE... The topics help us to get some idea of what the Bulletin is about so we don't have to read every message that appears on the BBS. Bulletins are usually forwarded to every BBS system in the area, so if there is a Bulletin around, it will probably, eventually get to your local BBS for you to see. Personal Mail is usually addressed to a station @ (AT) some BBS address. For example the local BBS in this area is run by Arthur VK2ATM. So if you want to send a message to me you would send it to VK2DHU @ VK2ATM. There must be millions of Amateur Packet Radio callsigns in use around the world but there are a limited number of BBS systems so it is easier to track down VK2ATM than it is to find VK2DHU. This problem is further reduced with the introduction of Hierarchical Addressing which is a system of specifying more than just the BBS callsign, adding State, Country and Continent (or Region) details. For example, my full Packet address according to today's convention is VK2DHU @ VK2ATM.NSW.AUS.OC (meaning this station is in the State of New South Wales, in Australia, in the Oceania Region). Bulletins may be addressed to one particular BBS (eg to MORSE @ VK2ATM) but more commonly they would be issued to cover to a wider area (eg to MORSE @ ASIA). Then the Bulletin would be passed on from one BBS to the next within that area, and every BBS would have that Bulletin available for users to read.

Other Communications Modes

paKet is a COMMUNICATIONS program designed to communicate with a TNC or Modem. It provides communication facilities between the computer and the TNC but does not perform the decoding of packets - that is done in the TNC! Neither will paKet decode any of the other communications modes such as Morse, RTTY or AMTOR. These modes too, are decoded by the TNC. Not all TNCs handle these other modes so if this is what you want to do you will need one of the Multi-Mode TNCs available (such as the KAM, MFJ-1278, PK-232 or one of the DSP models) which decode these other modes. If you have one of those TNCs, you can use paKet for modes other than Packet Radio.