HAM Radio 1/HamRadio.cdr/news/info8688/gw0805.88

Text File | 1988-08-07 | 17KB | 381 lines

Gateway: The ARRL Packet Radio Newsletter is published by the

American Radio Relay League          Stan Horzepa, WA1LOU
      225 Main Street                       Editor
    Newington, CT 06111

Larry E. Price, W4RA                    David Sumner, K1ZZ
     President                       Executive Vice President

Vol. 4, No. 23                                    August 5, 1988

AMSAT ANNOUNCES 1989 LAUNCH OF PACSATS

On July 30, AMSAT-NA President Vern Riportella, WA2LQQ announced
plans to launch four "microsatellites" from a single European
Space Agency Ariane launch vehicle.  Of the four satellites, two
would be store-and-forward packet satellites (PACSATs).  One of
the PACSATs will be operated by AMSAT-NA, the other by AMSAT-LU
(Argentina).  The current Ariane launch schedule would result in
a June, 1989 launch of the AMSAT satellites.

The other two satellites will be special-purpose amateur
satellites.  One is being sponsored by Brazil AMSAT (BRAMSAT),
and will carry Project DOVE (Digital Orbiting Voice Encoder).
This satellite will carry a synthesized voice transmitter.  The
final satellite is sponsored by the Center for Aerospace
Technology (CAST) at Weber State College, of Ogden, Utah and will
carry a low-resolution camera.

The startling thing about these satellites is their truly tiny
size: a 23-cm (9-inch) cube of less than 10 kg (22 lb) mass.

Other organizations involved in the project are Tucson Amateur
Packet Radio (TAPR), which is providing some funding, and ARRL,
which is assisting with design and construction of the
satellites.

   from AMSAT-NA News Service

TEXNET SOFTWARE UPDATE

A number of new features have been incorporated into the new code
now being tested.  This code should be in full release to all
TexNet nodes in the next few months.  The following new features
are included.

o  Connect CQ @ NODE allows the user to transmit a CQ at the
requested node.  At the Cmd?> prompt, the user issues C CQ @ XYZ
and XYZ would then transmit a UI frame stating that the user is
calling CQ from whatever node.

o  Help contains more information on how to use commands.

o  When you issue BYE from a PMS or WMS, drops you to the network
prompt.  The last version of the software would drop the
connection and you would have to reconnect for another session.
To leave the network, issue BYE at the network prompt and the
network will disconnect.

o  The ***LINKED TO message has been changed so
that the node will wait until an acknowledgment has been received
from the station.  Then, the node will send the ***LINKED TO
message.  This was changed to increase connectivity to PBBSs that
were having problems seeing the ***LINKED TO message, primarily
from stations that are unable to buffer what they see being
received.

o  M @ NODE allows the network to support multiple PMS systems on
the network.

o  W @ NODE allows the network to support multiple WMS (Weather
Message System) systems on the network.

o  LS and LW within the PMS will now indicate, when used on a
non-WMS system, that they are not available as commands.  Issuing
LS on a PMS that does not have weather results in a message
indicating that you can not use that function.

   from The TPRS Quarterly Report

PS-186 PROGRESS CONTINUES

(This story provides additional information to the PS-186 status
report published in Gateway, Volume 4, Number 21.)

What is it?

The PS-186 is a high-speed, four-port packet  switch designed by
Mike Brock, WB6HHV, Tom Lafluer, KA6IQA, and Franklin Antonio,
N6NKF.  It is described in detail in the Sixth ARRL Computer
Networking Conference Proceedings.

Status?

In late May, we shipped one of the PS-186 prototypes to Gordon
Beattie, N2DSY, of the RATS ROSE project.  We applaud the
progress the ROSE software project has had in the last year and
look forward to a version of the ROSE software that will run on
the PS-186.

If you will recall, we originally built a run of eleven of the
prototype PC boards (Rev X).  These were assembled and
distributed to several software developers.  During the beta
test, several small design errors were discovered, resulting in
six cuts and jumps on the PC board.  These were incorporated into
the PC board design and a UART was added for a control port to
eliminate using one of the four high-speed ports for control.
This revised design is known as "Rev A"  (please ignore the past
erroneous references to "Rev B").

The first (evaluation) run of the new Rev A PC boards arrived
June 29.  We quickly assembled one and are happy to report that
the design changes appear to be completely successful.  The first
Rev A board passes all the diagnostic tests.  We had a total of
five boards built for this evaluation run and we now have #1
running, and #2, #3 and #4 almost completely assembled.

Now that the changes are checked out, the path is clear to
production of larger quantities of the Rev A boards.  These will
be built by AEA.  As described in Gateway, Volume 4, Number 17,
TAPR is organizing a group purchase of PS-186 boards, which they
intend to sell in the form of skeleton kits.  TAPR needs an
indication of interest from you if you would like to participate
in the group purchase.  Send TAPR a post card!

Finally, this last step has taken a little longer than expected
and I would  like to emphasize that we take responsibility for
these delays.  They are not due to any action (or inaction) by
either AEA or TAPR.

   from Franklin Antonio, N6NKF, for N6NKF,
   KA6IQA and WB6HHV via CompuServe's HamNet


