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!
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
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
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
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.
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.