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

Text File | 1993-12-31 | 86.8 KB | 1,833 lines

1-Aug-87 16:42:00-EDT,1259;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 1 Aug 87 16:42-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 1 Aug 87 15:15:36 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 1 Aug 87 15:15:20 EDT
Received: by june.cs.washington.edu (5.52.1/6.5)
    id AA12943; Sat, 1 Aug 87 12:16:43 PDT
Return-Path: <crash!gryphon![e-mail]>
Message-Id: <[e-mail]>
Date: 31 Jul 87 13:48:53 GMT
From: crash!gryphon![e-mail] (Dave Dodell)
To: [e-mail]
Subject: W0RLI BBS

I would like to upgrade my packet BBS from running WA7MBL software to the
newer versions of the W0RLI software.  I understand that we are up to
version 3.3 or so.

Can anyone suggest a landline source to download the software from that is
updated with each new release?

Thanks
David Dodell WB7TPY @ WB7TPY

--
uucp: {ihnp4, hplabs!hp-sdd, cbosgd} !crash!gryphon!ddodell
uucp: {seismo!scgvaxd, philabs} !cadovax!gryphon!ddodell
Bitnet: ARDSD @ ASUACAD   FidoNet : 114/15  Internet: [e-mail]
MCI Mail: DODELL          Telex II (TWX): 910-380-5182 (Dodell Phoenix AZ)


 1-Aug-87 16:58:04-EDT,1259;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 1 Aug 87 16:58-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 1 Aug 87 15:15:36 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 1 Aug 87 15:15:20 EDT
Received: by june.cs.washington.edu (5.52.1/6.5)
    id AA12943; Sat, 1 Aug 87 12:16:43 PDT
Return-Path: <crash!gryphon![e-mail]>
Message-Id: <[e-mail]>
Date: 31 Jul 87 13:48:53 GMT
From: crash!gryphon![e-mail] (Dave Dodell)
To: [e-mail]
Subject: W0RLI BBS

I would like to upgrade my packet BBS from running WA7MBL software to the
newer versions of the W0RLI software.  I understand that we are up to
version 3.3 or so.

Can anyone suggest a landline source to download the software from that is
updated with each new release?

Thanks
David Dodell WB7TPY @ WB7TPY

--
uucp: {ihnp4, hplabs!hp-sdd, cbosgd} !crash!gryphon!ddodell
uucp: {seismo!scgvaxd, philabs} !cadovax!gryphon!ddodell
Bitnet: ARDSD @ ASUACAD   FidoNet : 114/15  Internet: [e-mail]
MCI Mail: DODELL          Telex II (TWX): 910-380-5182 (Dodell Phoenix AZ)


 4-Aug-87 22:25:53-EDT,1138;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 Aug 87 22:25-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 4 Aug 87 20:40:36 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 4 Aug 87 20:40:21 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA09748; Tue, 4 Aug 87 17:41:49 PDT
Return-Path: <ihnp4!inuxc!iuvax!pur-ee![e-mail]>
Message-Id: <[e-mail]>
Date: 4 Aug 87 14:40:22 GMT
From: ihnp4!inuxc!iuvax!pur-ee![e-mail] (Henry R Frohne)
From: [e-mail]
Subject: BBS Software
Apparently-To: [e-mail]

Does anyone know of bullitin board software for the Apple II computers?
I would prefer to find public domain software, but would like to hear
of anything that is available.  I would like to get a BBS system going
on my ham radio.

If I get a good response I will be glad to summarize for the net.

Thanks in advance for the help!

                Rob Frohne (KL7NA/W9)
                UUCP address: ihnp4!pur-ee!frohne


 4-Aug-87 22:47:44-EDT,1138;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 Aug 87 22:47-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 4 Aug 87 20:40:36 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Tue, 4 Aug 87 20:40:21 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA09748; Tue, 4 Aug 87 17:41:49 PDT
Return-Path: <ihnp4!inuxc!iuvax!pur-ee![e-mail]>
Message-Id: <[e-mail]>
Date: 4 Aug 87 14:40:22 GMT
From: ihnp4!inuxc!iuvax!pur-ee![e-mail] (Henry R Frohne)
From: [e-mail]
Subject: BBS Software
Apparently-To: [e-mail]

Does anyone know of bullitin board software for the Apple II computers?
I would prefer to find public domain software, but would like to hear
of anything that is available.  I would like to get a BBS system going
on my ham radio.

If I get a good response I will be glad to summarize for the net.

Thanks in advance for the help!

                Rob Frohne (KL7NA/W9)
                UUCP address: ihnp4!pur-ee!frohne


 7-Aug-87 12:18:33-EDT,954;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Aug 87 12:18-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 7 Aug 87 10:59:02 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 7 Aug 87 10:58:40 EDT
Resent-Message-Id: <[e-mail]>
Date: Wednesday, 5 August 1987  04:52-MDT
Message-Id: <[e-mail]>
Sender: [e-mail]
From: [e-mail]
To: [e-mail]
Subject:   Xerox 820-II Packet Software
Resent-From: [e-mail]
Resent-To: [e-mail]
Resent-Date: Fri 7 Aug 1987 08:59-MDT

I have a pal who has recent accquired a Xerox 820-II computer. He would
like to know what (and where from!) is available in the way of Packet
Radio software for this beast.

Any suggestions ?


Thanks     -     Iain
10-Aug-87 13:43:14-EDT,3117;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Aug 87 13:43-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 10 Aug 87 12:17:01 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 10 Aug 87 12:16:06 EDT
Message-Id: <[e-mail]>
Received: from amc1 by AMC-HQ.ARPA id aa03724; 10 Aug 87 12:08 EDT
Date:     Mon, 10 Aug 87 11:05:17 EDT
From: "D. H. Bennett, AMCRM-FTM"  <dbennett@amc1>
To: packet-radio%eddie.mit.edu@amc-hq
Subject:  Recap of USA-PKT.08A

       Recap of USA-PKT.08A
       As of  9 August 1987
         by K4NGC

The  following is a computed recap
of  the USA-PKT file I maitain. It
shows   the  number  and  type  of
activities  by  state.  As soon as
I  write  the  program I will have
one  by  frequencies also.  If you
have   any    changes    to    the
USA-PKT.08A  files  please address
them to K4NGC @ K4NGC.

State            PBBS  DIGI  TOTAL
---------------- ----  ----  -----
Alabama             8    21    29
Alaska              6    13    19
Arizona            32    14    46
Arkansas            8     1     9
California         89    91   180
Colorado           26    48    74
Connecticut        11     9    20
Delaware            0     3     3
Dist of Columbia    0     2     2
Florida            66    57   123
Georgia            25    21    46
Guam                0     0     0
Hawaii              7     3    10
Idaho               2     4     6
Illinois           19    18    37
Indiana            31    17    48
Iowa               14    23    37
Kansas              6     6    12
Kentucky           11     9    20
Louisiana          11     4    15
Maine              11     1    12
Maryland           37    21    58
Massachusetts      29    18    47
Michigan           22     5    27
Minnesota          10     7    17
Mississippi        10     3    13
Missouri           11    36    47
Montana             1     0     1
Nebraska            1     0     1
Nevada              1     9    10
New Hampshire      10     3    13
New Jersey         49    20    69
New Mexico         12     6    18
New York           66    42   108
North Carolina     15    11    26
North Dakota        6     0     6
Ohio               31    17    48
Oklahoma            6     3     9
Oregon              5     6    11
Pennsylvania       41    41    82
Puerto Rico         0     0     0
Rhode Island        3     2     5
South Carolina      5     8    13
South Dakota        3     1     4
Tennessee          15    16    31
Texas              28    14    42
Utah                9    22    31
Vermont             1     2     3
Virginia           18    35    53
Virgin Islands      0     0     0
Washington         15    14    29
West Virginia       4    11    15
Wisconsin          19    15    34
Wyoming             5     8    13
         ----  ----  ----
Total             878   778  1656

The USA-PKT.08A is available on
CompuServe to all who want it. Its
in Text and DBase formats.

14-Aug-87 16:23:18-EDT,1097;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 Aug 87 16:23-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 14 Aug 87 14:26:16 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 14 Aug 87 14:26:05 EDT
Message-Id: <[e-mail]>
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 08/14/87 at
  14:29:30 EDT
Received: from NEUVM1.BITNET by MITVMA.MIT.EDU (Mailer X1.24) with
  BSMTP id
 7293; Fri, 14 Aug 87 14:29:25 EDT
Received: by NEUVM1 (Mailer X1.24) id 3967; Fri, 14 Aug 87 19:21:38 DNT
Date:         Fri, 14 Aug 87 19:15:36 DNT
From: Tage Madsen  <[e-mail]>
Subject:      HAPN-1
To: [e-mail]

HI GUYS
Does any of you know a packet-radio board named HAPN-1, and best of all
tryed one,then i will be very happy to here your oppinion.
All other hints and suggestions are very much appriciated.

Thanks in advance.          Kind regards from Copenhagen

                   Tage       OZ8TW
15-Aug-87 16:51:54-EDT,2867;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Aug 87 16:51-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 15 Aug 87 13:45:00 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 15 Aug 87 13:44:45 EDT
Date: Sat, 15 Aug 1987  11:42 MDT
Message-Id: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: SIMTEL20 archive server
In-Reply-To: Msg of Fri 14 Aug 87 14:10:53 MEZ from C0030006%DBSTU1.BITNET at CNUCE-VM.ARPA

The SIMTEL20 netmail archive server is no longer available.  SIMTEL20
is still accessable via standard anonymous FTP by Arpanet and Milnet
users.

