[net.ham-radio.packet] GATEWAY Vol 2, no. 7

wheatley@inuxi.UUCP (Steven Wheatley) (11/24/85)

Gateway: The ARRL Packet-Radio Newsletter
Volume 2, Issue 7
November 22, 1985

Published by:
ARRL
225 Main Street
Newington, CT 06111

Editor:
Ed Raso, WA2FTC


FROM THE EDITOR

As reported in the last issue, Jeff Ward, K8KA is no longer the editor of 
Gateway.  Instead, Jeff has decided to pursue a unique opportunity with the 
UoSat project in England.  I know all of you appreciate the superb job Jeff 
has done editing Gateway, and will join me in wishing Jeff success with his 
new endeavor -- good luck Jeff.

As the new editor of Gateway, I will continue to report the latest news and 
developments taking place in the packet-radio community.  Remember, much of 
the information contained in these pages comes from our readers.  If 
Gateway is to continue to report the latest news that shapes packet-radio, 
it needs your input and support.  If you have news that you would like to 
see included in Gateway, mail it to:

     ARRL
     Gateway Editor
     225 Main St.
     Newington, CT 06111

You may also send news electronically via CompuServe to ID: 72747,3207 or 
via American People Link (PLINK) to ID: ED*WA2FTC.  I hope you will 
continue to enjoy Gateway.

     Ed Raso, WA2FTC


KENTUCKY PACKET ASSOCIATION

Several local radio clubs in Kentucky have joined together to form a state-
wide packet organization.  The state will be divided into several regions, 
with each region represented by its own chapter.  The purpose of the 
organization is to coordinate packet activity and disseminate information 
throughout the state.  The organization plans to publish its first 
quarterly newsletter later this month.  For more information, contact:

     Dan Hund, KB4CF
     3444 Merrick Dr.
     Lexington, KY 40502

     From KE4NS


CALIFORNIA PACKET 

On November 3, 1985, the silence on 145.05 Mhz in the southern half of 
California was broken with the installation of KB6C-1 on Frasier Peak (8000 
ft).  The site covers the greater L.A. area, San Diego to the south and 
Visalia to the north.  KB6C-1, along with the existing site of WB6AIE-1 
high in the Sierra Mountains, provides coverage from San Diego in the south 
to Modesto in the North.  Plans are in the works to establish a site 
further north on 145.05 that will extend the coverage near the Oregon 
border.  This system should give users an alternate path while providing 
the state with a three-hop network for use during times of emergency. 

A mailbox is available in Fresno (middle of the network) operating under 
the call of WB6AIE.  It is hoped that the central location of the mailbox 
will provide two-hop access to most users.  This system is identical to the 
coastal 145.01 system operated by W6IXU.  The 145.05 system runs north and 
south in the middle of the state, while the 145.01 system runs along the 
cost.

Comments or suggestions should be forwarded to Dennis, KB6C or Jerry, 
WB6AIE via the WB6AIE mailbox.

     From WB6AIE


PACKET AND SET

On October 19, 1985, five north Texas stations participated in the 
Simulated Emergency Test (SET).  Two local digipeaters, KC5LW-1 and N5EG, 
proved essential for passing traffic.  The method of traffic handling was 
exclusively off-line message editing and preparation in accordance with 
ARRL radiogram format.  All messages were transmitted as files which 
reduced the transmit time per message to less then 15 seconds. 

A test of the prototype PACGRAM software (Packet Status Register, March 
1985) was conducted.  One PACGRAM was successfully received at the Regional 
DPS office.  This style of semi-automated message handling shows great 
promise for emergency service activities.  Overall, we passed as much, or 
more traffic than the voice operators, and from a much larger area.  
Participating stations were: W0DRO, KB5F, WB5IZL, WB5QLD and WA5MWD.

     From WA5MWD


KANTRONICS FIRMWARE UPDATE

Kantronics has released a new version of their TNC firmware.  The update 
costs $10.00 and may be ordered by phone.  New features include: 1) time 
and date stamping 2) calls heard list 3) trace command, and 4) path shown 
for repeaters.

     Via HamNet


PTT MOD FOR TNC2 CORRECTION

W3IWI reports that the TNC2 PTT modification published in the Packet Status 
Register and CTM has one error.  The last sentence of the last paragraph 
indicates that you can reverse the sense of the LED from bright=receive and 
dim=xmit by attaching the 1k resistor to pin-9 of U14 instead of pin-
8...this is wrong.

The problem stems from the fact that U14 is used as part of the BBRAM logic 
and is powered from the battery when the power is off.  If you reverse the 
sense, you will drive the battery current thru the LED and kill the 
battery.  The modification (dim on xmit) works fine and doesn't drain the 
battery. When the power is off, pin-9 of U14 is low and no current flows 
thru the LED.

     Via DRNET, W3IWI


SAREX II

