World of Ham Radio 1994 January/AMSOFT_1994.iso/packet/docs/pd198808.doc

Text File | 1993-12-31 | 92.8 KB | 2,055 lines

2-Aug-88 16:53:14-EDT,1844;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Aug 88 16:53-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 2 Aug 88 15:35:39 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 2 Aug 88 15:35:08 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA10023; Tue, 2 Aug 88 12:34:52 PDT
Return-Path: <muscat!jfcl.dec.com![e-mail]>
Message-Id: <[e-mail]>
Date: 1 Aug 88 21:47:59 GMT
From: muscat!jfcl.dec.com![e-mail] (Fred R. Goldstein)
To: [e-mail]
Subject: Re: Source Availability for TNC Software?
Keywords: tcp/ip ax25 ax.25
References: <[e-mail]>

In article <[e-mail]> [e-mail] (Gareth Howell) writes:
>Does anybody know of any public domain AX.25 TNC software?  I want to
>modify the Level 2 code to introduce level 2 acknowledgements, to ease
>network congestion without introducing NET/ROM or something similar.
>
>The idea is to create a more reliable sub-network that I can use IP
>over.  I want to create stand-alone nodes in the subnet that will

I dunno... why don't you just set the maximum frames outstanding to 1,
so there'll be a mandatory ack for each frame?  According to Phil's
computations (take them as you may, they are probably right), if
you have a half-duplex CSMA-ish channel like most of us are on, then
the optimal windowsize is 1.  And run CONNECTED-MODE AX.25 under IP,
so you don't need transport recovery all the time.  (On a one-hop link,
transport is the way to go, but on a backbone, it had better be GOOD
before you run connectionless at L2; not a lot of our 1200 bps links
are anywhere near good enough.)

>Any Thoughts?
   Just a thought!
      fred k1io


 4-Aug-88 14:04:51-EDT,5596;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 Aug 88 14:04-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 4 Aug 88 12:31:24 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 4 Aug 88 12:31:01 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA12873; Thu, 4 Aug 88 09:30:51 PDT
Return-Path: <aero![e-mail]>
Message-Id: <[e-mail]>
Date: 4 Aug 88 02:12:44 GMT
From: aero![e-mail] (Robert McGwier)
To: [e-mail]
Subject: AMSAT-NA Six Shooter

I think I blew it on the last attempt, if not, forgive the repeat.

AMSAT-NA has begun an exciting new venture.  This past November, Jan King,
W3GEY, Chairman AMSAT-NA, and (more importantly) its VP for Engineering,
proposed to a small group of AMSAT-NA techies a small satellite concept.
We were very enthusiastic and frankly had the overall picture mapped out
before the meeting in Detroit was over.  This included Phil Karn KA9Q,
Jan, Tom Clark W3IWI, and myself working all night a couple of nights
;-).  When presented to the board of AMSAT-NA in closed door session,
it was overwhelmingly approved.  The PACSAT project was joined in earnest.
A lot can happen in 8-9 months.  This is a bit of what has happened.

AMSAT-NA has signed a launch services agreement with Arianespace for the
launch of FOUR of the new satellites, which we call internally: microsat.
These will ride on the Ariane 4 with the Spot-2 and will be deployed by
a technique we helped develop.  This is a 10:30 sun synchronous orbit of
850 km, circular.

