----------------------------------------------------------------------------

           TAPR -- Packet Status Register -- Electronic Edition


TAPR News Service                                     PSR #56, Fall, 1994
----------------------------------------------------------------------------
Packet Status Register
Issue Number 56, Fall 1994
Published by Tucson Amateur Packet Radio Corporation

Contents:
    President's Corner
    DCD mod. in MFJ 1270C
    Cooling off the AEA PK-96
    FCC 800-number
    Report from 13th ARRL Digital Comm. Conference
    Impact of part 97 changes on HF Digital Modes
    St. Louis TCP/IP Packet Network Update
    Introducing the TAPR HF-SIG
    RUDAK-U Update
    @USBBS: Addressing Packet Bulletins
    A High Speed Multicast-capable Packet System 
    Regional Packet Organizations
    12th Space Symposium and AMSAT Annual Meeting Report


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Copyright 1994, Tucson Amateur Packet Radio Corporation
TAPR gives permission to all clubs and organizations to reprint any of the
information contained in this electronic issue of the PSR.  Please attach the
following tag with any materials used from this issue:

        Reprinted from: TAPR News Service, PSR #56, Fall, 1994 

Please attach the following to the end of all articles and information used:

     TAPR membership costs only $15/year (U.S. members)!  Visa/MC accepted.  
                Call (817) 383-0000 and join TAPR today!

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
	
Tucson Amateur Packet Radio Corp
      Director/President:                        Greg Jones, WD5IVD
      Director/Vice President:                   Keith Justice, KF7TP
      Director/Secretary:                        Gary Hauge, N4CHV
      Director/Treasurer:                        Jim Neely, WA5LHS
      Director/PSR Editor:                       Bob Hansen, N2GDE 
      Director:                                  Ron Bates, AG7H
      Director:                                  Jack Davis, WA4EJR
      Director:                                  John Koster, W9DDD
      Director:                                  Mel Whitten, K0PFX

For more information regarding the Tucson Amateur Packet Radio Corp write
to: TAPR, 8987-309 E Tanque Verde Rd #337, Tucson, Az, 85749-2544 or call
(817) 383-000 or fax (817)-566-2544.
*****************************************************************************

President's Corner

Has much changed since 1985?

We are about to find ourselves in the 10th anniversary of the TNC-2 
introduction next year.  Amazing that it has only been ten years since 
the TNC-2, but have we come all that far?  In 1985, packet was just 
gaining its stride to becoming the fastest growing Amateur mode ever.  Digipeating 
was the main mode of semi-networking and BBSs were pretty much the 
main local resource.  Talk of 9600 baud operation and debates on various 
networking strategies had already begun and were continuing.

I think we can agree that Packet Radio consists of two main technical 
elements: Radios (RF) and Computers (Digital).  I'll ignore the time, 
money, and manpower part of the equation in this discussion, but they 
do play a key part of what happens.  Since 1985, the increase in Digital 
Technology has mirrored the consumer explosion.  We were once paying 
$1500 for XT computers and now we get something a gazillion times 
faster for almost half the price. The problem has been that the RF 
side has not moved as fast.  Various packet radio resources can be 
attributed to the increase in computer power.  Look at the numerous, 
almost too many, BBSs, DX Clusters, Network Nodes, and all the others 
local resources.  However, our success with computing power is still 
weighed down by our lack of RF capability.  

Those that have been able to go faster than 1200 baud, have been the 
few that understood how the radios and modems worked individually 
and together.  In addition, they have had the necessary expertise 
and equipment to make them work correctly.  Many times I have read 
articles on why we need to work on Layer 1 (the physical, or RF layer) 
issues, but the critical mass of people required in a local area with 
the necessary expertise is hard to find, and even harder to get working 
together on a common project.  The successful networks and digital 
groups have been those that have been successful with pulling this 
critical cross-section together to work on radio technology.

Ten years from the introduction of the TNC-2, we find ourselves doing 
much the same thing, but only a ~lot more of it~.  Typically, 
a digital operator is on VHF/UHF operating with an older voice radio 
with a TNC operating at 1200 baud.  This probably represents more 
than 90% of the digital community.  HF communications has not been 
stuck in the same rut that VHF/UHF operations has.  A lot has been 
done in modem and software development to improve the performance 
of HF digital communications.  Some of this can be contributed to 
the fact that many HF digital operators are willing to pay more for 
the increased performance, but this is not the entire reason.  To 
get an idea on the type of increase in performance of HF digital operations, 
just read some of the papers in this year's ARRL Digital Communications 
Conference.

So, what is going to happen in our future if we cannot get things 
working better than they are now, while continuing to watch the number 
of digital operators increase.  If we continue to operate as we have 
been, then we will probably be at deadlock eventually, if not already 
in many metropolitan areas.  This impending overcrowding of the digital 
channels we use has caused some of the current availability of equipment.  Several 
possible answers are now beginning to appear with the introduction 
of various manufacturer's radios that allow faster than 1200 baud 
operations. Although early reports seem to indicate that much still 
needs to be done on some of these radios to make them work correctly, 
they are a beginning to providing wider equipment selection.  However, 
many of the Amateur radios available don't work well in environments 
where many local resources are found to be residing (i.e. buildings 
with lots of RF floating about).  The other limiting factor with these 
radios are cost.  It is hard to justify one of these data-ready radios 
at the current price.  For the price, you can go much faster; plus 
most of us don't need all the bells and whistles present for just 
a data radio (which is a normal voice radio with additional functionality).  The 
problem with going faster for the dollar with non-off-the-shelf equipment 
is again the need in having local expertise that can do it.

Cost and flexibility is the key to the radio problem.  The unknown 
factor in the future is the current emphasis in radio technology now 
occurring with regards to PCS (Personal Communications Devices) and 
other wireless technologies.  Much, much, much money is being spent 
on wireless communication technology.  Just look at the amount of 
money dropped on less than a Megahertz of spectrum this summer: $600,000,000.  Amateur 
radio at some point has to be able to take advantage of this technology 
for what we want to do -- that of having a low-cost, flexible, 
data-only radio.  Amateurs have not been successful in inventing radio 
technology, but we have been successful, in the past, of taking existing 
technology and transferring it to our needs.

The other solution to better channel performance, is making modems 
that work on our current voice radios.  I have heard many say, "I 
have a 14.4Kbps modem; why can't we just do this over radios."  Whole 
papers can be written on why this has problems.  Basically, telephone 
and radios are enough different to cause several problems with this 
concept.  Most folks don't understand that to have 14.4Kbps work over 
the phone requires a rather complex modulation scheme that establishes 
multiple bits per baud.  This works well in the known and stable telephone 
system, but the radio environment presents many factors which do not 
allow these current standards to work very well.  However, the cost 
of DSP technology is  going to continue to drop and at some point 
someone will introduce a less than $200 modem that allows approximately 
2400baud at N-bit per baud to allow something around 9600bps over 
our current voice radios.  Another answer to the task at hand.

The problem with any new work or project is finding folks capable 
of transferring the technology into the Amateur market.  Who can predict 
the future, but we have to begin serious work on getting operating 
speeds above 1200 baud to take advantage of the many things that Amateurs 
want to do.  As someone pointed out to me the other day, folks don't 
want to spend money to go faster until there is some reason.  For 
many, 1200 baud still does what they want.  1200 baud AX.25 operations 
will not go away for a long time. This is based on the number of TNCs 
that have been sold and are still operational.  For many more, the 
lack of faster speeds in easy-to-use form has definitely slowed packet 
growth and is, I believe, one reason for the turnover in packet 'movers 
and shakers' in the last five years.  

Development will continue in this area, but what form will it eventually 
take?  Who can tell?  We will all just have to wait and see. Someone 
will develop something that will transform what we are doing now. 
There are too many Amateurs ready to purchase something at the right 
price for someone or some manufacturer not to do something eventually.  It 
is just a matter of time.

-- Greg Jones, WD5IVD

*************************************************************************

TAPR DCD Mod. in the MFJ 1270C TNC

TAPR member, Bruce Spacer, WB8VCM, reported that the TAPR XR2211 DCD 
modification might not be compatible with the new MFJ 1270C TNC.  Bruce 
was kind enough to send his TNC to Lyle Johnson, WA7GXD, for Lyle 
to look into the situation.  Lyle reports that the 1270C has the same 
2211 modem system that is used in the MFJ1278, so the XR2211 DCD mod. 
isn't sufficiently useful to warrant its installation.

***********************************************************************

Cooling off the AEA PK-96

Mel Whitten, K0PFX
whitten@chestcp.attmail.com 