The message below explains.

--Keith Petersen

--forwarded message--
Date: Friday, 26 June 1987  08:58-MDT
From: Frank J. Wancho <WANCHO at SIMTEL20.ARPA>
To:   INFO-CPM, INFO-MICRO at BRL.ARPA, INFO-IBMPC at C.ISI.EDU
cc:   INFO-HZ100 at RADC-TOPS20.ARPA, INFO-HAMS, ADA-SW, UNIX-SW,
      INFO-APPLE at BRL.ARPA, INFO-MAC at SUMEX-AIM.STANFORD.EDU
Re:   Archive Server Shutdown

Several changes to the Archive Server have been made in the past few
weeks to improve service for replies sent through intermediate hosts.
One of the requested changes was to reduce the size of the messages by
half so that these messages don't hog the single-stream mail
channels, particularly on BITNET, for extended periods of time, and
thus give other mail a chance to get through in a timely manner.

Unfortunately, this has resulted in the SIMTEL20 mail queue to rapidly
grow way beyond all expectations: the Server was now generating twice
as many messages and our dedicated mailer for this service now had to
establish twice as many connections for the same number of replies.
That mailer could not keep up with the the queue, and for the second
time in as many weeks, we have had to shutdown the Server because we
were running out of disk space.

Because the disk space is at a premium for our regular users, and
because the resources required by both the Server and the mailer have
now reached a point well beyond the capabilities of our present system
configuration, the Server has been shut down until further notice and
for an indefinite period of time.  New requests will be returned
unanswered, and both present requests and replies will be flushed.

In the meantime, we are examining other possibilities to provide
access to our collections.  Because the great majority of requests
have come from BITNET users, we are looking for one or more BITNET
hosts willing to provide the disk space and BITSERV facilities for one
or more of our collections of public domain software.

--Frank
19-Aug-87 17:35:23-EDT,1886;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Aug 87 17:35-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 19 Aug 87 15:03:58 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 19 Aug 87 15:03:48 EDT
Message-Id: <[e-mail]>
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 08/19/87 at
  15:06:19 EDT
Received: from NDSUVM1.BITNET by MITVMA.MIT.EDU (Mailer X1.24) with
  BSMTP id
 1695; Wed, 19 Aug 87 15:06:13 EDT
Received: by NDSUVM1 (Mailer X1.24) id 5577; Wed, 19 Aug 87 14:04:35 CDT
Date:         Wed, 19 Aug 1987 13:16 CDT
From: Todd Enders WD0BCI
  <[e-mail]>
Subject:      Questions from a newcommer
To: <[e-mail]>


Greetings!

     I have decided to get on packet radio, but I have a few questions.
First, which TNC is *best*?  Most users in my area use either the Kantronics
or MFJ TNC's.  Personally, I am looking at the AEA PKT-232, but am open to
suggestion.

     Second, just what is NETROM (I know it is a modification to the ROM
code in the TNC) and what makes it better than the TAPR TNC code?  I asked
a few of the local *experts* but they really didn't seem to know WHY it
is better, just that it is better.

     Third, what about network and transport layer software?  I hear good
things about TCP/IP (from following along with the group here) but how
does one get the software, and are the hooks there to get it running with
a TNC?  Not that that bothers me, I could probably patch it in.

     Many thanks for any and all answers in advance!!!!

73 de WD0BCI

Todd Enders       |  BITNET: MN007334@NDSUVM1
Minot State U.    |  ARPA: [e-mail]
Minot, ND 58701   |  UUCP: ...!ihnp4!psuvax1!ndsuvm1.bitnet!mn007334
20-Aug-87 15:22:30-EDT,2990;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 20 Aug 87 15:22-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 20 Aug 87 13:32:46 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 20 Aug 87 13:32:31 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA27253; Thu, 20 Aug 87 10:33:53 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 20 Aug 87 07:19:31 GMT
From: bellcore!faline![e-mail]  (Phil R. Karn)
To: [e-mail]
Subject: Re: John Gilmore switches feet!
Summary: 56kbps *is* legal in the US
References: <[e-mail]>

I will have lots more to say about the Public Digital Radio Service vs ham
radio stuff that has been going on in comp.dcom.modems and is now spilling
over into rec.ham-radio.packet, but I wanted to correct one misconception
quickly:

There is absolutely nothing illegal about running 56kbps amateur packet
radio in the United States. At least I *hope* not, I have two beta-test
units designed by WA4DSY in the final stages of construction here, and a
number of other units are already on the air in the Atlanta area.

When in doubt, check the FCC rules. 97.69 gives you two options for running
digital communications:

1. Conventional Baudot, ASCII or AMTOR "RTTY-style" operations at speeds up
to 300 baud below 28 Mhz, up to 1200 baud between 28 and 50 Mhz, 19600 [sic]
baud between 50 and 220 Mhz, and 56kbps above 220 Mhz.  You can do this
either domestically or internationally.

-OR-

2. For domestic communications ONLY, you can run ANY digital code and
modulation method you want, as long as it's intended to facilitate
communication rather than to hide it from others.  In order to encourage the
development of bandwidth-efficient modems, under this option you are
restricted by bandwidth rather than signalling speed,  The limits are: 20
Khz between 50 and 220 Mhz, 100 Khz between 220 and 902 Mhz, and UNLIMITED
above 902 Mhz (assuming you stay within the band, of course). If you can
make a megabit modem that operates in only 20 Khz of bandwidth, it is
entirely legal to run it on 2 meters (although I'd suggest you talk to your
patent attorney first). You are also allowed to run spread spectrum (with
one of several standard linear polynomials) above 420 Mhz.

Once again, for US domestic digital communications you can do ANYTHING you
want above 50 Mhz within the bandwidth (not signalling rate) limits. So
basically there are NO arbitrary FCC limits on the technology we hams can
use on the air, as long as it meets the bandwidth limits and you operate it
according to the rest of the rules.

I suppose a Canadian can be excused for not being familiar with American
rules, but a licensed American ham who expresses strong interest in the
development of digital radio is another story...

Phil


20-Aug-87 17:15:17-EDT,1713;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 20 Aug 87 17:15-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 20 Aug 87 13:29:37 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 20 Aug 87 13:29:17 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA27186; Thu, 20 Aug 87 10:30:42 PDT
Return-Path: <ll-xn!ames!lll-tis!lll-lcc!well![e-mail]>
Message-Id: <[e-mail]>
Date: 20 Aug 87 07:49:03 GMT
From: ll-xn!ames!lll-tis!lll-lcc!well![e-mail] (Glenn S. Tenney)
To: [e-mail]
Subject: Questions: where do I find out...
Keywords: new-user

Ok, I got my ticket in the mail at noon on Monday and by 5pm I owned
an MFJ 1270B.  Not the best unit, but it'll get me started (just 2m
for now).  I've had one QSO and connected to some digipeters (I think
they were?).

The mfj manual is a joke.  I've skimmed thru "Get Connected".  The
problem is, neither one tells me things I want to know.  "Connected"
seems to be written for a person that just wants to know what it is,
while the manual wasn't written for humans.

Now, where do I find out the real poop.  The digipeters I connected to
say something about "NET/ROM" and only seem to allow these commands:
CONNECT, NODES, IDENT and USERS.  What is this thing?  What other
commands are there?  How do you disconnect from some node "n" levels
down?  How do I find out where node "x" is?  Where can I get lots of
documentation on these units?  How do I find people on packet?

As you can see, I'm just full of questions.  Any help for a newcomer?

Glenn Tenney


20-Aug-87 21:39:39-EDT,12358;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 20 Aug 87 21:39-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 20 Aug 87 15:49:04 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 20 Aug 87 15:48:05 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA00850; Thu, 20 Aug 87 12:49:09 PDT
Return-Path: <ihnp4!alberta!ers![e-mail]>
Message-Id: <[e-mail]>
Date: 19 Aug 87 19:21:06 GMT
From: ihnp4!alberta!ers![e-mail] (Lyndon Nerenberg)
To: [e-mail]
Subject: John Gilmore switches feet!

The following quotes are courtesy John Gilmore ([e-mail])
>from an article in comp.dcom.modems:

>As a 15-year computerist who got a ham license to experiment with
>packet radio, let me comment.  The ham fraternity is seriously
>reactionary.  Hams work hard to keep others out, so there will be more
>frequency spectrum for them to use, and they actively spy upon and
>report (to the Feds) violations of the mickey-mouse rules they operate
>under.  Everything you do is under control of government regulations
>which take years to update, and the army of reactionary spies makes it
>hard to operate outside the rules.

The ham fraternity is anything BUT reactionary. Nuclear war wouldn't
wake half of them up!
Perhaps hams in the US have the attitude that "it's mine, go play
in your own sandbox." This does not seem to prevail outside of the
US. Perhaps that's why the FCC has the wisdom to start the US phone
bands above the international allocations...
Perhaps you consider federal legislation "mickey mouse." The rest
of the world (for the most part) does not (thank God). Of course
in California murder is also a "mickey mouse" law ("don't change lanes
so close to me a**hole or I'll blow your brains out!").
I hate to make you face reality John, but most things in life are
under control of gov't regulations. It's a good thing there are
"reactionary spies" to keep people operating within the rules. If the
FCC is faced with having to enforce the regs in the ham bands, there
won't be hams bands in very short order (in the US anyway... hey, that's
not a bad idea).