DIGITAL COMMITTEE AX.25 WORKING GROUP MEETS

On July 16, Gordon Beattie, N2DSY; Terry Fox, WB4JFI; Phil Karn,
KA9Q; Tom Moulton, W2VY; Paul Rinaldo, W4RI; and Eric Scace, K3NA
met to review AX.25 level 2, version 2.0.  The homework prior to
the meeting was a digest of comments and suggestions from various
implementers by Terry Fox and SDL (state description language)
diagrams by Eric Scace.  Indeed, we found a few bugs in some of
the branches and twigs of the protocol, also some areas of
improvement.  After discussing these topics one by one, we came
up with a set of changes that could be applied to a version 2.1.
By definition, a version 2.N would be compatible with 2.0, so
versions 2.1 and 2.0 could be working together in the field.

In addition to the (many) minor fixes, we had to face a knotty
problem which was not adequately allowed for in AX.25, that of
reciprocal call signs.  That is, AX.25 permits call signs up to 6
characters in length, thus call-sign structures such as
VP2M/WB4JFI cannot be accommodated, giving us a problem in
certain countries.  In addition, AX.25 has become the lingua
franca of packet-radio link-layer protocols in the commercial and
governmental worlds, and other users use call signs as long as 11
characters.  After struggling with this problem for several
months, the working group came up with a virtually backwards-
compatible call-sign extension scheme--a bit quilty, perhaps, but
we think it will work.

These ideas relating to a possible version 2.1 will be detailled
in a paper by Terry Fox listing the reported problems and our
proposed fixes and in another paper giving SDL diagrams by Eric
Scace with these fixes in place.  These papers are to be
presented at the Seventh ARRL Amateur Radio Computer Networking
Conference on October 1.

The Digital Committee does not take protocol changes lightly, and
certainly we don't want packeteers to panic.  Don't pop your ROMs
out, point your .45 at them and say "BYE, old code."  It's not
that drastic a change.  Protocol stability has been one of the
reasons why amateur packet radio has grown and why others have
adopted it.  The plan is to make public disclosure of these ideas
and allow sufficient time for comment before recommending
implementation of version 2.1.

At the same meeting, we talked about a version 3.0.  If you think
we ought to be cautious about public comment and enough lead time
for implementation of a version 2.1, then a version 3.0 should be
approached even more gingerly.  By definition, a version 3.0 is
not interoperable with version 2.0.  But then again, link-level
protocols are strictly between consenting adults, meaning that
they can be used between two stations if the owners agree to do
so.  Theoretically, they shouldn't bother anyone with whom
they're not connected.  Unfortunately, this applies only to
point-to-point links with no intermediary stations, some of which
could be using an older protocol.  So, the easiest place to try
out a new version 3.0 would be on high-speed (56-kbit/s) point-
to-point links, and the worst on 2-meter or HF packet nets where
incompatibilities could cause a crash.

Nevertheless, packeteers rush in where fools and wise men won't.
After dealing with version 2.1, we went on to dreamineer a
version 3.0 that wouldn't have serpentine call-sign extensions
and would have some additional desirable features.  Phil Karn
kicked off that discussion, and his description follows this
article.  In addition, we talked about having not just one but a
suite of three link-layer protocols (eg, high-speed VHF/UHF,
robust HF, and meteor-scatter).  There will be at least one paper
on version 3.0 at the 7th Computer Networking Conference.  Co-
Jerseyites Gordon Beattie and Tom Moulton agreed to prepare a
paper.

   from Paul Rinaldo, W4RI


NEW LINK LEVEL PROTOCOL MUSINGS

In addition to upward-compatible changes to the existing
protocol, the ARRL Digital Committee has been talking about brand
new link protocols.  I've been working on the preliminary design
of one with the following properties:

1.  Be much simpler and easier than AX.25 to implement, mainly to
make high-speed DMA operation easier.  In particular, it will not
be necessary to scan every address field in a digipeater string
to see if you need to handle the packet or not.

2.  Handle completely arbitrary, variable length addresses,
including those longer than 6 characters, eg, G0/WA8DED.  The ISO
"address extension bit" convention would disappear.

3.  Take advantage of the address filtering feature in most HDLC
chips (this will be useful on busy high-speed channels).

4.  Make a clean separation between the datagram addressing layer
(the portion with call signs and digipeaters) and the logical
link control (LLC) layer.  There would be a "link level PID"
between the two layers to allow use of multiple LLCs.  LAPB could
still be used at the LLC layer, but it would have no special
status.  If it is used, though, it would begin with its own
"address" byte of 01 or 03 to signal "command" or "response";

that crude C-bit kludge of mine would go away.

5.  The addressing layer would have a header checksum and control
bits so a user could say that he's willing to tolerate errors in
the remainder of the packet.  This is useful for real-time error
tolerant applications like packet voice.

Frames would look something like this (I haven't decided on field
sizes yet):

   [FLAG] hash_id version flags lpid data_len addr_ptr hdr_cksum
   address#1address#n data [CRC] [FLAG]