The new PK-96 ventless case gives one the impression that this little 
jewel is not related to its toaster cousin PK-88.  Yes, it does run 
"kooler," however as can be seen from the PK-96 power requirements, 
400 ma has to be dissipated somewhere.  And, that somewhere is in 
its NMOS 8530 (Zilog's SCC, a 40pin DIP) and 7805 (TO220) regulator.  I 
measured the 8530 case temperature at 55~ C. and the 7805 at 75~ 
C. These are well within limits, but they contribute to nearly all 
the heat generated by the PK-96.  All other ICs are low power CMOS.

If heat is a concern, especially if you "stack" your gear, 
then you may want to consider replacing the 8530 with a CMOS version 
also made by Zilog.  The part number is  Z85C300PSC and is available 
from many distributors (Newark Electronics has them). Like air conditioning, 
koolness doesn't come cheap.  The part costs approximately $15.00 
in single quantities (a Newark price) but may be found for less from 
other sources.  In contrast, the NMOS part is less than one third 
the cost. 

Unfortunately, this little mod. is not for the faint-of-heart.  The 
8530 is a 40 pin through-hole device and not in an IC socket.  However, 
I recommend using an IC socket for the CMOS replacement. If you do 
not have experience and the proper desoldering equipment, do not attempt 
to remove the 8530.  

Power consumption with the 85C30 is around 100ma, depending on how 
many  LEDs are on.  The PK-96 now runs cool as a cucumber.  If you 
run your gear 24 hrs-a-day and your ambient shack temperature may 
rise, (loss of your air conditioning!) then this mod. will help avoid 
a heat related failure.

By the way, the "reset" switch on the rear of the PK-96 is 
a nice addition. Pushing it with power-on, however does not reset 
or "cold-start" the processor.  To reset, power-down the unit, 
hold the button in, power it back up and release the button.  All 
LEDs, except XMT will remain on until the PK-96 autobaud routine is 
performed.  AEA did a nice job on the manual, however this information 
was apparently overlooked.

*************************************************************************

FCC 800-Number

FCC establishes 800 number at Gettysburg licensing 
division as implementation of new customer service standards  begins

Declaring that "Customer service has taken on new meaning at the 
FCC,"  Chairman Reed E. Hundt has submitted to the White House 
the FCC's plan for new, improved customer service standards.

Submission of the plan is in response to an Executive Order of the 
President which requires that, in order to carry out the principles 
of the National Performance Review, the Federal Government must be 
customer-driven and provide the public with "the highest quality 
of service delivered to customers by private organizations providing 
a comparable or analogous service."  Each agency is required to 
submit to the White House its individual plan for review.

As part of its  overall plan, the FCC initiated a pilot program using 
customers of the Private Land Mobile Radio Services. It held a series 
of focus groups with external customers and then asked the employees 
of the Division  to develop customer service standards, using the 
information from the focus groups.  The Division then developed a 
brochure on customer service standards, including increased emphasis  on 
response to telephone inquiries. It also identified the need for an 
800 number for calling the licensing division.

Effective immediately, all public inquiries to the FCC's Gettysburg, 
PA, Licensing Division, Customer Assistance Branch, can be placed 
by calling 800-322-1117.  Hours of operation are weekdays from 8 AM 
to 4:30 PM, eastern time.   On the Commission's 24-hour automated 
information system, callers dealing with interference complaints, 
form requests, availability of records, Amateur radio call sign assignments, 
Marine radio licensing information, fee information and processing 
times may access recorded information.

Within the next 18 months, customer service standards will be developed 
for other areas of Commission operations to ensure that FCC customers 
receive the highest quality of service possible.  As these new standards 
become available, the FCC will inform its customers.

For more information contact Kay Hillegas at (717) 337-1215 ext. 103.

***************************************************************************

13th ARRL Digital Communications Conference

Compiled by Greg Jones, WD5IVD

The 13th ARRL Digital Communications Conference was held in Bloomington, 
Minn, on August 19-21, 1994, hosted by the TwinsLAN ARC.  The conference 
was attended by approximately 150 and was one of the best in the last 
few years. Amateurs from twenty states and seven nations were present.  A 
change was made in the organization of the overall conference, which 
resulted in three strands running through the entire conference.  This 
presented some problems due to the overlap of several topics, but 
was one of the few negatives comments that were heard during the weekend.  This 
format did allow for the numerous special interests to have time during 
the conference to discuss issues.  The conference seems to have moved 
more to specialization and away from generalization as was the presentation 
format in the early conferences.

Due to the number of sessions, each of the moderators was asked to 
write up a short overview of what happened during their session or 
forum.  The following information is a compilation of those writeups 
as well as a brief review of each of the technical paper sessions.

Technical Papers

Automatic Packet Reporting System

The paper (7 pages) discusses APRS (Automatic Packet Reporting System) 
and details several applications for APRS.  

MacAPRS: Mac Automatic Packet Reporting System

The paper (13 pages) discusses APRS and the Macintosh implementation 
of it.  Contains more detailed information on the system and has pictures 
of several items. 

Packet, GPRS,APRS, and the future

The paper (2 pages) discusses GPS (Global Positioning System) and 
how GPS is used in packet radio.

G-TOR: The Protocol

The paper (31 pages) details G-TOR. Includes: overview, technical 
details, speed transition diagram, SDL Diagrams, Huffman Decoding 
Tree, and C program routines.  

GMON-a G-TOR Monitoring Program for PC computers

The paper (6 pages) describes a method for monitoring G-TOR communications.  

A Theoretical Evaluation of the G-TOR Protocol Hybrid 
ARQ Protocol

The paper (6 pages) discusses the advantages of using a hybrid ARQ 
protocol through theoretical evaluation.  

A Preview of HF Packet Radio Modem Protocol Performance

The paper (4 pages) discusses protocol performance testing that was 
conducted at NTIA/ITS.  AX.25, AMTOR, PACTOR, SITOR, CLOVER II, and 
Baudot were tested in a simulator and the results shown in the paper.

How Amateur Radio Operators can Emulate an HF ALE 
Radio

The paper (3 pages) how Automatic Link Establishment (ALE)  can be 
used and some of the future potential for emulating an ALE radio using 
only typical Amateur equipment.  

FSK Modem with Scalable Baud Rate

The paper (7 pages) discusses the design of a scalable baud rate modem. 
Paper includes schematics. 

Designing Rural Telecom Systems for Developing Countries

Formation of the  BBS SIG

The paper (3 pages) describes the formation of the TAPR BBS Special 
Interest Group and future goals. 

Broadcast, UI, and Un-connected Protocols - The Future 
of Amateur Radio

The paper (4 pages) overviews user applications and the relevance 
of connected protocols and suggests formats for unconnected systems.  

On Fractal Compress of Images for Narrowband Channels 
and Storage 

The paper (5 pages) comments on several new classes of compression 
techniques based on fractals.  

Fast CLEP Algorithm and Implementation for Speech 
Compression

The paper (13 pages) describes a fast algorithm and implementation 
of code excited linear predictive (CLEP) speech coding for use over 
low-bit rate systems.  An excellent technical paper.  

Wavelet Compression of Images for Narrowband through 
Band Limited Channels

The paper (10 pages) studies compression scheme using wavelets for 
image transmission through band limited channels.  

Papers that were not presented, but are in the proceedings include: 
A Proposal for a Standard Digital Radio Interface by Jeffrey Austen, 
K9JA. Computer Networks in Africa:  From Utopian Discourse to Working 
Reality by Iain Cook.  ROSE X.25 Packet Switch Status Update by Thomas 
Moulton, W2VY. A Primer on Reliability as Applied to Amateur Radio 
Packet Networks by Tom McDermott, N5EG.  

Forums

Developments in DSP for the Amateur

The following topics were discussed: About five in the group had done 
or were considering doing some work with the TI DSK board. We discussed 
the use of this board and possible locations for obtaining the DSK 
which included TI distributors. TI has also introduced a new DSK which 
is based on the TMS320C50 and it is selling for about $100. Software 
to run on the DSK is available on Internet, ti.com. It was also noted 
that an Amateur has built a memory board to add to the DSK.

There was a limited discussion about working with sound cards for 
the PC. The problem here seems to be availability of detailed information 
to change the function of these cards. The interfaces are not easily 
adaptable to Amateur radio for functions required to control your 
radio.  The DSP-93 being developed by TAPR was briefly reviewed. The 
DSP-93 has all the required hardware and software to work in many 
Amateur applications. All of the information required to do additional 
software development is also being supplied with the unit.  A detailed 
discussion of implementing filters with DSP systems ensued when Timewave 
presented information on the subject. Timewave has developed filters 
for the Amateur market using hardware they build. Filter design and 
implementation are key advantages to DSP.  Also discussed was a recent 
article in QEX, the experimenters magazine from the ARRL, about Pactor. 
Code to implement Pactor and Amtor on a DSP based system was developed 
by HB9JNX and others. This code is available on internet at ftp.cs.buffalo.edu.  Of 
those in attendance, over half of the group was actually active in 
development of Amateur related DSP projects. Of these about half were 
working with TI based processors in the DSP-93 or DSK unit and most 
of the rest are working with the Analog Devices units.  One man was 
working with Burr Brown products.

The forum was a good opportunity to exchange ideas in an open, friendly 
environment. As the application of DSP products continues to grow 
in Amateur radio, I feel we will see more of these type of gatherings 
with more and more substance in each one.

TCP/IP - What's next?

"TCP/IP is obsolete and dying" -- The same statement had 
been heard over 12 years ago in the commercial world from the soothe 
sayers that saw OSI winning the protocol wars.  Now look at it today.  Broad-based 
commercial support in the popular network operating system (Netware, 
LANMan, etc.) and still going strong  as the life blood of the Internet.   No, 
TCP/IP is far from dead.   It is emerging as the preferred way  to 
interconnect computing platforms of different architectures and is 
the "on-ramp" to the Internet.

The "Information Super Highway" (Infobahn) and its relation 
to the public Internet was discussed.   It  was thought that the two 
would be interconnected, but the Infobahn would operate more like 
the commercial business model, charging for services and access.

There was a concern that the current DOS programming environment overly 
constrained the growth of NOS and  thus TCP/IP use in the Amateur 
community. The Intel 64K segment architecture and DOS 640K barrier 
proved to have serious limitations when adding new functions to NOS.  Phil 
Karn, KA9Q, pointed out that you do not have to  implement every new 
server application and Internet toy that comes along in NOS!  NOS 
on DOS is best deployed as a TCP/IP router and doing things specific 
to Amateur use like AX.25, NETROM, and BBS forwarding.  Network  alternatives 
such as a NOS front-end on ethernet or PPP to a Windows or Linux box 
should not be overlooked.

It was pointed out that the next version of Windows (tm) would likely 
include TCP/IP as part of the operating  system.  This would go a 
long way toward providing a future common programming model (Winsock) 
for both Amateur and commercial use that can overcome the 640K barrier.   The 
opportunity to adapt Amateur  applications (BBS, Converse/Mail servers, 
gateways,...) while exploiting the Internet tools for Windows like 
MOSAIC, WS FTP, Gopher, and Archie, is both a challenging  and an 
exciting concept. Many of these tools are also  available on other 
OS platforms (Linux, Unix, Mac, and OS-2), all interconnected with 
TCP/IP, ham radio  digital networks, and the Internet.

TCP/IP was seen by some as spectrum pollution and a channel hog.  It 
was pointed out by Phil Karn, KA9Q, and others  that this was not 
the case as NOS TCP/IP implements very sophisticated back-off algorithms 
and by default  is probably the most polite channel user around.   The 
multi-level protocol nature of TCP/IP provides tuning parameters  at 
each level that can be set to  maximize throughput while reducing 
channel congestion.  Phil noted that many of the  problems associated 
with TCP/IP are actually due to defects in link layer protocols (AX.25 
and NETROM).

TCP/IP-ready TNCs and digital radios were discussed.  It was felt 
that the KISS mode operation of TNCs left a lot of room for improvement 
in terms of both ease of use and hardware support.  Someone suggested 
that TNCs need to be more TCP/IP aware and implement most of the protocol 
stack with a terminal console/control interface to the host (ala Data 
Engine).  Phil Karn, KA9Q, mentioned that it may be time to consider 
replacing the AX.25 link layer with more effective Forward Error Correcting 
(FEC) protocols such as those being developed by Qualcomm and others 
for cellular radio digital packet use.

The need for a common messaging paradigm (addressing, store, routing, 
and format) for mail, news, bulletins, and forwarding was discussed. 
The richer programming and Internet-ready model provided by TCP/IP-based 
systems was seen as the tool that would lead the way toward consolidation 
of messaging systems in the future.  The easier to use graphical development 
tools that are now available in powerful multitasking operating environments 
(Linux, Win 4.0, Unix, and OS-2) will enable a lot of previously untapped 
talents to be contributed toward developing applications that can 
be shared by all.

ARRL Committee Updates: "Future Modes"

Paul Rinaldo, W4RI, opened the forum explaining the environment we 
find ourselves in today with the FCC.  He went to some detail to explain 
what the FCC reorganization was and how he thought it would affect 
us (lower priority, longer delays in processing changes, etc.)  He 
stated that the FCC consensus was that their priority should be to 
identify new technology and techniques that would promote increased 
population of the UHF and Microwave Bands.  Spread Spectrum was one 
of the areas mentioned. 

Tod Olson, K0TO, presented the 219MHz Committee's general plan to 
the audience.  The primary discussion was about those who want to 
use the band at baud rates less than 56KB, and concerns that the "Repeater 
Coordinators" in the Country aren't really Spectrum Managers in 
many areas and may not be the best people to coordinate the digital 
activities.  I spoke to both of these issues saying that the 56KB 
requirement was good planning since frequencies occupied by lower 
speed operations are very difficult  to displace (it is a guideline 
not a regulation), and that everyone should write to their ARRL Director 
about their spectrum management vs. coordination concerns since the 
Board is actively investigating this issue. 

Digital Data (Voice and Image) Transmission Method 
Developments

The presentation was started by talking about the Internet Multicast 
Backbone (mbone) and the audio and video conferencing tools that use 
it (vat, nv, wb). These tools use compression techniques at rates 
that, although fairly high, are not beyond reach of Amateurs: 13-64 
kb/s for voice and 128 kb/s (average) for medium-scan video (several 
frames per second). Software that implements them runs on standard 
workstations and is readily available over the net.  So wouldn't we 
like to see something like this come to Amateur radio?  One place 
this could be done is the new 219-220 MHz band.  Its "virgin" 
nature and the need to control transmitters make it an ideal choice 
for a high speed Amateur multicasting service that could carry, among 
other things, selected multicasts from the Internet MBONE (e.g., NASA 
Select during shuttle missions).  Lots of discussions ensued about 
various coding schemes for both voice and video, and a lively time 
was had by all.

High-Speed (above 1200 baud) data transfer Methods 
and networking techniques

The High-Speed Data Transfer forum at the DCC started with a discussion 
of some of the new hardware -- both RF and digital -- that's 
becoming available for high(er) speed packet radio.  The group was 
then treated to an impromptu presentation from Dewayne Hendricks, 
WA8DZP, on the current status of spread spectrum systems being used 
in Part 15 (unlicensed) service.  Since these devices operate in or 
near our bands, they offer a lot of potential for megabit-plus, relatively 
short range links.  After the break, the group resumed in an informal 
roundtable devoted to shoving fast data through slow radios.

HF Data Transmission Methods - An overview of current 
modes and what's coming next

Technical discussions were about evenly split between modem design 
issues (DSP in particular) and protocol issues.  Two general approaches 
to HF DSP modem design were discussed - matched filter and delay line 
discriminator. Noise reduction techniques were reviewed with special 
emphasis on DSP noise reduction delay. LMS adaptive noise reduction 
techniques appeared more suitable for use with HF modems than FFT 
bin clipping because of the lower process delay. Protocol discussions 
included AMTOR, PACTOR, G-TOR and a light discussion of PACTOR 2. 
Also some discussion on 300 bps packet.  A survey of forum attendees 
showed broad capabilities and interests in running everything from 
RTTY through G-TOR and on to 300 bps packet.

TAPR SIG Meetings (NETSIG/BBSSIG)

The NetSIG forum at the ARRL Computer Networking Conference in Minneapolis 
focused on how to gather and disseminate information about networking 
people and activities.  We agreed that a database of both networks, 
and network builders, would be a good idea.  It was agreed that we 
should start first by contacting area packet coordinators (where they 
exist) as an information resource, and build from there.  There was 
discussion -- but no real consensus -- on how much, and what 
type, of data we should be looking for. The general feeling was that 
we should try to include information about individual networks but 
not (at least for now) individual nodes.  The data should include 
contact information so that the primary builders/maintainers of each 
network segment are known.  The hope is that a national network map 
can emerge from this effort, as well as a national database of network 
builders.

Volunteers are currently designing the database format and we hope 
to start gathering information in the next few weeks.  In the meantime, 
we'd be happy to get names and e-mail addresses of network builders, 
so we can contact them directly when the info. requests are ready.  You 
can send that information to jra@ag9v.ampr.org if you'd like.

The forum also had a lively discussion about why we're building networks, 
and what we want to do with them.  As usual, no definitive answers 
emerged, but lots of folks had a chance to think about what draws 
us to this task.

A Low Cost DSP Modem for HF Digital Experimentation

This presentation touched on several reasons why HF digital offers 
unique opportunities for technical innovation and offered a low cost 
DSP-based solution. The presentation included a number of interesting 
topics such as: HF propagation, its variability and how these factors 
set the stage for special considerations in modem design, i.e. good 
dynamic range and carefully designed filters.  The presentation included 
a discussion of methods to increase dynamic range, criteria for demodulation, 
and detection using matched filters.  The design of the linear phase, 
finite impulse response (FIR) filters for a typical HF modem was shown.  This 
presentation showed that cost is no longer a factor for doing advanced 
digital experimentation using DSP - it has become a matter of applying 
classical DSP theory.  A number of interesting technical points were 
discussed afterwards amongst attendees that indicated the high level 
of enthusiasm that exists for DSP technology.  Although the meeting 
was the last one after a long busy day, it was well-received and well 
attended.

If You Couldn't Make It

1994 Conference Proceedings are available from the ARRL for $12. (203) 
666-1541.  Past Proceedings of the Digital Conference are available 
from TAPR.

Video tapes of the paper presentations are available.  The complete 
set is $60.  There are three tapes, which can also be bought individually.  For 
more information contact Paul Ramey, WG0G, 16266 Finland Ave, Rosemount, 
MN, 55068.

The TwinsLAN folks did an outstanding job and have set a fine trend 
for future DCCs.  

Next year's Digital Communications Conference will be co-hosted by 
TAPR and TPRS (Texas Packet Radio Society) in Sept. 1995, in the Dallas/Ft. 
Worth area. 

The ARRL National DCC as I saw it...

   Dave Wolf, WO5H)

