QRZ! Ham Radio 1/QRZ Ham Radio Callsign Database - December 1993.iso/ucsd/packet/misc/blowby.txt

Text File | 1991-03-20 | 63.9 KB | 1,313 lines

A Blow-By-Blow Account of the 1991 TAPR Annual Meeting
======================================================

The following is based on the notes I took during the TAPR annual
meeting.  Any mistakes are mine.  On no account should you assume
that this account represents the official position of TAPR or anybody
else.  But I hope you find it interesting.
        73  -Paul Williamson, KB5MU

The 1991 TAPR Annual Meeting was called to order by "Packet" Pete
Eaton, WB9FLW, at 9:00AM at the Inn At the Airport in scenic Tucson.
The attendees introduced themselves; the usual suspects were present
from all over the country.

Bob Nielsen, W6SWE, new President of TAPR, announced the new
Directors and Officers:
    President    Bob Nielsen, W6SWE - also new director
    Vice President    Harold Price, NK6K
    Sec/Treasurer    Greg Jones, WD5IVD - also new director
    new director    Jerry Crawford, K7UPJ

Greg Jones, WD5IVD, presented the proposed agenda for the meeting.

Bob Nielsen, W6SWE, introduced Bob Hansen, the new editor of the PSR.
Bob Hansen stated that, as always, he's looking for articles for the
PSR.  If you're doing something interesting locally, even if it seems
like old hat to the local crew, it can make an interesting PSR
article.  Examples: database applications, video, 9600 bps
interfacing, regional activities, networks with special features, DX
nodes, WX nodes.  Ghost writers can be provided if you're afraid your
prose isn't ready for prime time.  PSR also accepts would-like-to-get-
in-touch-with and help-wanted notes.  PSR would like to receive as
many local newsletters as possible.

Question: Would it be possible for PSR to routinely publish a list of
local and regional groups?
Answer: Sure.  Everybody please tell me about your local and
regional groups, and PSR will print it.