The hash_id is a hash function of the address pointed to by
addr_ptr.  This allows stations to use the HDLC controller's
address filter function to screen out 255/256 of the traffic on
the channel addressed to others while still seeing all of their
own.  Broadcasts are handled by the special value 0xff, which the
chips can recognize in addition to their own code.

The flag bits include ALLOW_DAMAGE and IS_DAMAGED.  The checksum
is used only if ALLOW_DAMAGE is set, since frames received with a
CRC error and ALLOW_DAMAGE off are always ignored.  If a frame
with a CRC error has ALLOW_DAMAGE set, the header checksum is
verified.  If it is correct, the IS_DAMAGED bit is set and the
frame is processed; otherwise it is discarded.

Each address entry consists of a length field followed by the
specified number of bytes.  They are scanned from left to right;
the first entry is always the source and the last is the
destination.  The data_len field points to the beginning of the
data field and the addr_ptr field points to the next address in
the chain.  When you get a frame, you simply look at the field
pointed to by addr_ptr and see if it's you.  Move the pointer
past the field and see if it equals data_len; if so, you're the
final destination, so kick it upstairs to the LLC protocol
specified in lpid.  Otherwise, you're being asked to digipeat it,
so recompute the hash_id from the next address, recompute the
checksum if necessary, and retransmit the packet.

Comments are welcome.

   from Phil Karn, KA9Q,
   via CompuServe's HamNet


COMMODORE 64 LIBRARY ACCESS

There is an extensive library of files, currently numbering 68,
for the Commodore 64 computer and its users on the WB2MNF PBBS in
Southern New Jersey.  All are available for the asking by using
the following commands.

1.  To receive a complete listing and full explanation of all
files, send the following  message:

   S REQFIL @ WB2MNF
   Title: C64DIR.15A @ (your PBBS)
   (No message content)
   <CTRL-Z>

2.  To receive a listing of file names and their length, send the
following message:

   S REQDIR @ WB2MNF
   Title:  C64 @ (your PBBS)
   (No message content)
   <CTRL-Z>

3.  Once you have decided which files you want, you may request
an individual file by sending the following message:

   S REQFIL @ WB2MNF
   Title: C64/(file name) @ (your PBBS)
   (No message content)
   <CTRL-Z>

To recapitulate: do not send messages to SYSOP WB2MNF or me
(K2UK).  The addressee is REQFIL or REQDIR as specified above.
When your PBBS prompts you for a title, enter the name of the
file you want as specified above [C64DIR.15A, C64 or C64/(file
name)] followed by "@" and the call sign of your home PBBS.  When
your PBBS prompts you for the message contents, enter nothing
except a Control-Z <CTRL-Z> or /EX (whatever you normally use to
end a message).  Send the message exactly as outlined above
including spaces and the call sign of your home PBBS as
indicated.  If you follow these directions to the letter, the
WB2MNF PBBS will know what to do when it receives your message
and to whom and where to send the file automatically.

Note that the above instructions differ from those published
earlier (Gateway, Vol. 4, No. 18).  Several errors have been
noted in recent requests, notably the use of REQDIR instead of
REQFIL for the C64DIR.15A files and the apparent use of C64 as
the home PBBS.  The former will simply tell you that the
C64DIR.15A files exist and how long it is, while the latter will
result in a message addressed to @ C64 and not to your home PBBS
and is, thus, undeliverable.

Please request only one or two files per day so as not to
overload the system.  I strongly urge you to get the user files
first and print them for reference.

If you have never requested any files from WB2MNF, it is a good
idea to send a message to WB2MNF to let him know where your home
PBBS is located.  There are a lot of REQFILs and REQDIRs coming
in that are addressed to PBBSs that are unknown and Jon has no
option but to kill those messages because they are undeliverable.
Once you have received any message from the WB2MNF PBBS, you know
that the forwarding route is in place.

If you have any problems or questions, do not hesitate to ask me.

   from Ed Ludin, K2UK

NETWORKING CONFERENCE REGISTRATION ADDRESS

The address for registration for the Seventh ARRL Networking
Conference mentioned in the last issue of Gateway is as follows:

   Don Bennett, K4NGC
   PO Box 1944
   Woodbridge, VA 22193

If you plan to attend the conference, you are asked to register
early.  A registration fee of $20 will provide a copy of the
conference proceedings, buffet luncheon and defray the costs of
putting on the meeting. If your registration is received after
Sept. 25, the fee will be $30.  Make your checks payable to Don
Bennett.  Registrants will be sent a list of suggested
hotels/motels in the area, maps, etc.

GATEWAY CONTRIBUTIONS

Submissions for publication in Gateway are welcome.  You may
submit material via the U.S. mail to:

   Gateway
   Stan Horzepa, WA1LOU
   75 Kreger Drive
   Wolcott, CT 06716-2702

or electronically, via CompuServe to user i.d. 70645,247.  Via
telephone, your editor can be reached at 203-879-1348 on evenings
and weekends, and he can switch a modem on line to receive text
at 300, 1200, or 2400 bauds.