The two most prevalent topics that struck me at the DCC were HF digital 
and DSP.  A minor thread that was reflected (and is a perpetual topic 
of discussion among ham digital enthusiasts) was "we've got this 
great technology at our disposal, let's find something useful to do 
with it." APRS is one of the applications for packet that addresses 
this.

Some of the discussions at the Futures Committee and among several 
of the hams during the weekend should be talked up.  The only areas 
in Amateur radio where you don't find plug-and-play the order of the 
day are in digital communications and satellites (with healthy overlap 
between the two).  If ham radio is to continue as an outlet for technological 
experimentation, the rules and regulations must encourage this.  If 
we are not allowed opportunity to experiment (and occassionally screw 
up in the process!), the kind of work that engineers do in their 'off 
hours' in their ham hobbies will evaporate completely.  All of the 
marvelous talent working on hardware and software for Amateur use 
will be dedicated to commercial endeavors.  If one attends hamfests 
and sidewalk sales, it is easy to come to the conclusion that ALL 
hams are appliance operators who crammed enough technical knowledge 
to pass their tests.  While this might be true for many in the ranks, 
it isn't true for everyone.  We've always had our share of operators 
and tinkerers.  As a group, we must encourage our representative organizations 
and our regulators to continue to allow great latitude in the rules 
for experimentation.