>In contrast, the computer fraternity is seriously radical.  New ideas
>and new people are welcomed.  Experimentation is encouraged.  If you
>get a good idea and you do it, people are free to do things the old way
>or do it your new way.  You don't need to ask the FCC whether you can
>plug a better printer or piece of software into your computer, or whether
>you are permitted double the speed of your machine.  If you can afford
>to buy it or have enough imagination to create it, you can use it.

The only time you need to ask the FCC about hooking up a piece of
equipment is when the act of "hooking it up" might effect another
persons ability to use whatever it is you are hooking up to. If you
wire your printer cable wrong, you will zap your own computer - not
someone elses. If you wire your phone wrong you could impact all
the users on your exchange. If you transmit spurs and/or harmonics
you are going to bother a lot of non-hams. The regulations are in
place to ensure that these other users have some recourse in the
event you interfere with them.

>I was interested in packet radio as a vehicle for carrying data for
>computer users.  While at least 4 or 5 people in the Pacific Packet Radio
>Society (the local ham digital-radio group) agreed, the rest of the
>hams were solidly against the idea of computer users being able to just
>send their data through the ether without going through all the hassle that
>THEY had had to go through.  They wanted to use their new, experimental
>packet radios for the same old shit -- ragchewing (ham-ese for shooting
>the bull over the radio).

Sounds like you want to become a common carrier. If you think getting
a ham license is so damn difficult, then you should get a license to
become a common carrier. I would be interested in talking to you
about the application process when you're done (you should be finished
in about 1990). The cost of the application should not be a problem.
As you indicated above, the nice thing about the computing hobby is
that you can buy anything if you have the money. C'mon John, let's
see you finance a country wide packet network.

>What hams knew, or wanted to know, about computer networking in 1982
>would fill a thimble, maybe.  There are a few people like Phil Karn who
>span both computer networking and ham radio, but the rest were
>basically ignorant.  Their "networking" consisted of passing 10-word
>messages from one person to another, by voice or Morse code, down a
>line of humans, on a fixed nightly schedule.  This was (is) mostly done
>by people who have nothing better to do than read other
>peoples' messages over the air.  This has nothing to do with
>computer networking, though these people have finally realized that
>they can automate the processing if they can ever get their packet
>radios to work reliably enough.  So now they want a few computer people
>to come in and fix 'em up so they can do their same old same-old,
>without, of course, letting many new computer users in to crowd the radio
>spectrum.
>
>[They claim to be practicing for providing emergency communications
>service.  However, if the public was permitted to use the airwaves for
>REGULAR communications service, then no EMERGENCY service would be
>needed, since the regular service would continue to work in
>emergencies.  E.g. the cops don't rely on hams, they have their own
>radios for regular and emergency use.]

As you may be aware, those of us in Edmonton had the misfortune of
experiencing a rather nasty tornado a couple of weeks back. It hit
at roughly 1507, and had passed over the city by 1530. At that time
I was doing work for one of our clients (Alberta Public Safety Services -
the Provincial gov't organization that handles peacetime disasters).
By 1600 I had activated the amateur station at APSS (VE6ACD) and was
putting together a list of hams and equipment available to help
with communications. At 1700 we received a request from the City
of Edmonton police dep't to assist them with communications in two
of the hardest hit areas. By midnight we had dispatched over 40
amateurs to these sites to assist in locating victims buried in
collapsed buildings, and provide logistical communications support
for the people bringing in food and medical supplies. It is very
obvious that in a disaster of this magnitude no single emergency
service has the ability to handle the volume of traffic generated.
These amateurs continued to assistthe police at the Evergreen
trailer park until late Sunday afternoon.

In addition to the above activities, we set up an emergency station
at the Red Cross offices, and handled over 2000 messages in a 48 hour
period from people around the world trying to find out the status
of freinds and relatives in the disaster area. Part of this traffic
was carried via HF packet links (at a dastardly slow 1200 baud - sorry).

I operated a total of almost 72 hours over that weekend. I don't
recall hearing you volunteer to handle any traffic to the US.

>That's funny, the hams who are currently doing packet radio are doing
>it at 1200 baud.  It's in fact illegal to go faster than 9600 baud over
>ham radio in the United States.  Ham packet radio was started in
>Canada, where the government didn't get nearly as much in the way.
>It took an immense amount of work in the US just to get the use of ASCII
>legalized over the air -- before that, it was Morse or Baudot or
>nothing.  56Kbit modems are a research project at a few places, like
>Linkoping University in Sweden; Stanford; and at Tucson Amateur Packet
>Radio.

When will the American people realise that their problems are NOT the
rest of the worlds problems? The amatuer services is an experimental
service - if you present a reasonable case to the FCC, you should
be able to obtain a waiver for 56KB operation under the existing
regs. Of course this assumes you're going to do something with it
besides spouting more hot air...
Not *all* hams run 1200 baud. We are currently building a network
through the province running on a 56 KB backbone with fanout at
9600 baud. The Calgary hub will be tied to a network in Ottawa
via a 9600 baud satellite link. I believe similar networks are
*already* operational in the US.

>>                         Mr. Decker suggested extending range by using
>> digital repeaters. Hams have found that in practice using more than two such
>> links in a row tends to bog down, although the newer NETROM modification to
>> the conventional TAPR TNC software seems to be a big help in linking.
>
>As explained above, the ham fraternity knows nothing about networking.
>This is why they are using very lossy links, but with protocols where
>acknowledgement and retransmission only happens end-to-end.  This data
>is being relayed at a maximum of 1200 baud -- HALF DUPLEX -- between
>each relay point.  If you connect directly (no repeaters), you might
>get 1000 baud since you have to turn the line around once in a while
>for acknowledgements.  If you use one repeater, divide by more than 2,
>since each packet has to go to the repeater, then, from the repater to
>the destination.  (Each of these hops involves a delay of up to .3
>seconds while switching from receive to transmit, depending on the
>quality of the radio.)  Just going through one repeater, you drop under
>300 baud; two repeaters gets you say 100 baud, or 10 cps.  That is,
>when all the data gets through error-free.  No wonder it "bogs down" on
>more then two links!

Well John, CP/M and Apple DOS 3.x are pretty crude too. I wonder why
the people using these systems are not burning them and running out
to buy the latest, greatest Sun workstations? Could it be that they
are content with what they have? It's funny, but as I look out the
window I see a lot of four and six cylinder cars driving around, but
very few dragsters. Oh well, that's government regulations for ya...

>>                                    I am saying only that computer hobbyists
>> should not reject the option of pursuing ham radio as a medium for radio
>> modeming solely on the basis of erroneous statements made by someone who
>> obviously doesn't know whereof he speaks.
>
>How about rejecting the option on the basis of MY statements, made by
>someone who DOES know whereof he speaks.  I tried it.  I still have my
          :-)