The SAREX II packet-radio experiment to be carried aboard Shuttle flight 
STS-61E by Ron Parise, WA4SIR, has the potential for the greatest number of 
two-way contacts of any shuttle experiment to date.  Operating in robot or 
monitor mode, the TNC has the capability of logging as many as ten calls 
every ten seconds.  The sheer volume of packet-radio stations (10,000) by 
the March 1986 launch date precludes carrying any simple logging scheme on 
board.  Instead, log beacons will be transmitted from the TNC on the 
downlink frequency for all stations to copy in real-time.  Not only does 
this method give real-time feedback to public demonstration stations, but 
it also can be used to demonstrate the efficiency of the existing 
terrestrial packet-radio network during post-flight data collection.  By 
collecting all log packets received on the ground into a database, a 
complete log of all spacecraft packet activity can be constructed.

The purpose of this is to suggest an organized scheme and plan for the 
forwarding of all log data via Amateur packet-radio or other electronic 
mail into a central database.  Because of the tremendous volume of reports 
and the regional similarity of most received reports, data reduction should 
be accomplished by regions and forwarded to a central point in a standard 
format.

Since most local area networks (LAN) are served by at least one W0RLI BBS, 
a first cut is to suggest that one station per BBS be designated to collect 
log reports from his LAN in message format.  This station will accumulate 
individual messages into three Xerox 820 summary files:  1) a short file of 
all stations submitting a log report, 2) a file of all HEARD reports, and 
3) a file of all WORKED reports.  (One set of files per day of SAREX II 
packet operation).  Each of these BBS files will be forwarded to a regional 
SAREX II coordinator to eliminate all redundant data and prepare a regional 
log.  These logs will be submitted to Goddard ARC for final processing and 
assembly.  For ease of processing, all logs submitted should be word 
processed by the originator into a specific format.  An optimum solution 
would be to have the shuttle TNC time stamp each beacon.  Using this 
method, only the exact beacon text string need be included in the collected 
data from individual stations.  The standard format will simplify the data 
reduction algorithms significantly.  These logs will be reduced into 
regional databases showing a maximum of ten HEARD times and five QSO 
numbers.  Times will be in a six-digit serial UTC (HHMMSS) format.  The QSO 
log is a four-digit hex number allowing as many as 65,000 unique 
assignments.

It is requested that regions select a single data reduction facility that 
has the capability of reducing data from the Xerox 820 message file format 
into IBM PC format for reduction using dBASE II.  Regions can best be 
defined by arbitrary groupings of packet activity such as: SOUTHNET, 
EASTNET, GRAPES, MAPRC, NEPRA, CITS, etc.  For more information, contact:

 W3IWI
     59 Southgate Ave.
     Annapolis, MD 21401

     Via DRNET


TNC2 UPDATE

A problem has cropped up on a very small number of TNC2 boards.  The MF10 
switched capacitor filter will latch-up to the positive +5 supply causing 
the regulator to become very hot.  To cure the problem, change C10 on the -
5V supply from 10uf to 47uf.  If you experience any latch-up problems after 
changing C10, please notify TAPR immediately.  Given our results, I 
strongly recommend all TNC2 owners institute this change.

     From AD7I


NEW PACKET VENDOR

A new company, PacComm Packet Radio Systems, Inc., of Tampa, Florida has 
announced the availability of its TNC-200 Terminal Node Controllers for 
packet-radio applications.  PacComm has been licensed by Tucson Amateur 
Packet Radio (TAPR) to produce packet controllers based on the TNC2 design.

The hardware design is the latest TAPR Revision 2 printed circuit board.  
The standard TNC-200 features 16 kbytes of RAM, 32 kbytes of EPROM, a CMOS 
Z-80 processor and a long-life lithium battery.  The unit is packaged in 
the familiar extruded aluminum cabinet.  The TNC-200 is available in 
standard low-power CMOS or optional NMOS.

PacComm Packet Radio Systems is owned by Andy Demartini KC2FF and Gwyn 
Reedy W1BEL both of whom are actively involved in FADCA, the Florida 
Amateur Digital Communications Association.  Gwyn Reedy is currently editor 
of the FADCA>BEACON. For more information, contact: 

     PacComm Packet Radio Systems, Inc.
     4040 W. Kennedy Blvd., Suite 620
     Tampa, FL 33609

     Via KC2FF


Packet Radio on the Move -- The Club Connection

(Fourth in a series by Steve Place, WB1EYI, 
Manager, ARRL Volunteer Resources)

When we last left our hero, Pierre Packette, he was stuggling valiantly at 
the podium, flailing the air with a large club in a selfless attempt to 
save the townspeople from the evil clutches of Phil la Text . . . Ooops.  
Sorry.  Hallucinating.  At times, the bi-weekly serial approach to planning 
a club meeting gets a bit frustrating for me as well as for you.  Thanks 
for bearing with me so far.

At this point in your fledgling packet-radio club's first meeting, you've 
made your guests feel welcome and have determined just what sort of critter 
has shown up -- and what sort of task you're faced with.  If your gang did 
its pre-meeting promotional work well, you'll have a broad spectrum of 
technical sophistication and experience before you.  What's the next step?