*************************************************************************

Impact of Part 97 Changes on HF Digital Modes

Johan Forrer, KC7WW

How does the new proposed amendment to Part 97 accommodate future 
developments in the digital modes for HF?

The digital community has been asked for input on the proposed amendments 
to Part 97. These changes deal with automated and semi-automated operations. 
My views are that of both a user and an experimenter.

There effectively are two basic types of digital modes of operation: 
keyboard-to-keyboard (one-to-one) operations including Aplink semi-automatic, 
and the AX.25 packet networking/BBS (many-to-one) groups. These two 
modes require totally different needs. 

Lets look at AX.25 packet first: in this instance there are several 
stations sharing a common "channel". Even if the channel is 
not occupied, this does not mean that the channel is free for use 
by keyboard-to-keyboard or semi-automatic operation. Present and future 
protocols that manage the flow of traffic require this -- it is 
also anticipated that a great deal of these operations would fall 
in the "automatic" category. The main challenge here is to 
deal with the nature of HF propagation especially skip conditions 
and the "hidden transmitter." It makes sense to give these 
traffic nets a fair chance of success by allocation of sub-bands for 
this type of operation. I also wish to point out that the present 
state of these operations are in great need for technical innovations 
--  increasing their efficiency, making them more robust and giving 
them added throughput capability -- more about this later.

The other type of operation, i.e. keyboard-to-keyboard and Aplink 
traffic handling, all require synchronous links. They are unforgiving 
when it comes to sharing frequency. Besides issues of operating courtesy, 
the nature of HF propagation often adds to the confusion caused by 
interfering stations. How often have I not heard several stations 
calling CQ on nearly the same frequency, but realizing that I can 
hear several of them, but they often can't hear each other. Add to 
this the confusion added by skip stations activating Aplink stations 
in semi-automatic mode and one can understand the degree of unhappiness 
expressed by those just wishing to have a peaceful keyboard-to-keyboard 
QSO. Will the proposed amendment to Part 97 allowing semi-automatic 
operations in the "real-time" sub-band be effective here? 
I have doubts. Skip conditions will still be there and so will the 
problems caused by poor operator judgement. Will a 500 Hz bandwidth 
limitation, as it stands in the proposal, have the desired effect? 
I am not convinced either. QRM on one's operating frequency is just 
as undesired whether it is 100 Hz or 800 Hz wide. I suspect that the 
intention was to "channelize" Aplinks in 500 Hz slots and 
thus limiting bandwidth of such semi-automatic operations. This way 
it is intended that others can "avoid" those frequencies. 
I am not sure that it is realized that most of the commercial equipment 
manufactured for the ham radio market as used by semi-automatic operations, 
even with the best of intentions, emits in excess of 500 Hz bandwidth. 
To illustrate this point further, take a simple example -- two 
stations, each using the same TNC-type transmit a "clean" 
170 Hz shift, 100 baud FSK signal, one at a 100W output level, the 
other at 1KW. Do they occupy the same bandwidth? What happens when 
there is a QSO in progress 500 Hz away where signals are marginal? 
In the given example, the 100W signal probably will be tolerable, 
however, the power in the sidelobes of the high power signal will 
probably wipe out the weak signals in the adjacent channel. Does this 
sound familiar? I hope that this example illustrates that output power 
plays just an important role. The 500 Hz proposal needs to specify 
whether that is measured at the -3dB or -60dB levels in order to be 
effective.

That brings me to my main concern: what about the future? I would 
hope that there is agreement that with the development of DSP applications, 
we are about to see significant technological advances. Besides the 
affects that it will have on future radios, the digital modes will 
most certainly experience marvelous technological advances. This includes 
possibilities for more robust bandwidth-efficient modulation schemes, 
better modems and protocols for both real-time operations and high 
speed networking. 

How does the proposed amendments to Part 97 affect the future of these 
developments? For sake of argument, I have put together a few possibilities 
in Table 1. I do not guarantee that all is feasible or accurate -- 
please use your own judgement. Cases 1-4 are what we presently have 
-- existing equipment. Cases 1a-4a shows the spectral efficiency 
achievable by using PSK instead of FSK. Case 5 is something along 
the lines of the ALE format, just for interest sake. In cases 6-11, 
my assumptions are as follows: maximum baudrate ~100 baud, minimum 
separation ~85 Hz, parallel tones along the lines of MIL-STD-188. 
The four tone system for cases 6 and 7 is along the lines of the CLOVER 
II system and could possibly be implemented on something like a DSP 
sound card or the TAPR DSP-93, however, I suspect that 8-11 may require 
multiple DSP's.

I do wish to point out that we can achieve a lot with a 1000 Hz bandwidth 
channel, that is within the present Part 97 framework. I hope that 
it could be shown that 1200 bps, perhaps even 2400 bps would be possible 
under favorable conditions. This would be a wonderful achievement 
for Amateur radio. On the other hand, I do wish to express grave concerns 
for excessive power usage on such extended bandwidth modes. This would 
be contrary to all the efforts to develop spectrally-efficient high-speed 
digital modes. This obviously need careful further planning. 

In Summary

The separation of the one-to-one vs. the many-to-one types of operations, 
into different sub-bands makes a lot of sense.

The 500 Hz recommendation should be phrased to include how that bandwidth 
is measured, i.e. -60dB levels may be workable. Perhaps bandwidth 
and output power should be the norm. This needs some further thought.

I respectfully request that the 300 baud / 1000Hz shift, as presently 
contained in Part 97, be retained for future explorations, even if 
that restricts this to the "automated" sub-bands.

I also strongly suggest that the HF digital group get involved with 
the VHF movement to improve and overhaul the existing AX.25 networking 
protocol. In this regard, HF has some special considerations.   

I appreciate your time and the opportunity to voice my opinions and 
for considering this plea.

*************************************************************************

St. Louis TCP/IP Packet Network Update

John Wilson, N0TYZ

Presently, in St. Louis, Missouri we are working on setting up a 9600 
Baud TCP/IP Gateway to the Internet.  St. Louis packet users formerly 
entered the Internet via a private LAN connection that routed packets 
via California and then to Chicago, Illinois where they finally entered 
the Internet.

Working with Washington University's Amateur Radio Club, W0QEV, the 
Missouri Amateur Packet Society (MoAmPS), and local St. Louis and 
western Illinois radio clubs, we are providing an IP Gateway Network 
that will route packets to regional nodes.  These regional nodes will 
be on another backbone frequency, (yet to be determined), along with 
the Gateway node which is centrally located at the WUARC site.  To 
cover the greater St Louis area, the Gateway node will have links 
initially to two existing Gracilis PackeTens. Future plans call for 
a higher speed links and additional Gracilis switches.  We hope to 
have the St. Louis Gateway up and running by the end of the year. 

**************************************************************************

Introducing the TAPR HF-SIG

Johan Forrer, KC7WW

Objectives for the HF-SIG

The purpose of the HF-SIG is to serve as a forum for those involved 
in experimenting, and developing digital applications for HF.

Background

HF offers unique challenges and rewarding opportunities for Amateur 
radio - it allows for both short and long distance digital communications 
without the involvement of specialized terrestrial or space-based 
equipment such as repeaters, or satellite transponders.  It allows 
for one-to-one (keyboard to keyboard) as well as many-to-one (networking), 
modes of operation. These are quite different in philosophy and functional 
needs.

The Amateur bands have seen a dramatic increase in diversity in technology 
as well as increased activity in the use of digital modes.  This is 
due mostly to the availability of TNCs and application of personal 
computers. Basic technology, however, has not changed much since the 
60s and is in great need for innovation to meet future challenges.

Development of future technology for HF digital requires experimentation 
with several topics on communications such as:

1. Bandwidth-efficient modulation schemes, i.e. for 
increased robustness, speed, and useability. These include various 
forms of m-ary FSK, m-ary PSK, or QAM using single or multiple carriers. 
However, other technologies such as spread-spectrum communications 
also need to be explored.

2. Application of coding theory for error detection 
and correction for increased reliability. This will require the use 
of block and/or convolutional codes.

3. Protocols to suit new proposed modulation and 
coding schemes. Various forms of ARQ and FEC are possible. The possibilities 
for half and full duplex modes need to be explored.

In addition, development platforms for such experimental work will 
most certainly receive attention.

4. Programmable DSP platforms. Hardware, and software 
for application development.

5. Host-based software. Typically th~is include 
low-level I/O, CUA/SAA compliant user-interface development, but also 
a user-contributed software repository for commonly-used algorithms 
such as frame synchronization, channel equalization, scrambler polynomials, 
fast CRC calculations, various error-detection/correction algorithms 
such as Golay (24,12), Reed-Solomon, and~ trellis/Viterbi codes 
for example.

Getting involved

We require talents representing a wide range of topics such as mathematics 
(coding theory, signals and transforms), software engineering (algorithm 
development, real-time OS, low-level I/O, host OS), electrical engineering 
(analog, digital and RF), digital signal processing (theoretical, 
hardware and software), etc.  However, there also is a simialr need 
for technical writers, beta testers, and project management.

It is unlikely that this type of experimental work will be using any 
existing TNC hardware.  A general-purpose programmable DSP platform, 
such as the TAPR DSP-93, a DSP-based sound card, or equivalent would 
be required as well as a fairly fast 386/486 or equivalent host computer 
for high-level software development.

Besides development efforts, there will be ongoing on-the-air testing 
to establish how well theoretical ideas are working in practice. It 
is envisaged that there would be rapid evolution of modulation and 
protocol development and thus the need for fully programmable hardware.

This introductory note is probably incomplete, however, it presents 
some perspective and direction for the HFSIG. I would appreciate further 
suggestions and feedback.

Subscribing

To subscribe to this mailing list send a message to `listserv@tapr.org` 
with the following line in the body of the message:

subscribe list full name

Example: 

subscribe hfsig Joe Amateur

Here We Go

I thought it would be of interest to provide further outlines of some 
ideas and get the discussion and interaction started. Please be so 
kind and take a few moments to study the summary given below.

1). HF Comms at the physical layer

Regardless of whether you are to apply results to networking or real-time 
keyboard operations, I believe that our efforts should first address 
issues surrounding the physical layer.

2). Choosing the modulation scheme

Which modulation scheme would be appropriate. HF demands a robust 
modulation scheme to address:

2.1 Flat fading~
2.2 Selective fading~
2.3 ISI due to multiplath~
2.4 Unique noise characteristics - probably peculiar to each band~
2.5 Bandwidth limitations

Experience on Amateur projects has shown that 100 baud, i.e., 10 ms 
signaling elements (bauds) may be taken as a rough upper bound. FSK 
has been the main modulation method -- in its non-coherent form, 
it is easy to implement, easy to tune, and has proven to be reasonably 
robust. It would be possible to implement m-ary FSK to "stack" 
several bits to a baud and thus increase throughput, however, it can 
be shown that for the given throughput, it will use a lot of additional 
bandwidth. The best we probably can do with FSK would be to implement 
a form of m-MSK.

As an alternative, I would, however, like to suggest the use of some 
form of phase shift keyed modulation. The justification is that bandwidth 
may be used conservatively by using n-parallel, complex-modulated 
carriers. The parallelism provides both throughput, and when conditions 
are poor, redundancy fallback. It would be possible, I believe, to 
initially develop a single channel using readily available hardware. 
Extension to multiple channels would follow, however, may require 
further research work into optimal pulse shape.

3) Evaluation of Modulation

It is good engineering practice to first test these ideas by simulation. 
This requires computer simulation and modeling.

The second phase would be to test the computer model with some real 
data. For this purpose, we need an HF channel simulator. In its simplest 
form, this could be a number of "gold standard" recordings 
off the air and made available as .WAV files that could be played 
through a sound card or applied directly in a simulated environment. 
Such standards should also be used to test and compare incremental 
development efforts.

4) On-the-air testing

It is essential that throughout early development, experience be gained 
from actual on-the-air testing. We will require a simple protocol 
to experiment with. There are several options that we can use here.

5) Protocol development

This will follow as soon as the we have a working modulation scheme. 
This probably will include either block or convolutional coding, compression 
etc. However, it probably will require an extensive development cycle 
similar to the modulation scheme.

*************************************************************************

RUDAK-U Update

Lyle Johnson, WA7GXD, 
for the RUDAK-U team

RUDAK-U is a digital communications system being designed for you!  Currently 
slated to fly aboard the International Phase 3D Satellite (P3D) being 
built by AMSAT organizations worldwide, RUDAK-U will bring real-time 
digital communications with global coverage.

Presently, your packet traffic is typically handled on VHF/UHF channels 
at 1200 bps or 9600 bps data rates.  The station you directly communicate 
with is usually less than 25 miles (40 km) away.  Most of your traffic 
is in the form of electronic mail, bulletins and programs or data 
files.

You've been conditioned to believe that packet is for non-real-time 
communications, and you've exploited this limitation.  Some of you 
have tried to use packet for keyboard-to-keyboard QSOs and have had 
the local "experts" tell you are clogging up important file 
transfer channels, and that packet isn't intended for such communications.

Existing packet satellites have been optimized to exploit their low 
earth orbits (LEO) and are, in effect, flying mailboxes.

Well, a new dimension is about to be added to packet communications 
in particular, and Amateur digital communications in general.

RUDAK - What?

RUDAK-U will be able to see half the world at a time, and from almost 
any location on the planet you'll have access to almost all the rest 
of it over a 48-hour period.  It will have the file store-and-forward 
ability you're already accustomed to.  We're hoping to augment the 
spacecraft's memory systems with ground-based mass storage facilities.

But let's look at the real-time opportunities.

RUDAK may have as many as ten (10) communications channels operational 
at a time.  During these times, multiple QSOs can be carried out using 
multimedia, digital voice, and so forth.  At other times, only a few 
channels will be operating.  Some of these channels will likely be 
"scheduled" to minimize QRM (oops, I meant "collisions").

There is a possibility that there will be a special, bandwidth-efficient 
256 kilobit/sec modem aboard the satellite and that RUDAK-U will have 
the opportunity to connect to it.  We're talking serious capability 
here, like real-time motion video!

Speaking of video, RUDAK-U  is expected to be the primary communications 
path for images from the SCOPE earth-imaging cameras on Phase 3 D.  It 
will also be a source of precise information from the on-board Global 
Positioning Satellite (GPS) experiment.

Some of the time, RUDAK-U will have only one or two downlinks running, 
but with sufficient power that a ground station with a low-noise front 
end and a small beam antenna (perhaps 5 or 6 elements, maybe fewer) 
will be able to fully utilize.  At other times,  when more downlinks 
are on or high-speed links are in use, a better antenna will be required.

As you can see from this brief sketch, RUDAK will have something for 
everyone in the digital communications community.

RUDAK has something for you!

RUDAK - When?

The design has been worked out at the block level, and detailed circuit 
design is being completed as this is written.

Engineering prototypes are expected to be built and shaken down in 
the December 1994 timeframe.  Flight hardware construction will begin 
in January and the flight module will be delivered to the satellite 
integration facility in Orlando, Florida, in March, 1995.

RUDAK - Some Details

RUDAK will carry two independent computers.

CPU-A will be based on the NEC V53 processor.  This processor is a 
superset of the V40 flying aboard the MicroSats and scheduled to fly 
on UNAMSAT.  The V53 is flying now as part of AO-27.  It will have 
16 megabytes of error correcting memory, and sixteen (16) DMA-based 
communications ports.

CPU-B will be based on the Intel i386EX processor.  This is a high-end 
controller and is being investigated for use on future Amateur spacecraft 
as well.  Like CPU-A, this one will have 16 megabytes of memory, with 
error correction to help protect against the hazards of radiation 
upsets.  It will have fewer communications channels than CPU-A due 
to limited DMA resources (8 channels).

For comparison, the MicroSats have 256 kilobytes of error-correcting 
memory (1/64th the amount of either CPU on RUDAK-U) and a total of 
8-1/4 megabytes of memory (about 1/2 the amount of either CPU on RUDAK).  They 
have six (6) DMA ports.

The CPUs will be tied together by a high-speed first-in first-out 
(FIFO) buffer.  This will effectively enable each CPU to have access 
to much of the other CPU's memory resources.

The modems for RUDAK will interface to the IF switching matrix on 
P3D.  This means a different kind of interface (similar to that pioneered 
by RUDAK-II aboard RS-14/AO-21) and the ability to operate on multiple 
frequency bands along with the analog transponders.

One of the design goals of RUDAK-U is to be compatible with existing 
packet users.  Another goal is to be flexible for future operations.  Since 
we expect P3D to be operational for more than ten years, we don't 
want people to have to use today's (obsolete) technology.

Each CPU will have a modem module.  Each modem module will have the 
following lineup:

(1) One 1200 bps Manchester uplink/PSK downlink for low speed, lower-power 
operation.

(2) Two 9600 bps FSK uplink/downlink for "typical" operation.  These 
modems will be switchable to 19.2 kbps and perhaps as fast as 38.4 
kbps.

(3) At least two DSP-based modems.  These will allow operation at 
reasonable data rates (we are looking at making them capable of 56 
kbps operation) as well as more complex modulation schemes.  They 
will of course be able to provide compatibility with today's satellite 
standards.

RUDAK - How

RUDAK-U is happening because some volunteers are pouring countless 
hours of toil and love into it.  These volunteers have reduced the 
dollars required to about $60,000.  TAPR [1] has set up a special 
fund for supporting this project. Please consider making a donation.  Consider 
it an investment in the future of Amateur digital communications [2].

Just so you don't think your money might be spent on a Caribbean Cruise, 
here is a condensed breakdown of the budget:

Module     	Flight 	Engineering
CPU-A  		590        		330
CPU-B        	620        		310
MEMORYx2    5080       		1340
MODEMx2     	1760       		1140
TOTAL      	14890       	5600

NOTE: A complete system includes one CPU-A, one CPU-B, two MEMORY 
and two MODEM.

There will be four engineering units and two flight units.

Parts                                      		 $52,180
PCB charges                                        8,800
Travel, Meetings, Initial Integration      5,500
Parts Discounts                                  (2,880)
Estimated Total                            	 $63,600

Like the rest of P3D, RUDAK-U is a truly international effort.  The 
main players in the technical team include Lyle Johnson (Project Manager), 
Peter Guelzow, Chuck Green, Harold Price and Jeff Ward.  We are all 
licensed Amateurs with long experience in volunteer service to Amateur 
radio, Amateur packet radio and Amateur Satellites.

As you can tell, we're very excited about this project.

Won't you help us make this dream a reality?

[1] TAPR, 8987-309 E. Tanque Verde Road #337, Tucson AZ  85749-9399.   Phone: 
(817) 383-0000.  Fax: (817) 566-2544.  MC/Visa Accepted.

[2] If you are a U.S. taxpayer itemizing deductions, such donations 
may be tax-deductible.  Consult your tax advisor.  Your mileage may 
vary.

*************************************************************************

@USBBS:
Addressing Packet Bulletins

By Brian Battles, WS1O

QST Features Editor
ARRL HQ
225 Main St
Newington, CT 06111
ws1o@ws1o-2.ampr.org
WS1O @ W1EDH.CT.USA

Anyone who has visited the Never Land of written electronic communication 
knows that the open forum provided by telephone bulletin boards (BBSs), 
the Internet and other similar media have long offered users exciting, 
effective means of discussing, debating and announcing diverse opinions, 
issues and emotions. These environments have traditionally relied 
on two basic means of controlling the content of messages posted and 
behavior of those who choose to participate: (1) a "gatekeeper" 
and (2) peer pressure. The gatekeeper (SysOp) can decide who may post 
material, what may be posted and if it will be forwarded. Peer pressure 
provides a vocal, but officially impotent form of obligation to conformity. 
It does this through friendly advice, admonishment, chastisement, 
and outright insult. In Amateur packet radio, a third entity wields 
a measure of control: The FCC determines what is legally acceptable.

Traditional networks, such as the seminal Fidonet, maintain an accepted 
level of decorum through a voluntary standard of cooperation and a 
hierarchy of people who have definite levels of enforcement authority. 
Specific areas, also known as "conferences" or "forums" 
(or Echoes, in the case of Fidonet), are designated where users may 
write messages pertaining to that area's usually narrowly defined 
topic. A volunteer, often selected by conference participants, acts 
as a moderator. This person's job is to regularly post a set of conference 
rules and to monitor posted messages. Theoretically, the moderator's 
presence is to serve as a referee, to inform users of transgressions 
and to reduce the amount of peer-to-peer bickering over each others' 
perceived misbehavior. Users who repeatedly violate the rules after 
sufficient warnings from the moderator are reported to the SysOp of 
the site where the user logs in to post messages. It's the SysOp's 
responsibility to counsel, rehabilitate, educate, or bar the user's 
access to the conference. The SysOp is motivated by the potential 
consequence of having his BBS excommunicated from the network if he 
fails to exercise the proper control over his users' behavior.

In the world of Amateur packet radio bulletin boards (PBBSs), however, 
there are differences that make control and adherence to standards 
difficult to implement. The spirit of democratic, uncensored participation 
that offers many advantages to radio Amateurs precludes most SysOps 
from refusing access to uncooperative users, induces them to make 
undesirable messages available to all of their local users, and even 
to forward such messages to other PBBSs in the network. SysOps have 
been roundly and publicly criticized for refusing to forward bulletins 
they deemed to be inappropriate, even if only for purely technical 
reasons. In raging discussions, misinformed or selfish users maintain 
that a SysOp is obligated to accept and forward their message without 
question, as long as it doesn't expressly violate any FCC rules. (This 
is, by the way, entirely untrue. No SysOp is under any obligation 
to do anything whatsoever with any radio Amateur's messages and the 
FCC rules state that a PBBS is its SysOp's privately operated radio 
station, for which the SysOp is permitted -- in fact, expected 
-- to monitor and control the material it transmits.)

Educating Users


To turn to a more basic, pragmatic issue, many packet operators have 
spent many hours discussing the frustration of having these PBBSs, 
supposedly designed and built for the purpose of carrying person-to-person 
mail traffic and occasional bulletins of general interest, into electronic 
"classified ad pages." Notices that carry announcements of 
items for sale, swap, or wanted, noticeably outnumber other single 
types of bulletins. Because of its convenience, low cost, and apparent 
effectiveness, PBBS users inundate the airwaves with a nationwide 
swapfest day and night. Most messages in this category are individually 
harmless, but when viewed as a class, are the greatest consumers of 
computer storage space, message-forwarding time and bandwidth.

Many SysOps and PBBS users complain that all you ever see listed on 
a PBBS today are screenfuls of SALE@USBBS messages and so on. It's 
an understandable lament: there's a lot of stuff in there, but most 
of it is "junk mail" most users never read. For example, a 
ham in Boston isn't likely to care about a personal computer or hand-held 
transceiver being sold by an Amateur in Seattle. But there are hundreds, 
maybe thousands of Amateurs in Washington or perhaps the Pacific Northwest 
region who will read and respond to such a notice. So why waste the 
time and bandwidth to send this bulletin ping-ponging all over the 
US by addressing it so it's forwarded to @USBBS?

In a sadly ironic way, most packet traffic isn't nearly as efficient 
as the non-SysOp packet operator believes. Notices of items too insignificant 
or unwieldy to be easily sold to Amateurs hundreds of miles away are 
routinely sent out addressed to SALE@USBBS. This is a lazy, or perhaps 
misunderstood, format that causes thousands of hams in a state like 
Alabama, for example, to have their local PBBSs spew forth several 
screens worth of listings for hand-held transceivers, parts, batteries 
and other such items being offered by hams in Oregon or Alaska, which 
are likely to be sold by the time they reach most out-of-state PBBSs, 
anyway.

SysOps: Can You Do It?


Perhaps there needs to be a system implemented by which SysOps would 
be asked to voluntarily help educate users. Each user could be compelled 
to read an educational message about the most appropriate way to address 
bulletins before he'd be given the privilege to post a message intended 
to be forwarded to other PBBSs. This would require at least two things: 
(1) The PBBS software would have to support a method of doing so, 
and (2) The SysOp would have to be willing to invest whatever additional 
time it might take to grant access to potential users who acknowledge 
that they've read and understand the proper procedure.

Is it reasonable to suggest that PBBS SysOps route incoming messages 
addressed to @USBBS to some kind of holding bin, unless they meet 
certain criteria (e.g., ARL, KEPS, AMSAT, FCC, SYSOP, DX, etc)? For 
example, do we really need so many SALE, WANTED, HELP, FEST and EXAM 
bulletins addressed to, and circulated over the airwaves to, @USBBS? 
Does it offer any real advantage to the user who posts it? Isn't it 
more efficient, timely and appropriate to post most bulletins to a 
local, state, or regional circulation? Could PBBS SysOps do this, 
and would they want to? How much extra time and effort would it take? 
Can any of this be automated? Will an investment in the time and energy 
now pay off later with less "junk mail" coming through each 
PBBS in the near future, if users can be taught to cut down the unnecessary 
Amateurs, regarding the possible decrease in traffic transmitted via 
VHF/UHF backbone and HF forwarding?

This could certainly be implemented in a friendly manner, with errant 
users gently instructed in a friendly, helpful manner. Each PBBS SysOp 
could prepare a "boilerplate" text he could use to inform 
a user whose postings were held or rerouted that would explain what 
was done, why it was done and how to avoid such faux pas in the future. 
A standard one-page (one screen?) message from the SysOp could simply 
inform the user that @USBBS is, by conventional agreement, reserved 
for messages that, by their inherent nature, lend themselves most 
advantageously to distribution to the entire nation's Amateurs. It 
could advise the user that buying, selling, swapping or evaluating 
almost any Amateur Radio item could be quite effectively accomplished 
via a local or regional bulletin, and that he should seriously consider 
if the hams in a distant state will care or be able to take advantage 
of the information in certain types of messages.