>ham license (KB6DQC, technician's).  I'm gone though.  I'm building
>free software rather than building packet radio networks, because there
>is no government actively standing in the way of building and using
>free software.

Great! You're saving the world! Care to explain why TWO MONTHS after
I sent in my PRE-PAID order for the Gnu distribution tape I still
haven't received it? It took FOUR phone calls to the FSF answering
machine to get someone to call back. This despite the fact that I included
with the order a phone number and email addresses that I could be reached
at in the the event of a delay. I was informed that the FSF had
run out of tapes, but that new tapes were now in and that my tape
would be shipped via special delivery mail that day. That was TWO
WEEKS ago and I still don't have the damn tape! Maybe you should start
a FREE BUSINESS SCHOOL and enroll everyone from the FSF. And no, I don't
give a damn that it's FREE software. You took $200 of my money so you
bloody well better show me something for it!

>               I figure about 20 years' worth of old hams will have to
>die before it becomes possible to do anything interesting with the
>amateur spectrum space.  I'd be glad if somebody would prove me wrong.

The world owes you a living? If you don't like it, why don't you
DO SOMETHING ABOUT IT?

>{dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu          [e-mail]
>My name's in the header where it belongs.

Any your foot is in your mouth...

Lyndon Nerenberg  VE6BBM
alberta!ncc!lyndon  pyramid!ncc!lyndon  winfree!ncc!lyndon


21-Aug-87 01:43:23-EDT,1712;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Aug 87 01:43-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 21 Aug 87 00:13:05 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 21 Aug 87 00:12:50 EDT
Message-Id: <[e-mail]>
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 08/21/87 at
  00:15:21 EDT
Received: from NDSUVM1.BITNET by MITVMA.MIT.EDU (Mailer X1.24) with
  BSMTP id
 6471; Fri, 21 Aug 87 00:15:09 EDT
Received: by NDSUVM1 (Mailer X1.24) id 5155; Thu, 20 Aug 87 23:15:16 CDT
Date:         Thu, 20 Aug 1987 22:41 CDT
From: Todd Enders WD0BCI
  <[e-mail]>
Subject:      Re: John Gilmore switches feet!
To: <[e-mail]>
In-Reply-To:  Your message of 19 Aug 87 19:21:06 GMT


     I think Lyndon hit the nail squarely on the head!  As far as Mr.
Gilmore goes, I think you are forgetting who developed packet radio in the
first place!  And what about Amateur Satellites?  I don't see computer
hobyists building satellites to pass data through.  Further, Amateurs were
building (and are still building) extremely effective and innovative
comsats for far less than anyone thought possible.  There are many so
called *radicals* in amateur radio, but most of them are too busy building
new and innovative equipment to spend much time on the air!  There is
substantially more to ham radio than ragchewing, just ask some of the
people ACTIVELY involved in packet radio networking, Amateur Satellites,
or spread spectrum.

     If you still want out of amateur radio, John..... Bye, bye!

73 de WD0BCI
21-Aug-87 14:19:43-EDT,4753;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Aug 87 14:19-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 21 Aug 87 12:09:49 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 21 Aug 87 12:09:33 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA10410; Fri, 21 Aug 87 09:11:01 PDT
Return-Path: <bellcore!faline![e-mail]>
Message-Id: <[e-mail]>
Date: 21 Aug 87 06:47:36 GMT
From: bellcore!faline![e-mail] (Phil R. Karn)
To: [e-mail]
Subject: Re: John Gilmore switches feet!
Summary: Hams did NOT invent packet radio
References: <[e-mail]>

> ... I think you are forgetting who developed packet radio in the
> first place! ...

Just in case anyone is tempted to conclude from the context of this
statement that hams developed packet radio in the first place, I must point
out that this is not the case.  Credit for the first packet radio network
belongs with the ARPA-sponsored ALOHANET experiment at the University of
Hawaii, begun in 1970.  Much of the foundation theory of multiple-access
contention based networks was inspired by this project.

It was not until almost ten years later that the Canadian amateur groups
started with the "Vancouver board", a small-scale, purely experimental
development.  Many of the design choices made by the Vancouver group became
de-facto standards due to their adoption by the Tucson Amateur Packet Radio
(TAPR) group in the early 1980s.  Unfortunately, many of these choices (the
"TNC plus dumb terminal" model, the use of HDLC even for slow speed links,
X.25-inspired connection-oriented protocols, etc) were either suboptimal or
are now no longer appropriate given advances in both hardware and software
technology. Some, like the use of 1200 baud Bell 202 modems, were recognized
even at the time by the Vancouver group as already obsolete, and were
adopted supposedly only as stopgap measures. We've still got them almost a
decade later.

And this is the heart of the problem with amateur packet radio today.  The
majority of hams are not really interested in trying something new and
experimental with the hope of pushing the state of the art; they just want
to buy something off the shelf, plug it in, and chat with their buddies
across town. It's hard to get them interested in something new unless their
friends already have it and they're worried about being "left behind."

Occasionally there is even active opposition to new and novel things. I
chuckled the first time I heard somebody complain about all the "garbage
characters and bells" that were "messing up his printer" when he monitored
TCP/IP traffic. After all, the packets weren't addressed to him so I don't
see how his complaint was justified.  Now this sort of thing is so common
it's no longer funny.  And now NET/ROM gets flamed for the same reason.

I hardly expect every ham to turn into a hardware or software hacker
overnight. After all, diversity is one of amateur radio's main strengths.
Besides nifty new technology, we need lots of imaginative and dedicated user
types to find useful applications for it, like public service and disaster
communications.  *This* is the sort of thing that really "pays the bills"
when it comes to keeping our frequencies.  At the same time, the users need
to actively support and encourage the tekkies.  Much more thought should be
given to long range planning, instead of worrying solely about things like
where you'll put up your new digipeater.

The unique thing that amateur radio *has* done with packet radio was to make
it inexpensive and widely available, if not exactly state-of-the-art.  Sad
to say, in many ways this has made amateur packet radio grow far too fast
for its own good.  Those who advocate a separate "public digital radio
service" should first study and learn from amateur packet radio's
experiences.  Yes, we do have some inexcusably outmoded licensing
requirements. We have an awful lot of conservative (perhaps even
reactionary) intertia. But don't assume you won't run into other, perhaps
more serious problems we hams haven't encountered. After all, you're
proposing something that would probably be orders of magnitude larger than
what we hams have done, and the average user would be even more of an
"appliance operator" than the average ham.  If you don't like paying UPS to
ship your packages, fine; you are certainly entitled to start your own
shipping company. It can even be a non-profit cooperative if you like.  But
don't complain because everybody has to learn how to drive a truck.

Phil


21-Aug-87 16:34:18-EDT,2353;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Aug 87 16:34-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 21 Aug 87 12:43:35 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 21 Aug 87 12:43:19 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA10542; Fri, 21 Aug 87 09:16:35 PDT
Return-Path: <husc6!sri-unix![e-mail]>
Message-Id: <[e-mail]>
Date: 21 Aug 87 02:00:43 GMT
From: husc6!sri-unix![e-mail] (Alan Larson)
To: [e-mail]
Subject: Re: Questions: where do I find out...
References: <[e-mail]>

In article <[e-mail]>, [e-mail] (Glenn S. Tenney) writes:
> Now, where do I find out the real poop.  The digipeters I connected to
> say something about "NET/ROM" and only seem to allow these commands:
> CONNECT, NODES, IDENT and USERS.  What is this thing?  What other commands
> are there?  How do you disconnect from some node "n" levels down?  How do I
> find out where node "x" is?  Where can I get lots of documentation on these
> units?  How do I find people on packet?

NET/ROM is an attempt at a higher level backbone system, where several
useful items got omitted.  (end user manual/support, operational support
of the network, etc.)

There is also a PARMS command, that will print out some statistics that
appear useless to me.

You don't disconnect from a node levels down.  You drop the whole
connection.  (Either end can initiate the disconnect.)  This is not
so much of a problem, since when net/rom networks are working, you
only connect to the local one, and have it connect to the most distant
one.  You don't have to know about the ones in the middle.

Where is node 'x' ?   Well there are lists occasionally on some of the
packet bboards.  They are rarely complete.

You probably have to buy one to get the manual.  There is little general
user documentation.

There is no provision in net/rom to find people at the other end.
Locally, you could monitor (just like listening on 'radio'), and
call (connect) when they finish their current connection.

Packet is nice for reading bulletins on the local packet bboards.
If you have over a 1200 baud modem, usenet is faster.

    Alan


21-Aug-87 17:14:23-EDT,1088;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Aug 87 17:14-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 21 Aug 87 15:53:46 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 21 Aug 87 15:52:03 EDT
Received: from phun.riacs.edu by icarus.riacs.edu (5.54/2.0G)
       id AA00203; Fri, 21 Aug 87 12:50:31 PDT
Received: from localhost by phun.riacs.edu (3.2/2.0N)
       id AA06167; Fri, 21 Aug 87 12:50:26 PDT
Message-Id: <[e-mail]>
To: bellcore!faline![e-mail] (Phil R. Karn)
Cc: [e-mail]
Subject: Re: John Gilmore switches feet!
In-Reply-To: Your message of 21 Aug 87 06:47:36 +0000.
         <[e-mail]>
Date: Fri, 21 Aug 87 12:50:18 -0700
From: [e-mail]

See PRoceedings, IEEE, January 1987, Special Issue on PRnets, for much
info on past and current research activities related to PRnet.  Sorry to
say nothing on amateur and commercial, for which I apologize.
----------
21-Aug-87 17:55:05-EDT,1088;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Aug 87 17:55-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 21 Aug 87 15:53:46 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 21 Aug 87 15:52:03 EDT
Received: from phun.riacs.edu by icarus.riacs.edu (5.54/2.0G)
       id AA00203; Fri, 21 Aug 87 12:50:31 PDT
Received: from localhost by phun.riacs.edu (3.2/2.0N)
       id AA06167; Fri, 21 Aug 87 12:50:26 PDT
Message-Id: <[e-mail]>
To: bellcore!faline![e-mail] (Phil R. Karn)
Cc: [e-mail]
Subject: Re: John Gilmore switches feet!
In-Reply-To: Your message of 21 Aug 87 06:47:36 +0000.
         <[e-mail]>
Date: Fri, 21 Aug 87 12:50:18 -0700
From: [e-mail]

See PRoceedings, IEEE, January 1987, Special Issue on PRnets, for much
info on past and current research activities related to PRnet.  Sorry to
say nothing on amateur and commercial, for which I apologize.
----------
21-Aug-87 20:46:39-EDT,2279;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Aug 87 20:46-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 21 Aug 87 19:37:15 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 21 Aug 87 19:36:59 EDT
Received: by po2.andrew.cmu.edu (5.54/3.15) id <AA01223> for [e-mail]; Fri, 21 Aug 87 17:17:17 EDT
Received: via switchmail; Fri, 21 Aug 87 17:17:13 -0400 (EDT)
Received: FROM po3.andrew.cmu.edu VIA qmail
      ID </cmu/common/mailqs/q000/QF.po3.andrew.cmu.edu.212cb897.49e8a>;
      Fri, 21 Aug 87 17:16:09 -0400 (EDT)
Received: FROM cmu-psy-boxwood VIA qmail
      ID </cmu/psy/ah4h/.Outgoing/QF.cmu-psy-boxwood.212c73b1.93c67e>;
      Fri, 21 Aug 87 12:22:10 edt
Received: from cmu-psy-boxwood by Messages.4.21.CUILIB.3.30.SNAP.NOT.LINKED.MS.3.42 via sun3; Fri, 21 Aug 87 12:22:09 edt
Message-Id: <oV=[e-mail]>
Date: Fri, 21 Aug 87 12:22:09 edt
From: [e-mail] (Andrew Hudson)
To: [e-mail]
Subject: TNC review? && miscellaneous
In-Reply-To: <[e-mail]>

Howdy all,

I'd be very interested to hear a comparison of the popular TNC's. I'm soon to
purchase one and I've heard that AEA's has better filtering than the MFJ
TNC2. But the TNC2 has the LED signal strength indicator which is handy for
HF bands. I've also seen a number of small-production type TNC's advertised.
Are these worth looking into?? Perhaps there has already been a consumer's
review of these boxes, maybe someone could post it.

I'm also curious to know about the new networking rom which is out for many
of the popular TNC's.  What new functions does it provide?

It may interest some to know that 73 Amateur Radio magazine published a list
of packet repeaters in the August issue, #323. There are also a few other
articles in the same issue on packet with next to nil content. These can be
safely ignored.

A packet ham from Southern N.J. informed me that there is a satellite link
from a N.J. packet repeater to another in California. Is this an amateur
satellite?!? Any details??

Happy packets,
Andrew Hudson
[e-mail]
KA2KHD
21-Aug-87 20:58:31-EDT,2279;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Aug 87 20:58-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 21 Aug 87 19:37:15 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Fri, 21 Aug 87 19:36:59 EDT
Received: by po2.andrew.cmu.edu (5.54/3.15) id <AA01223> for [e-mail]; Fri, 21 Aug 87 17:17:17 EDT
Received: via switchmail; Fri, 21 Aug 87 17:17:13 -0400 (EDT)
Received: FROM po3.andrew.cmu.edu VIA qmail
      ID </cmu/common/mailqs/q000/QF.po3.andrew.cmu.edu.212cb897.49e8a>;
      Fri, 21 Aug 87 17:16:09 -0400 (EDT)
Received: FROM cmu-psy-boxwood VIA qmail
      ID </cmu/psy/ah4h/.Outgoing/QF.cmu-psy-boxwood.212c73b1.93c67e>;
      Fri, 21 Aug 87 12:22:10 edt
Received: from cmu-psy-boxwood by Messages.4.21.CUILIB.3.30.SNAP.NOT.LINKED.MS.3.42 via sun3; Fri, 21 Aug 87 12:22:09 edt
Message-Id: <oV=[e-mail]>
Date: Fri, 21 Aug 87 12:22:09 edt
From: [e-mail] (Andrew Hudson)
To: [e-mail]
Subject: TNC review? && miscellaneous
In-Reply-To: <[e-mail]>

Howdy all,

I'd be very interested to hear a comparison of the popular TNC's. I'm soon to
purchase one and I've heard that AEA's has better filtering than the MFJ
TNC2. But the TNC2 has the LED signal strength indicator which is handy for
HF bands. I've also seen a number of small-production type TNC's advertised.
Are these worth looking into?? Perhaps there has already been a consumer's
review of these boxes, maybe someone could post it.

I'm also curious to know about the new networking rom which is out for many
of the popular TNC's.  What new functions does it provide?

It may interest some to know that 73 Amateur Radio magazine published a list
of packet repeaters in the August issue, #323. There are also a few other
articles in the same issue on packet with next to nil content. These can be
safely ignored.

A packet ham from Southern N.J. informed me that there is a satellite link
from a N.J. packet repeater to another in California. Is this an amateur
satellite?!? Any details??

Happy packets,
Andrew Hudson
[e-mail]
KA2KHD
23-Aug-87 13:25:25-EDT,10319;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Aug 87 13:25-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 23 Aug 87 11:51:26 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 23 Aug 87 11:51:10 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA15658; Sun, 23 Aug 87 08:52:44 PDT
Return-Path: <ll-xn!ames!amdcad![e-mail]>
Message-Id: <[e-mail]>
Date: 21 Aug 87 23:12:51 GMT
From: ll-xn!ames!amdcad![e-mail] (Rob Warnock)
To: [e-mail]
Subject: More history (was Re: John Gilmore switches feet!)
References: <[e-mail]> <[e-mail]>

[Sorry if this got to be a bit long, but sometimes I start reminiscing...]

Just to continue the history a bit further:

In article <[e-mail]> Phil R. Karn writes:
+----------
| +----------
| | I think you are forgetting who developed packet radio in the first place!...
| +----------
|  ... Credit for the first packet radio network
| belongs with the ARPA-sponsored ALOHANET experiment at the University of
| Hawaii, begun in 1970.  Much of the foundation theory of multiple-access
| contention based networks was inspired by this project.
+----------

Quite so, and there has been a *LOT* of theory worked out since then,
including such issues of how to do routing when some radios are hidden
behind mountains, etc. If anything, there is *TOO MUCH* theory available,
so that when people go to implement stuff they have trouble sorting out
the "useful" from the "pedantic". (Like, who really cares if there's this
magic protocol that get's you another .001% of useful bandwidth, if it
takes a Cray-2 and a gigabyte of disk to support it!)

Anyway, it is worth noting that good ol' Ethernet is nothing but packet
radio on a wire, instead of over the "ether".

What's that? You say, "You can't do 'Ethernet' on radio!! Ethernet uses
CSMA/CD and you can't do collision-detection on radio!!". Suuuurre...you can!
It's just not as easy or reliable. That's why there are all these weird
protocols out there [see the literature] with names like BTMA (busy-tone
multiple-access), FSA/RTDMA (fast slotted-Aloha reservation TDMA), &c., all
of which attempt to give CSMA/CD performance without actually having CD.

When I worked for Xerox/XTEN (remember them? it's o.k., nobody does...)
back in 1979, we looked at all that crap. (XTEN planned to use packet radio
at 10.6 GHz to build a "bypass" digital common carrier, going straight from
the subscriber's roof to XTEN's switches. I was helping with link-level
protocols for the local-node-to-subscriber hop.) The best scheme I ever saw
was a hybrid of TDMA & Aloha, where you split the channel up into packet-sized
slots (in a larger "frame"), and one or more slots were used for an Aloha-
like subchannel for making "reservations" to use the other slots.  (And that
"best" scheme wasn't more than a few percent better than simple polling --
see below.) There were maybe 30+ papers published on variations of that sort
of thing. Just wading through it all was a major pain.

There are some useful simple numbers that came out of all that, though.
[See any decent text on packet switching or local-area networks.] For
a "large" number of hosts contending for the channel (and even assuming
everyone is trying to cooperate), the actual throughput can max out at
some pretty small fractions of the channel bandwidth "C".

1. Pure "Aloha" protocol (just send and hope) tops out at C/(2*e)
   (e ~= 2.718...), or about 18.4% of C.        (Abyssmal, what?)

2. "Slotted" Aloha, where everybody sends only on "slot" (packet)
   boundaries (so a collision can only wipe out *one* packet, not *two*)
   gets twice as much: C/e or about 37%.        (Yawn...)

3. CSMA (carrier-sense multiple-access, a.k.a. "listen before talk")
   throughput depends on the dimensionless number "a", the ratio of
   the round-trip propagation time to the average packet length.
   (Since you listen first, there is an inherent "slotting" effect,
   so the numbers are based on slotted-Alhoa.) Unfortunately, I don't
   have the chart in front of me, but as best I recall the throughput
   is "very good" (>95% of C??) for "a" < .001, about 90% for "a" ~= .01,
   not so hot (67% ?) for "a" ~= .1, and gets worse than slotted-Alhoa
   for "a" > 1. (*ugh*)

4. CSMA/CD effectively squares "a". So a CSMA/CD net with a=.05 (so-so, if
   CSMA) gets an effective a=.0025 (very good). (This is why Ethernet wins.)

And all of the above assumes that *EVERYONE* is "polite" and is monitoring
the total channel load and applying some load-limiting algorithm (for example,
the "binary exponential backoff" of Ethernet). If you don't, then the channel
*WILL* collapse to an average of zero throughput after some random period
of time. Everyone will be re-transmitting and stepping on everyone else.
(Haven't we seen this on voice channels?  ;-}  ;-}  )

To put some numbers on it, if your average packet is, say, 80 characters
(including headers, etc.) you're at 1200 baud async (one stop bit), the
average packet length is 667 milliseconds. If your furthest direct-path
digipeater is 25 miles, your round-trip prop time is 268 microseconds
plus (and you *have* to include this!) say 20 milliseconds for your
carrier-detect (yours may be worse!). [Yes, it is not unusual for
carrier-detect time to dominate r-t prop time.] That gives you an "a"
of about .03, which is not bad, but not great. Total collapse of the
net is likely whenever average offerred traffic briefly exceeds 80% of
capacity (unless TNCs do some sort of backoff, which I sincerely hope!).

Anyway, after reading all that "literature", I was finally convinced that:

1. There was then (even now?) no obviously "best" protocol for completely
   peer hosts in the general case; if you had one or more distinguished
   "traffic-cop" hosts things got a LOT better.

2. There was no "best" protocol, even with traffic cops, when you had a
   "large" number of hosts (assuming you can't use CD -- if you can, use
   the Ethernet protocol, it's "good enough"). Variations on the "Urn"
   protocols (such as "Silence-Is-Golden"-plus-Urn) work o.k.

3. If you *have* a traffic cop, simple old "polling" works nearly as well
   as anything, especially when some stations can hear only the traffic cop.

4. "Hub go-ahead" (used in some multi-point systems) or "virtual token"
   systems (such as Datapoint's ARCnet protocol) do fairly well if there's
   no traffic cop, but absolutely depend on everyone hearing everyone else.

5. Polling or token-passing (in all their forms) lose big when the cost
   of doing the handoff (including round-trip prop time and carrier-detect
   time) is a large fraction of the average packet size and you have a large
   number of hosts. It also really depends on a fairly reliable channel.
   (In all of the Ethernet-vs-token wars, token advocates usually ignore
   the fact that regenerating a lost token is *exactly identical* to an
   Ethernet station acquiring the channel in the first place.)

6. CSMA & CSMA/CD win for a large number of hosts, but lose big when the
   propagation delay rises too far (*including* carrier detect time).
   CSMA/CD ("Ethernet" and friends) survives much longer than CSMA.
   They both handle lossy channels better than polling/token.

Lessons for ham (and public) packet radio? (My own opinions here)

1. Continue to use CSMA, but push the modem manufacturers for the shortest
   possible carrier-detect times. (For VHF work, it totally dominates
   propagation time.) Ultra-short carrier-detect times are *CRUCIAL* for
   good channel utilization (low "a" factor). (Some cheapo 1200 baud modems
   take nearly a second to see carrier!)

2. Insist on dynamic load-limiting algorithms ("exponential retransmission
   backoff") to avoid catatrophic channel collapse. [This is in addition to
   TCP backoff, Phil.] For example, adjust the "p" in a "p-persistent CSMA"
   using the "silence-is-golden" algorithm. (Basically, don't attempt to
   send more than "x" percent of C, where "x" is the amount of "silence" or
   unused channel time that would result on the channel *after* including
   yours and everyone else's traffic. Use a simple low-pass filter on carrier-
   detect to compute the "silence" [or lack thereof].)

3. Look at higher-level protocols (as opposed to the link-level stuff I talked
   about above) which try to send large packets where possible such as TCP/IP
   with the "Nagle algorithm". Remember that "a" = RTprop/pktlen, and you want
   low "a". Avoid like the plague systems which send lots of short packets!!!
   (E.g. disallow character-at-a-time echo over the net.)

4. Be aware that higher-speed (56 Kbit and up) channels will cause "a" to
   grow (*boo* *hiss*), as packet times becomes smaller due to the higher bit
   rate, and as carrier-sense times become longer due to more complex modulation
   schemes.  Expect lower percentage utilization of bandwidth to result.

   Note that this factor has forced a switch to token rings or "reservation"
   busses for very-high-speed LANs (>100 Mbit/sec).

5. Consider partitioning the world into "smart" and "dumb" sites, where the
   smart sites run fancy routing algorithms and do polling of (or run some
   sort of reservation system for) the dumb sites. Smart sites should have
   the most reliable links between them, so the routing algorithm is more
   stable.

But most important, as Phil pointed out, don't let your mind set into treating
today's TNCs and protocols as "given" (even though they'll "always be around"
as a popular leaf-level system).  It's important to do a lot more research
(even if only reading the literature) before freezing what the higher-speed
backbones are going to look like.

There are a lot of wild & wooly things left to do out there...


Rob Warnock                             [Alas, no ticket... yet.]
Systems Architecture Consultant

UUCP:     {amdcad,fortune,sun,attmail}!redwood!rpw3
ATTmail:  !rpw3
DDD:      [phone]
USPS:     627 26th Ave, San Mateo, CA  94403


24-Aug-87 18:25:52-EDT,6873;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 24 Aug 87 18:25-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 24 Aug 87 16:02:17 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 24 Aug 87 16:01:31 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA06525; Mon, 24 Aug 87 13:02:50 PDT
Return-Path: <rutgers!princeton!idacrd![e-mail]>
Message-Id: <[e-mail]>
Date: 24 Aug 87 17:32:14 GMT
From: rutgers!princeton!idacrd![e-mail] (Bob McGwier)
To: [e-mail]
Subject: Re: John Gilmore switches feet!
References: <[e-mail]>

>
> There is absolutely nothing illegal about running 56kbps amateur packet
> radio in the United States. At least I *hope* not, I have two beta-test
> units designed by WA4DSY in the final stages of construction here, and a
> number of other units are already on the air in the Atlanta area.
>
> I suppose a Canadian can be excused for not being familiar with American
> rules, but a licensed American ham who expresses strong interest in the
> development of digital radio is another story...
>
> Phil

Let me add a couple of thoughts to what Phil started here.  I also have
two of the DSY 56KB modems and four 9600 bps modem kits (K9NG's) and
will not have to ask anyones permission to put them on the air.  As far
as what hams are doing, Gilmore has gotten it all wrong in my opinion
(stick to computer software John when you want to flame).

(1) The ENTIRE amateur radio "network" with very few exceptions is built
    from equipment that is owned by one individual or a few individuals
    who have donated the services of THEIR equipment to meeting the
    needs of others.  It is a kludge but their are anecdotal instances
    of it working very well.  I personally send mail to Canada (VE3GYQ)
    about twice a week and the delivery time has never been more than
    six hours (New Jersey to VE3) and this is over links that are all
    1200 or 300 bits per second.  I send mail to California to W0RLI
    about once a week and it goes 1200 bps to Maryland and then through
    a 56 Kbps satellite link to California (Frisco) and delivered there.
    It is a kludge but it does meet some mail needs.

(2) Work is going on to build much better networks.  It is heartening to
    see that Gilmore knows about the work of Phil Karn to produce code
    for interworking because the only reward Phil is getting for this is
    the knowledge that people of Gilmore's stature know of and appreciate
    his work.  The TCP-IP-UDP implementation that KA9Q has written is
    currently running away with what has come to be known affectionately
    as the protocol wars (as it should) BUT there are other folks
    working on other stuff (OSI software and "home grown" stuff). We are
    not standing still while dust collects on our shoulders.  Phils
    later submission concerning the conservative nature of hams is
    unfair in my opinion in that it singles out hams for this "flame".
    When was the last time you installed new software that caused some
    member of your computer community to have to learn as much as a
    single new command?

(3) AMSAT/TAPR are funding a digital signal processing project which I
    co-chair with Tom Clark W3IWI whose purpose is to bring the tools of
    DSP to bear on amateur signalling problems.  We are working on all
    the tools necessary to bring a mini ISDN into being.  Software that
    currently works on the devices we are working on (TMS320 family)
    provides ADPCM and LPC encoding of voice at 9600 bps rates and
    W5SXD is working on some TMS340 video compression schemes.  I will
    unveil my software modem at ARRL L.A. Networking Conference (yes
    we run a conference every year for the purpose of people-networking
    of those working on a broad spectrum of topics in computer
    networking).  Tom put together an implementation of a PSK modem for
    use in satellite digital communications and that is being provided
    in kit form from TAPR for $100.

(4) As for inter and intra continental digital signalling:  AMSAT and
    JAMSAT have together in orbit, working now, two satellites that
    afford digital communications in some form or another.  FO-12,
    Japan's first amateur radio satellite, has functioning digital
    repeater software and it also has a a store and forward mailbox
    on board.  The University of Surrey has Oscar-11, which has a
    digital store and forward capability.  Both of these are
    experimental and do not provide the necessary facilities for
    major internetworking.  HOWEVER, with the development of the
    PSK modems, and the launch of AMSAT-NA, AMSAT-DL, and others
    Phase-IIIC, we WILL be able to move megabits of data on a routine
    basis.  Also on board is a dedicated packet experiment that
    is a simple repeater but can do some store and forward.  Phase-IIIC
    is currently scheduled for launch in March 1988 and we are gearing
    up now for our big pre-launch publicity push.

(5) TAPR is funding a hardware project to try and produce a generic
    networking box and the interest is very high in producing a
    follow on to this initial effort in which we have a larger set of
    development tools available to us so that progress will go faster.

(6) The American Radio Relay League's ad hoc digital committee is
    pursuing and underwriting experiments in signalling working on
    HF, VHF, UHF, and microwave to find "optimal" solutions for each
    of these environments.


(7) AMSAT is currently funding a reseach project to design a Phase-IV
    satellite which has come to mean geosynchronous.  The digital
    (nonlinear hard limited high efficiency etc.) transponder on this
    is now proposed to be T1 for providing large capacity (as far as
    ham-radio is concerned) pipes for networking.  Tony England, head
    astronaut on the space station project, is also on the engineering
    team (Phil K., Tom Clark, Bdale Garbee, and myself are readers of
    this service on the team) for Phase IV.  He wants to use the digital
    transponder for compressed video in a TDRS style operation as an
    educational tool.

Look I could go on until this gets really boring (it already is?
Sorry :-).

The point is that no one should say that we aren't trying to do better.
Don't give up on us yet.

If you are interested in participating in some of the projects or
want to be put in touch with those who can put you on the project please
feel free to call me at home

(609)-443-8963 after 8 PM Eastern and before 10 PM Eastern

I don't mind putting people to work :-)

Bob N4HY


26-Aug-87 19:13:44-EDT,4885;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 Aug 87 19:13-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 26 Aug 87 15:41:58 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 26 Aug 87 15:41:37 EDT
Received: by june.cs.washington.edu (5.52.1/6.6)
    id AA06463; Wed, 26 Aug 87 12:43:08 PDT
Return-Path: <ihnp4!homxb!hou2d![e-mail]>
Message-Id: <[e-mail]>
Date: 26 Aug 87 13:58:39 GMT
From: ihnp4!homxb!hou2d![e-mail] (G.BEATTIE)
To: [e-mail]
Subject: Radio Amateur Telecommunications Society COSI-Switch Development Status
Keywords: RATS X.25 CCITT ISO

**************  The Radio Amateur Telecommunications Society  ************
******************** Information Bulletin 20 August 1987  ****************

To: All Radio Amateurs
Fm: N2DSY @ KD6TH-4/201
Sb: COSI-Switch and RATS Update


The delays in getting out the COSI-Switch have been long and
somewhat frustrating for everyone.  Things are finally coming
together.

What should be clear to everyone by now is that the originally
announced X.25 Level 3 code has not arrived.

Something had to be done...

The project has been started from scratch by Tom Moulton, W2VY.
He is getting consultation support from John Howell, N2FVN,
Harlan Worchel, KB2CNL, and Gordon Beattie, N2DSY.  All of these
individuals have previously implemented X.25 switches or Packet
Assembler/Disassemblers (PADs).  We had a design review on the
14th of August and we are all quite pleased with the progress
Tom has made.  (Kudos to TOM !)

The revised delivery scedule is as follows:

1 Oct - Alpha testing of a completed COSI-Switch Level 3 module

1 Nov - Beta testing of a completed COSI-Switch machine - TNC-2/DR-200
    (Any other hardware suggestions ?)

1 Jan - Production shipment begins


All individuals and clubs that contacted RATS regarding this
project will receive MS-DOS Disks and EPROMS with the code
during each phase of the testing cycle.  We got a good deal on
diskettes and EPROMs so we will include everyone !  The
production version will include SOURCE in "C".

As with all the SOURCE we distribute, it is free for
non-commercial use.

---  Delete the following before transmission over Amateur Radio networks ---

Support contributions are accepted and commercial
licensing arrangements can be made.  Contact RATS for details.

--------------------  END DELETE  -------------------------------------------

ALL proceeds go to the enhancement of the Packet Network.


Other happenings:

John Howell N2FVN has produced an implementation of the
"Asynchronous Framing Technique (AFT) in "C".  This is useful
for providing error-checked, transparent  HDLC links through
asynchronous interfaces.  AFT can be run over seven or eight bit
networks and handles HDLC frames transparently.  It is a nice
building-block for the network.

This AFT is a generic implementation (accompanied by a "DOC"
file) that includes code that runs under MS-DOS.  Distribution
of this code, in compressed form, will be via Amateur Packet
Radio, Usenet and CompuServe HAMNET.  The file name(s) will be
based on the string "AFT10" for AFT version 1.0.  It will be
distributed in compressed form.  We'll send it out with the
first COSI-Switch test code.

John is working on a matching capability for the TNC-2.  This
would provide a error-checked link between PCs and TNCs.  Harlan
Worchel, KB2CNL (yes, a NOVICE !) is working on porting the code
to the Commodore 64.

Brian Riley's (KA2BQE) latest release of the Packet Radio
MailBox System, version 95c, supports forwarding
through COSI-Switch, GatorSwitch and NET/ROM.  It also has the "KT"
(kill traffic) feature that will automatically generate a
service message when a traffic message is removed from the
packet network.  It is available from RATS, with the "C" SOURCE
CODE.  Send a message to N2DSY @ KD6TH-4/201 or KA2BQE @
KA2BQE-4/609 to get a copy of the code.

RATS is currently beta-testing the GLB Netlink 220 19.2 KBps
modem/radios.  So fast ! Sooo goood !  We are also burning-in eight
PAC-COMM DR-200s.  These will be deployed shortly.


RATS wishes to thank you for your patience.  We're not real
happy with how we got into the Level 3 COSI-Switch delay, but we
think the effort is on the right track.  If you have any
questions call or send me a message.

Hang tough.  We think you'll like the output !

Next update will be sent on or about 15 September.


             Vy 73,

        J. Gordon Beattie, Jr.

        MAIL
Unix:       ihnp4!houxm!hou2d!n2dsy
Amateur:    n2dsy @ kd6th-4/201

        TELEPHONE
Office:     201-615-2506
Home:       201-387-8896


26-Aug-87 20:33:30-EDT,6069;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 Aug 87 20:33-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 26 Aug 87 18:53:05 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Wed, 26 Aug 87 18:52:30 EDT
Resent-Message-Id: <[e-mail]>
Date: Wed, 26 Aug 87 14:09:20 -0700
Message-Id: <[e-mail]>
Sender: Einar Stefferud <[e-mail]>
From: Einar Stefferud <[e-mail]>
Reply-To: [e-mail]
To: [e-mail]
Cc: [e-mail]
Resent-From: [e-mail]
Resent-To: [e-mail], [e-mail], Info-Xmodem
Resent-Date: Wed 26 Aug 1987 16:52-MDT

I am sending this to the whole list, plus -request because I think it is
important to immediately press a vital issue, as follows:

The entire globe needs yet anotehr new protocol like it needs 5 billion
new holes, one each in the heads of the earth's 5 billion people.

We have seen much effort put into development of the new OSI stuff
(ISO/CCITT/NBS/...).  I would much prefer to see you and others put
their efforts into spreading the new OSI stuff around and making it
available and useful on lower order machines of the class we commonly
call PC's today.  In particular this includes the use of dialup public
switched telephone connections to pass Mail, Transfer Files, and do
Remote Logins.

There is a reasonably large gap in the ISO/CCITT OSI suite in this
special area.  Use of DialUp connections is very hard to accomplish.

But, at the higher levels (Session, Presentation, ASN.1, ROSE, ACSE,
FTAM, et al) much of the desired work has been done.  Much, but not all
is freely available to the public (almost but not quite public domain).
X.400 Mail Handling Systems are already available for MSDOS for prices
under $500 per copy.

I would propose that this revived PCNET effort be focused on taking this
existing body of OSI stuff and porting it down to PC Class machines.
And then add to it the ability to use DialUp connections at the Network
Layer, under TP0 for use by Session and the other Higher Layers.

You can freely obtain copies of the relevant ISO Development Environment
stuff from several sources in the US and Europe.  See my attached notice
of a new FTAM Service that is offered in the UK.

OIn shoort, there is a really massive movement already underway, and it
is my proposal that you all work to take advantage of it by hooking the
PCNET effort to it to make it available tro the masses of Isolated PC
Class Systems out there in the DialUp World.

------- Included FTAM Service Announcement

Date:    Sat, 22 Aug 87 11:27:59 +0100
Subject: FTAM Service at UCL
From:    Steve Kille <[e-mail]>
To:      [e-mail],
     [e-mail], [e-mail],
     [e-mail], [e-mail]
cc:      [e-mail]

I am pleased to announce an experimental FTAM service at UCL.

Let me explain what I mean by this, and why I have sent this message to
such a large group of people.

By FTAM, I mean the ISODE implementation, which is to DIS, with a few
pieces of critical information taken from the IS.

By service, I mean that from now on, we intend to make all public files
at UK.AC.UCL.CS (currently available by NIFTP), also available by FTAM.
I believe that the software we have is now in a state where this will
start to be useful to some sites.  We have already shipped many
megabytes over PSS, and have some confidence that this system is usable.
To start with, the following are available:
 1) UCL Service documents and guides
 2) RFCs (the UCL collection, which is substantial, but not complete)
 3) Mailgroup documents
 4) ISODE Sources

The service is available on PSS (23421920030016) and on Janet
(0000051160016).   It is also available on the Internet, at
CS.UCL.AC.UK on the ISODE socket.   The transport selector is 256,
which should be ASCII encoded (we do also accept the rather bizarre
US GOSIP encoding).  There are no other selectors.

Username "anon" will give public access.  The locations of the files
should be "obvious".

Why announce this now?

1) This so far appears to be the only DIS FTAM implementation around.
I do not really believe this, and hope that this may encourage some of
the others to creeep out of the woodwork.   Interworking tests are
clearly desirable.   Perhaps I should note here, is that UCL's interest is
in promoting and using OSI.  We are not intending to do FTAM
development.

2) The timing is so that this topic may be
discussed at the RARE WG1 and WG2 meetings, where it is relevant.
In particular, I believe that this system is appropriate for an
experimental RARE service, perhaps along the lines of the EAN
experimental MHS service that has been emerging.   This could be a core
activity for WG2.  WG1 have a need for document and table update.

