1644 lines
87 KiB
Plaintext
1644 lines
87 KiB
Plaintext
PACKET RADIO: An Introduction - - by Larry Kenney, WB9LOZ
|
||
|
||
Packet Radio is the latest major development to hit the world of
|
||
Amateur Radio. If you haven't already been caught by the "packet
|
||
bug", you're probably wondering what it's all about and why so many
|
||
people are so excited about it. Well, continue reading, because
|
||
you're about to find out.
|
||
|
||
Packet seems to offer something different from other facets of
|
||
Amateur Radio, yet it can be used for everything from a local QSO to
|
||
a DX contact 2500 miles away (on 2 meters!), for electronic mail,
|
||
message transmission, emergency communications, or just plain
|
||
tinkering in the world of digital communications. It presents a new
|
||
challenge for those tired of the QRM on the low bands, a new mode for
|
||
those already on FM, and a better, faster means of message handling
|
||
for those on RTTY. Packet is for the rag chewer, the traffic
|
||
handler, the experimenter, and the casual operator.
|
||
|
||
A ham can get involved very easily with relatively small out-of-
|
||
pocket expenses. All you need is a 2-meter transceiver, a computer
|
||
or terminal, and a TNC. You probably already have the two meter rig
|
||
and a computer of some kind, so all you need to buy is the TNC, which
|
||
costs just over $100. The TNC is the Terminal Node Controller, the
|
||
little black box that's wired between the computer and the radio. It
|
||
acts very much like a modem when connecting a computer to the phone
|
||
lines. It converts the data from the computer into AFSK tones for
|
||
transmission and changes the tones received by the radio into data
|
||
for the computer. It's a simple matter of wiring up a plug and a
|
||
couple jacks to become fully operational.
|
||
|
||
Packet is communications between people either direct or indirect.
|
||
You can work keyboard to keyboard or use electronic mailboxes or
|
||
bulletin board systems to leave messages. Due to the error checking
|
||
by the TNC, all of it is error free, too. (That is, as error free as
|
||
the person at the keyboard types it.) As the data is received it's
|
||
continuously checked for errors, and it isn't accepted unless it's
|
||
correct. You don't miss the information if it has errors, however,
|
||
because the information is resent again. I'll go into how this is
|
||
accomplished in a later part of this series.
|
||
|
||
The data that is to be transmitted is collected in the TNC and sent
|
||
as bursts, or packets, of information; hence the name. Each packet
|
||
has the callsign or address of who it's going to, who it's coming
|
||
from and the route between the two stations included, along with the
|
||
data and error checking. Since up to 256 characters can be included
|
||
in each packet, more than three lines of text can be sent in a matter
|
||
of a couple seconds. There is plenty of time between packets for
|
||
many stations to be using the same frequency at the same time, and
|
||
all using the same repeater. The repeaters, known as digipeaters,
|
||
are simplex operations and occupy a single frequency, as opposed to
|
||
the common two-frequency repeaters used for voice communications.
|
||
You can link from digipeater to digipeater, too, extending your range
|
||
tremendously. I've worked twelve states on 2-meters with packet, all
|
||
with a ten watt rig, thanks to this linking capability.
|
||
|
||
If all of this sounds confusing, don't let it bother you, because
|
||
that little black box, the TNC, does everything for you automa-
|
||
tically. Packet might seem very confusing at first, but in a day
|
||
or two you're in there with the best of them. In future parts of
|
||
this series, I'll be telling you more about packet--how you get on
|
||
the air, how to use it to your best advantage, and ways to improve
|
||
your operation. We'll even talk about that little black box, the
|
||
TNC, and tell you about all its inner-most secrets.
|
||
|
||
(Thanks to K4CEF and Westlink Report for providing "POINTS TO PONDER
|
||
ABOUT PACKET - FOR THE NON-PACKETEER" in their November 14, 1986
|
||
issue. I've used information from that article in this column.)
|
||
|
||
|
||
PACKET RADIO: An Introduction - PART II - by Larry Kenney, WB9LOZ
|
||
|
||
In the first part of this series we told you, in general terms, what
|
||
packet radio was all about...what it is, its uses, the equipment used
|
||
and, generally, how its transmitted. Now we're going to tell you how
|
||
to get on the air, make a QSO, and become familiar with your packet
|
||
station. Whether you're new to packet, having just received a new
|
||
TNC, have been involved for just a short time, or are one of the "old
|
||
timers" with three or four years of experience, this series should
|
||
help all of you. Even if you don't yet own a TNC, you should keep
|
||
this article handy for future use. I'll bet you'll be joining us soon!
|
||
|
||
The equipment needed to get on the air is a VHF transciver, a
|
||
computer or terminal, and a TNC - the terminal node controller - the
|
||
little black box we talked about in part 1. (There is packet activity
|
||
on HF, but VHF is where all the action is. It's the best place to
|
||
start out in packet.) The TNC contains a modem and is equivalent to
|
||
the modem used to connect your computer to the phone lines, except
|
||
that it also contains special software that's specially designed for
|
||
ham radio packet use.
|
||
|
||
When you buy a TNC and take it out of the box, you'll find cables
|
||
supplied for connecting it to the radio, but you'll have to attach
|
||
the appropriate mic and speaker jack connectors for the radio you're
|
||
going to use. You also have to furnish the cable that connects the
|
||
TNC to your computer or terminal. In most cases, the standard RS-232
|
||
port is used between the TNC and computer, however this varies on the
|
||
type of computer and TNC used. The operating manuals supplied with
|
||
the TNC have a good write up on the various computers and the cabling
|
||
needed. I would advise that you read the introduction and set up
|
||
procedures for your particular TNC very carefully. Most companies
|
||
have supplied excellent manuals, and you usually can figure out all
|
||
of your set up problems from the the information supplied in the
|
||
manual.
|
||
|
||
Once you have everything wired and connected together, turn on the
|
||
computer, load a terminal program (anything used for a phone modem
|
||
will work well for packet) and get into receive mode. Now turn on
|
||
the radio and make sure the volume is turned up about a quarter turn
|
||
(about the "10 o'clock" position) and make sure the squelch is set.
|
||
It should be at the point where the background noise disappers, just
|
||
as it would be set for a voice QSO. Next, turn on the TNC. You
|
||
should get a "greeting" or sign on message showing the manufacturer's
|
||
name, software version, etc. If you see a bunch of gibberish, such
|
||
as &tf$d.#ssan>m, it means that the data rate of the TNC and computer
|
||
are not the same. This data rate is better known as the baud rate.
|
||
The baud rate of the TNC has to match the baud rate used by your com-
|
||
puter terminal program and is easily adjusted. Check you TNC manual
|
||
for this procedure, as it varies from TNC to TNC. If you don't see a
|
||
"greeting" or the gibberish, check your cables and connections. Make
|
||
sure that you have everything connected properly, that the right wires
|
||
are on te right pins, etc.
|
||
|
||
Now we need to explain the three levels of communicating you can do
|
||
from the keyboard. First, you can communicate with your computer for
|
||
setting up the terminal program; second, you can communicate with the
|
||
TNC; and third, you can communicate with the radio. It's very impor-
|
||
tant that you know which level you're in when working packet. I
|
||
can't help you much with the computer level, since that varies with
|
||
manufacturer, model and type, but once you get the terminal program
|
||
ready to receive data, you're ready to talk to the TNC.
|
||
|
||
First, do a "control C" (press the CNTL and the letter C simultan-
|
||
eously); this puts the TNC in COMMAND mode, the level where you
|
||
communicate directly with the TNC from the keyboard. You should see
|
||
"cmd:" on your screen. Enter "MYCALL - - - -" with your callsign in
|
||
place of the dashed lines, such as "MYCALL WB9LOZ", followed by a
|
||
carriage return (CR). All commands are followed by a (CR). This
|
||
sets into the TNC memory the call that you're going to use on the
|
||
air. If you type "MYCALL" (CR) now, it should respond with your
|
||
call. If it does, you've proven that the computer to TNC linkup is
|
||
working fine. If you do not see anything on the screen when you
|
||
type, blindly enter the following: ECHO ON (CR). If you see two of
|
||
everything that you type, such as MMYYCCAALLLL, enter ECHO OFF (CR).
|
||
|
||
You're now ready to go on the air! Tune the receiver to any odd
|
||
numbered frequency between 144.91 and 145.09 that has some activity on
|
||
it and set the rig up for simplex operation. Enter "MONITOR ON" (CR),
|
||
then watch the screen. You should soon be seeing the packets that
|
||
are being sent over the air by other stations. If you don't see
|
||
anything in a minute or two, try tuning to another frequency. Watch
|
||
for callsigns with a * next to it, such as W6PW-1*, WA6RDH-1*, or
|
||
WB6SDS-2*. Callsigns with an asterick indicate that you're copying
|
||
the packet from that station, as it's being repeated, or digipeated.
|
||
Jot down the call.
|
||
|
||
In packet, you can have up to 16 different stations on the air at the
|
||
same time using the same callsign. That's where the numbers come
|
||
into play. The calls W6PW, W6PW-1, W6PW-2, W6PW-3, W6PW-4 and W6PW-5
|
||
are all individual stations operating under the same station license.
|
||
The numbers are used to differentiate between the various stations.
|
||
|
||
Now, before you try to make your first QSO with someone else, you
|
||
should check out your equipment to make sure it's set up properly.
|
||
To do that, you can CONNECT to yourself. Note one of the callsigns
|
||
you jotted down a minute ago. Make sure your radio is still tuned to
|
||
the frequency where you heard that call, then enter the following:
|
||
"C - - - - V - - - -" (CR) where the first dashed lines are YOUR
|
||
callsign and the second dashed lines are the call of the station you
|
||
jotted down. The C means CONNECT and the V means VIA. "C WB9LOZ V
|
||
W6PW-1" means connect to WB9LOZ via W6PW-1. You should soon see
|
||
"*** CONNECTED TO (your call)" on the screen. You have now entered
|
||
the third level of communications, called CONVERSE mode, and this is
|
||
where you communicate from the keyboard to the radio. Anything you
|
||
type on the keyboard will be transmitted over the air as a packet
|
||
every time you hit a (CR). If you enter "Test" (CR) you should see
|
||
"Test" a second time on the screen, as it's transmitted, then digi-
|
||
peated and sent back to you. In this case you'll only be talking to
|
||
yourself via another station, but it's a good way to check to make
|
||
sure your system is working properly. If that works, hit a CONTROL
|
||
C. This puts you back into COMMAND mode where you talk to the TNC
|
||
again. Enter "D" (CR). This will disconnect you from the other
|
||
station, and you'll see "DISCONNECTED" on the screen.
|
||
|
||
Now you're ready to talk to someone else! Watch for a familiar call
|
||
on the screen while monitoring or note calls you see frequently. Be
|
||
sure to note whether or not a digipeater is being used by watching
|
||
for the *. If you see WB9LOZ > WA6DDM, W6PW-1*, for example, you're
|
||
receiving the packets from W6PW-1. If you do not see an asterick,
|
||
you are copying the station direct. When the station you want to
|
||
contact is finished with his QSO, enter "C - - - -" or "C - - - -
|
||
V - - - -" (depending on whether or not a digipeater is needed)
|
||
followed by (CR). You should get a "*** CONNECTED TO ..." on the
|
||
screen, which means you're in converse mode, and your first QSO with
|
||
someone else is underway! Anything you type now will be sent to the
|
||
other station, and anything he types will be sent to you. When you're
|
||
finished, be sure to do a CONTROL C to get back into command mode,
|
||
then enter "D" to disconnect from the other station.
|
||
|
||
You're on the way now to lots of packet fun and adventure!
|
||
|
||
|
||
INTRODUCTION TO PACKET RADIO - PART 3 by Larry Kenney, WB9LOZ
|
||
|
||
In our last column I talked about how to get on the air and make your
|
||
first QSO. This time I'll be explaining the special calls used in
|
||
packet radio, the use of digital repeaters (called digipeaters), and
|
||
how to use some of the commands in your TNC.
|
||
|
||
THE SSID: Each licensed amateur is allowed to have up to 16 different
|
||
stations in operation at the same time on packet radio. You could have
|
||
your home station, several digipeaters and a bulletin board system all
|
||
operating with your callsign. To differentiate between the various
|
||
operations you use an SSID, a "Secondary Station ID", attached to the
|
||
end of the callsign. The SSID is shown as a dash followed by a
|
||
number, 0 through 15. An SSID of -0 is usually not shown, and is not
|
||
needed.
|
||
|
||
DIGIPEATERS: Digipeater is the term we use to describe a packet radio
|
||
digital repeater. Unlike voice repeaters, most digipeaters operate on
|
||
simplex and do not receive and transmit simultaneously. They receive
|
||
the digital information, temporarily store it and then turn around and
|
||
retransmit it.
|
||
|
||
Your TNC will allow you to enter up to eight digipeaters in your
|
||
connect sequence, but using more than 3 usually means long waits,
|
||
lots of repeated packets, and frequent disconnects, due to noise and
|
||
other signals encountered on the frequency.
|
||
|
||
When entering the list of digipeaters in your connect sequence, you
|
||
must make sure that you enter them in the exact order that your
|
||
signal will use them. You must separate the calls by commas,
|
||
without any spaces, and the EXACT callsigns must be used, including
|
||
the SSID, if any. That means you need to know what digipeaters are
|
||
out there before randomly trying to connect. Turn MONITOR ON and
|
||
watch for the paths that other stations are using or check the
|
||
digipeater listings. Here are some examples of proper entries:
|
||
C W6PW-3 v W6PW-5
|
||
C N6ZYX v WA6FSP-1,WB6LPZ-1
|
||
C W6ABY-4 v K6MYX,N2WLP-2,AB6XO
|
||
|
||
Something to remember when using digipeaters is the difference
|
||
between making a connection and sending information packets. If the
|
||
path isn't all that good, you might be able to get a connect request
|
||
through, but will have a difficult time with packets after that. The
|
||
connect request is short so it has much less of a chance of being
|
||
destroyed by noise or collisions than a packet containing informa-
|
||
tion. Keeping information packets short can help keep retries down
|
||
when the path is less than ideal.
|
||
|
||
NODES: Net/Rom and TheNet nodes are another means of connecting to
|
||
other packet stations. A complete review of their operation will be
|
||
covered in a later part of this series.
|
||
|
||
TNC PARAMETERS: The Terminal Node Controller, that "little black
|
||
box" we've talked about in the past, has more than 90 different
|
||
commands available. You're able to customize your packet operating
|
||
with these commands and turn on and off various features as you wish.
|
||
Not all TNCs are exactly alike, but all have pretty much the same
|
||
functions. I'll be using the commands used by the TNC2 and clones in
|
||
my examples.
|
||
|
||
We covered a few of the commands in a previous article: CONTROL C for
|
||
entering command mode, MYCALL, MONITOR, CONNECT, and DISCONNECT. Now
|
||
let's discuss a few that can change the way your station functions.
|
||
|
||
ECHO: This command tells the TNC whether or not it should send what
|
||
you type back to the monitor screen. If you don't see anything when
|
||
you type, set ECHO to ON. IIff yyoouu sseeee ddoouubbllee, like
|
||
that, set ECHO to OFF. This setting will depend on how your partic-
|
||
ular computer system functions.
|
||
|
||
CONV (converse mode): Your TNC will automatically switch to this mode
|
||
when you connect with someone, but you can also do it by entering
|
||
CONV (CR) at the Cmd: prompt. When in converse mode, nnything you
|
||
type will be transmitted via the path you set with UNPROTO. (See the
|
||
next paragraph.) Anyone in monitor mode will be able to read what you
|
||
transmit. Packets in converse mode are sent only once and are not
|
||
acknowledged, so there is no guarantee that they'll get through. This
|
||
mode is used frequently for sending CQ's.
|
||
|
||
UNPROTO: This command designates the path used when in converse
|
||
mode. The default is CQ, but you can enter a series of digipeaters
|
||
if you wish, or a specific group or club name. Some examples:
|
||
CQ v WB6SDS-2,W6SG-1,AJ7L
|
||
SFARC v W6PW-1,W6PW-4
|
||
Remember, you have to change UNPROTO for use on different frequencies,
|
||
unless you leave it set simply to "CQ".
|
||
|
||
FRACK: This determines how long your TNC will wait for an acknowl-
|
||
edgement before resending a packet. It shouldn't be set too short,
|
||
or you simply clutter up the frequency, yet it shouldn't be too long,
|
||
or you'll spend too much time waiting. I use FRACK set to 7, and
|
||
have found that to be an overall good value.
|
||
|
||
DWAIT: Used to avoid collisions, DWAIT is the number of time units
|
||
the TNC will wait after last hearing data on the channel before it
|
||
transmits. I have DWAIT set to 16, and have found that to work well.
|
||
|
||
PACLEN: Determines the number of characters in your packets, ranging
|
||
from 1 to 256. The more characters you send per packet, the longer
|
||
it takes to transmit the information and the greater your chances
|
||
are of noise, interference or another station wiping it out. I've
|
||
found a PACLEN of 80, which is the length of one line, to be a good
|
||
value. When working a station nearby, PACLEN can be increased. When
|
||
working a distant station, it should be decreased.
|
||
|
||
RETRY: Your TNC will retransmit a packet if it doesn't receive an
|
||
acknowledgement from the station you're working. RETRY indicates the
|
||
number of times the TNC will try to get the packet through before
|
||
giving up and disconnecting. This can be set from 1 to 15, but I've
|
||
found 8 to 10 to work well. Less than that causes an unnecessary
|
||
disconnect if the channel happens to be busy, but more than that
|
||
clutters up the channel.
|
||
|
||
Try working with those commands. In the next article I'll cover a
|
||
few more, plus take a look at how to use a packet bulletin board
|
||
system.
|
||
|
||
|
||
INTRODUCTION TO PACKET RADIO - PART 4 by Larry Kenney, WB9LOZ
|
||
|
||
The TNC commands that affect the monitoring mode and what you see
|
||
on the screen while monitoring will be discussed in this part, then
|
||
we'll take a look at the basics of packet bulletin board operation.
|
||
|
||
TNC COMMANDS:
|
||
MONITOR - This must be ON for you to monitor anything. When ON,
|
||
you see packets from other stations on the frequency you're tuned
|
||
to. What packets you see is determined by other commands from the
|
||
list below. If MONITOR is OFF, you see only packets sent to you
|
||
while you're connected to another station.
|
||
MALL - If MALL is ON, you receive packets from stations that are
|
||
connected to other stations, as well as packets sent in unproto
|
||
(unconnected) mode. This should be ON for "reading the mail".
|
||
If MALL is OFF, you receive only packets sent in unproto mode by
|
||
other stations.
|
||
MCOM - If ON, you see connect <C>, disconnect <D>, acknowledge
|
||
<UA> and busy <DM> frames in addition to information packets. If
|
||
OFF, only information packets are seen.
|
||
MCON - If ON, you see packets from other stations while you're
|
||
connected to someone else. This can get very confusing, but is
|
||
useful when your path is bad and you want to see if your packets
|
||
are being digipeated okay. If OFF, the monitoring of other stations
|
||
is stopped when you're connected to another station.
|
||
MRPT - If ON, you see a display of all the stations used as
|
||
digipeaters along with the station originating the packet and the
|
||
destination station. If OFF, you see only the originating and
|
||
destination stations. For example, if you have MRPT ON, you might
|
||
see a transmission such as this:
|
||
K9AT>WB6QVU,W6PW-5*: I'll be leaving for the meeting at about 7:30.
|
||
If MRPT was OFF, the same transmission would look like this:
|
||
K9AT>WB6QVU: I'll be leaving for the meeting at about 7:30.
|
||
In the first case, you can see that the W6PW-5 digipeater was being
|
||
used. The asterick indicates which station you were hearing the
|
||
packet from. In the second case you have no idea if digipeaters are
|
||
being used or what station you were receiving.
|
||
HEADERLN - If you have this turned ON, the header of each packet is
|
||
printed on a separate line from the text. If OFF, both the header
|
||
and packet text are printed on the same line.
|
||
MSTAMP - Monitored packets have the date and the time the packet
|
||
was received if MSTAMP is ON. If it's OFF, the date/time stamp is
|
||
not shown.
|
||
|
||
I run my station with all of these commands, except MCON, turned ON
|
||
so that I can really see what's happening on the frequency I'm
|
||
monitoring. Try various combinations of these commands and then
|
||
decide on the combination you like best for your station.
|
||
|
||
USING A PACKET BULLETIN BOARD SYSTEM:
|
||
You connect to a bulletin board system (BBS) exactly the same way as
|
||
you connect any other station. Once connected, you'll see a welcoming
|
||
message, some basic instructions and other information. This informa-
|
||
tion will vary from system to system. The first time you connect you'll
|
||
receive a request to enter your name, home BBS, QTH and zip code for the
|
||
system user file. You enter your name using the letter N followed by a
|
||
space and then your first name, such as: N Larry. Your "home BBS" is the
|
||
system you plan to use regularly and want all of your personal messages
|
||
delivered to. You enter that by typing NH followed by a space and then
|
||
the call of the BBS, such as NH W6PW. (Note: SSIDs are not used with BBS
|
||
operation except for when making the connection. The BBS software ignores
|
||
all SSIDs.) Your QTH is entered with the NQ command, such as NQ San
|
||
Francisco, CA. Enter the full city name and the two letter state abbre-
|
||
viation. You enter your zip code with NZ followed by a space and your
|
||
five-digit zip. The home BBS, QTH and zip code information is sent to a
|
||
central data bank at the WD6CMU BBS known as the "White Pages", and can
|
||
be used by anyone. System operators (sysops) use it for determining the
|
||
correct system when forward messages, and you can use it to find out the
|
||
"home BBS" of your friends. How to use the "White Pages" will be discussed
|
||
later on in this series.
|
||
|
||
When checking in to a BBS for the first time, you should become familiar
|
||
with the commands available to you. Each BBS or mailbox is a little
|
||
different from the next, so read the introduction carefully and follow
|
||
the directions. If you don't know what to do next, enter H for the HELP
|
||
instructions. Make note of the command letters, enter only one command
|
||
at a time, and make sure you enter them correctly. Computers are not very
|
||
forgiving and expect things to be entered in proper form. Take your time,
|
||
check out the features that the particular BBS or mailbox offers and enjoy
|
||
yourself. There's no need to feel rushed or intimidated. If you get to
|
||
a point where you don't know what to do next, don't give up and disconnect,
|
||
enter H again for HELP. That's what it's there for! I suggest making a
|
||
printer copy of the complete help file so that you have it available as a
|
||
reference when using a BBS.
|
||
|
||
Now let's go through the basic procedures you should follow when checking
|
||
into a BBS. When you receive the welcoming message, you'll note that the
|
||
last line ends with a >. This is known as the prompt, and is where you
|
||
enter the command you want performed next. If there are personal messages
|
||
addressed to your call, the BBS will list them for you following the wel-
|
||
come message. Note the message numbers.
|
||
|
||
At the prompt, the first thing you should always do is list the new
|
||
messages, by entering L. The BBS program updates the user file each time
|
||
you check in, logging the latest message number. The next time you check
|
||
in, only new messages that have been received by the system will be included
|
||
in your list. The first time you'll receive all of them, since they're
|
||
all new to you. This list can be very long, as many systems have more
|
||
than 200 active messages on line. When you receive the list, note the
|
||
numbers of the messages you're interested in reading.
|
||
|
||
Next, read the messages you're interested in. You do this by entering
|
||
R XXXX, where the Xs represent the message number, such as R 4521. Note
|
||
that there is a space between the command and the number. It's best to
|
||
have your buffer or printer turned on when reading messages, because
|
||
they're apt to come in faster than you're able to read them. You should
|
||
have a means of saving them for reading later after you've disconnected.
|
||
If there were messages addressed to you, you should erase or "kill" them
|
||
once you've read them. You can do this with the "KM" command, which means
|
||
"Kill Mine". This command will erase all messages that are addressed to
|
||
you that have been marked as having been read. You can also kill each
|
||
message individually by entering K XXXX, where the X's are the message
|
||
number.
|
||
|
||
Once you've read all the messages you're interested in, you have several
|
||
options. You can look back at old messages, send messages to other
|
||
stations, see what's available in the files section, download a file,
|
||
upload a file, check the list of stations that have recently checked in
|
||
to the BBS or stations that have been heard on frequency, monitor other
|
||
frequencies used by the BBS, use the gateway feature (if available),
|
||
check the status of the BBS tasks, or a variety of other things. In
|
||
part 5 we'll cover some of the other BBS commands. In the mean time,
|
||
the help file of the BBS should give you all the information you need
|
||
to try any of the functions mentioned above. Enjoy!
|
||
|
||
|
||
INTRODUCTION TO PACKET RADIO - PART 5 By Larry Kenney, WB9LOZ
|
||
|
||
In this part of the series, I'll explain how to use the various BBS
|
||
commands that you have available to you. This information is based
|
||
on W0RLI software, so it might vary slightly for users of AA4RE,
|
||
WA7MBL, or other type systems. Use the H - HELP command on your BBS
|
||
if some of these commands do not work as described.
|
||
|
||
LIST COMMAND: The first thing you should do when logging on to a
|
||
BBS is to use the LIST command. There are many variations available,
|
||
but L, by itself, is the one used most often.
|
||
L (List) - Lists all new messages, except other user's personal
|
||
messages, that have been entered since you last logged in.
|
||
If you want to list specific messages, you can use one of the follow-
|
||
ing variations of the L command:
|
||
Lx - Lists all messages of the type designated by 'x'. Example: LB
|
||
will list all bulletins.
|
||
L # - Lists messages back to and including number #. Example: L 4050
|
||
will list all messages, except personal messages to others, from the
|
||
latest one back to #4050.
|
||
LL #- Lists the last # messages. Example: LL 15 lists the last 15
|
||
messages received at the BBS, excluding other's personal messages.
|
||
L 1 - Lists ALL non-personal messages.
|
||
L> callsign - Lists all messages TO callsign indicated. Example:
|
||
L> N6XYZ
|
||
L< callsign - Lists all messages FROM callsign indicated. Example:
|
||
L< N6XYZ
|
||
L@ designator - Lists all messages that have that "designator" in
|
||
the @ BBS column of the message header. Example: L@ ALLCAN will list
|
||
all messages with ALLCAN in the @ BBS column.
|
||
|
||
READ COMMAND: To read a message, you enter R followed by a space
|
||
then the message number. Example: To read message 5723, you'd enter:
|
||
R 5723. You also have the option of using the RH command, which will
|
||
give you all of the forwarding headers in detail, rather than just
|
||
giving you the path. Example: To read message 5723 with the full
|
||
headers, you'd enter RH 5723.
|
||
There is one other version of the READ command, and that's RM.
|
||
Entering RM by itself will give you all of the messages addressed to
|
||
you that have not yet been read.
|
||
|
||
ERASING MESSAGES: Once you have read a personal message, please
|
||
erase it. The sysop will appreciate your help in clearing up "dead"
|
||
messages. You use the K - KILL command to do this. You can enter
|
||
K #, such as K 5723, which will erase that particular message, or you
|
||
can enter KM, which will erase all of the personal messages you have
|
||
read. If you use the KM command, the BBS will list the message
|
||
numbers for you as they're killed.
|
||
|
||
THE DUAL PURPOSE "S" COMMAND: S (Status) and (Send) - The letter S
|
||
by itself will give you a reading of the BBS status, showing the
|
||
callsigns of stations using the system, the time they connected, the
|
||
port used, etc. It also shows information on the message and user
|
||
files.
|
||
|
||
The "S" command is also used for sending a message, but it must be
|
||
further defined. There are three types of messages found on a packet
|
||
bulletin board system: Personal, Bulletin, and Traffic. "SP" is used
|
||
for sending a personal message to one other station, "SB" for sending
|
||
a bulletin, and "ST" for sending a message that's going to be handled
|
||
by the National Traffic System.
|
||
|
||
You're able to send a message to one particular person, to everyone
|
||
on the local BBS, to everyone at every BBS and mailbox in Northern
|
||
California, in Southern California, in the entire state, or all
|
||
across the entire country. It all depends on your addressing.
|
||
|
||
At the BBS prompt you enter the appropriate command (SP, SB, or ST)
|
||
followed by a space and then the addressee. The addressee can be
|
||
a callsign or it can be something of a general nature, such as ALL,
|
||
QST, ARES. Examples: SP WB9LOZ SB ALL. All commands, of course,
|
||
must be followed by a <CR>.
|
||
|
||
If you wish to send the message to someone at another BBS, you have
|
||
to indicate the call of the other BBS following the call of the
|
||
addressee. For example, to send a message to N5PQ, who uses the
|
||
W5XYZ BBS, you would enter: SP N5PQ @ W5XYZ.
|
||
|
||
To send a general message to more than just the local BBS, you need
|
||
to use a designator in place of the BBS call. The designator
|
||
indicates the area where you want the message distributed. ALLCAN
|
||
indicates that you want the message sent to all Northern California
|
||
BBSs, which includes all of them from Santa Cruz, Hollister, Gilroy,
|
||
and Fresno northward. ALLCAS will send the message to all BBSs in
|
||
the southern part of the state. A message that's sent @ ALLCA will
|
||
go to EVERY BBS in the state, and a message sent @ ALLUS will be sent
|
||
to EVERY BBS IN THE USA. Extreme care should be used when using the
|
||
ALLUS designator. Please make sure that the subject matter is of
|
||
interest to EVERY packet user and please keep the message SHORT. The
|
||
National HF Packet Network is somewhat fragile, due to band condi-
|
||
tions, so unnecessary traffic can keep more important traffic from
|
||
getting through. Here are a few examples of addressing bulletin-type
|
||
messages for general distribution: SB ALL @ ALLCAN SB ALL @ ALLCA
|
||
SB QST @ ALLCAS SB ALL @ ALLUS
|
||
|
||
If you have traffic for the National Traffic System, you must use a
|
||
special format. NTS messages are entered as ST ZIPCODE @ NTSXX,
|
||
where XX is the two-letter state abbreviation. Examples:
|
||
ST 03452 @ NTSNH ST 60626 @ NTSIL
|
||
NTS traffic for California locations do not need the NTSCA. Simply
|
||
enter ST 90028 or ST 94101, for example. (You'll find more details
|
||
on NTS traffic handling in a later part of this series.)
|
||
|
||
When you have the address line complete, you enter a carriage return.
|
||
You'll then receive a prompt asking for the SUBJECT or TITLE of the
|
||
message. Enter a brief description of what the message will be
|
||
about, followed by a carriage return. Next, you'll be prompted to
|
||
enter the TEXT of the message. When entering the text, you should
|
||
insert carriage returns at the end of each line, as if you were
|
||
typing a letter. A normal line has a maximum of 80 characters, so
|
||
when you have 70 to 75 characters typed, enter a carriage return and
|
||
continue on the next line. This will prevent words from wrapping
|
||
around to the next line and the program inserting an unnecessary
|
||
blank line in the text.
|
||
|
||
When you have your message complete, you end it with a CONTROL Z.
|
||
(You send a CONTROL Z by holding down both the CONTROL key and the Z
|
||
key simultaneously.) You should follow the CONTROL Z with a carriage
|
||
return. When you receive the BBS prompt back, you'll know that the
|
||
message has been accepted by the system.
|
||
|
||
FILE DIRECTORY COMMANDS:
|
||
|
||
W (What) - Entering W, by itself, gives you a list of the direc-
|
||
tories available on the BBS.
|
||
Wd - Gives a list of the files in the directory indicated by d.
|
||
The list you obtain with the W command will indicate what letter to
|
||
use for "d" to list the files of specific topics.
|
||
|
||
D (Download) - Used for reading files from a directory. Must be
|
||
used with a directory ID and filename using the following form:
|
||
Dx filename. x is the directory ID and the filename must be
|
||
entered exactly as listed in the directory. Again, the
|
||
directory ID is obtained from the list you receive with the
|
||
W command. Example: DG FCCEXAMS.88
|
||
|
||
U (Upload) - Used for uploading (sending) a file to the BBS. The
|
||
command must be used with a directory ID, followed by the filename
|
||
you're assigning to the file, using the form: Ud filename. The d
|
||
indicates the ID of the directory where you want to enter the file.
|
||
Filenames can have up to 8 characters preceding the dot and 3 char-
|
||
acters following the dot. Example: UM FLEAMKT.INF would upload a
|
||
file named FLEAMKT.INF into the directory with the M ID. The BBS
|
||
program will not allow you to upload a file with a filename that
|
||
already exists, and some directories are set by your local sysop
|
||
for downloadiing only.
|
||
|
||
GENERAL MISCELLANEOUS COMMANDS:
|
||
|
||
I (Info) - Gives you details on the hardware, software and RF
|
||
facilities of the BBS you're using.
|
||
|
||
J - Displays a listing of stations that were heard by the BBS or
|
||
that connected to the BBS. Must be used with a port identifier, such
|
||
as JA, JB, etc. J by itself will list the port IDs for you.
|
||
|
||
M (Monitor) - Used for monitoring the activity on another port of
|
||
the BBS. Must be used with a port identifier, such as MA, MB, etc.
|
||
M by itself will list he port IDs.
|
||
|
||
B (Bye) - When you're finished using the BBS, you enter a B to
|
||
disconnect.
|
||
|
||
|
||
INTRODUCTION TO PACKET RADIO - PART 6 - By Larry Kenney, WB9LOZ
|
||
|
||
In this part of the series we're going to take a look at how to use
|
||
NET/ROM and THENET for making contacts. It's a way of making your
|
||
operating time on packet more enjoyable due to the increased relia-
|
||
bility of the network and the greatly expanded area that you can
|
||
reach.
|
||
|
||
When a digipeater adds NET/ROM or THENET it becomes a digipeater/node.
|
||
This means that you can still use it as a regular digipeater, but you
|
||
can also use it to access a far reaching network of nodes. When using
|
||
a string of digipeaters, your packets have to reach their destination
|
||
parity correct, and the receiving TNC has to return an acknowledgement
|
||
(ack) to your TNC for each packet cycle to be completed. As you add
|
||
more digipeaters to the string, the chances of this happening become
|
||
less and less. Other stations on the frequency and noise can be the
|
||
cause of many retries. When using a node, your packets no longer have
|
||
to reach their destination before acknowledgements are returned to your
|
||
TNC. Now, each node acknowledges your packet as its sent along the way
|
||
toward its destination.
|
||
|
||
Here's how you use the nodes network: No matter what station you want
|
||
to work, you connect to the closest node. When you connect, your TNC
|
||
automatically switches to converse mode, so anything you now type is sent
|
||
to the node as a packet, and the node acknowledges each packet back to
|
||
your TNC. For the remainder of your connection your TNC works only with
|
||
this node.
|
||
|
||
Once you're connected to the node, enter "NODES" <return> and you'll
|
||
receive a list of the other nodes available to you. It's sometimes
|
||
difficult to determine the location of the nodes from this list, since
|
||
the IDs and callsigns you receive aren't always very descriptive. You
|
||
might find the node maps and listings that are available on most packet
|
||
bulletin boards to be useful tools. With these maps and listings, you
|
||
can easily determine where the nodes are located. Make sure you have a
|
||
recent copy, as new nodes are being added quite frequently.
|
||
|
||
Let's say you want to have a QSO with N6XYZ. You first must determine
|
||
what node is closest to that station. Let's say it's W6AMT-3. Once you
|
||
know the call of that node, you connect to it WHILE STILL CONNECTED TO
|
||
YOUR LOCAL NODE. You use standard protocol, C W6AMT-3. Your TNC will
|
||
send this as a packet to your local node, and your local node will ack
|
||
it. Your TNC is happy because the cycle is completed as far as it's
|
||
concerned. The network will then go to work for you and find the be<62><65>
|
||
path between your local node and the one you're trying to reach. You'll
|
||
then see one of two responses: "Connected to W6AMT-3" OR "Failure with
|
||
W6AMT-3". If it can't connect for some reason, try again later. It could
|
||
be that W6AMT-3 is temporarily off the air or the path has decayed and is
|
||
no longer available. We're going to be positive here and say we received
|
||
the first option.
|
||
|
||
Now that you're connected to W6AMT-3, enter "C N6XYZ". Again, your TNC
|
||
will send this as a packet to your local node and the node will acknowl-
|
||
edge it and send it down the path to W6AMT-3. W6AMT-3 will then attempt
|
||
to connect to N6XYZ. Here again you'll get one of the two responses:
|
||
"Connected to N6XYZ" OR "Failure with N6XYZ". If you get connected,
|
||
you hold your QSO just as you normally would, but there's one BIG diff-
|
||
erence -- your TNC is receiving acknowledgements from your local node,
|
||
and N6XYZ is receiving acknowledgements from W6AMT-3. That long path is
|
||
eliminated for both TNCs, retries are greatly reduced, and your packets
|
||
get through much faster. When you're finished with the QSO, you discon-
|
||
nect in the normal manner -- go to Command Mode using Control C and enter
|
||
"D" <CR>. The entire path will then disconnect automatically for you.
|
||
|
||
If you've been monitoring lately, you might have seen the nodes in action
|
||
and wondered why they were sending all of those weird symbols like @fx/<~|.
|
||
What you're seeing is the nodes communicating with each other, updating
|
||
their node lists. You also might have noted callsigns with high numbered
|
||
SSIDs, such as WB9LOZ-15, WA6DDM-14, W6PW-12, etc. The nodes change the
|
||
SSID of all stations so that the packets sent via the network are not the
|
||
same as those sent directly. If you were to use a node to connect to
|
||
another station in the local area, there's the possibility of your packets
|
||
being received at this station both from you directly and from the node.
|
||
If the call through the node wasn't changed, the TNCs involved would be
|
||
totally confused as it would appear that two stations were connecting
|
||
using the same callsign. The node automatically changes the SSID using
|
||
the formular 15-N, where N is your usual SSID. A call with -0 becomes
|
||
-15, a -1 becomes -14, -2 becomes -13, etc.
|
||
|
||
|
||
INTRODUCTION TO PACKET RADIO - Part 7 - by Larry Kenney, WB9LOZ
|
||
|
||
The network of NET/ROM, THENET and KAM nodes is expanding very quickly
|
||
and now covers most of the country. New nodes are showing up almost
|
||
daily. Thanks to all of these new stations and the interconnecting
|
||
links, you can now connect to stations in many far distant places using
|
||
your low powered 2 meter rig. Some nodes are set up for cross-banding,
|
||
and with the introduction of nodes on 10 meter FM, there's the possi-
|
||
bility of working a station just about anywhere.
|
||
|
||
A complete listing of NET/ROM NODES is available on most BBSs, as well
|
||
as maps showing how everything is tied together. The lists are updated
|
||
frequently by Scott, N7FSP, in San Jose.
|
||
|
||
NET/ROM is very simple to use, and I understand that THENET and KAM
|
||
nodes are very similar. As explained in part 6 of this series, to use
|
||
NET/ROM, you first connect to a local node. You then have several
|
||
options -- connect to another station within range of the node, connect
|
||
to another node, obtain a list of the nodes that are available, check
|
||
user status, or answer or call CQ.
|
||
|
||
There are only FOUR commands to remember to use the system: CONNECT,
|
||
NODES, USERS and CQ. The CONNECT command (which can be abbreviated as C)
|
||
works just like the CONNECT command in normal usage, except that you can
|
||
connect from one node to another. For example, you can CONNECT to W6AMT,
|
||
and then do another CONNECT to WA6RDH-1, another node. Let's go through a
|
||
simple connection via NET/ROM. Say I want to connect to a friend in Reno,
|
||
within reach of WA7DIA-1, a node in the Sierras. I would first connect
|
||
to my local node, say W6AMT, then connect to WA7DIA-1, then connect to my
|
||
friend. Here's what it would look like:
|
||
C W6AMT
|
||
Connected to W6AMT
|
||
C WA7DIA-1
|
||
SFO:W6AMT} Connected to RNO:WA7DIA-1
|
||
C K7ZYX
|
||
RNO:WA7DIA-1} Connected to K7ZYX
|
||
You then conduct your QSO, and disconnect in the normal manner. (Go to
|
||
command mode on your TNC and enter a D.) One disconnect command will
|
||
disconnect you from the entire network.
|
||
|
||
You'll note that many of the nodes have aliases, such as SFO for W6AMT,
|
||
VACA for WA6RDH-1, SSF1 for KA6EYH-1, etc. With NET/ROM, you can connect
|
||
to the alias identifier, so "C SFO" would work as well as "C W6AMT".
|
||
|
||
Once connected to a node, the other commands come into play. The NODES
|
||
command (which can be abbreviated as N) will give you a listing of other
|
||
nodes available from the node you're connected to. The USERS command
|
||
(which can be abbreviated as U) will show you the calls of all the
|
||
stations using the node you're connected to. The CQ command (which
|
||
cannot be abbreviated) is, of course, used for calling CQ, but also can
|
||
be used for replying to the CQ of another station. The CQ command is
|
||
available only in NET/ROM version 1.3.
|
||
|
||
There are two other commands, but they're used for status information
|
||
only. IDENT will simply give you the identification of the node you're
|
||
on, and PARMS (Parameters) is for the owner's use in determining how his
|
||
station is working.
|
||
|
||
Using the NET/ROM CQ Command: The CQ command is used to transmit a short
|
||
text message from a node, and is also used to enable stations that receive
|
||
the transmission to connect to the station that originated it. The
|
||
command is:
|
||
CQ [textmessage]
|
||
The "textmessage" is optional and can be any string up to 77 characters
|
||
long (blanks and punctuation are allowed). In response to a CQ command,
|
||
the node transmits the specified textmessage in "unproto" mode, using the
|
||
callsign of the originating user with a translated SSID as the source and
|
||
"CQ" as the destination. For example, if user station W6XYZ connects to a
|
||
node and issues the command: "CQ Anybody around tonight?", the node would
|
||
then transmit
|
||
"W6XYZ-15>CQ: Anybody around tonight?"
|
||
|
||
After making the transmission in response to the CQ command, the node
|
||
"arms" a mechanism to permit other stations to reply to the CQ. A station
|
||
wishing to reply may do so simply by connecting to the originating call-
|
||
sign shown in the CQ transmission (W6XYZ-15 in the example above). A CQ
|
||
command remains "armed" to accept replies for 15 minutes, or until the
|
||
originating user issues another command or disconnects from the node.
|
||
|
||
Any station connected to a node may determine if there are any other
|
||
stations awaiting a reply to a CQ by issuing a USERS command. An "armed"
|
||
CQ channel appears in the USERS display as:
|
||
(Circuit, Host, or Uplink) <~~> CQ(usercall).
|
||
The station may reply to such a pending CQ by issuing a CONNECT to the user
|
||
callsign specified in the CQ(...) portion of the USERS display--it is not
|
||
necessary for the station to disconnect from the node and reconnect. Here's
|
||
what a typical transmission would look like:
|
||
cmd: C KA6YZS-1
|
||
cmd: *** Connected to KA6YZS-1
|
||
USERS
|
||
501SJC:KA6YZS-1} NET/ROM 1.3 (669)
|
||
Uplink(WB9LOZ)
|
||
Uplink(K1HTV-1) <~~> CQ(K1HTV-14)
|
||
Circuit(LAS:K7WS-1 W1XYZ) <~~> CQ(W1XYZ-15)
|
||
Uplink(N4HY)
|
||
CONNECT W1XYZ-15
|
||
501SJC:KA6YZS-1} Connected to W1XYZ
|
||
Hi! Thanks for answering my CQ.
|
||
etc.
|
||
|
||
Users of the CQ command are cautioned to be patient in waiting for a
|
||
response. Your CQ will remain "armed" for 15 minutes, and will be visible
|
||
to any user who issues a USERS command at the node during that time. Wait
|
||
at least five minutes before issuing another CQ--give other stations a
|
||
chance to reply to your first one!
|
||
|
||
NOTE: As mentioned above, the CQ command was introduced in NET/ROM version
|
||
1.3. On a node using an earlier version, you will get the message "Invalid
|
||
command". The USERS command can be used to determine which version a node
|
||
is using as shown in the example above. If you cannot initially connect
|
||
to a node using version 1.3, that doesn't stop you from using the CQ command.
|
||
Once you're connected to a node you can reach, simply connect to one that
|
||
has version 1.3.
|
||
|
||
Give the new CQ feature a try. You might work someone locally, in Phoenix,
|
||
Seattle, or on the East Coast. You never know where you'll get connected
|
||
to next! Enjoy!
|
||
|
||
|
||
INTRODUCTION TO PACKET RADIO - PART 8 by Larry Kenney, WB9LOZ
|
||
|
||
The National Traffic System, known as NTS, is the ARRL sponsored Amateur
|
||
Radio message handling network. Packet radio is now playing a very
|
||
important part in the network, so we're going to look at the system and
|
||
give you some tips on handling NTS traffic by packet.
|
||
|
||
Handling third party traffic is the oldest tradition in amateur radio.
|
||
This is most valuable during disasters. Nationwide, the National
|
||
Traffic System has hundreds of local and section nets meeting daily
|
||
in order to facilitate the delivery and origination of such messages.
|
||
More and more of this traffic is being originated, relayed, and
|
||
delivered on packet. If you enjoy traffic handling, you can easily get
|
||
involved in NTS via packet. If you're on packet but know nothing about
|
||
NTS, this part of the series can get you off to a good start. At the
|
||
end of this part, you'll find some references for further information.
|
||
|
||
Local packet BBSs have to be checked daily for traffic that needs to be
|
||
delivered or relayed. When you check into your local BBS, enter the LT
|
||
command, meaning "List Traffic". The BBS will sort and display a list
|
||
of all NTS traffic awaiting delivery. It'll look similar to this
|
||
example:
|
||
|
||
MSG# STAT SIZE TO FROM @BBS DATE/TIME SUBJECT
|
||
7893 T 486 60625 KB6ZYZ NTSIL 1227/0712 QTC1 CHICAGO, IL 312-267
|
||
7802 T 320 06234 K6TP NTSCT 1227/0655 QTC1 NEW HAVEN, CT
|
||
7854 T 588 93432 KA4YEA 1227/0625 QTC1 CRESTON, CA 93432
|
||
7839 T 412 94114 KK3K 1227/0311 QTC1 SAN FRANCISCO 415-821
|
||
7781 T 298 94015 W1KPL 1226/2356 QTC1 DALY CITY, CA 415-992
|
||
|
||
You might see traffic that is being relayed by your local BBS to some
|
||
other part of the country as well as traffic for your local area. The
|
||
"Subject" or "Title" column of the listing will show the destination of
|
||
the traffic. If you see a message that is within your local area, help
|
||
out and deliver it.
|
||
|
||
RECEIVING A MESSAGE: To take a message off of the Bulletin Board for
|
||
telephone delivery, or for relay to a local NTS net, enter R followed by
|
||
the message number. Using the list above, R 7839 would send you the
|
||
message from KK3K for San Francisco. You'll find the message in a
|
||
special NTS RADIOGRAM format, with a preamble, address, telephone
|
||
number, text and signature, ready for delivery. After the message has
|
||
been saved to your printer or disk, the message should be erased from
|
||
the BBS. You use the KT command, which means "Kill Traffic", followed
|
||
by the message number. In this case you would enter KT 7839 to erase
|
||
the message you took from the BBS. This prevents the message from being
|
||
delivered again by someone else.
|
||
|
||
DELIVERING OR RELAYING A MESSAGE: Once you have received the NTS Radio-
|
||
gram, it should, of course, be handled expeditiously. If it's for your
|
||
immediate area, you should deliver the message by telephone. If you
|
||
took the message for delivery to the local traffic net, you should make
|
||
an effort to see that it gets relayed as quickly as possible.
|
||
|
||
SENDING MESSAGES: Any amateur can originate a message on behalf of
|
||
another individual, whether the person is a licensed amateur or not. It
|
||
is the responsibility of the originating amateur, however, to see that
|
||
the message is in proper form before it's transmitted. A special format
|
||
is used for NTS traffic, so that the messages are compatible across the
|
||
entire network. Each message originated and handled should contain the
|
||
following components in the order given: number, precedence, handling
|
||
instructions (optional), the station of origin, check, place of origin,
|
||
time filed, date, address, telephone number, text and signature. You
|
||
should check the ARRL publications or your local BBS for details on
|
||
message preparation.
|
||
|
||
When the message is ready to be entered into your local BBS, you must
|
||
use the ST command, which means "Send Traffic", followed by the zip code
|
||
of the destination city, and "NTS" followed by the two letter state
|
||
abbreviation. The form used is ST Zipcode @ NTSxx. A message being
|
||
sent to Boston, MA 02109 would be entered as follows: ST 02109 @ NTSMA
|
||
and a message for Iowa City, IA 52245 would be entered as ST 52245 @
|
||
NTSIA. The message SUBJECT or TITLE should contain "QTC 1" followed by
|
||
the destination city and state and the telephone area code and exchange,
|
||
if available. See the examples in the listing above. Only one NTS
|
||
message should be included in each packet message. The actual radiogram
|
||
should be included entirely within the TEXT of the packet message,
|
||
including all of the componE6%.@<40>[.]Y<> a<><61>W<EFBFBD> <09>Q<EFBFBD>$hZYH<59>֮<EFBFBD>X<EFBFBD><58><EFBFBD><EFBFBD>ѡ<EFBFBD><D1A1><EFBFBD><EFBFBD>5RTsual Control-Z.
|
||
|
||
IN TIME OF EMERGENCY: The National Traffic System functions on a daily
|
||
basis as a positive public service for both your fellow hams and the
|
||
general public. It serves another function as well. The NTS provides a
|
||
well oiled and trained national system of experienced traffic handlers
|
||
able to handle large volumes of third party traffic accurately and
|
||
efficiently during disasters. At least that is the goal. The ARRL
|
||
booklet "An Introduction to Operating an Amateur Radio Station" offers
|
||
detailed information on handling and preparing NTS Radiograms and the
|
||
files section of your BBS should have instructional files on NTS. You
|
||
should find files such as "Delivery.NTS", "Howto.NTS", "Whatis.NTS", as
|
||
well as several other helpful files. Check them out if you want to get
|
||
involved. Your help will be welcome!
|
||
|
||
|
||
INTRODUCTION TO PACKET RADIO - PART 9 - by Larry Kenney, WB9LOZ
|
||
|
||
In this part of the series I'll explain, in detail, the various parts
|
||
of the packet message. The following is an example of what you see
|
||
when listing or reading messages on a BBS. On some systems, the infor-
|
||
mation is displayed in a different order.
|
||
|
||
MSG# STAT SIZE TO FROM @ BBS DATE/TIME SUBJECT
|
||
4723 P 1084 WD5TLQ WA6XYZ N5SLE 0604/1240 Software working great!
|
||
|
||
The message number is assigned by the BBS program when the message
|
||
is entered and cannot be changed. The numbers are assigned sequen-
|
||
tially.
|
||
|
||
Next you find the STATUS of the message which includes several different
|
||
bits of information about the message.
|
||
|
||
The first letter of the STATUS indicates the TYPE of message: B for
|
||
Bulletin, P for Personal, or T for Traffic for the National Traffic
|
||
System. Bulletins are messages of general interest to all users, and
|
||
are available to be read by everyone using the system. Personal
|
||
messages are not listed for anyone except the sender and the addressee,
|
||
and only they can read them. (Of course, anyone in monitor mode can
|
||
see a message of this type as it's being sent, because nothing on packet
|
||
is absolutely private.) Traffic messages, type T, are messages used for
|
||
handling traffic on the National Traffic System. (Refer to part 8 of
|
||
this series for information on NTS.)
|
||
|
||
STATUS also shows if the message has been read, has already been
|
||
forwarded to all designated stations, is in the process of being for-
|
||
warded, or is an "old" message. You might see one of these letters:
|
||
Y - yes, it has been read, F - it has been forwarded, I - it's in the
|
||
process of being forwarded right now on another port, or O - the message
|
||
has been on the BBS long enough to become an "old" message. "Old" can
|
||
be anywhere from 2 days for an NTS message to 3 weeks for bulletins.
|
||
The time frame for each message type is specified by the local sysop.
|
||
The "O" is mainly used to catch the attention of the sysop.
|
||
|
||
The SIZE indicates the combined total of characters, including punctu-
|
||
ation in the message.
|
||
|
||
TO, normally, is the callsign of the addressee, but it is also used to
|
||
categorize messages on particular topics. You might find a message
|
||
addressed TO AMSAT, TO PACKET or TO ARRL, when it is actually a message
|
||
about AMSAT, about PACKET or having to do with the ARRL.
|
||
|
||
FROM shows the callsign of the station originating the message.
|
||
|
||
@ BBS is used if you want a message to be forwarded to someone at
|
||
another BBS or to a specific designator. In the example, the message
|
||
would be automatically forwarded to WD5TLQ at the N5SLE BBS. You can
|
||
enter special designators, such as ALLCAN, in the "@ BBS" column for
|
||
multiple forwarding to specific areas. (See Part 5 of this series for
|
||
details on using forwarding designators.)
|
||
|
||
Next is the DATE and TIME when the message was received at the BBS.
|
||
Keep in mind that the date and time are shown in the time used by the
|
||
BBS, and can be either local time or Zulu.
|
||
|
||
The SUBJECT (or TITLE) is a short line telling what the message is all
|
||
about. It should be brief, but informative. For bulletin type messages,
|
||
this is the information that determines whether or not a person is going
|
||
to read your message when he sees it in the message list.
|
||
|
||
The parts of the message mentioned so far are all included in the header
|
||
of the message, and are seen when listing messages. The remaining parts
|
||
are in the body of the message, and are seen only when the message is read.
|
||
|
||
If a message has been forwarded from another BBS, you'll see forwarding
|
||
headers at the top of the actual message. This is information added by
|
||
each BBS that was used to get the message from its origination point to
|
||
the destination. Each BBS adds one line showing the time the message
|
||
was received by that particular BBS, its call sign, and usually the QTH,
|
||
zip code, and message number. Other information is often added, at the
|
||
discretion of the sysop there. If you use the RH command, rather than
|
||
just R, when reading a message, such as RH 7823, you'll receive complete
|
||
headers. With just the R, headers are reduced to a list of the BBS
|
||
callsigns. Complete headers are useful if you want to determine how
|
||
long it took a message to be forwarded from the source to destination,
|
||
and they can be used to determine the path the message took to reach you.
|
||
|
||
The TEXT of the message contains the information you want to convey to
|
||
the reader. It can be of any length. When entering a message into a
|
||
BBS, use carriage returns at the ends of your lines, as if you were using
|
||
a typewriter. Do not allow the automatic wrapping of lines to occur.
|
||
A message entered without carriage returns is very difficult to read, as
|
||
words are cut at improper points, lines vary drastically in length, and
|
||
blank lines are often inserted.
|
||
|
||
You complete the text with either a Control-Z or these three characters:
|
||
the "slash" (/) plus the letters "EX". On some BBSs this must be on a
|
||
line by itself. This tells the system that you've finished entering the
|
||
message.
|
||
|
||
Messages that are going to be forwarded to several BBSs or across a long
|
||
distance should be limited in size. Extremely long messages can tie up
|
||
the forwarding system unnecessarily, so users are advised to break up
|
||
long messages into parts, keeping them to a length of 2 - 3 K each.
|
||
|
||
|
||
INTRODUCTION TO PACKET RADIO - Part 10 - by Larry Kenney, WB9LOZ
|
||
|
||
Here are some tips to help make your packet operating a little more
|
||
enjoyable. Whether it's while making local QSOs, checking into a
|
||
BBS or mailbox, or working DX, there are a few things you should
|
||
take into consideration that will help eliminate waiting time and
|
||
increase your throughput.
|
||
|
||
When connecting to another station, don't use a digipeater unless you
|
||
have to. Each digipeater you add to the chain increases the time
|
||
required to get your signal to its destination and to get an acknowl-
|
||
edgement returned. It also increases the chance for interference
|
||
and for collisions with other packets. You'll be amazed at the
|
||
difference in throughput when comparing a direct connect to one with
|
||
just one digipeater in the path.
|
||
|
||
Also, if you have a choice, use a frequency that doesn't have a lot
|
||
of other traffic on it. It makes sense that the more stations there
|
||
are on frequency, the more chances there are for collisions and
|
||
retries. A path that will work perfectly without a lot of traffic,
|
||
can become totally useless under heavy traffic conditions.
|
||
|
||
Dr. Tom Clark, W3IWI, has determined that for EACH HOP, the loss
|
||
of packets can vary anywhere from 5% to 50% depending on the amount
|
||
of traffic. Remember, each digipeater and node adds a hop, so
|
||
multiply those percentages by the number of hops, then multiply by 2
|
||
to account for the acknowledgement, and you can see how quickly the
|
||
path deteriorates as traffic increases and digipeaters and nodes are
|
||
added to it.
|
||
|
||
Another consideration, especially if working over a long distance, is
|
||
atmospheric conditions. You might not have experienced this before
|
||
on VHF, but with packet's high sensitivity to noise, a slight change
|
||
in signal strength can mean the difference between getting your
|
||
packets through or not getting them through. An example of one path
|
||
that is very vunerable to conditions due to its distance is from
|
||
W6AK-1 on Mt. Vaca to WB6AIE-1 on Bald Mountain in Yosemite National
|
||
Park on 145.05 MHz. Most of the time, packets go between these two
|
||
digipeaters without any problem, but there are times, especially
|
||
when it's a hot summer day in the Sacramento Valley, when it's impos-
|
||
sible to get a packet from one to the other. In the Bay Area, the
|
||
fog has a drastic affect on VHF signals. When a fog bank is moving
|
||
in off the Pacific, it can act as an excellent reflector. Signals
|
||
that are not normally heard can reach signal strengths of 40 over S9.
|
||
|
||
NET/ROM, TheNet, and KA-Nodes, as discussed in previous articles in
|
||
this series, do a great deal to help you get your packets through,
|
||
but you must remember that they, too, are affected by the number of
|
||
hops, the traffic load and the atmospheric conditions between you and
|
||
the destination station. The big advantage to NET/ROM is that the
|
||
acknowledgements do not have to return all the way from the desti-
|
||
nation station. Packets are acknowledged from node to node, so
|
||
that eliminates a large part of the problems encountered. Getting
|
||
the original packet through, however, remains to be as much of a
|
||
problem for the nodes as it is for you when using digipeaters.
|
||
|
||
|
||
INTRODUCTION TO PACKET RADIO - Part 11 - by Larry Kenney, WB9LOZ
|
||
|
||
In this part of the series we'll take a look at many of the TNC
|
||
commands available to you that we haven't covered in previous
|
||
articles. We will be discussing the commands used in the TAPR TNC2
|
||
and TNC2 clones. You might find that some of the commands are not
|
||
available in your particular TNC or that they're used in a slightly
|
||
different manner than the one explained here. Please refer to your
|
||
owner's operating manual for specific details on how to use these
|
||
commands in your TNC.
|
||
|
||
8BITCONV: This command enables the transmission of 8-bit data in
|
||
converse mode. Used with AWLEN - see below.
|
||
For normal packet operation, such as keyboard to keyboard trans-
|
||
missions, use of bulletin boards, and transmission of ASCII files,
|
||
8BITCONV should be OFF. If you need to transmit 8-bit data, set
|
||
8BITCONV ON and set AWLEN to 8. Make sure that the TNC at the
|
||
receiving end is also set up this way. This procedure is normally
|
||
used for transmission of executable files or a special non-ASCII
|
||
data set.
|
||
|
||
AWLEN: This parameter defines the word length used by the serial
|
||
input/output port of your TNC.
|
||
For normal packet operation, as described above, AWLEN should be set
|
||
to 7. Set to 8 only if you're going to send 8-bit data.
|
||
|
||
AX25L2V2: This command determines which level of AX.25 protocol
|
||
you're going to use.
|
||
If OFF, the TNC will use AX.25 Level 2, Version 1.0.
|
||
If ON, the TNC will use AX.25 Level 2, Version 2.0.
|
||
Some early TNCs will not digipeat Version 2.0 packets.
|
||
Version 2.0 has added features. See the CHECK command below. Many
|
||
operators have suggested that Version 2.0 NOT be used on the HF bands
|
||
as it tends to clutter the frequency.
|
||
|
||
BEACON: Used with EVERY or AFTER to enable beacon transmissions.
|
||
BEACON EVERY n - send a beacon at regular intervals specified by n.
|
||
BEACON AFTER n - send a beacon once after a time interval specified
|
||
by n having no packet activity.
|
||
n = 0 to 250 - specifies beacon timing in ten second intervals.
|
||
1 = 10 seconds, 2 = 20 seconds, 30 = 300 seconds or
|
||
5 minutes, 180 = 1800 seconds or 30 minutes, etc.
|
||
For example, if you set BEACON EVERY 180 (B E 180), the TNC will
|
||
transmit a beacon every 30 minutes. If you set BEACON AFTER 180
|
||
(B A 180), the TNC will transmit a beacon after it hears no activity
|
||
on the frequency for 30 minutes. B E 0 will turn the beacon off.
|
||
The text of the beacon is specified by BTEXT and can contain up to
|
||
120 characters. The path used for the beacon transmission is
|
||
specified by the UNPROTO command. YOU SHOULD USE BEACONS
|
||
INTELLIGENTLY! Beacons are often a point of controversy in the
|
||
packet community because they tend to clutter the frequency if used
|
||
too frequently. You should keep your beacons short and infrequent,
|
||
and they should only be used for meaningful data. Bulletin boards
|
||
use the beacon for advising the community of who has mail waiting for
|
||
them, clubs use beacons for meeting announcements, beacons are used
|
||
for weather warnings, etc.
|
||
|
||
CHECK n Sets a timeout value for a packet connection. Operation
|
||
depends on the setting of AX25L2V2. The value of CHECK
|
||
(n) determines the timing. Value may be 0 to 250. Check
|
||
set to 0 disables the command.
|
||
If a connection between your station and another exists and the other
|
||
station seems to "disappear" due to changing propagation or loss of
|
||
an intermediate digipeater, your TNC could remain in the connected
|
||
state indefinitely. If the CHECK command is set to a value other
|
||
than 0, the TNC will attempt to recover. The setting of AX25L2V2
|
||
will determine what action is taken.
|
||
If AX25L2V2 is ON, the TNC will send a "check packet" to verify the
|
||
presence of the other station if no packets have been heard for n *
|
||
10 seconds. (n = 1 = 10 seconds, n = 5 = 50 seconds, n = 30 = 5
|
||
minutes, etc.) If a response is received, the connection will
|
||
remain. If no response is received, the TNC will begin the dis-
|
||
connect sequence, just as if the DISCONNECT command had been sent.
|
||
If AX25L2V2 is OFF, after no packets are heard for n * 10 seconds,
|
||
the TNC will not send a check packet, but will begin the disconnect
|
||
sequence.
|
||
|
||
CMSG Enables the automatic sending of a connect message when-
|
||
ever a station connects to your TNC.
|
||
If CMSG is ON, the TNC will send the message contained in CTEXT as
|
||
the first packet of the connection. CTEXT can contain up to 120
|
||
characters. This feature is often used when the station is on but
|
||
the operator is not present. The connect message is used to advise
|
||
the other station of that fact, and often says to leave a message in
|
||
the TNC buffer. If CMSG is off, the text message is not transmitted.
|
||
|
||
MAXFRAME Sets the upper limit on the number of unacknowledged
|
||
packets the TNC can have outstanding at any time. (The
|
||
outstanding packets are those that have been sent but
|
||
have not been acknowledged.) It also determines the
|
||
maximum number of contiguous packets that can be sent
|
||
during one transmission. Value can be set from 1 to 7.
|
||
The best value of MAXFRAME depends on the frequency conditions. The
|
||
better the conditions are, the higher the value you can use. If
|
||
conditions are poor due to the amount of traffic on the frequency,
|
||
noise, or other variables, (shown by lots of retries) MAXFRAME should
|
||
be reduced to improve throughput. The best value of MAXFRAME can be
|
||
determined through experimentation. MAXFRAME of 1 should be used for
|
||
best results on HF packet.
|
||
|
||
MHEARD An immediate command that causes the TNC to display a list
|
||
of stations that have been heard since the command MHCLEAR
|
||
was given or the TNC was powered on.
|
||
This command is useful for determining what stations can be worked
|
||
from your QTH. Stations that are heard through digipeaters are
|
||
marked with an * on most TNCs. On the AEA PK-232, the stations heard
|
||
direct are marked with the *. (Check your TNC manual.) The maximum
|
||
number of stations in the list is 18. If more stations are heard,
|
||
earlier entries are discarded. Logging of stations heard is disabled
|
||
when the PASSALL command is ON. If the DAYTIME command has been used
|
||
to set the date and time, entries in the MHEARD list will show the
|
||
date and time the stations were heard.
|
||
|
||
PASSALL Causes the TNC to display packets that have invalid
|
||
checksums. The error-checking is disabled.
|
||
If PASSALL is ON, packets are accepted for display, despite checksum
|
||
errors, if they consist of an even multiple of eight bits and are up
|
||
to 330 bytes. The TNC attempts to decode the address field and
|
||
display the callsigns in standard format, followed by the text of the
|
||
packet. PASSALL can be useful for testing marginal paths or for
|
||
operation under unusual conditions. PASSALL is normally turned OFF.
|
||
|
||
SCREENLN n This parameter determines the length of a line of text on
|
||
the terminal screen or platen. Value may be 0 to 255.
|
||
A (CR-LF) carriage return and line feed are sent to the terminal in
|
||
Command and Converse modes when n characters have been printed. A
|
||
value of zero inhibits this action. If your computer automatically
|
||
formats output lines, this feature should be disabled.
|
||
|
||
TXDELAY n This parameter tells the TNC how long to wait before
|
||
sending data after it has keyed the transmitter.
|
||
All transmitters need some start up time to put a signal on the air.
|
||
Some need more, some need less. Synthesized radios and radios with
|
||
mechanical relays need more time, while crystal controlled radios and
|
||
radios with diode switching require less time. External amplifiers
|
||
usually require additional delay. Experiment to determine the best
|
||
value for your particular radio.
|
||
TXDELAY can also be useful to compensate for slow AGC recovery or
|
||
squelch release times at the distant station.
|
||
|
||
There are many additional commands available to you. I've only
|
||
covered the ones that I thought would be the most useful to you.
|
||
Spend some time reading the owner's operating manual that came with
|
||
your TNC to discover some of the surprises the other commands offer.
|
||
New versions of the TNC software have added several commands that you
|
||
might find useful in your packet operating.
|
||
|
||
|
||
INTRODUCTION TO PACKET RADIO -- Part 12
|
||
by Larry Kenney, WB9LOZ
|
||
|
||
In this article we're going to look at the White Pages. Not your
|
||
local telephone directory, but the packet radio directory known as
|
||
"White Pages". You help supply the information for "WP", and you can
|
||
also use it to find the home BBS, QTH and zip code of your friends on
|
||
packet.
|
||
|
||
"White Pages" was initially designed by Eric Williams, WD6CMU, of
|
||
Richmond, California. It's a database of packet users showing their
|
||
name, home BBS, QTH and zip code. It's updated and queried by packet
|
||
message, allowing stations from all over the world to take advantage
|
||
of it. Hank Oredson, W0RLI, later added a WP feature to his packet
|
||
bulletin board software. As users enter their name, home BBS, QTH
|
||
and zip code into the BBS user file, the software automatically
|
||
assembles a message once a day containing all of the latest user
|
||
information and sends it to the WD6CMU White Pages. Hank has now
|
||
expanded the WP feature, and each BBS running the W0RLI software can
|
||
now elect to operate its own White Pages database. Each BBS,
|
||
however, continues to send a daily "WP" update of new or changed
|
||
information to the WD6CMU White Pages. You can easily make use of
|
||
the packet White Pages information, both at your local BBS and at
|
||
WD6CMU.
|
||
|
||
If your BBS is operating with its own WP database, you may make
|
||
inquiries of it using the "P" command. Simply enter P followed by
|
||
the callsign you'd like information about. If you wanted information
|
||
on WB9LOZ, for example, you would enter: P WB9LOZ.
|
||
|
||
Information from the WD6CMU White Pages is obtained by sending a
|
||
message to "WP @ WD6CMU". You can also update the database with new
|
||
information. One message can contain several lines, including a
|
||
combination of queries and updates. Since the messages are read and
|
||
answered by the WP software, not a person, each line must have the
|
||
correct format. One of the following formats must be used:
|
||
<callsign> QTH?
|
||
<callsign> @ <BBS> <zip code> <name> <QTH>
|
||
DE <callsign> @ <BBS>
|
||
The first form is a query. It will cause a message to be returned to
|
||
you giving the home BBS, QTH and zip code of the person with the
|
||
given callsign. If the information is not available from the WP
|
||
database, the return message will tell you so. The second form adds
|
||
or changes the entry for the given callsign, and the third form
|
||
provides a return address for the requested information. Replies
|
||
will be sent to the originating station at the BBS specified. If the
|
||
return address line is not given, the WP program will attempt to
|
||
determine the originating station and BBS from the message headers.
|
||
|
||
Here are some examples of messages to the WD6CMU White Pages
|
||
database: Suppose you wanted to know the home BBS of K9AT. You
|
||
would send a message to WP like this:
|
||
(Your BBS) W6BBS>
|
||
SP WP @ WD6CMU
|
||
Enter title of message:
|
||
Query
|
||
Enter text:
|
||
K9AT QTH?
|
||
DE N6XYZ @ W6BBS
|
||
(Control Z)
|
||
Capital and lower case letters may both be used within the message.
|
||
|
||
If you wanted to update or add information to the White Pages, you
|
||
would send a message like this:
|
||
(Your BBS) W6BBS>
|
||
SP WP @ WD6CMU
|
||
Enter title of message:
|
||
Update
|
||
Enter text:
|
||
N6XYZ @ W6BBS 94199 John San Francisco, CA
|
||
AD6ZZ @ WB6ABC 94015 Anne Daly City, CA
|
||
DE N6ZYX @ W6BBS
|
||
(Control Z)
|
||
When updating or adding an entry to WP, you should make sure that the
|
||
information is accurate.
|
||
|
||
Here's an example of a message that has both queries and updates:
|
||
(Your BBS) W6BBS>
|
||
SP WP @ WD6CMU
|
||
Enter title of message:
|
||
Update/Query
|
||
Enter text:
|
||
K9AT QTH?
|
||
WA6DDM QTH?
|
||
N6XYZ @ W6BBS 94199 John San Francisco, CA
|
||
AD6ZZ @ WB6ABC 94015 Anne Daly City, CA
|
||
DE N6ZYX @ W6BBS
|
||
(Control Z)
|
||
|
||
Just like all other packet messages, messages addressed to WP @
|
||
WD6CMU are forwarded from BBS to BBS toward their destination. When
|
||
a message containing new or updated information passes through a BBS
|
||
operating the W0RLI WP program, the software recognizes the WP format
|
||
and extracts the information from the message for its di<64>`base. The
|
||
W0RLI WP program also collects data from any WP responses it sees and
|
||
from the message headers of every message that passes through. In
|
||
addition, if a BBS operating with the W0RLI WP sees a query, it will
|
||
respond with any pertinent information that it has available. As a
|
||
result, you might receive more than one response to your WP query.
|
||
|
||
The information on each call in a W0RLI WP database is usually
|
||
deleted in 60 to 90 days if it's not updated. This keeps each local
|
||
database current and at a manageable size. The WD6CMU White Pages
|
||
directory retains the data for a lo<6C>/er period of time.
|
||
|
||
It is important to note here that when you check into a new BBS, you
|
||
should always enter the same information that you have at previous
|
||
times. Choose ONE BBS as your home BBS, the one where you want all
|
||
of your messages delivered, and enter that callsign every time you're
|
||
asked. If you enter two or more different BBS calls at various
|
||
times, your mail could end up being sent from BBS to BBS.
|
||
|
||
When a message arrives at the destination given in the "@ BBS"
|
||
column, the latest software now checks the White Pages information to
|
||
make sure the message was delivered to the right place. If it finds
|
||
that you have a different BBS listed as your home BBS, it will insert
|
||
the new BBS callsign and send the message on its way. You may never
|
||
get it.
|
||
|
||
If you move or change your home BBS, you should then make sure that
|
||
you update the information for your call in the White Pages database.
|
||
If you use a BBS with W0RLI software, the BBS will send a WP message
|
||
for you if you use the NH, NQ and NZ commands to update the infor-
|
||
mation. If these commands aren't available on your BBS to make the
|
||
changes, you'll have to send a message update yourself to WP @
|
||
WD6CMU. Making sure that the information in the White Pages is
|
||
correct will help to get your messages delivered to the correct BBS.
|
||
|
||
|
||
INTRODUCTION TO PACKET RADIO - PART 13
|
||
by Larry Kenney, WB9LOZ
|
||
|
||
In this article, let's do some reviewing. I'm going to present a
|
||
short quiz on packet, covering the basics that I've presented in the
|
||
past 12 columns. Let's see how well you can answer the following
|
||
questions without looking back at the past articles. In Part 14,
|
||
I'll discuss each question and give you the correct answers.
|
||
|
||
1. What are the three TNC modes of communication?
|
||
a. Connect, Converse, Terminal
|
||
b. Command, Converse, Terminal
|
||
c. Command, Converse, Transparent
|
||
d. Command, Connect, Transparent
|
||
|
||
2. What TNC command is used to set the transmit path for beacons and
|
||
CQs?
|
||
|
||
3. What is the TNC command CHECK used for?
|
||
|
||
4. While you're connected to another station, what command is used to
|
||
monitor other traffic on the frequency?
|
||
|
||
5. If you saw one of the following lines on your screen when in
|
||
monitor mode, what would the asterisk indicate?
|
||
W6ABC-3>N6XYZ,W6PW-1*: Hi Bob
|
||
W6ABC-3>W6PW-1*>N6XYZ: Hi Bob
|
||
(Displays vary with various TNCs, so both common types are shown.)
|
||
|
||
6. Why do the NET/ROM and TheNet nodes improve communications?
|
||
|
||
7. If you're connected to a station in New Mexico using NET/ROM or
|
||
TheNet, how do you disconnect?
|
||
|
||
8. If N6ZYX-2 connected to you via a NET ROM or TheNet node, what
|
||
would the SSID of the station become at your end of the connection?
|
||
|
||
9. When you're connected to another station, what are the two most
|
||
probable causes for packets not to be received by the other station?
|
||
|
||
10. There are several basic commands used on a packet bulletin board
|
||
system. Indicate what you would enter to perform the following:
|
||
a. Receive a list of messages.
|
||
b. Download a file in the General (ID G) directory called
|
||
FCCEXAMS.89.
|
||
c. Enter a private message to Jim, WA6DDM, who uses the W6PW BBS.
|
||
d. Read message 7134 with complete headers.
|
||
e. Find out what stations have been heard on port B.
|
||
|
||
11. To send an NTS message via packet addressed to Tom Smith, 123 Main
|
||
Street, Keene, NH 03431, telephone (603) 555-4321, what would you
|
||
enter at the BBS prompt?
|
||
|
||
12. If a message has a STATUS of BF, what does that indicate?
|
||
|
||
13. If you received a message from a friend in Chicago that had been
|
||
forwarded to your home BBS through four other BBSs and the message
|
||
had a Date/Time of 0316/2245 when you listed it, which of the
|
||
following is a TRUE statement?
|
||
a. The message was written at 2:45 pm on March 16.
|
||
b. The message was entered into the BBS by your friend at 2245
|
||
on March 16.
|
||
c. The message was forwarded by your friend's BBS in Chicago at
|
||
2245 on March 16.
|
||
d. The message was received at your home BBS at 2245 on March 16.
|
||
|
||
14. If you wanted to send a message to your friend John, W4IP, but you
|
||
didn't know what the call of his home BBS was, what could you do to
|
||
try and find out what the call is?
|
||
|
||
15. BONUS: What is the maximum value for MAXFRAME? If you're working
|
||
a station on 30 meters and are sending a lot of retries, should you
|
||
increase or decrease MAXFRAME?
|
||
|
||
Well, how did you think you did? We'll take a close look at these
|
||
questions and more in part 14 of this series.
|
||
|
||
|
||
INTRODUCTION TO PACKET RADIO - PART 14
|
||
by Larry Kenney, WB9LOZ
|
||
|
||
How did you do on the review quiz in the previous part of this series?
|
||
If you haven't taken it, you might want to read part 13 and take the quiz
|
||
before reading any further.
|
||
|
||
Here are the correct answers and the series part number where you can read
|
||
more about the subject:
|
||
|
||
1 - Answer C is correct. The three TNC modes of communication are Command,
|
||
Converse and Transparent. Command mode is for communicating with the TNC.
|
||
The Converse mode is for normal QSOs, connects to a BBS or mailbox, etc.
|
||
and Transparent mode is used for binary file transfer. (Part 2)
|
||
|
||
2 - The UNPROTO command is used for setting the transmit path for both
|
||
beacons and CQs. (Parts 3 and 11)
|
||
|
||
3 - The CHECK command is used for setting a timeout value in your TNC.
|
||
If set to a value other than zero, the TNC will attempt to recover a
|
||
connection after a certain specified time if nothing is received from the
|
||
other station. This command is used in combination with the AX25L2V2
|
||
command. (Part 11)
|
||
|
||
4 - The MCON command (Monitor while CONnected) is used to monitor other
|
||
traffic on the frequency while you're connected to another station.
|
||
(Part 4)
|
||
|
||
5 - When monitoring, the asterick indicates the station that you actually
|
||
hear the packet from. The MRPT command must be ON for the monitor display
|
||
to show digipeaters. (Part 4)
|
||
|
||
6 - NET/ROM and TheNet nodes improve communications because packets are
|
||
acknowledged from your station to the first node, and then node to node
|
||
to the destination. A packet doesn't have to reach the destination
|
||
before an ack is returned. (Parts 6 and 7)
|
||
|
||
7 - When using NET/ROM or TheNet (no matter who you're connected to) you
|
||
disconnect by going to command mode on your TNC and sending a D, just like
|
||
at other times. The fact that you're using several nodes or are connected
|
||
to a distant station makes no difference. The network will take care of
|
||
disconnecting all stations and links. (Parts 6 and 7)
|
||
|
||
8 - N6ZYX-2 would appear as N6ZYX-13 if he connects to you using a node.
|
||
The nodes change the SSID using the formula 15-N. (Part 6)
|
||
|
||
9 - The two most probable causes for a packet not to get through are
|
||
collisions with other packets on the frequency and noise due to weak
|
||
signals. (Part 10)
|
||
|
||
10 - BBS commands:
|
||
a. To receive a list of messages: L
|
||
b. To download a file in the General (G) directory called
|
||
FCCEXAMS.89, you'd enter DG FCCEXAMS.89
|
||
c. To enter a private message to Jim, WA6DDM: SP WA6DDM @ W6PW
|
||
(The "@ W6PW" is not needed if you're using the W6PW BBS.)
|
||
d. To read message 7134 with headers: RH 7134
|
||
e. To find out what stations were heard on port B of the BBS, you'd
|
||
enter JB
|
||
(Part 5)
|
||
|
||
11 - If you wanted to send a message to Tom Smith, 123 Main Street, in
|
||
Keene, NH 03431, you would enter the following at the BBS prompt >
|
||
ST 03431 @ NTSNH (Part 8)
|
||
|
||
12 - A message with a STATUS of BF means that the message is a bulletin
|
||
and that it has been forwarded to all stations that are supposed to
|
||
receive it from the BBS you're using. (Part 9)
|
||
|
||
13 - Answer D is correct. The date/time of a message is the time the
|
||
message was received at the BBS you're using. Please note that the
|
||
date/time of a message does not indicate local time, zulu time, UTC,
|
||
GMT, or whatever. It indicates the time that that BBS is set to. Most
|
||
BBSs are now set to zulu time (UTC, GMT), but many still use local time.
|
||
When you read a message, you should be able to get the date and time
|
||
the message was written from the message header. (Part 9)
|
||
|
||
14-To find the call of the HOME BBS of your friends, use the White
|
||
Pages Directory. If the BBS you're using has the WP feature enabled,
|
||
you will find the P command to be useful, otherwise send an inquiry
|
||
to WP. (Part 12)
|
||
|
||
15-BONUS: The maximum value for MAXFRAME is 7. MAXFRAME is the number
|
||
of packets transmitted by your TNC contiguously, and the number of unack-
|
||
nowledged packets the TNC can have outstanding. You decrease MAXFRAME
|
||
when conditions are poor. Your TNC will send fewer packets at one time,
|
||
so there will be less information to collide with other packets on the
|
||
frequency and less chance of information being wiped out by noise.
|
||
(Part 11)
|
||
|
||
There is no passing grade on the quiz. It was designed for you to check
|
||
your general packet knowledge, and you'll have to be your own judge of that.
|
||
|
||
|
||
INTRODUCTION TO PACKET - Part 15
|
||
by Larry Kenney, WB9LOZ
|
||
|
||
W0RLI, N6VV, and VE3GYQ have devised a scheme called HIERARCHICAL
|
||
ADDRESSING. With hierarchical routing designators we have an opportunity
|
||
to improve traffic routing. No longer will a missing call in a BBS for-
|
||
warding file cause a message to remain unforwarded, sysops will no longer
|
||
have to burn the midnight oil trying to keep their forward files up to
|
||
date, and messages will move much more directly toward their destination.
|
||
|
||
The format for hierarchical routing is:
|
||
addressee @ BBScall.#local area.state-province.country.continent.
|
||
|
||
It might look complicated, but it's not. First, note that each section of
|
||
the format is separated by a period. Codes used for the continents and
|
||
countries are standards, now accepted throughout the world. You should be
|
||
able to find a list of them in the file section of your BBS. State and
|
||
province codes are the recognized two-character codes established by the
|
||
American and Canadian Post Offices. These may be found in the Callbook,
|
||
your phone directory, or any zip code listing. The code for local area or
|
||
county is optional, since most of you have no idea what code is being used
|
||
back in upper New York state or in Iowa City, IA. If you know it, use it,
|
||
since it will help get the message closer to where it's going. The code
|
||
for Northern California is #NOCAL, and the code for Southern California is
|
||
#SOCAL. You should use the appropriate one in your signature line. For
|
||
messages going outside of the US or Canada, the local area is optional
|
||
and the state is eliminated.
|
||
|
||
Using the hierarchical format, here are some routing examples:
|
||
WB9LOZ @ W6PW.#NOCAL.CA.USA.NA
|
||
N6KZB @ KD6SQ.#SOCAL.CA.USA.NA
|
||
KC3XC @ N4QQ.MD.USA.NA
|
||
JA1ABC @ JA1KSO.#42.JPN.AS
|
||
VK4AHD @ AX4BBS.AUS.AU
|
||
|
||
You'll note that the local area code is preceded by the octothorpe #.
|
||
(Now, how's that for a $5 word?) The reason is that the Japanese
|
||
network, and possibly other areas, want to use routing numbers for the
|
||
local area/county code, which could get confused with zip and postal
|
||
codes. Using the # on all local area codes will eliminate forwarding
|
||
problems.
|
||
|
||
We need to emphasize two very important points: hierarchical addressing
|
||
DOES NOT indicate a forwarding PATH, and ONLY ONE BBS call should be
|
||
included in the address. A list of BBS calls separated by dots will
|
||
not get your message to its destination. The addressing scheme is said
|
||
to be one area inside another area. Using my hierarchical address as
|
||
an example, WB9LOZ @ W6PW.#NOCAL.CA.USA.NA, here's how you would describe
|
||
the address: "WB9LOZ at W6PW which is in Northern California which is in
|
||
California which is in the USA which is in North America".
|
||
|
||
There are several BBS programs that implement hierarchical addressing
|
||
now, including the W0RLI, AA4RE and WD6CMU software. Check the ID
|
||
block you receive when you log into your BBS. If it has an H in it,
|
||
such as [RLI-9.07-CH$] or [4RE-02.4-HM$], your system supports it.
|
||
|
||
This next section explains how the BBS software uses the hierarchical
|
||
addressing scheme. We first have to understand how the software goes
|
||
about matching items in the "@ BBS" address with items in the forward
|
||
file. For an example, let's say that we send a message to Tom, W3IWI,
|
||
who operates his own BBS and is located near Baltimore, Maryland. We
|
||
would enter:
|
||
SP W3IWI @ W3IWI.MD.USA.NA
|
||
If the only entries in the forward file are California BBSs plus a list
|
||
of state abbreviations, let's see how the message would be forwarded. The
|
||
first thing the software does is attempt to find a match between the items
|
||
in the forward file and the left-most item in the address field. In our
|
||
case, it would not find W3IWI. If there isn't a match, it then moves to the
|
||
next section to the right. It would find MD and that match would allow the
|
||
message to be forwarded. If it had found the call W3IWI, that entry would
|
||
take precedence (because it is more left in the field than MD) and would of
|
||
course also ensure delivery.
|
||
|
||
Here are some comments from the ones who devised the hierarchical addressing:
|
||
|
||
"There is another added benefit to this scheme. It involves Gatewaying
|
||
between the BBS world and other networks, such as TCP/IP via SMTP. Much
|
||
of the pioneer work in setting up the gatewaying protocols has been done
|
||
by NN2Z, N3EUA, and PA0GRI, amongst others. The W0RLI BBS package
|
||
allows for the forwarding of mail between the BBS world and the SMTP
|
||
world. Of note is the fact that the WA7MBL package has allowed such
|
||
message exporting and importing for some time now. This means that we
|
||
can take advantage of the the TCP/IP host-names and their domain or
|
||
hierarchal format for forwarding. Thus it is possible to send mail from
|
||
the BBS to VE3BTZ as ve3btz@pc.ve3btz.ampr.org or from SMTP to
|
||
w0rli@w0rli.ca.usa.na and not have any ambiguity.
|
||
|
||
"We expect that WA7MBL will also be implementing hierarchal routing in
|
||
the near future. This system is still compatable with older style
|
||
systems, as a system that handles hierarchal forwarding identifies with
|
||
the H feature letter: [RLI-8.00-CH$]. If it does not get an appropriate
|
||
response, it uses the left-most item in the "@ BBS" string as the "@
|
||
BBS" for the message.
|
||
|
||
"The authors hope that this paper will serve as a starting place for
|
||
improved message routing by means of implicit routing. Low-level (VHF)
|
||
BBSs need only maintain state or province or country codes for distant
|
||
BBSs, and route such traffic to their nearest HF Gateway. In turn, the
|
||
HF station routes it to the desired state, where the receiving Gateway
|
||
station would have a detailed list of the BBSs it serves."
|
||
|
||
Comments from W0RLI, N6VV and VE3GYQ.
|
||
|
||
73, Larry, WB9LOZ @ W6PW.#NOCAL.CA.USA.NA
|
||
|
||
|
||
INTRODUCTION TO PACKET RADIO - PART 16
|
||
By Larry Kenney, WB9LOZ
|
||
|
||
In the previous 15 parts of this series, this column has covered all
|
||
of the basics of packet radio - from setting up your TNC and making
|
||
your first QSO, to using digipeaters and Net/Rom. Many of the TNC
|
||
commands have been explained, including the best settings for normal
|
||
packet use. I have discussed the procedures used for logging into a
|
||
packet Bulletin Board System or Mailbox, and have given you informa-
|
||
tion on how to list, read and send messages, download and upload
|
||
files, and use other features available. I've talked about the
|
||
general message format, the reasons for limiting the number of
|
||
digipeaters you use, calling CQ on Net/Rom and a variety of other
|
||
topics.
|
||
|
||
More articles will be written as new developments are made and old
|
||
features are updated. There are several programs available for
|
||
making special use of packet, such as TCP-IP, Tex-Net and Conference
|
||
Bridging, and high speed modems are just around the corner. Perhaps
|
||
we'll take a look at those topics in the months ahead. Right now
|
||
I'm not familiar enough with them to write about them. I'm interes-
|
||
ted in getting on the air with TCP-IP, so I might get into that next.
|
||
|
||
If you have any comments on this series, have any questions on the
|
||
topics discussed, or want to suggest new topics for discussion in
|
||
future articles, please leave a message for me. I hope that you've
|
||
found this series to be informative and helpful in making packet more
|
||
enjoyable.
|
||
|
||
73, Larry Kenney, WB9LOZ @ W6PW
|
||
|