The Alternative


This primarily concerns standard AX.25 PBBS users and SysOps because 
more advanced software, such as that used for TCP/IP networking, doesn't 
even involve PBBSs as most hams have come to know them. A TCP/IP user 
finds his incoming mail neatly stored in his own private mail area 
on his own computer's disk drive. Bulletins can be forwarded only 
to TCP/IP operators who specifically request them, by category, from 
individuals or from stations that act as "gateways" to collect 
useful messages from local AX.25 PBBSs and mail them directly only 
to those who want to see them. Ideally, if all U.S. packet stations 
operated TCP/IP software, rather than just plain, "built-in" 
AX.25 TNC firmware, the traditional PBBS could be eliminated and Amateur 
packet radio would function more like the Internet. Each station would 
be accessible directly by every other station, and each Amateur could 
choose to "subscribe" to "newsgroups" that encompass 
particular topics.

Let's hear what you think, as a packet operator, and especially as 
a PBBS SysOp. Poke holes in these suggestions or offer ideas on how 
to improve them. Be constructive and thoughtful, and perhaps we'll 
be able to slowly educate our fellow packet operators so that we can 
all help each other maintain, expand and speed up the powerful, impressive 
Amateur packet radio network.

Send your comments to Tucson Amateur Packet Radio (TAPR), 8987-309 
E Tanque Verde Rd #337, Tucson, AZ 85749-9399; tel 817-383-0000;
Internet psr@tapr.org.

*************************************************************************

Proposal: A High Speed Multicast-capable Packet System 
for the 219 Mhz Band

Jeff King WB8WKA
Internet: jking@merit.edu
Packet: wb8wka@detroit.ampr.org
Date: 9/4/94

On August 19-21, 1994, I had the pleasure of attending the ARRL Digital 
Networking conference in St. Paul Minnesota. One of the committee 
meetings that I attended was a joint session of the ARRL Futures and 
219Mhz committees. One of the goals of the 219Mhz committee was to 
occupy the band once we obtain it. Phil Karn, KA9Q, proposed that 
the band, in part, be used for multicasting. What I propose here (and 
there also) is a system that will be multicast capable (when the protocol 
issues are ironed out) and be put to immediate use today.

One of the problems with packet is that it is half duplex. Even at 
medium speeds, such as 9600 bps, you are lucky if you can utilize 
half the channel capacity with our current system. While you certainly 
could operate full duplex, this would preclude others use of the channel 
due to the full occupancy of both of the channels (RX and TX).

Statistics on people's usage of the internet show that the majority 
of the data exchanges are asymmetrical. That is, you receive far more 
then you send. This factor can be to our advantage, both from a technical 
as well as economical perspective in Amateur radio tcp/ip.

A system like this is already in use on the Amateur PacSats. There 
are multiple low speed inputs with one high speed output. I propose 
a similar system for terrestrial use. With the high speed output on 
the 219mhz band (and users receiving there) you have greater control 
over placement of transmitters, which will be a requirement 
of the 219Mhz band that is a shared band.

The system would consist of one high speed output (128 Kbaud 
to 256 kbaud) on 219 or 222/223 MHz and multiple medium speed (9600 
baud) inputs on different bands, lets say 440 for now (but it just 
as easily could be 2m 9600 baud). The high speed channel could be 
based on a GRAPES MSK modem, transmitter only. This would feed an 
omni-directional antenna. Power output would vary depending on coverage 
required. The user inputs could be based on TEKK 440 data radios (or 
DR-1200). Antennas would be shaped coverage (beams or otherwise) directed 
towards the user area one wished to cover. Initially the user inputs 
(440 9600bps) could be simplex based, depending on height/coverage, 
one might want to make them mini repeaters so one could get DCD and 
eliminate hidden terminals. This has another advantage. Lets say you 
are running 4 9600 inputs at about 1 watt ( User areas: North, East, 
South, West). You'll need to space them at least 1Mhz apart if you 
are at the same site and running 1 watt or so. If you run them as 
repeaters/DDR's (not hard at all at the 1 watt level), you can have 
them on adjacent channels. (i.e. 441.075/446.075 441.1/446.1 441.125/446.125 
441.150/446.150). 

On the digital hardware end, life is simple also. The Ottawa 
'PI' board would be a perfect fit for this, both from the client (user) 
and server end. The PI board is a $125 (U.S) board that has two ports 
on it similar to a DRSI with the exception that one port is DMA based. 
Meaning, you can run 56Kbaud on XT based machines with ease. Obviously, 
things work much faster on better class machines. The TEKK radio is 
in the 100-110 dollar range. A TAPR 9600 baud modem would set you 
back around $80. The server would be a 386+ class machine with multiple 
ports.

The real beauty of this plan is its scalability, system economics, 
and pay as you go feature. Remember, I mentioned it could be done 
today with existing hardware. A user (client) would initially purchase 
the 9600 baud equipment. With this, he could communicate with users 
on his LAN as well as do standard half duplex routing through the 
server/router. This is what we have today on the 2m 9600 baud as well 
as 440 9600 baud channels in the Detroit area. However, once the user 
wanted to upgrade, he would just need to purchase a 219 Mhz receive-only 
modem/receiver, which could consist of simply a wide-band police scanner 
or a low-cost Hamtronics receive transverter. Due to multipath concerns, 
all user stations would need to use beam antennas for the high speed 
channel (pointed at the server).

System economics is where this really shines also. That is, 
the system cost (add all the user costs+the server costs) is less 
then with standard high speed systems. If the server system invests 
in a higher power/better coverage high speed channel (and remember, 
there are no hidden terminals due to the fact there is only one transmitter 
on the server frequency) then the total system cost is reduced. This 
is due to the fact the users do not need to invest heavily in high 
antennas/towers to receive the site in addition they only need be 
concerned about receiving the site at high speed, their transmitting 
is only done locally with modest (inexpensive) equipment. Initially, 
the user station would do symmetrical routing (as would the server), 
that is, out the same port he receives on. (User: route add server.ampr.org 
440, Server: route add user.ampr.org 440) When he added his 
high speed 219 receive port, his routing then would be the same (route 
add server.ampr.org 440) but the server would return to him on the 
high speed 219 channel (route add user.ampr.org 219).

Now, how about some of the potential problems? When grabbing 
stuff from the internet at high speed, there will be plenty of 'holes' 
on the medium speed channels to get a 'packet in edgewise' due to 
the fact that most ACKs are quite short. Since the high speed channel 
is being controlled by a router (it's  not a DDR), it will be easy 
to interleave packets even if it is keyed continuously. User stations 
will be able to communicate amongst themselves as they do now (on 
simplex). Since the 440 (2m) radios will be RX and TX, DCD will be 
maintained reducing collisions. The only potential problem we will 
have is if a user wishes to send a file to the internet. Then we would 
run into a problem that the 9600bps channel would be continuously 
occupied (with ACKs coming back at 56Kbaud on 219). I believe this 
problem could be solved in software. Obtaining a high speed internet 
feed could be a problem, but here in the Detroit area we have two 
well-connected sites (WSU and MERIT) that could feed the multicast 
server (which is a high site by definition).

OK, so how can we do this now? We can start on a 56kbaud TX 
channel in the 222/223 range... we may have to be a bit creative, 
i.e., horizontal polarization, overlay on top of distant repeater 
outputs, but technically it is very do-able. When (if) we get the 
219Mhz band, we move the server down there and up the speed to 128Kbaud. 
The user would simply need to move his receiver as all his hardware 
will still be capable of the higher speed (on AT class and above). 
And of course, our medium speed user channels are already going into 
place.

Now I've just talked about a system that could be implemented 
today. Like high speed access to Mosaic (faster than any phone line), 
WWW, FTP's, Archies, you name it. These are all client/server applications. 
How about multicasting?

How would you like to receive the entire USENET feed? How about 
all the AX.25 bulletins? Would you like to watch NASA select (the 
space shuttle liftoffs) video from you PC screen? Listen to internet 
talk radio? Have multi-media roundtable's? All this is possible (and 
much of it already happening) with multicasting. With multicasting 
you don't acknowledge every transmission and multiple users can receive 
the same data. This is going to be much of the future both for the 
internet side as well as the AX.25 side for bulletin/information distribution. 
And one other possibility of Amateur multicasting, that was mentioned 
at the DCC is the fact that a SWL (DWL?) will be able to receive most 
of this information. This would also attract users (SWLs, DWLs) to 
the hobby.

So folks, what do you think? It won't take a rocket scientist 
to do this and it can be done today with off the shelf equipment. 
It will have to be a group effort though, as many things would have 
to fall into place, but it can happen if you wish it to. Speak up 
if you think it's a good idea, bad idea, questions, or have some thoughts.. 
I personally want to get high speed internet access and this seems 
to be the most economical way I have run across yet. Remember, if 
you do nothing, nothing will happen. Let's here from you. Comments, 
questions to
semcon@detroit.ampr.org

Reference:

Karn, Phil (KA9Q).  (1987).  A High Performance, Collision-Free 
Packet Radio Network.  Proceedings of the ARRL 6th Computer Networking 
Conference, Redondo Beach, Calf, August 29, 1987, pp. 90-94.

**************************************************************************

Help TAPR Create a Data Base of Regional Packet Organizations

TAPR is generating an accurate list of regional and local packet groups.

Many of the lists we have seen published in the last few years have 
been woefully out of date.  TAPR feels that an accurate listing for 
regional/local packet groups is necessary to help exchange information 
and allow TAPR to tell people how to contact their regional/local 
groups.

We will distribute this information in various future TAPR publications.  So, 
getting this club information correct will help your group as well 
as TAPR.  In addition, we will be adding each of the groups to the 
PSR mailing.

TAPR believes that local and regional groups are essential for educating 
and supporting local operators.  As a national organization, TAPR 
can provide the necessary glue and information sharing needed to tie 
all our groups together.

The Board has been busy transforming TAPR from strictly a hardware 
/ software development group, into a more well-rounded membership 
society which continues to work on technology.

 In the future, it is hoped that together, TAPR and the regional packet 
groups can provide the kind of leadership that digital communications 
enthusiasts are eagerly looking for.

You can provide information for the data base by mail, FAX, phone, 
or Internet: tapr@tapr.org. We look forward to your feedback.

P.S. If you have any suggestions on how TAPR can work with your group 
or others, please feel free to give us a call or send e-mail.

**************************************************************************

12th Space Symposium and AMSAT Annual Meeting

Greg Jones, WD5IVD

The 1994 AMSAT-NA Annual Meeting and Space Symposium was held at the 
Holiday Inn, Orlando International Airport, Florida on October 7-9, 
1994.  The turnout was great and lots of information was presented 
and exchanged regarding current satellite issues and the upcoming 
Phase 3D launch.  This is a brief listing of the topics that were 
presented at the conference and the papers presented in the proceedings.

The conference kicked off on Friday at 1pm with updates on various 
mission status briefings.  Frank Bauer, KA3HDO, Lou McFadin, W5DID, 
and John Nichol, WD5EEV, discussed SAREX activity in 1994.  Joan Freeman, 
KD4SRD, presented a SAREX Case Study.  Dennis Wingo, KD4ETA, talked 
about SEDSAT1 and SEDSAT2 which is amateur radio in Lunar Orbit.  Dan 
Schultz, N8FGV, presented Hubble Space Telescope Photographs.  Robert 
Diersing, N5AHD, presented a Report on DOVE Recovery Activities.  David 
Liberman, XElTU, presented a paper on UNAMSAT: An Operational Guide.  Philip 
Chien, KC4YER, talked about Launch Opportunities Beyond Phase 3D.

On Saturday, the conference was opened by Bill Tynan, W3XO, and Al 
Brinkerhoff, WB5PMR. The  morning session focused on Orbital Science 
and System.  The first paper by Professor Robert Twiggs discussed 
Investigating the Integrated Control of Payloads and The Stanford 
SQUIRT Microsatellite Program.  He finished the talk with a question 
about how AMSAT in the future would work with the various university 
programs.  Peter Guelzow, DB20S, discussed the Re-Entry of Oscar-13 
and what the future holds during that process.  Tom Clark, W3IWI, 
presented an informative talk on GPS technology titled: Where Am I 
and What Time Is It? After the first break, Walter Daniel, KE3HP, 
presented a paper on the use of Star Cameras for Attitude Determination 
of Amateur Radio Satellites.  Doug Loughmiller, KO5I/GOSYX, presented 
UoSAT: The Successful Evolution, which discussed how UoSAT (Univ of 
Surrey Satellite Program) has been successful in the past and what 
direction they are going in the future.  Finishing the morning session, 
actually into the lunch break, were Greg Jones, WD5IVD, Bob Strickland, 
N5BRG, and Robert Diersing, N5AHD, who presented the latest information 
on the TAPR/AMSAT DSP-93 project.  Much interest was shown in the 
design and future applications.

The afternoon session focused on the P3D Design Review.  This session 
was packed with information and news on the P3D design.  Bill Tynan, 
W3XO, opened with comments on the Phase 3D satellite and a New Era 
for Amateur Satellites.  Dick Jansson, WD4FAB, talked about the P3D 
Mechanical and Thermal Design.  Dr. Karl Meinzer, DJ4ZC, presented 
information on the P3D RF Subsystems and Attitude Control.  Stan Wood, 
WA4NFY, talked about Antenna Designs of the P3D Spacecraft.  Lyle 
Johnson, WA7GXD, presented information on the P3D IHU and RUDAK-U 
project.  Peter Guelzow,DB20S, talked about the P3D Controller Area 
Network.  Dick Daniels, W4PUJ, updated the current progress on the 
P3D Propulsion System.  Tom Clark, W3IWI, updated current progress 
on the P3D GPS Experiment.  Doug Varney, WAlUVP, and Tom Clark, W3IWI, 
discussed the actual P3D GPS hardware.  Bdale Garbee, N3EUA, Ron Luse, 
KD9KX, and Lyle Johnson, WA7GXD, discussed the P3D GPS Computer System.  Tom 
Clark, W3IWI, and Bill Hickey, WA5FXE presented information on P3D 
GPS Antennas.  Doug Loughmiller, KO5I/GOSYX talked about the current 
AMSAT-UK contributions to P3D.

The Saturday night banquet was well attended and Dr. Paul Shuch N6TX, 
gave a banquet talk on "The Search for Dark Matter."  A number 
of plaques were presented after the banquet talk.

Early Sunday morning saw the Area Coordinators Breakfast.  The Sunday 
morning session featured talks on Satellite Operating.  Keith Baker, 
KB1SF, held a Beginners Forum.  Robert Diersing, N5AHD, presented 
a paper entitled "...Examination of AO-16 and U0-22 Activity".  Dr. 
Paul Shuch, N6TX, talked about "Orbital Analysis by Sleight of 
Hand."  Ed Krome, KA9LNV, discussed "Feeds for Mode-S Dish 
Antennas."  Gould Smith, WA4SXM, presented a talk on "Beginners 
Guide to Radio Sputniks."  Ned Stearns, AA7A, discussed and showed 
slides on their "Major Field Day Satellite Operation."  Roy 
Welch, WOSL, discussed AMSAT Software.  John Hansen, WA0PTV, talked 
about various software for the Digital Birds.

A Packet Satellite Ground Terminal was set up and working in the Continental 
Room for most of the conference.  The ground station attracted a lot 
of attention since it was using Wisp.  The DSP-93 was also being shown 
by TAPR. Mike Zingman, N4IRR, hooked up his PC to show off an alpha-version 
of the scope program by Tom McDermott, N5EG.  Lots of interest in 
seeing the DSP-93 work during the weekend.  Throughout the conference, 
buses were taking attendees to the P3D Integration Facility.  Everyone 
was impressed by the setup and the current process of the satellite.

Overall, this year's AMSAT-NA meeting was a big success and another 
enjoyable weekend spent with other Amateurs.

The following papers appeared in the conference proceedings:

Phase 3D, A New Era for Amateur Satellites, The Phase 3D 
Design Team

Phase 3D Critical Component Radiation Testing, Paul A. Barrow, 
VE6ATS

Contingency ACS Configurations for the AMSAT Phase 3D Spacecraft, 
Walter

Daniel, KE3HP

Telecommunications Satellites from the World's Garage - 
The Story of the Amateur Radio Satellites, Keith Baker, KB1SF, and 
Dick Jansson, WD4FAB

Launch Opportunities Beyond Phase 3D, Philip Chien, KC4YER

The Re-Entry of OSCAR-13, James Miller, G3RUH

1993-94 Report on DOVE Recovery Activities, Robert J. Diersing, 
N5AHD

A SAREX Case Study - Getting Teachers Interested in Amateur 
Radio and Space Education, Joan Freeman, KD4SRD, and Philip Chien, 
KC4YER

UoSAT-3: Lessons Learned from Three Years of Serving the 
Development Community, Eric Rosenberg, WD3Q

A Long-Term Examination of AO-16 and U0-22 Activity Logs, 
Robert J. Diersing, N5AHD

UNAMSAT-l: An Operations Guide, David S. Liberman, XElTU

LUSAT-1 CW Beacon Transmitter, Gustavo Carpignano, LW2DTZ

VOXSAT Review, Gustavo Carpignano, LW2DTZ 

The Stanford SQUIRT Micro Satellite Program, Christopher 
A. Kitts and Richard A. Lu

Investigating the Integrated Control of Payloads with Amateur 
Satellites, Christopher A. Kitts

Use of Star Cameras for Attitude Determination of Amateur 
Radio Satellites, Walter K. Daniel, KE3HP

Orbital Analysis by Sleight of Hand, Dr. H. Paul Shuch, 
N6TX

Dish Feeds for Mode S Reception, Ed Krome, KA9LNV

Monolithic Microwave Integrated Circuits at S-Band, Doug 
Varney, WAlUVP 

A Major Field Day Satellite Operation, Ned Stearns, AA7A

Arctic HF Satellite Radio Propagation Studies, John Branegan, 
GM4IH