3) It might be useful to someone

What is the software?
The ISODE software is written in C, and targetted initially for  UNIX
(it is aimed to be as independent of UNIX as possible).   There will be
a new release (ISODE 3.0) available in the near future.   This will
contain support for three different X.25 interfaces:
    SUN (Sunlink)
    Vax (CAMTEC Dexpand)
    Vax (DMF 32 + UBC interface)
Announcements will be made to the ISODE list (contact
[e-mail]).  Europeans may be added to the
European expansion of this list (contact [e-mail]).

Who is responsible:
Most of the system has been written by Marshall Rose of Northrop.
Credit should also go to John Pavel of NPL and George Michaelson of UCL
for making the X.25 fly, and to George for setting up the service.


onward with OSI!

Steve

------- End of included FTAM Service Announcement
27-Aug-87 12:13:51-EDT,1561;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Aug 87 12:13-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 27 Aug 87 10:56:51 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 27 Aug 87 10:56:14 EDT
Date: Thu, 27 Aug 87 16:47:13 +0200
Posted-Date: Thu, 27 Aug 87 16:47:13 +0200
Received: by tor.nta.no (5.54/3.21)
    id AA00290; Thu, 27 Aug 87 16:47:13 +0200
From: Karl Georg Schjetne <[e-mail]>
To: <[e-mail]>
Message-Id: <511:[e-mail]>
Subject: Doubledos vs. DOS 3.2.