Packet Radio Overview and Tutorial

You should decide among yourselves what sort of overview is most 
appropriate based on your expertise and your audience's sophistication.  A 
few battle-scarred techniques, tested under full combat conditions, 
however, will help you sustain a high level of interest.

     * keep it light and keep it loose
     * approach the introduction from the user's perspective and stay there
     * don't get bogged down in technical detail
     * impress them with the simplicity and ease of using packet radio, not 
       with your technical prowess
     * use very simple, clearly sketched depictions of what a packet 
       "looks" like as well as diagrams of uncomplicated networks (well-
       chosen graphics can create breakthroughs in understanding)
     * have all such visual aids (including chalkboard, chalk, eraser and 
       handouts) ready before the meeting starts
     * let them hear what a typical transmitted packet sounds like and gain 
       a sense of the typical time delays in routing a packet through a 
       number of stations
     * leave the full-blown demonstration(s) for the next portion of the 
       meeting

Be prepared to answer cheerfully the ubiquitous inaugural-packet-radio-
club-meeting questions that are innocently and sincerely raised by people 
who should nonetheless know better:

     * What equipment do I need?  (answer at the "black-box" level)
     * How much will it cost me to get a packet station on the air?  (be 
       honest; cover the options and tradeoffs briefly)
     * Why bother with packet radio?  I'm already using my computer on RTTY 
       and CW.
     * What will joining this club do for me?  What's it cost?
     * Who sells this stuff?  How hard is it to build?  Do I have to build 
       it?  Which brands are best?

Everyone has his own definition of what's best: the least expensive; the 
most reliable; the most compatible/adaptable; or the model sporting the 
flashiest chrome, brightest blinking lights, most awe-inspiring strap-
yourself-in-for-blastoff console and the cutest little baby shoes hanging 
from the rearview mirror.  Be honest.  Talk from your own experience.  And 
whatever you do, if you don't know the answer to a question, simply admit 
it, ask if any of the other club members can help and promise to get the 
answer for everyone by the next meeting.  Honor that promise.

When you get right down to the bottom line (final amp in ham radio 
parlance?) the most effective tutorial overview of packet radio for a first 
meeting is the simple, informal chat aimed at covering what it's all about 
and why your guests should be interested.  If you do it with a smile and 
pace your explanations to meet their needs, you'll give them a taste of the 
adventure, a desire to pursue their interest just a little further and a 
belief that your club is heaven's answer to their feelings of technical 
inadequacy. If I'm not mistaken, that sounds a little bit like the 
objectives you wanted to achieve!

But don't stop there.  You've cast the net with your welcome and chummed 
the waters with your tutorial.  No self-respecting packet-trawler Captain 
would hoist anchor and set sail for port without first hauling in his 
catch.  Spark their interest with a hands-on demonstration; convince each 
guest with carefully-tailored special working groups that packet radio is 
the solution to his particular problem; give each guest a reason to show up 
at the next meeting by assigning to each working group a small study on 
which they are to report back to the club; and then make each guest want to 
return by welcoming him into your club socially at a local bistro. 

We'll help you chart a safe return course -- your main hold overflowing 
with a fresh catch of packeteers -- in the next installment.

     From WB1EYI 


NTS Needs Packet

Ed Eklund, K6XI, responding to "Does NTS have to stand for Naturally 
Troublesome System . . ." (in "Packet Radio and Warm Bodies," Gateway, 
October 1, 1985, Vol. 2, No. 4), writes --

     "Amateur Radio is a public service,   'particularly with respect to 
     providing   emergency communications.'  That does not   mean just 
     being around to yell for help at   chance encounters;  it means 
     organized   preparedness.

     "We are unique among voluntary   services in our potential for 'formal   
     written' traffic but unfortunately NTS   is slow, inaccurate, 
     undependable and   has insufficient capacity for emergency   
     communications.

     "An increasingly sophisticated public is no   longer awed by the 
     performance of amateur   radio.  A major effort might show that   
     amateur radio is indeed a public service   and the biggest bang for 
     the buck would be   to vastly improve NTS, something that is now   
     possible thanks to packet radio.

     "Nationwide packet radio system linking   mailboxes serving present 
     general   participation nets could make NTS fast,   accurate, 
     dependable and have sufficient   capacity for emergencies.  ARRL Hq 
     could   plan a packet system, establish protocols   and standards for 
     equipment and do   massive promotion.

     "Many veteran 'higher-echelon' operators   would resent having their 
     positions   eliminated and they have the clout through   area staffs.  
     However, section net operators   would like better service as it would 
     greatly   increase volume and interest, but   unfortunately they, the 
     main body of NTS,   have no direct representation.

     "The public, if asked, would wonder what took   us so long.  After 
     all, are we not said   to be 'expert communicators on the   cutting 
     edge of technology?'

     From K6XI


REPRODUCTION OF GATEWAY MATERIAL

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