The one and only Heather Johnson (TAPR office staff and "the Mother of
all Johnsons") was introduced.  She welcomed everyone to Tucson, and
apologized for the weather (it was raining).  She announced the
hospitality suite in the hotel, where she'd be holding court to sell
various merchandise and accept membership renewals.  Kit prices may
be going up, so she urged us to buy now.  TAPR office hours will be
more strictly observed: 10:00 AM to 3:00 PM Tuesday through Friday.
The answering machine will take your message other times, but Heather
would rather speak to you in person (and you'll enjoy it more too
-Ed.).

Pete Eaton, WB9FLW, presented a corsage to Heather, in appreciation
for all the hard work.  He described her as TAPR's biggest asset and
Secret Weapon.

=============================
Harold Price, NK6K - Microsat status report

This is the first TAPR meeting since the Microsats became
operational.  Four microsats were launched; one was half funded by
TAPR out of the proceedings of TNC-2 sales.  The satellites were
designed by AMSAT, but the funds came from various organizations
around the world.

Microsats serve as floating BBS stations, and they are optimized for
that application.  About 9 inches on a side, they weigh 22 lbs and
carry 3 transmitters, 6 receivers, a NiCd battery pack, a computer
with 8 megabytes of memory, serial ports, and a telemetry and control
system.  A slide of AMSAT OSCAR-16 was shown.  These satellites are
much simpler than AO-10 or AO-13, since the payload is basically a
computer, and the orbit is low.  They contain no moving parts.
Attitude control is required to control thermal problems: hot on one
side and cold on the other is only good for McDonald's BLT's.  The
attitude control system consists of magnets which tend to align the Z
axis, a solar windmill which tends to spin the satellite faster and
faster, and lossy hysteresis rods which regulate the spin rate by
dissipating energy.  The photovoltaic panels generate an orbit
average of about 8 watts, and the battery pack levels the voltage
over the orbit.

The satellites were originally supposed to be stamped out like
cookies from a cookie cutter, but it didn't work out that way.
Every satellite was different in some way.  A slide of WEBERSAT
OSCAR-18 shows the penthouse (or attic, depending on who you ask)
containing a Canon CCD-based video camera.  The camera experiment
samples the NTSC output from the hardened stock camera assembly.
This permits color to be recovered from the sampled image.  For
example, Franklin Antonio, N6NKF, has written a program that extracts
good quality color images from WEBERSAT pictures.  Unfortunately, no
good pictures have been taken since WO-18 was launched.

A picture of DOVE OSCAR-17 is dominated by Junior De Castro, PY2BJO,
a major benefactor of the Microsat program.  DOVE transmits on 2
meters FM through its outsize downlink antennas.  The primary mission
is a digital voice encoder intended for educational uses.

A picture of a partially assembled Microsat illustrates the stacked
slice chassis concept.  Another picture shows the wiring harness: a
simple 25-pin ribbon cable.  Various analog voltages from telemetry
points are multiplexed onto just one of the wires, under the control
of a serial local-area-network that logically interconnects the
stacked modules.

A picture of the AMSAT lab shows key workers Jan King and Jeff Zerr.
Many other credits for work on design, flight integration, and
software were recounted.  A picture of preparations for thermal
vacuum test illustrates the kind of special resources that can be
obtained through connections.  Some of the leading enthusiasts have
been "doing satellites" since 1970, and in the meantime they have
risen to positions of authority in their companies.  Having a company
bigwig fetching and toting cables makes a big impression on the other
employees; this makes it easier to get cooperation from them!

A picture of a Microsat with the hood open shows that the modular
stacksat concept makes it relatively easy to service.  (At least,
that's the theory.  -Ed.)  A picture of UoSAT OSCAR-14 provides a
contrast.  It weighs 60 kg, about twice as big as a Microsat.  The
wiring harness contains more than 400 wires.  It does contain more
redundant subsystems than a Microsat; the Microsat strategy was to
have redundancy through multiple independent satellites.

More pictures: UoSAT OSCAR-15, which failed shortly after launch and
hasn't been heard from since.  The Microsat/UoSAT deployment
mechanism: a spring, compressed with a bolt.  The huge crowd of
quality control people it takes to supervise the operation of
tightening four bolts to mount a Microsat to the ASAP.  Cleanroom
equipment: just home PC's, and donated gear from Kenwood, Icom, MFJ,
and TAPR.  NK6K attaching the umbilical cord to a Microsat, for
charging and monitoring on the ASAP.  A spider found in the
cleanroom.  SPOT-2, the primary payload.  SPOT-2 and the Microsats
mounted for launch - boy is SPOT-2 big compared to the Microsats!

The pacsat mission was written up in an interview published in the
May 1984 issue of Byte.  The original plan was a user interface
similar to the familiar W0RLI-style BBS software.  Later it was
realized that an interface that permitted and encouraged off-line
typing and automatic forwarding would be better; humans type too
slowly.  With a satellite audible to large areas simultaneously, it
makes sense to implement a broadcast protocol that permits listeners
to reconstruct transmitted files.  This protocol is currently in use
for AMSAT News Service bulletins, Keplerian element sets, and so
forth.

For non-broadcast messages, the goal was automatic store-and-forward
operation.  But it wouldn't do to put the routing intelligence in the
spacecraft -- spacecraft software is hard to write, and forwarding
schemes change all the time.  So the satellite acts as a file server.
The satellite software requires a special header on each file, which
contains a description of the file's contents.  One field of the file
header contains a free-form routing designator.  The BBS software can
use the routing scheme du jour to decide which files to download and
forward.

Question: What equipment is needed to work the Microsats?
Answer: 70cm SSB receiver, 2m FM transmitter, PSK modem.  PSK was
chosen for reasons of efficiency.  Software for ground station use is
available via CompuServe, TAPR, and others.  The spacecraft can also
be used as a simple digipeater for realtime QSOs.

Question: What is the life expectancy of the Microsats?
Answer: The orbit lifetime is estimated at 107 years.  Radiation
damage may become a problem after 3 to 7 years.  The NiCd batteries
have a relatively easy life, and are expected to last a long time.
UOSAT OSCAR-11 celebrated its 7th birthday yesterday with the same
batteries, and is going strong.

Question: Do you still plan to implement the part of the broadcast
protocol that permits ground stations to request fills for missed
parts of a file?
Answer: Yes.

Question: What kind of NiCd batteries are used, and how are they
managed?
Answer: The charge level is managed by varying the transmitter power.
The batteries are purchased commercially for $15 each, x-rayed,
temperature tested, and grouped into sets matched for charge and
discharge rates.  From 200 batteries, 6 sets of 8 matched cells were
obtained.  Compare with the manufacturer-qualified price: $700 each.



=======================
Lyle Johnson, WA7GXD, reading a letter from Tom Clark, W3IWI -- SAREX

About 90% of the logs from WA4SIR's operation on the space shuttle
have been processed.  They amounted to 400K of data plus 4 inches of
paper listings.  The QSL cards will be ready soon; the Goddard ARC
will distribute them.  238 "gold star" 2-way QSOs were logged by the
GRiD laptop computer aboard the shuttle.  800 "silver star" QSLs will
be awarded for stations heard by WA4SIR and awarded one of the 1700
QSO numbers. The QSO rate averaged about 20 per hour, peaking at 30
or 40 per hour.  USA stations were greatly disadvantaged by
interference, and by failure to run low modulation.  35 countries
were logged, but no European stations were logged except a few SWL
reports.  It required over 200 pages of documentation to get
authorization to carry the SAREX equipment on the flight.

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

Bob Nielsen, W6SWE, described a message from Jerry Crawford.  A
company called Hadron (spelling?) has a packet radio controller
product, the PRC6064A, which is based on licensed TAPR technology.
These devices are being used by special forces in Operation Desert
Storm.

Al Dennis, who has some connection to the Department of Defense,
spoke up about DoD use of amateur packet equipment.  They've been
using it since we started.  It is used for man-carried
single-threaded narrowband links.  The packet controllers work
naturally with the laptop computers and digital radios they already
have in the field.  The 18th Airborne Corps has been building up
applications.  Amateur-like packet is a de facto standard, because
it's cheap and give interoperability.

Packet is used both point-to-point and in networks.  For logistic
information transmission, packet replaces Jeep shuttles.  Networking
is coming, and interfaces to the DDN.  They want to extend the DDN
right into the jeeps in the field.

Question: Are you aware of tactical front-line use of amateur packet
gear in Desert Storm?
Answer: Yes!  It is being used between camps in the desert.  Then as
the frontline troops advance, they outrun the logistics people - and
use the packet thin-links to keep in touch.

Question: Can you *please* give this talk to the FCC?
Answer: Not sure we can get involved.  We did push for reciprocal
licensing with Persian Gulf states.
Question: Regulatory issues are getting to be a problem.  Pointing
out the benefits of amateur radio may help keep the regulators from
getting out of control.
Answer: We don't normally deal with the FCC, but I'll do what I can.

Question: Does the enemy have any trace of this kind of capability?
Answer: No specifics, but note that TNC-2's are available world-wide,
and so are smart people.
NK6K: Note that they aren't using the TNC-2's modem through a voice
radio like we do.  They connect digitally, through a Crypto unit.  So
the communications wouldn't be easy to monitor.

Question: How well does it perform?  It's not really optimized for
this kind of work.
Answer: It works well.  Better than the other stuff they have.  The
amateur packet gear is the only error-correcting protocol they have
that works on half-duplex radios.  They even use it on UHF satellite
links, which have just a few poor-quality channels available.
NK6K: We have a cheap satellite design you might be interested in ...
Answer: We're very interested, and we've had proposals for years, but
haven't gotten very far.



==============================
Lyle Johnson, WA7GXD --- TAPR/AMSAT DSP Project

TAPR and AMSAT undertook a joint project, spearheaded by N4HY and
W3IWI.  The idea was to handle the proliferation of different modems
for use on HF, Microsats, RUDAK, and so on.  By digitizing the analog
signals, a high-speed processor can be used to simulate filter, PLLs,
and other modem components.  When the next new modem is needed, all
that's required is a new program for the DSP board - it's only bits.

The original efforts used the Dalanco-Spry Modem 10, a PC plug-in
board based on the TMS32010 first-generation DSP processor from Texas
Instruments.  In 1988, the DSP project proposed a standalone box with
a TMS32015 (a slightly improved TMS32010), 4k words of 70ns memory,
8-bit analog I/O, provisions for a second DSP board in case extra
horsepower is required, power supply, and V40-based controller board,
all plugged into a back panel interface board.  Boards were layed
out, and some prototypes were built.  Then the Microsat project got
under way, and key project personnel were suddenly very busy.

In January 1989, after the Microsat launch, the hardware team was
freed up.  The DSP project was revived at the 1990 TAPR meeting.
After a few months, a new design evolved: a PC plug-in board, based
on a newer TMS320C25 processor.  By using a PC plug-in, the project
can take advantage of cheap IBM PC development platforms, at least
for the initial version.  This is great except for Japan, where the
popular PCs don't have the IBM PC bus.  The TMS320C25 is much more
capable than the TMS32010 or TMS32015.  It was too expensive when the
project started, but now there is a version in the high $20's range.

The radio interface is still 8 bits wide.  This gives about 40dB
useful dynamic range.  This is thought to be enough; the beta test
will tell.  Miscellaneous I/O like up/down tuning buttons are
provided for.  A sample clock phase-shifting circuit makes it
possible to use lower sample rates.  A watchdog timer is included.
The DSP board has no ROM; it is booted from the PC.  It takes up
just 16 addresses from the PC's I/O space, and no memory addresses at
all.  The PC can access DSP memory without disturbing the DSP
processor, by inserting just 1 wait state per access.  An 8530 serial
communications chip is included on the DSP board so it can handle the
TNC functions easily.  It should be especially easy to interface to
the KA9Q TCP/IP software, since that software already supports the
8530.

A 6-layer beta test board was displayed.  It's fully functional, with
just a few white wires.  The 4th of a planned 10 beta test boards is
currently under construction.  The beta test goal is to get some
applications running to verify the applicability of the hardware.
Then the production phase will begin.

There was a discussion in the TAPR Board meeting about whether the
DSP board should be sold as a kit or fully assembled, or something in
between.  Construction of the DSP board requires 10 to 20 hours of
careful work with a suitable temperature-controlled soldering iron.
Beta test results will indicate if a kit is practical.  A quick poll
of the audience indicated that many people would be interested in a
kit.  Most of those liked the idea of having the soldering done for
them, even if the soldered boards were untested.  It has been claimed
that assembled and tested boards would only cost $35 to $50 more.  A
poll showed that nobody would be interested in building the kit if
the A&T version only cost $50 more.

Question: When can I buy one?
Answer: Depends on how the beta test goes.  Definitely not by Dayton
this year, but very confidently before Dayton 92.

Question: What software will be included?
Answer: We intend to provide a monitor/debugger, assembler, and
applications, hopefully including source code.  The intention is to
provide the tools required for code hackers, AND at least a minimal
set of modems and packet applications for operators.  One member of
the software team is into images, so expect an SSTV application.
Another member proposes to create a spectrum analyzer.

Question: How much compatibility will there be between this board and
the other platforms announced by vendors?
Answer: Not much.  There are significant differences, such as a
different DSP processor.  The algorithms will be the same, but the
code will have to be rewritten.  There is a European group that has a
small board based on the DSP56001 used by the other vendors; they
have implemented a bit-banging HDLC driver on the DSP chip.

Question: I want to plug in my scanner and receive 9600 bps
broadcasts.  How do I get this done by a certain date?
Answer: mumble mumble.

Question: What baud rates will the DSP board be able to support?
Answer: It should be able to handle FSK up to 9600 bps with no
problem.  Nobody's quite sure if it'll handle something fancy like a
V.29 modem at 9600 bps.
Comment: Telebit Trailblazers use this processor, and they do V.29.

Question: Can the board be sped up?
Answer: Yes.  It's designed to go 40 MHz.  You just need to plug in
faster parts.  The limit will probably be the PALs, which need to be
7ns parts to go 40MHz.
N3EUA: With faster DSP you may be able to get a 2X speedup, but
you'll never get another order of magnitude speedup.  You have to
choose a performance class and build the best solution for that
class.

Question: What range of sampling rates can it handle?
Answer: Up to about 400 kHz.  A fast sample rate like this is useful
for non-modem applications, like spectrum analyzers.  That was one
reason for choosing 8-bit I/O instead of more precise, slower
converters.

Question: How much power does it require?
Answer: No measurements have been made yet, but only two chips on
the board get noticeably warm.  Guess: less that 5 watts.

Question: Other than DSP software gurus, are volunteers needed to
help with the DSP project.
Answer: No.


At this point the crowd got a much-needed 10-minute break.

==========================
Dave Toth, VE3GYQ -- BBS Issues

Recent FCC citations (involving a bulletin soliciting support for a
political group via a 900 telephone number) have led to a high level
of paranoia among BBS sysops.  Message traffic may be delayed.  Many
sysops are killing or at least screening bulletin traffic.  The HF
forwarding network doesn't handle bulletins anyway, so there is
little effect there.  20 meters carries most of the load, followed by
30 meters.  15, 10, and 40 also carry some.  All channels are
essentially saturated.  Retiring BBS stations are not being replaced,
in hopes of limiting contention.  VHF paths are being substituted
where possible, for example between VE3GYQ and W3IWI.  8 to 10 BBS
stations per channel might be a reasonable target.

Meanwhile, BBS software developers are working on adding compression
of forwarded message data.  Some standardization is needed.  W0RLI is
proposing LHARC, sent in binary form through the G8BPQ software
interface.

Question: Is forwarding run on a schedule, with beams pointed at the
target station?
Answer: Not really.  The antenna is usually left fixed at a
compromise heading.  This is workable since each station only tries
to forward to a few specific destinations.  Forwarding times are
theoretically slotted, but typically BBSs overrun their forwarding
slots.

Question (self-asked): Have things changed in the last year?
Answer: More system are running multiple connections via the G8BPQ
software.

Question: Some people seem to agree with the FCC that the content of
bulletins is out of control.  What do sysops thing?
Answer: I hold ALLBBS and AMSAT message for manual review.  I'm not
impressed by the intelligence level exhibited by message posters OR
by sysops, and I sympathize with complaints about the noise level on
ALLBBS.  But I think the issue should be handled within the BBS
community.  Local sysops should take some control.  It's worth noting
that the originator of the 900-number message was a repeat offender.


============================
Dewayne Hendricks, WA8DZP - Packet in Northern California

The Northern California Packet Association (NCPA) will host the next
Computer Networking Conference, September 27-28, 1991, somewhere in
Silicon Valley.  There were complaints about the format at the last
Conference in London, so format changes (undetermined) are planned.

NCPA was formed 3 years ago to control frequency wars.  It is an
umbrella organization over northern CA packet groups.  It is tasked
with frequency coordination, and is recognized as packet frequency
coordinator by NARC, the repeater coordinator for that area.

There are currently no high-speed (>1200 bps) links in regular use in
northern CA.  This has been tolerable because of the organization
imposed on the network by NCPA.  Frequencies are allocated for higher
speed, but everything is operating at 1200 bps.

Nationally, NCPA serves as an educational and information
distribution service.  It publishes a very nice quarterly
newsletter.  Expect to see more publications from NCPA.  The
newsletter is available for $10/year.

Question: What exactly do you mean by "coordination"?
Answer: Exactly the same thing meant by "coordination" of repeaters.
So far we've had no disputes that weren't resolved.


========================
Paul Newland, AD7I - METCON project

Packet is an ideal way to transmit low-tech telemetry data.  He has
developed a simple telemetry monitor program for an 8051
microcontroller.

A block diagram shows the 8751 microcontroller (with lots of goodies
all integrated onto the microcontroller chip), up to 6 relay outputs,
and current loop inputs for switch closures or outboard
voltage-to-frequency (VTF) converters for measuring analog voltages.  A
multiplexer selects from several VTF inputs.  The VTF approach was
chosen because it is less susceptible to noise, and can be
opto-isolated if necessary.  A serial EEPROM is provided to store
default values or passwords.  There's support for a conventional
8-channel A/D converter.  An RS-232 port connects the board to a TNC
for remote control and sensing.  The TNC can automatically collect
periodic sensor readings, and can transmit a message when a reading
changes.  There's a line oriented command structure by which the
remote user can control the board.

TAPR has adopted the METCON board as an official project.  Pete Eaton
is in charge of the development group.  Lyle Johnson and Paul Newland
on hardware.  Kits just might be available by Dayton.  Source code
for the software is expected to be available, even though that will
weaken the user authentication scheme and possibly embarrass Paul by
revealing his coding style to the world.  New software is welcome.

A prototype METCON board was shown around.  A prototype VTF board was
also shown.  The VTF board can measure temperature directly with the
addition of two components.  The A/D board is not done yet.  A power
manager board for battery-powered sites is under consideration.
Another possible improvement would be to switch to a Signetics
version of the 8051 with more I/O and more code space.

Question: would the Signetics part be code-compatible?
Answer: Yes.

Question: What temperature range?
Answer: The device will operate over the commercial temperature
range, -20 to +85C.  The sensor range is -50 to +70 or +80 C.

Question: Does it fit inside a TNC?
Answer: No.  But it does run on 12VDC, 100 to 150 ma.

The device can be used for a remote weather station, or as a very
elaborate repeater control system.  If everybody used it for repeater
control, every repeater control link could be on the same frequency!



At this point, everybody adjourned to the Garden Room for lunch
(except a few who can't eat rye bread).

===================================
After lunch, videotape clips from the early years of packet radio
(1982 to 1984) were shown.  Chuck Green, N0ADI, is shown giving a talk
describing an early version of the packet protocol.  It featured single-
byte station addresses with a couple of bits reserved, for a maximum of
64 stations in an area.  There was going to be a network control station
that dynamically allocated addresses to stations entering the network.
The control station would periodically broadcast the mapping from network
address to station callsign.  CW ID was required in those days, and there
was a scheme to reduce the network overhead by having every station
transmit their CW IDs simultaneously.

Another video clip showed Lyle Johnson, WA7GXD, describing the rationale
for the TAPR TNC (now known as the TNC-1).  Compared to the existing
Vancouver VADCG TNC, it was designed to be cheaper, easier to use, and
more operator-oriented.  Power supply and modem were on-board, and a
transmitter watchdog was provided.  An alpha-test TNC was shown
transmitting a packet.  This was a 6502-based board running a FORTH
system.

A third video clip discussed the possible applications of packet radio.
Sharing an expensive computer resource (like, say, a TRS-80 Model I) was
an important potential application.  HF operations at 300 bps and 10 meter
operation at 1200 bps were mentioned.  AMTOR was proposed as a possible
linking mechanism for poor HF paths.  Packet operations via satellite,
possibly even by portable stations, were envisioned.  And an exciting
blue-sky possibility was described: linking together different areas
using VHF links.

One last video clip was a cautionary piece about computer viruses, that
looked and sounded like something produced by the Civil Defense authorities
during the '50s.

============================
Lyle Johnson, WA7GXD, presented a plaque to Harold Price, NK6K, for his
contributions to packet radio since 1982.  In accepting the award, NK6K
said that he sees himself as a link between the experimenters on the
forefront of technology and the users of the technology.

============================
Jon Bloom, KE3Z  -- League issues

As an aside, Jon started by mentioning that NK6K's QST article entitled
"What's All This Racket About Packet?" is always held up as an example of
the kind of explanatory article that QST needs.

There has been little progress on the proposed version 2.1 of the AX.25
Level 2 protocol spec.  The update is still waiting for the specification
in "state description language" to be completed.

At the Computer Networking Conference in Colorado Springs in 1989, the
community agreed that there was a need for work on HF packet: modems,
protocols, diversity reception, and spectrum management.  A grant from
FEMA was obtained to work on some of these issues.  The terms of the
grant included a provision that the government would own any intellectual
property that arose from the research, and this discouraged people from
working under the grant.  Since then, FEMA has relented, and participants
in the program will now retain all intellectual property rights.  $9500
is available for HF experiments; proposals may be submitted informally to
Paul Rinaldo or Jon Bloom at HQ.  One possibility is to develop a new
protocol for HF work, being something like a hybrid of AMTOR and AX.25.
CCIR study group 8 (amateur and maritime) could be approached to make a
new protocol a CCIR Recommendation.

The FCC citations against BBS sysops for relaying a message with apparent
commercial content has received a lot of attention, which seems to have
been what the FCC wanted.  It is hoped and expected that these particular
people will escape any fines.  ARRL believes the FCC is taking an
inconsistent position.  FCC has stated officially that every station is
responsible for the content of all traffic passing through it.  But in
the automatic control docket, FCC acknowledged that it is impossible to
screen all the traffic.  FCC seems to be resolving the conflict in favor
of full responsibility for all stations.  Perhaps they would relent if we
could provide an audit trail by which the originating station alone could
be held responsible.

Notice the implicit double standard, as compared to voice repeaters.
Of course, if it came down to it the FCC could decide that voice repeater
operators are responsible for content as well.  Or, they can maintain a
double standard if they wish.

Question: there are technical solutions, involving authentication schemes.
Answer: the FCC just wants somebody to be responsible, and they want the
amateur community to solve the problem.  How we solve it is up to us, as
long as we can convince the FCC that we have solved it.

Question: No matter what we do, we won't be able to stop infractions
before or even while they happen.
Answer: We can avoid that problem by finding a way to hold the originating
station responsible.

Question: How is the audit trail in the BBS headers, apparently used by
the FCC to write citations, any better evidence than the old tape recordings
and DF fixes that the FCC has always refused to accept for prosecution?
Question: It looks like an overzealous engineer-in-charge got carried
away on this one.
Answer: Maybe so, but the issue would have come up sooner or later.
The head of the Private Radio Bureau intends to come out with a policy
statement or rulemaking on this subject.  We have some opportunity to
influence this process if we act now.

Question: Does this mean that the FCC no longer considers a callsign to
be meaningful?
Answer: There is no ARRL position on this.  KE3Z's opinion is that the
callsign is useful in enforcement, but is not sufficient evidence of
guilt.

Question: Is this a one-time problem?
Answer: This case was just a catalyst.

Question: It's time to relicense the Microsats under some other country's
authority.
NK6K: It's not clear that that is possible.  Even if it were, it would
make it very difficult to get the next satellite license.  Also, most
other countries have worse rules, not better.
KE3Z: On the other hand, the US is the only country that defines 3rd
party traffic to include ham-to-ham relay traffic.
Comment: The UK prohibits ALL 3rd party traffic.
KE3Z: It is in our best interest to prevent intruders using the network.
We want some control over who uses the network for what purposes.

Question: How does this differ from some ham dialing up a 976 number on
an autopatch and ...

Question: How much time will the FCC give us to resolve this issue?
Answer: If we are visibly trying to implement a technical solution, we
can probably have whatever time we need.  If we're planning to stonewall,
the deadline may be late summer or early autumn.

Question: If we come up with a solution, who will tell the FCC?
Answer: Everybody.  I don't know.  ARRL will certainly be working on the
problem.
W6SWE: TAPR has set up a committee to study the problem.
KE3Z: TAPR should contact Dave Sumner at HQ to coordinate efforts.

Question: Can we just ask the FCC to give us a ROM with a coded password
in it?
Answer: Yes, but they won't do it.  They don't see this as a problem:
they can just continue the current policy and cite us for violations.
Notice that the FCC doesn't see any distinction between ALLBBS and any
other transmission.

Question: What about the issue of the right to due process?
Answer: The cited stations have that right.  There is an appeal procedure.
Everyone who was cited is believed to have filed an appeal.
NK6K: We have to look beyond the details of this case.  Their easiest
defense is that the network audit trail doesn't prove they did it.  That
claim contradicts our claim that the network is a "pipe" and can be
treated as such.  This is a very dangerous regulatory position.

Question: How long ago was version 2.1 of AX.25 first discussed?
Answer:  Uh... about three years ago?
Question: Why do we need to change the protocol?
Answer: There were various issues; channel access was one.
Question: Maybe we should just disband the committee.
Answer: Getting protocols down on paper has always been slow work.

Question: What is the status of the HF unattended operation proposal?
Answer: I'm not aware of any proposal.  The STA was extended again to
run through the end of this year.  It'd probably be a good idea to get
this whole issue resolved before the STA comes up for renewal again.

Question: There have been complaints from RTTY operators on 20 meters
that packet BBS stations are encroaching on RTTY frequencies.  Some claim
it's a conspiracy by the STA operators.
VE3GYQ: It's not STA operators, but there has been some encroachment.

============================
Mel Whitten, K0PFX - Radios for 9600 bps Operation

Hams in Missouri are trying to build a 9600 bps network on 440 MHz.
They obtained a number of Mitrek radios from a water company.  They
initially looked good for data, but experience shows that they are too
narrow-banded for data.  Widening the IF (following Mike Schroeder's
article) has been a struggle, but it helped somewhat.  Three links are
up and running now, giving about 2400 bps thruput.  These are 30-mile
links; 5 to 6 mile links work a bit better.

A company called TEKK makes a very small 2-watt data transceiver that
seems ideal for this application.  They currently come for commercial
frequencies around 461 MHz, but a ham band version is possible.  With
G3RUH modems, interfacing is easy and bit error rate tests give good
results.  They run all day without retries.  Mike Chepponis, K3MC, has
moved a couple of the commercial-band TEKK radios into the amateur band.

========================
Dewayne Hendricks, WA8DZP - K3MC proxy report

One of the TEKK radios, mounted in a chassis with a Kantronics G3RUH
modem, was passed around.  The TEKK radio costs only $150 in single unit
quantities!  The radio is tiny.  Recovery time less than 8ms.  Sensitivity
0.3 microvolts for 12dB SINAD.  Crystal controlled, single channel.

He is also working with K3MC on 900 MHz Part 15 spread spectrum devices.
A tiny 121kbps 1W 900MHz data transceiver was passed around.  It costs
about $150.  There was a session on wireless networking at the recent
Hacker's Conference.  They discussed the new no-code amateur license, but
weren't very excited about it: the content restrictions imposed on the
amateur service are too onerous.  They'd rather stick with the Part 15
devices, which may be used to transmit any kind of messages.

Most of the commercial units are direct sequence spread spectrum.  One
recent unit is frequency hopped instead.  Chips sets are becoming available
for spread spectrum.  More information will be presented at the next
Computer Networking Conference.

K3MC has left Apple Computer.

Apple Computer filed a petition with the FCC a month ago, seeking to create
a personal data communications service.  The comments deadline is March 11.
They don't think Part 15 devices are suitable.  They want 1 watt, 1 Mbps,
at 1.8 GHz.  They want some different tradeoffs between power and antenna
directionality.  They propose a phase-in of frequencies.  The IEEE has
formed a committee for wireless LAN issues.  WA8DZP (and soon K3MC) is
a member of the committee.

==========================
Chuck Green, N0ADI - TAPR Production

Did you ever wonder about how all the parts in your TAPR kits got there?
N0ADI's wife does all the kitting.  His spare room (which was going to
be the hamshack...) is the TAPR warehouse.  In the early days of the TNC2,
the warehouse took over the family room and part of the living room, as
well.  2700 TNC-1 kits and 1200 TNC-2 kits were packaged, and countless
smaller kits.  2500 kits, all small, were shipped last year.

Question: How many K9NG modems?
Answer: A few hundred.

When a production run ends, TAPR retains a quantity of spare parts.  If
you need a spare part, they probably have it.  Full kits of parts for
boards are not available, though.

N0ADI also has possession of a computer owned by TAPR for PC board layout
using ProCAD software.  It was on display in the meeting room, with the
very complex layout of the DSP board on the screen.  The DSP board holds
67 ICs.  Notice that the bottom rear corner of the board is shaved off to
permit insertion from the top of the PC chassis.

Question: How many hours did it take to lay out the DSP-1?
Answer: A couple hundred.

Question: We have 8 K9NG modems unbuilt; can we get kits of parts without
boards to fill them?
Answer: The theory was that the parts not included in the partial kit
were easy to obtain.  So no, we don't plan to issue a parts-only kit.


=========================
Don Lemley, N4PCR - the PackeTen Switch

[Editor's Note - this talk contained a lot of detail given at lightning
speed.  I couldn't begin to write it all down.  The following is some of
what I did catch.]

Why the PackeTen switch?
Overloaded networks.  Advanced applications are not practical at the
low bandwidths currently available.
There were political problems.
He decided to focus on the digital side of the problem, since that is
where his expertise lies.  He wanted to provide an off-the-shelf solution
that would support the fastest modems and radios available, up to 56 kbps,
and future platforms to 1 Mbps.  It provides backwards compatibility to
the existing users.  And at lower cost than the usual configuration of
many TNCs.

The PackeTen features a MC68302 special-purpose processor running at
16 or 20 MHz.  3 high-speed synchronous or asynchronous channels, with an
aggregate thruput of 2 Mbps.  Clocking is software configurable.  EEPROM
memory stores configuration info.  CMOS is used for low power.  2 megabytes
each of RAM and ROM can be installed.

The card comes in two versions: standalone and PC plugin.  The PC plugin
card has a very fast dualport memory interface to the PC.  It can use an
8 or 16-bit interface to the PC bus.

The PackeTen runs a customized version of the KA9Q NOS networking software
("NOSINABOX").  This version supports NET/ROM for backwards compatibility
with NET/ROM networks and users.  And of course, TCP/IP users can use its
more sophisticated features.

Pictures of the Chicago area network before and after upgrades using the
PackeTen were shown.  After the upgrade, the network had fewer nodes,
was more organized, and supported higher data rates.

Question: What's the name and address of the company?
Answer: Catch me after the meeting.

Question: If the Chicago group was like most, the original network
resources were owned by a variety of clubs and individuals.  How did you
deal with this when upgrading the network?
Answer: The IP users group put together the funds to build the new network.
When it was up and working better than the old network, the other stuff
just faded away and the users switched to the new network.

Question: Does the Chicago network use the PC plugin card or the standalone
version?
Answer: Both.  The PC version is used in the nameserver, and the standalone
version is used in the switches.

Question: Does the diskless node require a custom BIOS, or what?
Answer: NOSINABOX takes care of all that.

Question: What frequency is all this networking done on?
Answer: 70 cm.

Question: What's the price?
Answer: $700 for the standalone version, $800 for the PC version.

Question: What's this 4800 bps landline link shown in your diagram?
Answer: That's really a 1.2 GHz link to a tower that hosts the wormhole
to California.

==========================
Bdale Garbee, N3EUA - Colorado report

Welcome to ex-members of the former Rocky Mountain Packet Radio Association.
As RMPRA disbanded, a group of new faces formed COPA, the Colorado Packet
Association.  Bdale ended up chairman of the Technical Standards Committee
of COPA.

The network just didn't work.  Now they are focussing on east-west linking
across the mountains, instead of the former emphasis on north-south linking
along the front range.  A new backbone is planned for this summer.  The
current network works so poorly that backwards compatibility isn't much of
an issue.

Lack of organization has been a problem.  Not everyone understands the
distinction between an occasional path and a reliable path.  Many of the
paths currently in use rely on knife-edge propagation, which is not
suitable for high-speed data links.  Site selection and service goals were
the main issues.  It was necessary to use point-to-point line-of-sight
links of less than 50 miles.  300-mile links between 14000 foot peaks
were the wrong answer.

The plan is to put 10GHz links at 6 nodes, arranged in a linear backbone.
With two backbone links and two user access ports at each node, they
needed 4-port controllers.  Given that, the cost differential between the
usual low-performance multi-TNC implementation and the PackeTen was
small.  They bought 3 PackeTen standalone units, with 3 more to be obtained
soon.  A working group is trying to make the 10 GHz 1 Mbps modems designed
by N6GN and others mountainworthy.

They want to make use of full duplex to conquer the hidden terminal problem
that tall mountains produce.  They have permission for a duplex machine
on Pikes Peak.  A crossband duplex machine is already in operation near
N3EUA.

It is hoped that by the time of the Computer Networking Conference, bare
PCBs or perhaps even kits will be available.  They are still investigating
interface issues for 10 GHz modems.  The current theory is to add the
circuitry to the modem, so they can be connected directly to the PackeTen.
There is some thought of varying the data rate as conditions change.


===========================
Phil Anderson, W0XI - Kantronics

Last year, the market was depressed, but since September volume has been
up surprisingly.  Commercial customers are buying TNCs for HF and VHF,
and even some 2400 bps QPSK units.  Amoco and Tennessee Gas are using
TNCs for sending data to operators in mobile units.

The latest product from Kantronics is the TelemetryUnit.  A front panel
was passed around.  The TU hooks up between instruments and a TNC to
relay telemetry.  It features screw terminals on the back panel to ease
field installation.  Firmware is available that supports an anemometer,
wind direction sensor, ratiometric A/D converter, temperature sensor,
and rain gauge.  They're still looking for a suitable pressure sensor.
This firmware gives a text-based human interface on the data port.  The
operator specifies the sample rate, and it automatically collects the
data.  You then ask it for a report, and it dumps the data to you.
Sampling everything every 5 minutes, there's room for a few days info.
Sampling just temperature every 30 minutes, it'll go a year before it
fills up.  Another firmware version is available that provides a general
units-translation feature, with user-specified units.

Kantronics is developing the D4-10 data transceiver.  They will be seeking
FCC Part 15 approval soon.  It has microphone, analog data, and digital
data interfaces.  Two channels, crystal controlled.  They have some tricks
to make TX/RX switching fast.  The receiver filtration scheme and major
parts choices were discussed.  The built-in slicer can tolerate up to
4 kHz of frequency error.  Spectrum analyzer displays for various tests
were shown.

They hope to have the D4-10 available by Dayton.  Pricing is not yet
determined, but it will probably be around $300.

Question: Do commercial band users have trouble getting licensed to use
data transmission on shared voice channels?
Answer: We've found that most 2-way radio shops don't understand data.
They estimate that 50 shops in the country can really handle it.
On a shared voice repeater, data is secondary to voice.  There is some
movement toward data in trunked SMR.  Nobody seems to know where the data
market is.  There's more data on HF, in ship-to-shore, governmental, and
utility applications.

Question: What about public safety services?
Answer: Riverside County, CA is very enthusiastic about data communications.
But each user needs custom software, and that's not practical.  For example,
Amoco cut its 30-man communications staff to 2 after the oil embargo.  In
that kind of situation, companies need turnkey solutions.

Question: Have you tested against radar QRM?
Answer: No.  The radio was tested in Chicago.  Pagers have been something
of a problem.  In an earlier model, aircraft frequencies fell on an IF
image and caused problems.

============================
Gwyn Ready, W1BEL -- PacComm

PacComm's EM-NB96 9600 bps data communications line is growing.
The modem has a new feature: the modem disconnect is brought out so that
other modems can be chained onto the same TNC.
The NB96 modem can be connected directly to the TEKK radio; PacComm worked
with TEKK as a beta tester for data applications.  They work very well on
good RF paths.  In commercial service, they specify the modems to work
with a path of a certain quieting, and the user can't complain if they
don't work on crummy links.

The TEKK radio *will* be available on amateur frequencies.  They'll be
tunable from 420 to 440 MHz, crystal controlled.  Some should be
available at Dayton.  They're looking for input as to what frequencies
should be made available.

The TINY-2 PLUS is an add-in board for the TINY-2 TNC.  It's aimed at
experimenters, with other features intended to encourage volume sales.
It has open squelch DCD, a hardware clock, room for 512K of extra RAM,
and 3 extra EPROM sockets.  The ROMs can be selected by software.  You
can put RAM in the EPROM sockets and download code to it.  The serial
ports have LEDs for debugging.  A mini-BBS and remote commanding are
supported by the standard firmware.  A monitor EPROM is available.  The
add-in board draws about 40 ma.

There's also a smaller, cheaper add-in board that just expands the memory.
It plugs into the Z80 socket, and gives 128K of RAM expansion.

One of the first PacComm HandiPacket TNCs was recently delivered to the
Soviet space station Mir.  There seems to be a bit of a problem with
user training; the cosmonauts don't understand all of the features.

===============================
TAPR Annual Business Meeting

President Bob Nielsen, W6SWE, called the TAPR Annual Meeting to order
at 4:23 PM.  He introduced the new board members and officers.

Bob Hansen, N2GDE, is the new editor of PSR.

Greg Jones, WD5IVD, is now the manager of the packetRadio project.
Boards have been prototyped and debugged, but still need some work.
No date is promised.  A more complete report is expected later this year.

The METCON and DSP projects were discussed in the board meeting.

A Guide to Operating Packet is to be published in time for sales at Dayton.

The packet video featuring Pete Eaton, WB9FLW, is to be updated this year.

A Committee to develop a TAPR position on the current regulatory issues
was appointed: NK6K, N3EUA, VE3GYQ.

METCON is the only new project that was officially adopted, but some
other ideas are cooking in the back room.  New ideas and project proposals
are solicited; you don't need to be a member of the inner circle (or even
a member of TAPR) to propose a project.

Prices for software and kits will probably be increased before Dayton.

Greg Jones, WD5IVD, gave the financial report.  Total assets are around
$103,000.  Revenue this year was about $79,000, mostly from the sales of
small kits.  OEM licensing revenues from TNC-2 sales have all expired.
The membership has increased from 700 to 1200 members.  This year's net
is $2000.  Quite a bit was spent on R&D.

Question: What liabilities are there?
Answer: The liabilities sheet was shown.  One liability is a member
services reserve.  This reserve covers the cost of quarterly PSRs for the
duration of all paid-up memberships, so that the Board can't spend the
money that's already promised to members.

In August, the bookkeeping switched to a new, more automated service in
Austin, TX.  The new arrangement gives more services for the same price.

Question: Do dues cover costs?
Answer: About 80% of dues pays for PSR.  The rest depends on what
assumptions you make about how Heather's time is spent.

NK6K: Notice that there are no engineering salaries in the budget.
We only pay for services that engineers won't do.

Question: Why are Board meetings closed?  Maybe a Member At Large would
be a good idea.
Answer (NK6K): Some issues are too volatile to discuss in a large group.
Some Board members think the Board is too large anyway.  Board meetings
aren't usually officially closed, but sometimes they have to be.
N3EUA: Note that the Board does meeting continuously via Compu$erve.
You can bring issues or proposals before the Board at any time of year.

Question (joking): Where the Version 4.0 of the TNC-1 software?
Answer (NK6K): Nowhere.

The meeting was adjourned - dinner ensued.


==========================
Steve Hall, WM6P -- HF Diversity Reception

Experiments with diversity reception for HF packet have been carried
out.  The scheme used two separate antennas, receivers, and modems.
Software provided by Kantronics was used to keep statistics on packets
copied by both TNCs and packets copied by one but not the other.  The
receivers were mostly listening to the 20 meter BBS forwarding channel.
This provided a variety of locations, signal strengths, and angles of
arrival.

The results were surprisingly consistent: A second receiver gave about
50% improvement in packets received.  For instance, if the A channel
receives 4000 packets correctly, typically the B channel would receive
an additional 2000 packets that A didn't copy.  This performance level
was largely independent of the quality of equipment used on the B channel.
Even relatively inferior equipment (R390 and R388 surplus receivers with
random wire antennas) provided about 50% additional packets, even when
relatively first-class equipment (TS940S receiver on a monoband beam)
was used on the first channel.

The results were also largely independent of the antenna configuration
used.  The only pair of antennas that didn't exhibit good diversity was
a pair of horizontal dipoles at right angles with colocated feedpoints.
Parallel dipoles spaced a half wave apart gave good results.  Comparative
tests were difficult, since ionospheric conditions changed performance
more radically that antenna selection.

In light fading, diversity improvement fell to about 20% additional
packets.  When fading was heavy, diversity improvement was larger, since
the two channels tend to fade independently.

Another test configuration using a dual-port DRSI PC*PA board with
software provided by Andy DiMartini gave similar results.

So far, the diversity combining tests have been a laboratory curiosity.
The next step is to make a combiner box that will allow two TNCs to
handshake and do diversity receiving automagically.  He has talked to
manufacturers, with lukewarm results.  Jon Bloom, KE3Z, is interested,
and they plan to move ahead with a prototype that will interconnect two
KISS TNCs.

Question: What spatial separation was required to get space diversity?
Answer: A half wave gave nearly full diversity.

Question: When you watched the S meters on the two receivers, did you
observe fading that was too fast for packet-level combining to cover?
Answer: Yes, there was some fast fading.  It was hard to sort out the
effects of collisions from those of fading.  We tried some tests with
a lower baud rate (100 bps), which seemed to indicate that the long
packet durations overwhelmed any advantage.

Question: Did you try diversity combining using analog voting?
Answer: No.  That scheme would assume that the stronger packet is the
good one.  Observations show that sometimes it's the weaker one that
(a) can be demodulated successfully and (b) is the packet you want.

Question: Did you try polarization diversity?
Answer: Yes.  But with the ionosphere changing faster than the antenna
configurations, it was hard to draw any conclusions.

Question: In the old RTTY days, we sometimes ran two receivers with a
common AGC so that the strong signal would overwhelm a weaker one.
Answer: Again, that would assume that strong equals good.  I didn't
do it that way.

Question: What packet length was used?
Answer: All lengths.  Whatever was on the channel.
Question: This would work better with shorter packets, wouldn't it?
Answer: It seemed to work OK with random lengths.

Question: Did you ever see better than 50% improvement?
Answer: Yes, we saw 60% sometimes.  But there were also times when there
was little fading, and both receivers were copying nearly every packet.

Question: How many packets were missed?
Answer: Many packets were lost to collisions.  Sometimes one channel would
see a collision, but the other channel would copy one of the packets.

Tests were run near the MUF and well below it.  It didn't seem to matter.

Question: Will the results be published?
Answer: Yes, in some ARRL publication or other.

Question: A local company, Dovetron, has done diversity work.  Your
results correlate with their claims.  This technique has been around a
long time for RTTY.
Answer: Yes, I did play with RTTY some.  It worked there as well.  Also
on AMTOR.  Not discarding entire packets gave better improvements, but
it required human intelligence to determine which receiver had the right
data.  With packet, that process is automated by the CRC.

Question: Could you explain how a strong signal could be worse than a
weak signal?
Answer: There are only two kinds of packets: perfect and useless.  Any
packet you can demodulate is good.
Comment: Assume a flat earth, and fixed ionosphere height, and raytrace
a few angles.  You'll quickly see the interference pattern, resulting in
areas with no signal, and areas with strong signal.

Question: Can you propose a model for a strong, bad signal?
Answer: Sure.  Two signals colliding makes a big signal.
Comment: Bit smearing by multipath can ruin a packet, too.
Answer: Another case is when the weaker signal is the one you want.

Tests were also performed on military signals that were strong and had
a clear channel.  Signals were still observed that could not be copied
even though they were loud.

Question: How did you perform the low baud rate tests?
Answer: With a cooperating connected station.

Question: At low baud rates, did you use a correspondingly narrow filter?
Answer: No, we used the same 500Hz filters for all speeds.

Question: Did you see frames with no detectable fading that you still
didn't copy?
Answer: Yes, and I can't really explain them.


=======================================
Phil Karn, KA9Q - NET/NOS status

Anders Klemets, SM0RGV, has evolved the simple mailbox is NOS into a
fullscale BBS.

The RSPF (Radio Shortest-Path-First) protocol has been added to NOS.
It's more stable than algorithms like the one NET/ROM uses when paths
go up and down.  Each node only keeps track of the routes to his neighbors.
The information is distributed by flooding, and each node is able to
compute a map of the network.  RSPF mirrors OSPF, an Internet protocol.

PPP, the Point-to-Point Protocol, has been implemented by Katy Stevens.
This serves as a replacement for SLIP (like KISS) on wired links.
She has also implemented TCP header compression, which replaces the usual
40 bytes of header overhead with 3 bytes.  This is especially interesting
when sending a lot of single-character packets, as when doing remote
keyboard echoing.  Anders has ported the compression to the AX.25 module,
but it's not as exciting there because of the AX.25 header and keyup delay
overhead.

Anders has implemented stream compression based on the LZW algorithm.
This scheme is transparent to applications.  It works reasonably well for
large file transfers, but isn't very useful for small files like mail
messages.

NOTE: A lot of work on NET/NOS has been done by others, but KA9Q gets
lots of gripes and questions about parts of the software he didn't write
and may never even have seen.  Please don't call him unless you're sure
it's his part of the code that's a problem.

He's been trying to get the code running with some faster modems.  He's
been running a 56kbps WA4DSY modem on 220 MHz for a long time, but the
host interface is a problem.  His HS driver uses a PC plug-in card with
a 8530 chip without DMA support.  Since the machine can't service an
interrupt per character, the HS driver has to sit in a spin loop while
receiving a packet.  This causes the machine to freeze up.  In the last
few months, two new cards have appeared that support DMA: the Ottawa
Packet Interface (PI) board, and the DMASYNC card by WA6FXT and N6XJJ.
The DMASYNC uses a WD1950 instead of an 8530, so it has only one channel.
Since there's only one DMA channel available in a PC anyway, that's no
big loss.

Question: Doesn't anybody make a card with a shared-memory interface?
Answer: The PackeTen is the only one, and it's pretty expensive.  Both
of these DMA-supporting cards are cheap.  You don't need a fast machine
to run NET as a gateway or switch.

Last year KA9Q described a collision avoidance algorithm, and he's still
working on that. He now has an idea to modify P-persistence dynamically.
The TNC would be slow to take the channel after hearing a packet that
needs to be acknowledged by someone else, and fast to take the channel to
acknowledge a packet for itself.  This might help mitigate the hidden
terminal problem.  It might also be useful to enhance the MHEARD feature
to keep track of hidden terminals, so as to try to avoid transmitting when
a hidden terminal is probably transmitting.

This kind of enhancement can even help on a point to point link, by
reducing the collisions between data frames and acknowledgement frames.
With the HS driver, back-to-back data frames had a short gap between them,
just long enough for the other station to jump in and collide with the
next data frame.

Question: What about your work with authentication schemes?
Answer: I'm working on several schemes.  Some are weak against an active
attacker, and some aren't.

Question: If we have a good system of authentication, there may be
problems with export restrictions.
Answer: My understanding is that authentication systems (unlike crypto
systems) are not a problem.  Control of export of authentication systems
has been transferred from the State Department to the Commerce Department.

KA9Q has implemented a scheme for transmitting passwords over the air.
The method is misnamed MINK, for Master InterNet Key.  It's based on the
idea of a one-way function: a mathematical function that is relatively
easy to compute, but whose inverse function is very difficult to compute.
The standard crypto system DES is an example of a one-way function.

Aside: Shamir (the S in "RSA") has found an attack that breaks many
simple variations of DES.  Under this attack, DES is exactly as difficult
to analyze as under the brute force approach.  If this attack is the best
possible, this shows that the choice of key-size (56 bits) was exactly
right.  If so, charges that the NSA reduced DES's key-size in order to
weaken its security are ill-founded.

MINK uses a one-way function called MD4.  MD4 produces a 128-bit output
from any size input.  The scheme is to take your (secret) key, and apply
MD4 to it many times, say N times.  Call this result F[N](x), where x is
your password.  Since the inverse of MD4 is hard to compute, it will be
hard to compute F[N-1](x) given only F[N](x).  So it's safe to transmit
F[N](x) over the air, provided that in the next session you use F[N-1](x),
and F[N-2](x) in the one after that, and so on.  Since MD4 itself is easy
to compute, the server you're logging into can easily verify that the
password you're using now, F[N-1](x), corresponds correctly to the one
you used last time, F[N](x), by simply computing F[1](F[N-1](x)).

This scheme is secure (to the extent MD4 is really hard to compute) against
passive eavesdroppers, who only try to learn your password by listening to
what you transmit.  It is not at all secure against an active attacker,
who may transmit messages of his own in an attempt to gain access to your
account.  Also note that the computer itself doesn't have your current
password; it only has your previous password.

MD4 is used instead of DES, which is probably much more secure, because
DES is too hard to compute in the forward direction.  Since MINK involves
computing many iterations of the crypto algorithm every time a new password
is needed, a difficult-to-compute function is impractical.

Question: Doesn't this assume that the users have local computers that
can compute the encrypted passwords?
Answer: Yes, that is a potential problem.  Perhaps the users could be
asked to have smart cards to compute passwords.  For the user who does
have a computer, he needn't worry about MINK at all.  The telnet program
he uses to log into the remote computer can easily respond to the MINK
password prompt automatically.

Question: If you have a password with many bits, don't you have a problem
with users mistyping a long numerical password?
Answer: A standard way around this problem is to use mnemonic words.
You assign a list of, say, 2048 standard common words.  Each word can then
be assigned a unique 6-bit number.  So if your password is 66 bits long,
you just have to remember (and type in) a sequence of 11 common words.

Question: Doesn't this system demand that you always log in from the
same place?
Answer: No.  The server computer maintains all the state information.
When you try to log in, it tells you what N it expects you to use.
For example, a login dialog might look like this:
login: karn
MINK 99 KA9Q1
Password:_
So you have N, and the input to the function.  You just run MD4 with your
secret key N times on the seed "KA9Q1" and type the result back to the
computer. If you're on a secure link instead of a radio link, you can
also type your regular (plaintext) password.

Also notice that if you don't trust the computer you're using to log in
from, you can't let it do the password computation for you.  That would
involve telling it your secret password.  The only secure alternative is
to carry your own password computer with you.  We use Atari Portfolios.

Question: Is MD4 available?
Answer: I will be releasing a package soon.

Question: What are the relative advantages and disadvantages of Unix
vs. DOS for a TCP/IP server?
Answer: The most important thing is to get a recent version of TCP/IP
with the Van Jacobson enhancements.  I recommend that the best way to
put a Unix box on the air is to use a dumb PC as an ethernet to radio
TCP/IP gateway.  The gateway PC can handle your dialup link to work, too.

Question: Can't I just connect a TNC to a TTY port?
Answer: Yes, you can, but that only handles one interactive user.  With
a TCP/IP port you can support more users and get more functionality.
With BSD Unix for the '386 coming out, the art of hacking TCP/IP support
into Unix will become obsolete.  Besides, putting NOS into Unix or even
putting all sorts of features into NOS is counter to the original spirit
of NOS: to introduce TCP/IP to amateur radio, for cheap.

Question: What flavors does NET/NOS come in, and where can we get them?
Answer: If you have Internet access, ftp to thumper.bellcore.com
([128.96.41.1]) and log in with username anonymous and password your name.
Look in /pub/ka9q; there are different subdirectories for different
versions.  If you wish to contribute something, put it in
/pub/ka9q/incoming.  I can't handle any other distribution mechanism.
The code is also available on several dialup BBS systems.

Question: What about the TAPR library?
N3EUA: I have given up on packaging the KA9Q code for releases.  It was
just too time-consuming.  We've been at this project for 5 years!

Question: What are the difficulties of configuration control?  What
works and what doesn't for a widely-distributed group effort like NOS?
Answer: Everything works fine if people are working in separate areas.
For instance, Anders work on the mailbox code was easily integrated back
into the standard release.  If two people are working on the same module,
there's a problem.  In a volunteer project, you can't use someone's
promise to do a task as a locking mechanism.  For example, two different
people fixed the domain name system simultaneously, and now I have to
choose one and snub the other.
N3EUA: the 890421 release of NET was a big integration problem, with many
different sets of conflicting changes.  One developer made wholesale
changes (some of which were unnecessary), and that code is still a
separate branch that will probably never be integrated.

=======================
Ron Bates, AG7H, works at NRAO with the radio telescopes on Kitt Peak.
He invited interested parties to go on a tour of the telescopes after the
meeting.  Provided the road isn't blocked by a rockslide!

Lyle Johnson, WA7GXD, thanked everyone for coming to the meeting.
See you next year!