I have been running a BBS-system (MBL) on my UNISYS HT for more than a
year. At present I am running version 3.20 under MS DOS 3.2.

My family sometimes need the PC for other purposes.  Thus I have tried
to use Doubledos to serve both my fellow hams and my family at the
same time.  This worked fairly well under DOS 2.11.

Some days ago I put DOS 3.2 on the PC  -  DDOS does not work any more!

DDOS starts OK, but the system deadlocks imediately after startup  -  before
the BBS gets any opportunity to do any work!

I would certainly appreciate all possible help and suggestions from any-
body "out there" with experience with DDOS and 3.2.

Some additional information:
    -  My PC is very close to an IBM XT, with 640Kbytes, 20 Mbytes etc..
    -  My version of DDOS is (3.2) V.

73 de Karl Georg Schjetne, LA8GE,
      Steinhaugen 29,
      N-7049  TRONDHEIM
      NORWAY.
27-Aug-87 15:52:02-EDT,1098;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Aug 87 15:52-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 27 Aug 87 14:20:13 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Thu, 27 Aug 87 14:19:53 EDT
Message-Id: <[e-mail]>
Received: from NEUVM1.BITNET by wiscvm.wisc.edu ; Thu, 27 Aug 87 13:17:53 CDT
Date: Thu, 27 Aug 87 09:02:31 DNT
To: [e-mail]
From: [e-mail]
Return-Receipt-To: [e-mail]
Subject: Packet software