Our close friends, the University of Surrey, UK, have decided this is too
good an opportunity and will have UOSAT D & E on board as well.  I will leave
it to them to describe their birds.  Suffice it to say that one is guaranteed
to be in the amateur radio service as of the last time I talked with Martin
Sweeting, G3YJO, leader of the UOSAT bunch (last week in the UK).
This guarantees that there will be FIVE amateur radio satellites on board
the Ariane 40 (no strap on's).

The microsat missions are, in order of funding:

PACSAT 1:  A dedicated store and forward packet radio satellite.  It will
run at 1200 BPS up to 4800 BPS, switchable from the command station.  The
signalling scheme to and from the satellite is identical to that used on
Fuji Oscar 12.  Manchestered FSK (hook the modem to an FM radio) in the
2 meter band, and PSK (linear receiver - SSB ) on the downlink.  At 1200 BPS
this is completely compatible with the JAS-1 modem available from TAPR or
G3RUH via AMSAT-UK.  This satellite was designed from DAY NUMBER 1 with
the thought of a positive power budget in mind and yet, we will still be
able to deliver at least 3 watts on the downlink (FO-12 is 1 watt).
There will be four uplink channels and one down as on FO-12.  The BBS will
be W0RLI style interface and forwarding will be done but only through the
`reverse forwarding' as it is called.  This bird is done in cooperation with
TAPR.

DOVE:  Digital Orbiting Voice Encoder.  This will be a digitalker and
will have playback of digitized audio as well.  This will be AMSAT-NA's
first participation in a satellite dedicated to educational purposes.
This is a joint project and is funded by Junior deCastro, PY3BJO.

PACSAT 2:  This is a CCD camera mission with a fully functional PACSAT
in order to best serve the users of this camera mission.  It is a color
CCD camera.  In case the camera fails (heaven forbid), the satellite can
continue its life as a PACSAT.  This will probably NOT have the W0RLI
style BBS at the beginning of life.  It will downlink pix in AX.25 UI
frames or HDLC frames, depending on how design work goes.  Display software
for several micro's is planned for the AMSAT-NA Software Exchange.

PACSAT 3: Is in every way identical to PACSAT 1.  It is funded by and will be
built in cooperation with AMSAT-LU.

Possibly you now understand what we did not feel could be told before now
and that is the REAL reason we have been too busy to finish the DSP project.

However, the CPU design team is about to hand off to the layout and software
team.  That means Lyle Johnson, TAPR's super tech, is done with the CPU design
and is handing off to WA4ONG for layout and construction and to Harold Price,
Skip Hansen, and yours truly for software work on the wirewrap.  Lyle had
invaluable aid from N0ADI Chuck Green.

Lyle and Chuck Green also are doing the DSP-1 layout for the DSP project.
Tom Clark, who has done all the receiver and module interface design work
for the microsat and myself have been too busy with this to do a lot on
the DSP software.  We will expect to use the DSP-1 as the primary ground
station for 4800 BPS.  It will be out soon after the launch if not before.

Four satellites, and the DSP project are what faces AMSAT-NA.  We have
received funding aid from TAPR but we need your support in the form of
membership , etc.  We are pitching as hard to advance amateur radio as
anyone and for no $$$ for the team members since this is a volunteer
organization.  Thanks for the support in advance.  It is just an incredible
year for amateur radio in general and amateur satellites in particular with
the recent success of our high elliptic bird, AO-13 and now will have
Oscar-14 through Oscar18 and maybe 19 on this mission.

Thanks fer listening!

Bob McGwier, N4HY
AVP AMSAT-NA

AMSAT, P.O. Box 27, Washington, D.C. 20044, (301)-589-6062


 5-Aug-88 18:41:05-EDT,1179;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 5 Aug 88 18:41-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 5 Aug 88 17:07:14 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 5 Aug 88 17:06:47 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA01168; Fri, 5 Aug 88 14:06:33 PDT
From: att!whuts!homxb!hotps![e-mail]
Return-Path: <att!whuts!homxb!hotps![e-mail]>
Message-Id: <[e-mail]>
Date: 4 Aug 88 19:57:13 GMT
To: [e-mail]
Subject: HAMS Lose 220-222 MHz

LATE NEWS !

Today, the FCC ruled against Radio Amateurs by re-allocating
the 220-222 MHz to Landmobile Services.
No other details are known at this time.

NOTE:  Don't go selling your 220 gear yet...

There is likely to be a fight with the FCC on this and lord
only knows how long that'll take!

Thanks,
        J. Gordon Beattie, Jr., n2dsy
        Chairman, The Radio Amateur Telecommunications Society

E-mail:    att!speedy!n2dsy-4!n2dsy (Unix)  [e-mail]
Telephone: [phone] (Home)


 5-Aug-88 20:52:16-EDT,16415;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 5 Aug 88 20:52-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 5 Aug 88 18:43:20 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 5 Aug 88 18:42:04 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA06333; Fri, 5 Aug 88 15:41:52 PDT
Return-Path: <osu-cis!n8emr![e-mail]>
Message-Id: <[e-mail]>
Date: 5 Aug 88 13:51:22 GMT
From: osu-cis!n8emr![e-mail] (Gary Sanders)
To: [e-mail]
Subject: gateway 7/22/88


Gateway: The ARRL Packet Radio Newsletter

Stan Horzepa, WA1LOU, Editor

Volume 4, Number 22                     July 22, 1988

W0RLI PBBS VERSION 6.12

Version 6.12 of the W0RLI PBBS software is now available from the usual
sources.  This version provides the ability to send parameter changes to
the TNC at forwarding time and also includes some enhanced commands.

SEVENTH COMPUTER NETWORKING CONFERENCE

The ARRL Seventh Annual ARRL Amateur Radio Computer Networking Conference
is scheduled for Saturday, October 1 at the Johns Hopkins Applied Physics
Laboratory (APL) in APL's Kossiakoff Center.  It will be hosted by the
packeteers of the Washington- Baltimore area.  The facility has an
auditorium that will seat approximately 500.  In addition, two classrooms
have been reserved for a large open area for show 'n' tell exhibits.

Those intending to attend the conference will have to register in advance.
Registration includes admittance into the conference, lunch and a copy of
the Conference Proceedings (advanced registration is required so that a
contract with the caterer can be completed).  If you register late, a
sizeable penalty will be charged.  Registration will be handled by Don
Bennett, K4NGC.

A list of recommended hotels and motels in the Columbia-Laurel (Maryland)
area will be published soon.  Attendees will have to make their own
reservations.  The locals will do what they can to help with special
problems.

As usual, the ARRL will publish the Conference Proceedings. The deadline
for camera-ready manuscripts is August 25. Contact ARRL headquarters for an
author's kit.

Sponsoring organizations of the conference include the ARRL, APL ARC, TAPR,
AMSAT, AMRAD and VPRA.

>from Tom Clark W3IWI via CompuServe's HamNet

FIRST ASIANET SYSOP CONFERENCE

Plans for the inaugural AsiaNet PBBS SYSOP Conference are underway. The
conference will be held September 3-4, 1988, in Brisbane, Australia at the
Gazebo Hotel.  The venue is located on Wickham Terrace, approximately 20
minutes from Brisbane International Airport, a five minute walk from
downtown Brisbane and a 15 to 20 minute walk from the Expo complex.

The conference is being hosted by the Queensland Amateur Radio Data and
Teletype Association (QARDATA), the Queensland Digital Group (QDG) and the
Wireless Institute of Australia (VK4 Division).  An informal social
get-together is tentatively scheduled for Friday, September 2 at the home
of Brian Beamish, AX4AHD, at 35 Chester Road, Eight Mile Plains,
Queensland.

It is anticipated that many local and international delegates from various
digital and packet radio groups and Amateur Radio societies will attend the
conference.  SYSOPs from Australia, Japan, Indonesia, New Zealand,
Philippines and West Malaysia have indicated that they will attend the
conference.

The program for the conference has yet to be announced, however, major
topics for consideration include the following:

o  PBBS forwarding plans for AsiaNet

o  Satellite and HF packet radio links

o  TCP/IP networking and development

o  Band planning for packet-radio development
   on HF

o  Developments in HF packet-radio forwarding
   technology

o  Frequency coordination of closed and
   opened HF PBBSs

o  Super-narrow FM 1200-baud forwarding

o  AsiaNet International Association

o  Emergency and NTS-type traffic handling

o  Third party traffic restrictions

o  Forthcoming IARU Region 3 Conference

o  Standard format for bulletin groups

o  AMSAT-DL Phase 3-D 56-kbit/s experiment to
   link AsiaNet using transponder or
   digipeater

o  AsiaNet Software Exchange Library

If you would like to present a paper or talk at the conference or have some
ideas on what should be discussed at the conference, please let the
conference coordinator (AX4AHD) know soon so that the paper or discussion
may be scheduled.

For further information, contact Brian Beamish, AX4AHD SYSOP @ AX4BBS,
telephone [phone] (home) or 07-394-2555 (business), FAX [phone]
or mail to PO Box 254, Stones Corner, QLD 4123, Australia.

>from Gil Mays, VK6AGC @ VK6AGC

WESTERN U.S. NETWORK MAP

N7EOJ is now the keeper of the N7HPR packet-radio network map of the
Western United States (N7PHR has moved to Florida).  This regularly updated
map indicates the location of digipeaters, nodes, PBBSs, HF gateways and
the interconnecting network in California, Colorado, New Mexico and the W7
call district.  It is available by sending an SASE to Budd Turner, N7EOJ,
412 N.  Belvedere Av, Tucson, AZ 85711.

>from Budd Turner, N7EOJ @ W1FJI

AMSAT OSCAR 13 UPDATE

In the third and final segment of a flawless trek from a jungle launch pad
to its orbital residence for the next millennium or so, AMSAT OSCAR 13
(AO-13) has fulfilled a decade-old plan that two prior efforts failed to
achieve.  It has become history's first OSCAR in a Molniya-type orbit.
This momentous event was culminated in a dramatic go-for-broke in-orbit
maneuver consisting of a 5.5 minute burn of AO-13's kick motor.  Early
indications are that the burn was perfect yielding close to the best
expectation for orbital plane change and apogee target.

The first step to orbit was a flawless launch to geosynchronous transfer
orbit by the new Ariane-4 launcher of the European Space Agency June 15.
All three satellites launched by Ariane mission V-22 have now successfully
attained their final orbits.

The second step for AO-13 took place a week after launch when, on June 22,
the kick motor was ignited for the first time.  The result was an
intermediate orbit with perigee at 1081 km and inclination raised to 14.3
degrees.

Beginning immediately after the first burn, re-orientation and spin-up
proceeded.  By July 2, AO-13 had attained the desired second burn attitude
(-59 degrees longitude, -70 degrees latitude in the Bahn coordinate
system).  By July 6, the spin rate reached the desired 60 rpm.

Thus, the stage was set for the third and climactic step.  It had been
decided to raise the target perigee to approximately 2200 km to add some
margin for error and to increase subsequent Southern Hemisphere coverage.
The increased margin for error was desired since even a relatively minor
propulsion system "hiccup" at the wrong moment could spell disaster.

The 5.5 minute rocket engine burn began at 21:05 UTC, July 6.  The burn
added about 1 mile per second to AO-13's orbital velocity. The plane of the
orbit was raised to about 58 degrees and the perigee was raised to about
2500 km.

AO-13 reached its near-Molniya orbit where two prior attempts have failed.
Phase 3A was lost in 1980 when Ariane mission L-02 failed and was
destroyed. In 1983, Phase 3B (which became AO-10) made it to geosynchronous
transfer orbit aboard Ariane L-06 and achieved an initial motor burn but
was unable to re-ignite the motor later because of a suspected propulsion
system leak.  The Phase 3 Program began with early planning in 1976 as a
follow-up to AMSAT OSCAR 7, the first OSCAR to use Mode B.  AMSAT OSCAR 8
was built as a gap-filler when it appeared the first Phase 3 satellite
would not be available until after AO-7 died. Thus, with AO-13 finally
reaching the Phase 3 objective orbit first outlined in 1976, it caps a 12
year-plus program costing well over $1 million.

Phil Karn, KA9Q, provided his best estimate of the orbit, as follows:

   Satellite:     OSCAR 13
   Catalog number:  19216
   Epoch time:       88190.00000000
       Fri Jul  8 00:00:00.0   1988 UTC
   Element set:     KA9Q-5
   Inclination:         58.9522 deg
   RA of node:         247.7443 deg
   Eccentricity:         0.6545803
   Arg of perigee:     187.1127 deg
   Mean anomaly:       293.2909 deg
   Mean motion:          2.09619370 rev/day
   Decay rate:           0 rev/day^2
   Epoch rev:           49
   Semi major axis:  25789.393 km
   Anom period:        686.959416 min
   Apogee:           36292.717 km
   Perigee:           2530.260 km
   Ref perigee:       3841.08839978

All that remains to be done before turning on AO-13's transponders is to
reorient the satellite to a suitable operational attitude and spin it down
to about 30 r/min.  With work on bringing AO-13 to full operational
readiness going so well, initial plans for opening the satellite to
operation have been announced.  If all continues to go well, AO-13 could be
on the air by July 20.

Here is the preliminary AO-13 operating schedule.

   Mode     From      Thru       Duration
                MA    Minutes

   Off      MA 225    MA  29    61    163.7
   B        MA  30    MA  97    68    182.5
   L (1)    MA  98    MA 157    60    161.0
   JL (2)   MA  98    MA 157    60    161.0
   B        MA 158    MA 224    67    179.8
   S (3)
   RUDAK    Concurrent with Mode L

   (1) daily
   (2) weekends only
   (3) Mode-S operations will commence when
       sun angles permit, likely in September

Each MA (Mean Anomaly) unit equals 2.6834 minutes.  This is calculated by
taking the period of the orbit (686.96 minutes) and dividing it into 256
equal parts.  The MA clock resets to zero at perigee.  Half way through the
orbit, the MA clock equals 128 at apogee.

>from AMSAT NA News Service

A LOOK AT LANS AND WANS

What follows is simply an appeal that we apply some degree of frequency
coordination within the digital allocations on 2-meter FM.  We have noted
rapid growth in the Washington, DC area with over 38 PBBSs, 35 digipeaters
and a number of NET/ROMs and TCP/IP nodes spread over the 100-kHz segments
starting at 145.0, 145.5 and 145.6 plus 221 MHz.  The nature of packet
radio is quite forgiving in accommodating multiple users and a mix of
services on any one frequency, but, condoning a total free-for-all mixture
cannot possibly result in an efficient network.  The opposite extreme of
total coordination and rule making is restrictive and abhorred by most
radio amateurs.

The following scenarios illustrate the two extremes of purely local-area
networks (LANs) and wide area LANs.

Scenario 1:  Nine LANs on the same frequency with nine users using nine
different local PBBSs with no contention.  There is no hidden-transmitter
problem, and each user gets 100 percent of the channel during his session.

Scenario 2: One wide area network (WAN) with eight users using eight
different PBBSs through a wide-area digipeater or node.  A full-duplex
repeater is required to solve the hidden-transmitter problem.

What I hope to show is that LANs should be kept relatively limited in range
and that WANs may cover as much area as they need, but that the two
functions should be on separate frequencies to optimize the efficiency of
both.

Scenarios 1 and 2 have the same users and the same services, but, in order
to have the same performance, the full-duplex repeater and all of the users
and services in Scenario 2 will have to operate at eight times the data
rate as those same users in Scenario 1.  Since the full-duplex repeater
occupies two frequencies, the overall efficiency in this worst case example
is 16-to-1 in favor of the Scenario 1 approach.  Ma bell was no dummy when
she invented cellular!

However, to make cellular work, there has to be cell-to-cell or LAN-to-LAN
connectivity.  This is where the WAN of Scenario 2 plays its best role.
The wide area full-duplex repeater is an optimum solution to moving
LAN-to-LAN traffic in this example.  The wide area repeater is also optimum
where a given community of users whose traffic statistics look like a LAN
are widely geographically distributed.  There is an equal need for this
capability in the area.

I want to argue that delivering mail via the present PBBSs is a purely
local function.  Our goal should be that every ham has access to at least
one mail drop system.  We have reached that condition here in the
Washington, DC area and we should optimize that function, but not at the
expense of others, through reasonable frequency management.  With most PBBS
software supporting multiple ports and frequencies, the separation of user
access from forwarding channels is going well and must continue to be
encouraged.  This establishes the basic cellular LAN structure.

The second part of the cellular equation is minimizing interference through
geographical distribution and power limitations.  Since most PBBS stations
are located at home stations with typical antenna heights, they serve as a
good cell center model.  They should be balanced with their users so there
is no need to have one kilowatt power levels if the user is typically only
running 25 watts.  The following recommended power levels for PBBSs,
digipeaters, NET/ROMs and other 24-hour services on the LAN frequencies
should not be too restrictive to the typical ham station which is being
used as a cell service provider, but it does discourage the installation of
alligators, which are disruptive over large areas on LAN frequencies.

   Antenna Height Above    Recommended Power
   Average Terrain (ft)       Level (W)

      1000                    0.1
       300                    1.0
       100*                  10
        75                   25
        50                   40
        25                  150

   * I would prefer to make 100 ft a top
     limit.

This proposal places no restrictions on who can operate on LAN frequencies,
only on the area of their influence.  In fact, all forms of digital
services are equally welcome including PBBSs, digipeaters, NET/ROMs,
repeaters and TCP/IP operations, although some of these would be less
useful than others under the LAN restrictions.  Home users would even be
encouraged to leave their stations in the unattended digipeater mode to
assist connectivity within the LAN.  Anyone may also operate his station at
any power level and at any height, but not as an unattended service
provider on the LAN frequency.  Direct PBBS forwarding would be permitted
where needed, but long-haul, digipeated and PBBS- forwarding should be
limited to non-prime hours.

This proposal has no intent to establish particular cells or to provide
exclusive protection for any particular cell.  Rather, it is intended to
simply provide a protective framework for the LAN concept.  A few
frequencies are required so that multiple services in a close geographical
area can choose separate frequencies.  It would seem that three or four
frequencies should fill this need.  Finally, this proposal cannot work
without wide area-systems.  Without WANs, packet radio would appear too
restrictive to the average ham who wants to exploit his full potential.  I
strongly support all WAN initiatives.  Separating the two will help the
hams have the best of both worlds.

>from Bob Bruninga, WB4APR @ WB4APR

GATEWAY CONTRIBUTIONS

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

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

or electronically, via CompuServe to user ID 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.

REPRODUCTION OF GATEWAY MATERIAL

Material may be excerpted from Gateway without prior permission,
provided that the original contributor is credited and Gateway is
identified as the source.

--
Gary W. Sanders                         HAM/SWL BBS 614-457-4227
(uucp) gws@n8emr                        (uucp) osu-cis!n8emr!gws
(packet) N8EMR @ W8CQK                  (cis) 72277,1325


 6-Aug-88 15:02:05-EDT,4216;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Aug 88 15:02-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 6 Aug 88 14:08:20 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 6 Aug 88 14:07:54 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA29112; Sat, 6 Aug 88 09:27:43 PDT
Return-Path: <osu-cis!n8emr![e-mail]>
Message-Id: <[e-mail]>
Date: 5 Aug 88 13:48:36 GMT
From: osu-cis!n8emr![e-mail] (Gary Sanders)
To: [e-mail]
Subject: arrl board on packet

Subject: ARRL BOARD & PACKET RADIO
Bulletin ID: KC8TW_13367
Path: AD8I!N8NN!WA8JXM!KC8TW

Excerpted Verbatim (with titles and call letters added for completeness)
>from the Minutes of the ARRL Board of Directors, 1988 Second Meeting

23) Mr. Comstock, as liaison {N5TC, Vice Director, West Gulf  Division}
presented the report of the ARRL Committee on Amateur Digital
Communications.  On motion of Mr Haynie, {WB5JBP, Director, West Gulf
Division} seconded by Mr. Butler, the following resolution was adopted:

WHEREAS, packet-radio digipeaters, network switches, computer based message
systems and other network servers often share a limited set of designated
frequencies, and

WHEREAS, the efficient use of such shared resources requires cooperation
among servers and users within local areas and between adjacent areas, and

WHEREAS, each area of the United States has a local frequency coodinator
having experience with the coordination of voice repeaters and some other
VHF/UHF operations, and

WHEREAS, some frequency coordinators function not only as voice repeater
coordinators but also as spectrum managers representing the user community
in general, now therefore.

BE IT RESOLVED that the following guidelines are recommended:

1. It is the responsibility of the VHF/UHF spectrum management body to
designate specific VHF/UHF frequencies for packet use, in coordination with
other users and in consideration of the ARRL band-plans.

2. It is the responsibility of the packet-radio community in each frequency
coordination area to determine the need for, and extent of, coordination of
packet frequency use appropriate to the area, and to determine what body is
competent to represent the needs of the amateur packet community.   For
example, this  packet coordinating body may or may not be part of or
subsidiary to the spectrum management body.  Further, the packet
coordinating body may determine that it is necessary only to establish
guidelines for the general type of usage according to frequency or may find
it desirable to coordinate certain specific network servers.   Packet
coordinating bodies are encouraged to cooperate with neighboring
counterparts.

3. The spectrum management body and the packet coordinating body are
encouraged to establish a permanent relationship such that the needs of the
packet community and those of other communities continue to be fairly
addressed by the spectrum management body.

4. The packet coordiating body should serve as packet-radio advisors to the
spectrum management body, and serve as liaison between the frequency
coordinator and the packet-radio community.

5. The packet coordinating body is encouraged to work with area packet
groups in order to achieve an agreement on the orderly usage of the
designated frequencies within that area and with counterparts in adjacent
areas.

6. Packet radio groups within an area are urged to consult with one another
and with the packet coordinating body on guidelines for uses of each
frequency and the need, if any, to coordinate specific network servers.

=======================================================================

Comments and suggestions may be sent to:

Leonard M. Nathanson, W8RC @ 48075, Director, Great Lakes Division

or

Hank Greeb, N8XX @ 45252, Assistant Director, Great Lakes Division

or your local Assistant Director.

--
Gary W. Sanders                         HAM/SWL BBS 614-457-4227
(uucp) gws@n8emr                        (uucp) osu-cis!n8emr!gws
(packet) N8EMR @ W8CQK                  (cis) 72277,1325


 6-Aug-88 15:18:45-EDT,14678;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Aug 88 15:18-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 6 Aug 88 14:09:23 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 6 Aug 88 14:08:26 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA29100; Sat, 6 Aug 88 09:26:12 PDT
Return-Path: <osu-cis!n8emr![e-mail]>
Message-Id: <[e-mail]>
Date: 5 Aug 88 13:50:34 GMT
From: osu-cis!n8emr![e-mail] (Gary Sanders)
To: [e-mail]
Subject: gateway 7/8/88

Gateway: The ARRL Packet Radio Newsletter

Stan Horzepa, WA1LOU, Editor

Volume 4, Number 21                     July 8, 1988

VADCG TNC+ TERMINAL SOFTWARE RELEASED

Phil Sampson, VK8KJJ (PO Box 1442, Darwin NT 5794, Australia), has
announced the first public release of packet radio terminal software
(PAKIT, version 2.0) for the VADCG TNC+.  The software is comprised of
several ARC files with code for various systems and a common ARC file for
files that are common to all systems.

In the interests of getting PAKIT to the user as quickly as possible,
documentation has not been completed, however, users will find on-line
context-sensitive Help that is sufficient to permit users to use most, if
not all functions with a little experimentation.  A comprehensive user
document will be released in the future.

PAKIT is one of the few multifunctional terminal programs for the VADCG
TNC+ and X.3/X.28 providing a packet radio specific environment that can be
adapted to other uses through the PAKIT.INI configurations file.  It
eliminates the need to use compromised landline modem programs.  PAKIT
completely divorces the user from needing to know or understand the X.3
parameters and provides automatic control of all TNC parameters to suit the
selected function.

PAKIT provides the following main functions with many options within each
function.

Terminal emulation.

Private mailbox.

Propagation surveys.

Secure file transfer using the PAKIT1 binary or ASCII protocols.

PAKIT has evolved over the past three years with a spurt of activity during
the past three months occupying about six hours per day to produce the
latest rewrite and protocol debug.  It is now comprised of more than 6000
lines of source code and uses extensive overlays and, for this reason, all
PAKIT files should remain in a common directory and must be on line all of
the time (floppy diskette users should leave the PAKIT diskette in the
system).  Overlays are used so that PAKIT may be fitted into the limited
memory of the 64-kbyte, 8-bit systems as well as larger capacity 16-bit
systems.

The PAKIT1 protocol was designed to be as efficient and simple as possible
while allowing binary and ASCII file transfers with a method of ensuring
file integrity at the receiving end.  This has been achieved and the
protocol is capable of transferring data at optimum speed within computer
and program limitations.  PAKIT1 uses a series of tokens for end-to-end
synchronization and communications.  It is also designed to be simple to
implement and incorporate into PBBS and mailbox systems.

PAKIT1 does not use the TNC+ transparent mode.  It stuffs the DLE character
much like the HDLC flag.  This reduces overhead in setting parameters and
TNC modes.  Token lead-in characters are also stuffed, thereby making DLE
and tokens transparent in the data stream.

Before data transfer, the sender and receiver select the relevant menu
options from the Files menu and (provided they are linked) the PAKIT
programs will synchronize and exchange information about the highest level
of the protocol that can be supported (later versions will do wild cards,
etc.).  The file is then transferred filling all buffers until XOFF occurs.
XON/XOFF controls the data transfer on the reverse channel.  At any time, a
station may type <CTRL-E> and an abort token will be sent to the remote end
to kill the transfer.

Upon completion of the transfer, the sender transmits a done tokens and a
single byte checksum character, which is unique to the transferred data.
The receive end, having calculated the checksum of the incoming data, will
determine if the file integrity has been maintained (no characters lost)
and notify the sender of the result.  There are 16 error messages in
PAKIT1, which can describe any problems quite accurately.  If all went
well, the program returns to idle mode.

The philosophy behind PAKIT1 is to use the link protocol for character
integrity, the overall checksum for file integrity and have maximum data
flow in the forward direction.  This means no checking is done within the
transfer at the PAKIT1 level as is done with 128-byte blocks in XMODEM, for
example.  Lastly, PAKIT provides synchronization in order that no garbage
characters appear in files and the operators need not have knowledge of the
X.3 parameters required at either end.

>from Phil Sampson, VK8KJJ via The Australian Packeteer

PS-186 STATUS

The first evaluation lot of PS-186 packet switch "rev A" printed-circuit
boards arrived Tuesday, June 28.  We built up the first board, and tested
it June 30.  Lo and behold, it worked on the first try!  The diagnostic
passes and the debugger runs.  "Rev A" fixes six cuts-and-jumps that were
required on the original board design and adds a UART for a diagnostic/
control port so that none of the four high-speed ports need to be used for
such functions.  The new UART appears to work as anticipated.  We also
tested a new version of the debugger that operates through this UART port.

There are five boards in the evaluation lot.  The other four will be built
up within the next few days.

>from Franklin Antonio, N6NKF, via CompuServe's HamNet

G8BPQ AX.25 PACKET SWITCHING SYSTEM

Near the end of last year, I saw various bulletins on the MBX network
concerning plans to increase the speed of the existing packet radio
network, e.g., the High Speed Eastnet proposal.  These led me to think in
detail about how the existing system worked and I came to the conclusion
that the current NET/ROM-TNC 2 combination was not an ideal building block
for a fast, large network.  The problem areas I foresaw were as follows.

The bottleneck of the multidropped asynchronous link used to interconnect
the TNCs of a multichannel node would become the limiting factor and makes
the use of high-speed external links rather pointless.

The maximum link speed was 9600 bauds, which may be adequate in the short
term, but I have heard of plans for much higher speed microwave links.

The NET/ROM requirement for a separate call sign and alias (and hence NODES
list entry) for each channel of a multichannel node means that the number
of nodes in the system rapidly gets out of hand.

At about the same time, multiuser mailbox software was arriving and it
seemed there must be a better way of using it rather than having an array
of rigs, TNCs and multiport asynchronous cards.  I, therefore, decided to
develop a packet switching system which would be compatible with the
existing network, but would overcome its problems.

System Overview

The system, which currently runs on an IBM PC or clone, provides the
following features:

Multiple AX.25 links using a variety of Comms hardware (see below).

Link to NET/ROM asynchronous port.

Multistream WA7MBL DesqView-compatible COMBIOS interface applications
within the PC allowing multiuser PBBSs direct access to the network.

Single call signs/aliases.

The Comms hardware is currently a Persyst DCP88 board, which provides four
HDLC channels at, at least 64,000 bit/s.  I hope to use the Pac-Comm PC-120
card to support low spe links (up to 9600 baud), but, as yet, I have been
unable to get hold of one.  The system will also allow the use of a
standard TNC in KISS mode, which may provide an economical upgrade path for
existing systems.  The software is designed to allow easy implementation of
drivers to support other hardware as it becomes available.  It would be
relatively easy to run it on a four-port 80186-based board.

Current Progress

I have been working on the system for about two months and it is currently
just about usable, but still needs a few details sorted out and, no doubt,
still contains a lot of bugs.  I have not yet decided to what extent it
should support Level 2 digipeating.  Currently, it allows one digipeater on
user links, but not on node-to-node links and does not function as a
cross-band digipeater.  The command handler needs a fair bit of tidying up
(it currently only allows single letter abbreviations for the commands) and
the internal TNC support is the bare minimum needed to support the WA7MBL
PBBS.  The system should allow a high-speed network to be developed,
however, I have not addressed the problems of radios and modems for such a
network and would be interested to hear from anyone who is working in that
area.

>from John Wiseman, G8BPQ, via Connect International


TRAFFIC FLOWS FREELY THROUGH NEW JERSEY

The article titled "New Jersey Traffic: Not of the Garden Variety" that was
published in Gateway, Volume 4, Number 10, was incorrect.  The article
contained references to the effect that packet radio traffic addressed with
a TO field, but not containing an @PBBS entry could not be automatically
forwarded through the New York-Philadelphia, that is, through New Jersey.
This was only partially correct because there was only one network on one
frequency that actually had this problem.  The backbone networks, which
carry traffic throughout New Jersey had no problem whatsoever and the one
network that had the compatibility problem was corrected quickly.

>from Richard Bauer, WA2HEB, SM SNJ and Robert Anderson, K2BJG, SM NNJ

BLIND PACKETEER SEEKS ASSISTANCE

Paul Graziani, WD5BIV, is a blind ham trying to get on packet radio using a
Commodore 64 computer and he needs a terminal or communications program
that does not reside in memory locations 57000 to 57400 inclusively
(programs that reside or use those portions of RAM interfere with his
speech synthesizer, a Hear Say 1000 that plugs into the computer's game
port.) If you can assist Paul, you can write to him at 119 Pearl St, Little
Rock, AR 72205-5959 or telephone him at 501-372-7387.  Your assistance is
appreciated.

FIELD DAY PACKET RADIO QUERY

Al Kaiser, N1API, wonders how those who used packet radio on Field Day did.
Do you or your group feel that packet radio is a productive mode for Field
Day?

Al is interested in what were your most productive bands and frequencies.
His club, W1NRG, worked 2 meters only and made 38 contacts.  They were
going to work HF also, but the CW operation interfered with the HF packet
radio transceiver "real bad." Please drop a note to Al via N1API @ N1API

>from Al Kaiser, N1API


SOVIET UNION ON PACKET RADIO!?

On June 28 at 0324Z, Bill Slack, NX2P, worked UA3CR via packet radio on
14.105 MHz.  Bill saw UA3CR trying to connect to a VE2 station, which he
was unable to copy and, after the connect to the VE2 was unsuccessful, Bill
attempted to connect to the Russian station.  It took about 20 retries to
make the connection because UA3CR had his transmit and receive frequencies
offset.  (Bill guessed there was an offset when he did not make the
connection after the sixth retry.  UA3CR had a good signal, Bill was
running 1000 watts and the band was empty at his end, so he started moving
his frequency a little until he got a response to his connect request, then
he adjusted his RIT so he could decode the response and, sure enough, the
connection was made.)

Bill noted some oddities while connected.  Some of the packets being sent
to him were unnumbered information frames and he saw a packet sent with a
frame number of 1 get repeated with a frame number of 2.  All of Bill's
packets were ACKed (except the last packet when he retried out) and UA3CR
apparently received what Bill sent since he noted Bill's name and QTH.
UA3CR said his name was Leo, but Bill did not get his QTH.  The two were
connected for about 5 minutes (averaging 3 retries) until the band dropped
out and the connection was lost to retries.

Bill is interested in any comments others may have as, last he had heard,
Soviet stations were not on packet radio.

>from Bill Slack, NX2P


VK2 6-METER BAND PLAN

The New South Wales (Australia) state repeater committee discussed the use
of packet radio on 6 meters on May 13.  The discussion was relevant to FM
usage in the 53 to 54 MHz section of the band (packet radio using AFSK in
the SSB end of the band was not discussed).

With new repeater allocations and the standardization of 1-MHz repeater
offsets taken into consideration, it was decided to recommend the following
frequencies as a packet radio sub-band in the simplex area of the band.

   53.000 MHz   PBBS forwarding network
   53.025 MHz   General usage
   53.050 MHz   General usage
   53.075 MHz   General usage (note 1)
   53.100 MHz   General usage (note 2)

Note 1.  This frequency should not be used until the 6-meter repeater in
VK3 changes its input frequency to the new offset of 52.675 MHz.

Note 2.  This frequency is believed to have been used by others as a
simplex net frequency in the past and may still be in use.

It cannot be emphasized strongly enough that this is not a national band
plan, but will be submitted as a recommendation to the federal body for
acceptance as such.  In the meantime, it can be considered as a temporary
expedient as band plans can take many months to obtain acceptance.

>from Barry White, VK2AAB via The Australian Packeteer

GATEWAY CONTRIBUTIONS

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

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

or electronically, via CompuServe to user ID 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.


REPRODUCTION OF GATEWAY MATERIAL

Material may be excerpted from Gateway without prior permission, provided
that the original contributor is credited and Gateway is identified as the
source.
--
Gary W. Sanders                         HAM/SWL BBS 614-457-4227
(uucp) gws@n8emr                        (uucp) osu-cis!n8emr!gws
(packet) N8EMR @ W8CQK                  (cis) 72277,1325


 7-Aug-88 12:22:48-EDT,6858;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Aug 88 12:22-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 7 Aug 88 11:35:46 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 7 Aug 88 11:35:16 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA19913; Sun, 7 Aug 88 08:35:07 PDT
Return-Path: <[e-mail]>
Date: 7 Aug 88 01:29:10 GMT
From: ncar!oddjob!mimsy!aplcen!wb3ffv![e-mail] (Howard Leadmon)
To: [e-mail]
Subject: FCC Ruling on the 220-222 Mhz Band..
Keywords: 220 fcc ruling
Message-Id: <[e-mail]>
Organization: Fast Computer Service, Inc. - Middle River, MD



Report No. DC-1218          ACTION IN DOCKET CASE          August 4, 1988



   COMMISSION ALLOCATES SPECTRUM IN THE 216-225 MHZ BAND THREE WAYS

              (GEN. DOCKET 87-14)



     The Commission today divided allocation of the 216-225 MHz band three

ways.  By its action, the Commission: 1) maintained the maritime mobile

allocation in the 216-220 MHz band; 2) allocated the 220-222 MHz band to

the land mobile service; and 3) allocated the 222-225 MHz band to the

amateur service for exclusive use.



     A variety of factors were considered in making these allocations,

including the need to provide for narrowband land mobile operations, the

impact on the amateur use of the 220-225 MHz band, and the potential

interference to TV broadcasting, as well as the actions taken in the 1979

World Administrative Radio Conference (WARC).  As a result of the 1979

WARC, the amateurs have received several new frequency allocations.



     First, the Commission concluded that the public interest would be best

served by providing dedicated spectrum for the development of narrowband-

spectrum efficient land mobile technologies, if such technologies are to

have a reasonable opportunity for acceptance in the market place.  As

compared to conventional land mobile technology, narrowband technology may

provide a three to four-fold increase in the number of channels that can be

made available in a given amount of spectrum.  The Commission noted that

promoting narrowband technology for the land mobile service is consistent

with the directive of the Communications Act to encourage the provision of

new technologies and services to the public.  In considering an allocation

for narrowband land mobile service in the 220 MHz region, the Commission

noted two constraints that precluded operation in the 216-220 MHz band.



     The first constraint is that land mobile operation in the 216-220 MHz

band would be impractical due to the need to provide adequate protection to

TV channel 13 broadcast operation located in adjacent spectrum at 210-216

MHz.  The second is the Commission's decision not to restrain the

development of the maritime mobile service in the 216-220 MHz band.

Consequently, after careful consideration of a variety of alternatives, the

Commission found that allocation of 220-222 MHz band was best suited for

this purpose.  The Commission noted that reallocation of this band to the

land mobile service to be shared by government and non-government users is

supported by National Telecommunication and Information Administration.



     With respect to amateurs, the Commission believes that they will

benefit from an exclusive allocation of the 222-225 MHz band.  The

Commission noted that several other frequency bands are available for

amateur service.  In particular, amateur bands at 28-29.7 MHz, 50-54 MHz,

144-148 MHz, 222-225 MHz, 420-450 MHz, 902-928 MHz and 1240-1300 MHz

support amateur operations similar to the 220-222 MHz band.



     Several hundred channels will remain available for amateurs to use for

emergency communications, which should meet the local area communication

requirements of any emergency or natural disaster.  Taking these factors,

along with others into consideration, the Commission found the reallocation

of the 220-222 MHz band to be in the public interest.



     The Commission reiterated its continued support for the amateur

service.  It recognizes that amateurs have a long history of public service

and of providing assistance in emergencies, including national and

international disasters.  Further, amateurs are a vital resource of persons

knowledgeable in the radio art and have had a long history of contributions

to the advance of radio science.  The three megahertz allocated to amateurs

on an exclusive basis in this proceeding, together with the many other

amateur bands, should continue to provide adequately for this service.



     The Commission noted that the 220-225 MHz band is currently allocated

internationally on a co-primary basis to the fixed, mobile, radiolocation

and amateur services as resulting from actions of the WARC.  The

radiolocation service will start January 1, 1990, and no new

station may be authorized for this service.  In implementing these

allocations domestically in 1984, the Commission conformed the domestic

allocations to the international allocations.  However, the Commission

stated that the fixed and mobile services would not be implemented until a

proceeding was initiated to determine precisely how the band would be

shared among the various services and between Federal and public users.

The Commission stated that the basic principle that would apply is the

equality of right to operate.  In the meantime, amateur use of the 220-225

MHz band, which had formerly been secondary in this band, was permitted to

continue.  Today's action resolves the sharing issue.



      The Commission pointed out that this proceeding only addressed

frequency allocations and not service rules and that a new proceeding would

be initiated to develop procedural and technical rules for licensing

private land mobile operations in the 220-222 MHz band.



     However, since the 220-222 MHz band is to be shared between government

and non-government users, the development of coordination procedures is

needed.  Consequently, neither government nor non-government users will be

allowed access to the 220-225 MHz band until the Commission has adopted

final service rules.



     Amateurs are also advised to begin an orderly transition of on-going

operations in the 220-222 MHz band to other amateur service frequency bands

in order to avoid an abrupt termination of such activities.



     Action by the Commission August 4, 1988, by Report and Order (R&O

number to be specified).



                 -FCC-


 8-Aug-88 18:51:23-EDT,1434;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 8 Aug 88 18:51-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 8 Aug 88 17:33:01 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 8 Aug 88 17:32:45 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA04011; Mon, 8 Aug 88 14:32:34 PDT
Return-Path: <somewhere![e-mail]>
Message-Id: <[e-mail]>
Date: 8 Aug 88 20:17:04 GMT
From: [e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: gateway 7/22/88
Summary: Amateur misuse of the term "LAN"
References: <[e-mail]>

> A LOOK AT LANS AND WANS

Once again I would like to point out that using the term "LAN" (local
area network) when referring to an amateur packet radio channel in a
town or city area is incorrect. In the non-amateur networking world, the
term is universally understood to mean a network covering a building or,
at most, a collection of closely located buildings (e.g., a corporate
park or college campus).

The proper term for a network, radio or otherwise, that covers a town-
or city-sized area is "MAN" (metropolitan area network).

We really should use the correct terminology so we don't confuse the
non-amateur networking people when we (try to) impress them with the
work we're doing.

Phil


 9-Aug-88 17:00:08-EDT,902;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 9 Aug 88 17:00-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 9 Aug 88 15:02:19 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 9 Aug 88 15:02:03 EDT
Message-Id: <[e-mail]>
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 2489; Tue, 09 Aug 88 15:00:22 EDT
Received: from AUDUCVAX.BITNET (RLSNSDL) by MITVMA.MIT.EDU (Mailer X1.25) with
 BSMTP id 2485; Tue, 09 Aug 88 15:00:12 EDT
Date:     Tue, 9 Aug 88 13:45 CST
From: <[e-mail]>
Subject:  change of address
To: [e-mail]
X-Original-To:  [e-mail], RLSNSDL

PLease change my address to RLSNSDL@AUDUCVAX
My old address was AGEN@AUDUCVAX
thank you -- Bob Schafer (KA4PKB)
11-Aug-88 19:07:26-EDT,6869;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Aug 88 19:07-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 11 Aug 88 17:22:06 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 11 Aug 88 17:21:32 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA04878; Thu, 11 Aug 88 14:21:19 PDT
Return-Path: <mimsy!aplcen!wb3ffv![e-mail]>
Message-Id: <[e-mail]>
Date: 9 Aug 88 20:32:07 GMT
From: mimsy!aplcen!wb3ffv![e-mail] (Howard Leadmon)
To: [e-mail]
Subject: A consultants view of TheNet -vs- NET/ROM
Keywords: packet NET/ROM TheNet


   Hello All,

 The foloowing information was pulled from one of the local Packet BBS's,
and since I haven't seen it appear on USENET I figured I would post a copy
for those of you that are interested...

---------------------  Begin  ---  Text  ---------------------------------------


16 June 1988         Net/Rom  versus  The Net


An independent report from  Ronald R. McCallister, N7FYA

When THE NET first appeared, I was concerned that my investment in
Net/Rom from Software 2000 was in danger.  I also was curious about
The NET because research into new products is my livelyhood.  I read
all the comments from those at Software 2000 about piracy.  I do NOT
believe in stealing any program.  I think that software programmers
should be able to make a living because I am one.  I realize that
this report will make a lot of individuals mad at me but I am in the
consulting business and my opinions are as objective and accurate as
I am able to make them.  Please feel free to make comments back to me
at N7HFZ BBS here in Washington or mail to AI Research, Inc.
P.O.  Box 97044,  Tacoma, Wa  98497.

This report is broken into two major sections:

1. comparison of code and my opinion of the comparison.

2. personal observations concerning NET/ROM and THE NET.



Section 1.

I called Ron, WA8DED at Software 2000 to get permission to disassemble
NET/ROM (N7FYA-8) for the purpose of comparing the disassembled code
to the disassembled code of THE NET.  I was given verbal permission
to do so provided I destroyed all papers upon completion.  I have done so.
I disassembled the NET/ROM and THE NET using SLR Z80DIS.  I found that
the two products are about 85% identical. Since both products were compiled
by two versions of one compiler and used the same libraries, I expected
60 to 65% of the code would be the same.  This is normal in programming.
When I talked to Ron @ Software 2000, he said that there were assembly
code sections that had been hand massaged to improve performance but he
failed to tell me which section.  In assembly code on the Z80 there are
only a few ways to do certain items efficently.  This means that any
two GOOD programmers working on different programs in Z80 code are likely
to code in a similiar if not exact fashion.  The names in the procedures
will be different in the source code but will look the same in the object
code.  In 'C' there are many ways to code anything BUT to be efficent in
the Z80 environment, you must optimize to the hilt.  That means if you
are trying to do a connect sequence in a TAPR type TNC2 and want to
stay compatible with the rest of the amateur community, You mus follow
a specific set of rules.  These rules will make 80% of connect sequence
code identical.  As Ron Raikes said,  the code in the two roms are
very much alike.  As to being identical...... NO WAY!  THE NET has some
distinct differences that make it the better of the two node controllers.
1.  It can operate in a full duplex mode whereas NET/ROM cannot.
2.  THE NET is considerably faster in its reponse to changing network
conditions.  This alone tells me that the code is better optimized.
3.  There are numerous features in THE NET that the NET/ROM is incapable
of doing because of the Call Encrytion code.
4.  It also will not crash.  I have tried to crash it and NET/ROM for
15 days.  THE NET has better error handlers than the NET/ROM.

I cannot give any more specifics than this because I would be giving
away the code from NET/ROM.


Section 2.     Personal Observations.

As a software programmer,  I can see the need to make money and to
provide a good income for my family.

As a end user however,  I cannot but wonder why I need to pay a
company $100.00 for a pair of eproms with a program.  The eproms cost
in single quantity cost $7.00 each (150ns).   Then you add programming
time.  And finally you add the cost of the software and manual.  Now it
sounds fair.  Let's go buy the orginal NET/ROMs for a hilltop.
The two nodes just cost us $100.00 with only ONE manual.  Version 1.0.
Ahhhhh.  Version 1.2 just became available and it fixes a few of the
bugs in version 1.0.  What? You mean I have to send my two original
eproms back to be reprogrammed and it costs me $35.00 for each.  That's
$70.00  It is now 5 months later and a new version is out.  Version 1.3
Here we are again sending $35.00 per eprom to have the bugs removed.
Now we have decided to change the SSID on the node for compatability.
That is another $35.00 per eprom.  I have now spent $310.00 for just
the eproms and STILL there are bugs in the programming.  I also only
have one manual.  I charge $35.00 an hour in my job.  How much is
Software 2000 paying their people to reprogram one eprom?  If you
look at the big companies like Microsoft, Micropro, and Borland you
find that they send you updates of their software with brand new
rewritten LARGE and multiple manuals for $25.00 to $35.00 .  What
does Software 2000 offer that makes that big a difference?  Also, these
other big companies offer a FREE upgrade if they fix bugs within
a short period of time, usually 3 months.  Does Software 2000?

This NOT the end of my opinions but I will stop.  My personal opinions
are separate from my findings of the investigation into the code
of NET/ROM and THE NET.  I would like to see the original code of NET/ROM
and compare it to THE NET source code I recently received.  Without
the NET/ROM orginial code to compare,  I must say that I prefer THE
NET in performance.  Last but most important!  I say thanks to
Software 2000 for their contributions to Amateur Radio packet but I
would to caution them from alienating those that give them their
sales.

Sincerely,

Ronald R. McCallister,   N7FYA

[End of text]

-------------------------------------------------------------------------------
UUCP/SMTP : howardl@wb3ffv              |       Howard D. Leadmon
PACKET    : WB3FFV @ W3ITM              |       Fast Computer Service, Inc.
IP Address: 44.60.0.1                   |       P.O. Box  171
Telephone : [phone]              |       Chase, MD  21027-0171


11-Aug-88 19:08:17-EDT,2632;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Aug 88 19:08-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 11 Aug 88 17:13:27 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 11 Aug 88 17:13:12 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA04248; Thu, 11 Aug 88 14:12:56 PDT
Return-Path: <trwrb!aero![e-mail]>
Message-Id: <[e-mail]>
Date: 11 Aug 88 01:51:06 GMT
From: trwrb!aero![e-mail] (Robert McGwier)
To: [e-mail]
Subject: AMSAT announcement

In my last announcement in which I described the 4 satellites AMSAT will
have launched this coming January (barring launch slips by Ariane), I
forgot two very important members of our team.  Weber State of Ogden
Ut., builders and designers of NUSAT and NUSAT II have become close
allies and team members with AMSAT-NA in a number of joint projects. The
group at Weber State operate out of the Center for Applied Science and
Technology (CAST) are our partners in this whole venture and partners
on our PHASE IV project as well.  They are flying the CCD camera mission
and are funding that satellite and its launch.  We thank them for the terrific
people they have working with us.

The ARRL is giving us support in the form of League personnel and laboratory
time and space (as part of their job at the League).  They are designing
/building the Battery Charge Regulator and the antennas for all four space
craft.

I apologize if anyone was offended by these omissions (no one has complained
but I wanted the whole story out), they were unintentional.

I wish to report the complete success the computer team of WA7GXD, NK6K,
WB6YMH who I had the honor of working with this past weekend.  The wire
wrap works and is running software as I type in the offices of Quadron
Services, Inc. who are responsible for the multitasking kernal and the
AX.25 modules.  They have donated a license for their kernal for these
amateur radio missions and (more importantly) the time of NK6K and WB6YMH.
Harold reported complete success in building the smart loader for loading
programs to the satellite CPU and now the long and grinding job of handling
multiple connects, spacecraft housing, etc. begins.

This and other AMSAT and TAPR projects will be described in great detail at
the 7-th Annual Networking conference in Laurel, Md. (ARRL Computer Networking
Conference) on October 1 and at the AMSAT-NA annual meeting which will be
in Atlanta this year.

Bob
N4HY


11-Aug-88 23:25:15-EDT,17125;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Aug 88 23:25-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 11 Aug 88 21:09:17 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 11 Aug 88 21:08:10 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA14228; Thu, 11 Aug 88 18:07:59 PDT
Return-Path: <osu-cis!n8emr![e-mail]>
Message-Id: <[e-mail]>
Date: 10 Aug 88 17:31:42 GMT
From: osu-cis!n8emr![e-mail] (Gary Sanders)
To: [e-mail]
Subject: gateway 8/5/88


Gateway: The ARRL Packet Radio Newsletter

Stan Horzepa, WA1LOU, Editor

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.
Contact the above address for details.  Registration includes conference
proceedings, buffet luncheon and defray the costs of putting on the
meeting.  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.

--
Gary W. Sanders                         HAM/SWL BBS 614-457-4227
(uucp) gws@n8emr                        (uucp) osu-cis!n8emr!gws
(packet) N8EMR @ W8CQK                  (cis) 72277,1325


12-Aug-88 16:31:00-EDT,1072;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Aug 88 16:30-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 12 Aug 88 15:05:04 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 12 Aug 88 15:04:45 EDT
Message-Id: <[e-mail]>
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 7657; Fri, 12 Aug 88 15:04:29 EDT
Received: from UCCCVM1.BITNET (WMLBTAM) by MITVMA.MIT.EDU (Mailer X1.25) with
 BSMTP id 7654; Fri, 12 Aug 88 15:04:26 EDT
Date: 12 Aug 88   15:02 EST
From: [e-mail]
To: [e-mail]
Subject: BITNET mail follows

Date: 12 August 1988, 15:01:26 EST
From: Theodore A. Morris        513-558-6046         WMLBTAM at UCCCVM1
To:   PACKET-RADIO at EDDIE.MIT.EDU

Sorry if this is a duplicate.  Please add me to subscription list for Packet-
radio under this new userid, WMLBTAM@UCCCVM1.  Please unsubscribe me from my
old userid, IMSGTAM@UCCCVM1.  Thanks!
12-Aug-88 16:46:25-EDT,1055;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Aug 88 16:46-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 12 Aug 88 15:12:34 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 12 Aug 88 15:12:17 EDT
Message-Id: <[e-mail]>
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 7711; Fri, 12 Aug 88 15:12:07 EDT
Received: from UCCCVM1.BITNET (IMSGTAM) by MITVMA.MIT.EDU (Mailer X1.25) with
 BSMTP id 7710; Fri, 12 Aug 88 15:12:06 EDT
Date: 12 Aug 88   15:08 EST
From: [e-mail]
To: [e-mail]
Subject: BITNET mail follows

Date: 12 August 1988, 15:07:29 EST
From: Theodore A. Morris        513-475-3907         IMSGTAM at UCCCVM1
To:   PACKET-RADIO at EDDIE.MIT.EDU

Please unsubscribe me from Packet-radio with this userid, IMSGTAM@UCCCVM1.
Another message asking to subscribe under my new id, WMLBTAM@UCCCVM1 should
be forthcoming.  Thanks!
14-Aug-88 12:19:07-EDT,1938;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 Aug 88 12:19-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 14 Aug 88 11:26:35 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 14 Aug 88 11:26:24 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA26537; Sun, 14 Aug 88 08:26:18 PDT
Return-Path: <uunet!mcvax!enea!kth!sics![e-mail]>
Message-Id: <[e-mail]>
Date: 11 Aug 88 12:19:32 GMT
From: uunet!mcvax!enea!kth!sics![e-mail] (Anders Klemets)
To: [e-mail]
Subject: Soviet Packet Radio Network

The following is a translation of a message I read in my BBS recently:

Msg # 9980  Type:B  Stat:$  To: ALL   @SCA     From: SK2GJ   Date: 08-Aug/2108
Subject: UA3CR QRV with TheNet in Moscow
Bulletin ID: 2702_SM5BKI
Path: SM5BKI!DK0MWX

The 5th of August the the network on 14.099 MHz got a new member, the
TheNet node UA3CR-2 (MSK2).
By connecting to UA3CR-1 (MSK1) from UA3CR-2 you will have access to the
VHF network in Moscow on 145.600 MHz.

According to SYSOP RA3APR, Evgeni (himself using a PK-232) does the node
consist of a MFJ-1274 TNC, an IC-751 and a 5 element yagi on 14.099 MHz and
on VHF a MFJ-1274, an IC-251 and a 9 element yagi.

Active on packet in Moscow are RA3APR, UA3CR, UA3HR, RW3DR and in the near
future also RA3AU and RS3A.

Evgeni who recently got his degree in engineering built a TNC with a
8080 CPU as his examination project. He hopes that it will be used by
many Soviet hams when his articles in the magazine 'RADIO' are published.

He also says that they are attempting to start a BBS in Moscow.

73' de SYSOP SK2GJ-5 (14.099 MHz)
Ulf/SM2EKQ

--
Anders Klemets                  Email:  [e-mail]
Sikvagen 51                             [e-mail]
S-135 41 Tyreso                 Packet: SM0RGV@SK0TM
SWEDEN


15-Aug-88 08:13:51-EDT,570;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Aug 88 08:13-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 15 Aug 88 07:21:34 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 15 Aug 88 07:21:09 EDT
Message-Id: <[e-mail]>
Date: 15 Aug 88 04:22:18 EDT
From: [e-mail]
Subject: BITNET mail
To: [e-mail]

Please schang my mail box from [e-mail] to
[e-mail]
THANKS
WA6LKS/TU

15-Aug-88 23:32:26-EDT,2077;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Aug 88 23:32-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 15 Aug 88 22:39:26 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 15 Aug 88 22:39:16 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA15628; Mon, 15 Aug 88 19:39:11 PDT
From: rochester!pt.cs.cmu.edu!cadre!pitt![e-mail]
Return-Path: <rochester!pt.cs.cmu.edu!cadre!pitt![e-mail]>
Message-Id: <[e-mail]>
Date: 12 Aug 88 15:41:28 GMT
To: [e-mail]
Subject: Re: Encoding binary data as text for xmit
References: <[e-mail]>

In article <[e-mail]> [e-mail] (Chris Elmquist) writes:
>...I'm wondering if there is a
>standard (read that: legal) way to encode binary files
>... Can someone recommend an algorithm for this that
>meets the FCC's special encoding rules.

There are no encoding rules for data anymore.  The rules say that you
must identify by one of the approved means (e.g. CW, voice, AX.25)
once every ten minutes.  What you send inbetween does not matter,
HOWEVER, you are not permitted to encode or encrypt anything with the
intent to hide the content.  Encoding for any other reason is OK.

I look at it this way:  If anyone should come to me with a complaint
about the encoded data I have been transmitting, I should be able
to decode it and show him the true contents of the message and
have him verify that it does not contravene Part 97.

Back to your original question:  what encoding to use?  There is
a program called BSQ that converts binary files to and from a
compressed-ascii format that can be sent over normal packet BBS
systems.  This program runs on IBM PCs and their kin and is available
>from Simtel20.ARPA in the file PD1:<MSDOS.PACKET>BSQ.ARC.1.

--
Bob Hoffman, N3CVL       {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman
Pitt Computer Science    [e-mail]


15-Aug-88 23:38:58-EDT,2050;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Aug 88 23:38-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 15 Aug 88 22:35:05 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 15 Aug 88 22:34:51 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA15597; Mon, 15 Aug 88 19:34:42 PDT
Return-Path: <rochester!kodak![e-mail]>
Message-Id: <[e-mail]>
Date: 15 Aug 88 01:26:46 GMT
From: rochester!kodak![e-mail] (barry ornitz)
To: [e-mail]
Subject: Anyone using a MFJ-1278 Multi-Mode Data Controller?
Keywords: packet, TAPR clone, TNC-2, MFJ, baudot, ascii, cw, fax, slow scan

Several weeks ago, someone asked for comments on the MFJ-1278 multi-mode data
controller on rec.ham-radio.packet.  I have yet to see any comments posted.

I am willing to take a gamble on all of the other modes except packet.  I would
like to use this controller to replace my 1270 "clone" and give me the other
features to use on HF, yet I want to be able to use KISS too.  They advertise
"genuine TAPR software/hardware" but with "hardware HDLC .. that makes possible
speeds in excess of 56Kbaud with a suitable modem."  I am likely mistaken but
I thought at Atlanta last year, they said that a TAPR TNC-2 could not dump data
into Dale's modem at that rate.

Does anyone in tcp-group have any more information on the MFJ-1278? Has anyone
run KISS and Phil's code on it?  Also, if you have used this controller, what
is your subjective opinion on the other operating modes besides packet?

If possible, I would like replies before the Shelby, NC hamfest (Labor Day
Weekend).  The cash is on hand!  Thanks.  BTW, I'll be glad to summarize any
responses.
                           73 de WA4VZQ  Barry

Barry L. Ornitz, Eastman Chemicals Division Research Laboratories, Kingsport,TN
PATH:         ....!rutgers!rochester!kodak!ornitz


16-Aug-88 21:34:48-EDT,795;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Aug 88 21:34-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 16 Aug 88 20:30:34 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 16 Aug 88 20:30:03 EDT
Received: by trwind.ind.TRW.COM (5.54/1.36)
    id AA00494; Tue, 16 Aug 88 17:27:56 PDT
Message-Id: <[e-mail]>
Received: by trwrc.RC.TRW.COM; Tue, 16 Aug 88 17:28:07 PDT
Date: Tue, 16 Aug 88 17:28:07 PDT
From: trwrc![e-mail] (Robert A. Agnew)
To: [e-mail]
Subject: Gateways to AX.25

Does anyone know of a list of gateways to/from arpanet and usenet
from AX.25? Has such a list ever been published to this mailing list?

23-Aug-88 18:42:16-EDT,1674;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Aug 88 18:42-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 23 Aug 88 17:08:13 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 23 Aug 88 16:56:59 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA28186; Tue, 23 Aug 88 13:53:04 PDT
Return-Path: <uunet!sco![e-mail]>
Message-Id: <[e-mail]>
Date: 22 Aug 88 18:46:44 GMT
From: uunet!sco![e-mail] (Dave Uebele)
To: [e-mail]
Subject: Another beginner looking for advice
Summary: public domain CPM software for packet?
Keywords: advice, software
References: <[e-mail]> <[e-mail]>

I am posting this for my dad (who does not have access to news).
He is trying to get his technician license now and once he does is
interested in using packet radio.

The question is what public domain software is available for packet radio
on CPM based machines.  My dad has a couple of North Star CPM machines.
Is it possible to find software for them, or is he better off buying a
cheap IBM clone.

He doesn't have call letters or equipment other than a scanner yet,
so send replies to me (uunet!sco!daveu).  He lives in the Gardnerville,
Nevada area.  I think he may be interested in contacting interested
parties directly, but I will leave that to him.

thanks,
Dave Uebele

--
Dave Uebele               {ucscc | uunet | decvax!microsoft}!sco!daveu
SCO Product Eng, Bugsco   decisions terminate panic
Santa Cruz, California    panic terminates decisions


23-Aug-88 18:46:04-EDT,2991;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Aug 88 18:46-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 23 Aug 88 17:19:30 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 23 Aug 88 16:56:57 EDT
Received: by june.cs.washington.edu (5.52.1/6.13)
    id AA28283; Tue, 23 Aug 88 13:54:15 PDT
Return-Path: <gatech!hubcap![e-mail]>
Message-Id: <[e-mail]>
Date: 23 Aug 88 16:44:13 GMT
From: gatech!hubcap![e-mail] (BJ Backitis)
To: [e-mail]
Subject: Re: beginner looking for advice
References: <[e-mail]>

>From article <[e-mail]>, by [e-mail] (Ted Medin):
>
>   I read an article about packet radio in a local computer magazine and
> became interested. At this point i have started learning the code and am
> looking for advice on these:
>
> Passing the fcc tests
> Equipment suggestions - i assume i wont go directly to packets??
>
> Being a beginner there are probably areas that i havent even thought of.
> So if you can spare a few minutes and a paragraph or two i would appreciate it
First of all, let me add my welcomes to the amateur radio world.  I have
only been a ham for about two years but I have been surprised by the
amount of fun and excitement it can bring.  Also, as a general rule, you
can't hope to meet a nicer bunch of folks.  And that is, IMHO, the
secret to getting into ham radio.

I was fortunate to be at a university with a radio club... although by
no means is that limited to schools.  Most areas have radio clubs, that
are ALWAYS looking for people interested in becoming amateurs.  Most
usually have classes in both code and theory, or you will find one or
two individuals willing to take you under their wing and help you along
the way.  Then they can give you the test (it takes two general class
hams to give the novice test), and help you in getting equipment and set
up.  I know that if it wasn't for the people I met in the club here I
would have never made it...

If you can find the zip code to Newington, Connecticut, I would write to
the American Radio Relay League and ask for information about becoming a
ham, including the names of clubs and ARRL officials near you.  They are
very willing to send information like that (I speak from experience). I
believe the address is 120 Main Street, Newington, Connecticut.  If you
can, go by a local library or bookstore and check out the current issue
of QST magazine... that will give you lots of addresses and useful
information.

I hope to work you on packet soon!!


--
Frank J. ("BJ") Backitis                       | Clemson University ARC
Information Systems Development                | WD4EOG
Division of Computing & Information Technology | P.O. Box 2277
Clemson University, Clemson, SC  29631         | Clemson, SC  29632