HI again guys
After my first not very lucky try, here is another.
Is there anybody out there who is able to supply me with information
about a source for NO TNC SOFTWARE for packet on IBM/PC.
Any hints and adresses will be appriciated, i would prefer PD but
commercial will do.

PS. MR. Nice Guy perhaps will beem me a copy of PD program via
the net.

Thanks in advance, and happy packeterring from Copenhagen

                          OZ8TW       Tage
29-Aug-87 10:41:56-EDT,3496;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 29 Aug 87 10:41-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 29 Aug 87 09:43:52 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sat, 29 Aug 87 09:43:42 EDT
Date: Sat, 29-Aug-87 00:34:08 EDT
From: k1bc![e-mail]
Subject: WA8DED firmware for TNC-1, TNC-2 and PK-87.
Message-Id: <8708290034.0.UUL1.1#[e-mail]>
To: [e-mail]
Sender: k1bc![e-mail]
Source-Info:  From (or Sender) name not authenticated.


Subject: WA8DED firmware for TNC-1, TNC-2 and PK-87.

This message announces an update and some additions to the
packet radio files at SIMTEL-20.ARPA .

Some time ago, the WA8DED firmware for the TAPR TNC-1 (and its
clones, the HD-4040 and AEA PK-1) was placed in the SIMTEL-20
archives.  Versions 1.0 and 1.1 were posted.  Recently, W8SDZ
asked me if I had version 1.2, which I did not.  After a little
poking, I came up with it and also with other implementations
for the TNC-2 and the PK-87.  These latter two implement the
same command interface, including the host mode, as the TNC-1
implementation.

For those who don't remember,  the WA8DED firmware is the
only one which implements version 2 of the AX.25 level 2
protocol in the TNC-1 hardware.  It also implements multiple
simultaneous connections.  It lets you place your callsign and
parameters in EPROM.  It properly digipeats version 2 frames,
which the TAPR firmware does not.  So it is the firmware of choice
for an unattended digipeater using TNC-1 hardware.

It implements a host mode which 1) allows arbitrary binary data
to be passed,  2) prevents the "*** Connect Request ..." messages
from being mixed with the data, and 3) provides proper flow
control to prevent lost data.

The down side is that the command set is not compatible with the
TAPR commands, so it cannot be run at a BBS/Mailbox site where the
computer wants to talk to a stock TNC-1 or TNC-2.

The changes from version 1.1 to 1.2 are a few minor bug fixes
and cosmetic changes.  One of some significance fixes a problem
encountered by users of the PSK modems on one of the satellites
(Sorry, I forget the details).

The implementation of these features on a TNC-2 or PK-87 was
news to me.  It looks useful for providing a compatible transparent
interface to both sets of hardware.

Note that this is NOT the same as the KISS protocol TNC used with
the KA9Q TCP/IP system.  This is a better-than-the-original AX.25
implementation, not a raw frame handler for an arbitrary protocol.

These programs are copyrighted by Ron Raikes, WA8DED.  He has
granted permission for non-commercial use by individual
Radio Amateurs.   For any other use, contact WA8DED.

The following files have been added to the SIMTEL-20 archives:

Filename                        Type     Bytes   CRC

Directory PD:<CPM.PACKET>
DEDTNC1.ARK                     BINARY   44836  7A7BH
DEDTNC2.ARK                     BINARY   60248  6004H
DEDPK87.ARK                     BINARY   97499  4B5DH

The .DOC file in the PK87 archive is an addendum to the .DOC file
in the TNC-2 archive.  So if you have a PK-87, you need both
of those archives.

These .ARK files contain binary and .HEX files for making EPROMs
and .DOC files.  Sources have not been released.

73,  Bob,  K1BC
[e-mail]     or     {backbone sites}!{spdcc or bbn}!k1bc!rcc


30-Aug-87 13:15:24-EDT,2153;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 30 Aug 87 13:15-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 30 Aug 87 12:29:43 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Sun, 30 Aug 87 12:29:07 EDT
Date: Sun, 30 Aug 1987  10:30 MDT
Message-Id: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To: [e-mail]
Subject: W0RLI-VE3GYQ C BBS version 3.2 for MSDOS now available

Now available via standard anonymous FTP from SIMTEL20...

Filename                        Type     Bytes   CRC

Directory PD:<MSDOS.PACKET>
IO32.ARC.1                      BINARY    8192  DBC7H
IOSRC32.ARC.1                   BINARY   43008  BC93H
MBBIOS.ARC.1                    BINARY   32256  E594H
RUN32.ARC.1                     BINARY  111616  7DB9H
SRC32.ARC.1                     BINARY   78848  E0DAH

Notes from the author:

     The W0RLI / VE3GYQ C BBS

Release notes for C BBS Version 3.2 - 5/21/87

*** Warning - starting with V3.0, "files in database" is
no longer supported. Make certian your messages are stored
as files. If in doubt, do GF before bringing up this version.

*** Note: Check that any sub-directory you use in config.mb exists,
the existance of any directory / device paths is NOT checked.

A special thanks to those who send little chunks of code showing bug
fixes they have found. w1goh, ag3f, kc8tn, ka2bqe, ve3gyq, k1bc,
and many others have contributed to this effort.

MBMODE can be used to set the port parameters, in the same
manner that MODE would be. MBMODE supports COM1 thru COM7.

The code has been run on:

  Several flavors of IBM and compatibles.
  Leading Edge "M".
  Victor VI, Victor V286 clone.
  Zenith Z-100 (port not yet finished).
  Xerox 820 (Not too useful).
  Victor 9000 (ah6cl, n6iya).
  OS-9 (Contact DH1IAZ for details).

The code runs under DoubleDOS or DESQView.

Please read the first few pages of NOTES.MB before you attempt to run
the program, and read it in detail for information on setting up
route tables, etc.

There WILL be sysops documentation sometime "soon".


... Hank

31-Aug-87 07:01:21-EDT,1135;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 31 Aug 87 07:01-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 31 Aug 87 06:13:20 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 31 Aug 87 06:12:46 EDT
Date: Mon, 31 Aug 87 11:03:27 +0200
Posted-Date: Mon, 31 Aug 87 11:03:27 +0200
Received: by tor.nta.no (5.54/3.21)
    id AA01335; Mon, 31 Aug 87 11:03:27 +0200
From: Karl Georg Schjetne <[e-mail]>
To: <[e-mail]>
Message-Id: <513:[e-mail]>
Subject: Printing in DIGIPAC II.

I am using DIGIPAC II for packet work  -  nice system.

However, printing of incomming information or log info do not work with my
UNISYS HT PC and IBM Proprinter  -  regardless of what parameters I feed
the system via the initialization file.

Does anybody out there have experiences or suggestions pertinent to
my problem before I write the program authors?

73 de Karl Georg Schjetne,
      LA8GE,
      Steinhaugen 29,
      N-7049, Trondheim,
      NORWAY.
31-Aug-87 17:14:47-EDT,2773;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 31 Aug 87 17:14-EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 31 Aug 87 14:07:19 EDT
Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <[e-mail]>; Mon, 31 Aug 87 14:07:00 EDT
Received: from Riesling.ms by ArpaGateway.ms ; 31 AUG 87 11:04:53 PDT
Sender: "Ferris_D._Jennings.osbunorth"@Xerox.COM
Date: 31 Aug 87 10:44:49 PDT (Monday)
Subject: PK-232 Help
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Message-Id: <870831-110453-5698@Xerox>




I took the big plunge into Packet last week and bought a PK-232...I've
just barely started to read the 200 page manual, but I already have a
question and a problem.

My equipment config is: PK-232 using default settings hooked to an Apple
II+ [64K, 40 column display] via an Apple Super Serial Card.

QUESTION: Right now I am using a simple terminal emulation routine found
in the back of the Serial Card manual that turns the Apple II into a
dumb terminal. It would be nice to have a bit more flexability; so can
anyone recommend a good communications program. I've seen a review on
such programs in a recent issue of Nibble Magazine and both ASCII
Express Pro and Modem Manager seem interesting: especially Modem Manager
which has a split screen option [top received data, bottom transmitted
data].

PROBLEM: I have the PK-232 hooked up to a 2 meter rig right now and it
seems to receive fine [I haven't tried to transmit yet]. The problem is
that the first character of each displayed line is deleted.

When I first turn on the PK-232 the sign on message and the CMD: prompt
appear intact. If I type a request for Display Z [as an example] the
first line is fine...all lines after that the first character is
missing. At the end of the Z list the CMD: prompt now appears as MD:.

Incoming call signs and routes displayed on the screen are intact unless
there is a message following...and if that message takes up a few
lines..again the first character of all subsequent lines is always
missing.

I've checked out the PK-232 with a Lear Siegler dumb terminal and
everything is OK..all lines intact with no letters missing...so I assume
the PK-232 is good.

I've run disgnostics on the Apple and the Serial Card using Nikrom
Master Diagnostics and they both check out ok. Also this problem doesn't
occur on any other program I run on the Apple.

The only things I can think of that could be causing this problem is
either there is a PK-232 command that I'm not using or not using
properly OR I need an 80 columnn card.

Any help or suggestions would be greatly appreciated.

Ferris  NB6T