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

Text File | 1993-12-31 | 406.0 KB | 6,916 lines

Sun, 1 Apr 90 13:06:48 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 1 Apr 90 20:03:44 GMTFrom:
[e-mail]  (Patty Winter)Organization: Apple Computer
Inc, Cupertino, CASubject: Memory reqs. for BM (Was Re: Bmailer
"going blank")Message-Id: <[e-mail]>References:
<[e-mail]>Sender: [e-mail]:
[e-mail] article <[e-mail]>
[e-mail] writes:>> The locals used to
give BM about 225K in Desqview.  That>seemed alright for a
while, but if I left my mailfile unpurged, it got big>and seemed
to loose its headers.Is it true that the DOS version of BM
really takes up that muchmemory? The Mac version recommends
128K; I've actually beenrunning it happily at 96KPat--how big is
a mail file you call "big"? Maybe if I stored 100or more
messages, I'd need more memory. Seems unlikely it wouldballoon
up to 255K, though.Patty--
*****************************************************************
************ Patty Winter N6BIS                        INTERNET:
[e-mail]: [44.4.0.44]                     UUCP:
{decwrl,nsc,sun}!apple!winter************************************
***************************************** From
packet-radio-relay  Sun Apr  1 14:45:18 1990Received: by
ucsd.edu; id AA20023    sendmail 5.61/UCSD-2.0-sun    Sun, 1 Apr 90
14:45:32 -0700Received: from Larry.McRCIM.McGill.EDU by
ucsd.edu; id AA20008    sendmail 5.61/UCSD-2.0-sun via SMTP    Sun, 1
Apr 90 14:45:18 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: from speedy by
Larry.McRCIM.McGill.EDU (5.61) with UUCP    id
<[e-mail]>; Sun, 1 Apr 90
17:45:11 -0400Received: by speedy.uucp (UUPC/pcmail 1.0095) with
UUCP; Sun, 01 Apr 90 07:08:59 ESTDate: Sun, 01 Apr 90 07:08:59
ESTFrom: John B. McCluskey
<[e-mail]>Message-Id:
<[e-mail]>X-Mailer: UUPC/mail 1.095To:
[e-mail] Meahan,  WA8TZG, writes:>Given that
packet uses modem signalling derived from telephone
applications,>it would seem appropriate to 'upgrade' the packet
modem standards to match>what the landline types do.  Would the
FCC object to PEP or V.32 operation>to get higher BPS rates
given that these encoding schemes do not take up any>more
bandwidth than a voice channel?  Anybody working on it?
                             ^^^^^^^^^^^^^^^^^^^^^^I'm looking
into it.Phil Karns has addressed the issue of why these modem
standards areinapropriate for radio channels, and I will further
point out thatattempting to hook up a telephone modem via radio
might work for FM, butfor SSB almost certainly not, because of
the difficulty in eliminating thefrequency offsets.
Economically solving the problem of LO offsets in abunch of
independent radio tranceivers would go a long way in raising
thebits/Hz figure in packet radio.   Any ideas?  The cheapest
thing that comesto mind is locking the LO to WWV or some other
local broadcast carrier.PEP is actually a nice modulation
technique and I believe that eventuallyall (non-spread-spectrum)
rf modems will use some variation of it.  Itproduces an output
signal with a Gaussian distribution, and this is themost
efficient way of sending bits/watt.  If you know the destination
ofyour packet, you can measure the channel characteristics and
shape yourouput spectrum to avoid dumping power into a spectral
null caused bymultipath.  PEP shapes the spectrum by variable
rate QAM in each spectralbin, which brings up the question of
variable rate coding for specificstation-to-station
channels.Shannon's theorems show that bit rate is proportional
to SNR (dB), and ifstation A is just round the corner from
station B with an SNR of, say, 90 dB,it is possible to push 56
Kbits/sec through a 4 Khz passband (using16384-QAM !).  Getting
14 bits/Hz is *possible*, not easy.  This looks barelyachievable
with 16 bit A-D & D-A hardware and DSP chips, but complicatesthe
networking a bit since station C, trying to monitor, may only
get 30 or40 db of SNR and has no hope in hell of decoding the
entire packet.  Thisimplies that the channel coding scheme has
to encode the network control(or broadcast) information with
enough SNR so that every station in the localcell can decode
it.Now I admit, 90 dB is an extreme example of a high SNR, but
many channellinks will be better than your typical
lowest-common-denominator 20 to 30 dBlink.  Doesn't it make
sense to use radio/modem hardware that can takeadvantage of the
SNR when it is available?  I have resisted buying existingmodem
hardware on this principle, since what I want is a DSP modem
that isbackwards compatible with old modulation standards just
by using differentsoftware.   I am hoping that 1990 is the year
when such a product reallyappears at a reasonable price (Are you
listening down there at TAPR & DRSI ?).Once such hardware
becomes universally available, the Nightmare of the Ninetieswill
be trying to get everyone to run the same version of the
software.--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=Snail Mail  : John McCluskey, 808 de Bienville,
Montreal P.Q. H2J 1V1,  CANADATelephone   : [phone]
Call Sign: KB6PZFEMail (home):
[e-mail] packet-radio-relay
Sun Apr  1 17:16:43 1990Received: by ucsd.edu; id
AA27564    sendmail 5.61/UCSD-2.0-sun    Sun, 1 Apr 90 17:16:45
-0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA27559    sendmail 5.61/UCSD-2.0-sun via SMTP    Sun, 1 Apr 90
17:16:43 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA24276; Sun, 1 Apr 90 17:14:56 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 1 Apr 90 23:35:48 GMTFrom:
ka9q.bellcore.com![e-mail]  (Phil Karn)Organization:
Secular Humanists for No-CodeSubject: Re: Packet(?) on
commercial bandsMessage-Id:
<[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail] (Henry Mensch)
writes:>finally, DES has been broken a variety of times by a
variety of>people; not all of these people have been
highly-skilled scientists,>either 8-]Please back up this
statement. There have been no known, proven cases inwhich DES
has been "broken" in the sense that the key was derived
fromciphertext alone (or even some matching cipertext/plaintext
pairs) exceptfor cases where the key was trivially chosen (e.g.,
an English word), makinga brute-force key search
feasible.Attacks on systems such as Videocipher II have all
relied on compromisingthe physical security of the system in
order to obtain the DES keys, or onattacking the control system
to enable the system to use its keys in wayscounter to the
manufacturer's intent. This does not involve "breaking" DES.This
simply illustrates the fact that it is usually much easier
tocompromise DES-based encryption systems by means other than
directmathematical attack on the algorithm itself.A
back-of-the-envelope calculation *does* make the construction of
a machinefor the brute-force known-plaintext cracking of DES
appear feasible, givenplenty of money and the ability to design
and produce large arrays of customVLSI chips. I would not rule
out the possibility that the NSA has alreadyconstructed such a
machine, but it seems unlikely that any organization withlesser
resources has done so.In any event, after a decade and a half of
intense scrutiny, the basicconcepts underlying the DES algorithm
still appear to be sound. Its mainpotential vulnerability lies
in the choice of a marginal key size. This canbe corrected by
designing a new algorithm that incorporates the sameprinciples
as DES but with larger S-boxes and a longer key.PhilFrom
packet-radio-relay  Sun Apr  1 18:30:20 1990Received: by
ucsd.edu; id AA01444    sendmail 5.61/UCSD-2.0-sun    Sun, 1 Apr 90
18:30:23 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA01438    sendmail 5.61/UCSD-2.0-sun via SMTP    Sun, 1 Apr 90
18:30:20 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA27756; Sun, 1 Apr 90 18:24:50 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 2 Apr 90 00:36:01 GMTFrom:
ka9q.bellcore.com![e-mail]  (Phil Karn)Organization:
Secular Humanists for No-CodeSubject: Re: (none)Message-Id:
<[e-mail]>References:
<[e-mail]>Sender: [e-mail]:
[e-mail] article <[e-mail]>
[e-mail] (John B. McCluskey) writes:>PEP is actually a
nice modulation technique and I believe that eventually>all
(non-spread-spectrum) rf modems will use some variation of it.
It>produces an output signal with a Gaussian distribution, and
this is the>most efficient way of sending bits/watt.I'm not sure
this is necessarily true. You can always gain in the
powerdepartment (i.e., require less watts for a given number of
user bits/sec) byadding forward error correction. The "coding
gain" of such schemes isusually expressed as some number of dB
with respect to standard binary PSK.This inherently relies on
the tradeoff between bandwidth and power; to savepower, you have
to spend additional bandwidth.>Now I admit, 90 dB is an extreme
example of a high SNR, but many channel>links will be better
than your typical lowest-common-denominator 20 to 30 dB>link.
Doesn't it make sense to use radio/modem hardware that can
take>advantage of the SNR when it is available?It depends on the
situation. In spatial frequency reuse situations (i.e.,most
terrestrial links and many satellite links) the need to maintain
a 90dB SNR ratio (or signal-to-interference ratio, to be more
precise) wouldrequire you to put transmitters so far apart that
the total carryingcapacity of the spectrum would be greatly
reduced. It would be much betterto use a different modulation
scheme that doesn't require as high a SNR.Even though it means
you don't get as many bits/sec/hz per transmitter, theability to
put transmitters so much closer to each other more
thancompensates for this.Cellular radio illustrates this very
well. The main reason cell phones useFM instead of SSB, even
though SSB is ten times narrower, is because FM'smuch greater
tolerance of interference (its "capture effect") allows thecells
to be placed much closer together, increasing the total
systemcapacity.PhilFrom packet-radio-relay  Sun Apr  1 22:30:25
1990Received: by ucsd.edu; id AA13728    sendmail
5.61/UCSD-2.0-sun    Sun, 1 Apr 90 22:30:27 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA13724    sendmail
5.61/UCSD-2.0-sun via SMTP    Sun, 1 Apr 90 22:30:25 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA10083; Sun, 1 Apr 90
22:18:48 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 2 Apr 90 05:17:57 GMTFrom:
apple.com![e-mail]  (Patty Winter)Organization: Apple
Computer Inc, Cupertino, CASubject: Congratulations,
Bob!Message-Id: <[e-mail]>Sender:
[e-mail]:
[e-mail] to our very own netperson
Bob McGwier, N4HY, onbeing named this year's winner of the
Dayton Amateur RadioAssociation's Technical Achievement award.
In part, the awardrecognizes Bob's inexhaustible work on the
Microsat project.This makes two years in a row that a Usenet
denizen has won one ofthe three Dayton awards. Anyone care to
try for Ham of the Yearin 1991? :-)PattyFrom packet-radio-relay
Mon Apr  2 08:47:09 1990Received: by ucsd.edu; id
AA07823    sendmail 5.61/UCSD-2.0-sun    Mon, 2 Apr 90 08:47:25
-0700Received: from dgbt.crc.dnd.ca by ucsd.edu; id
AA07816    sendmail 5.61/UCSD-2.0-sun via SMTP    Mon, 2 Apr 90
08:47:09 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by dgbt.crc.dnd.ca
(5.57/smail2.5/12-02-88)    id AA20745; Mon, 2 Apr 90 11:46:12
EDTDate: Mon, 2 Apr 90 11:46:12 EDTFrom: [e-mail]
(Barry McLarnon DGBT/DIP)Message-Id:
<[e-mail]>To:
[e-mail]: Channel access, node vs digiCc:
[e-mail] now for something completely
different...Recently, one of the users of my PBBS commented to
me that he seemed to getmuch better response when connected to
the BBS via a NET/ROM node, if heused the node simply as a digi
rather than connecting to it first, andthen downlinking to the
BBS.  I expressed surprise that this would be so,but upon
further reflection concluded that there was a
plausibleexplanation for this behavior.  Consider user A
connecting to BBS B vianode C, where A and B cannot hear each
other.  Assume that there are noother stations active on the
channel.  If C is used as a digi, everythingproceeds normally,
with no retries necessary.  What if C is used as anode?  B
transmits one or more frames, receives an ACK from C, then
Ctransmits the frames to A.  Here's where the problem arises: B
typicallywill have more frames queued to transmit, and it will
jump on the channelwhen C finishes, colliding with the ACK from
A to C.  Both B and C then gointo recovery... hopefully, the
FRACK values et al are such that C willrecover first and get the
frames down to A successfully before B barges inagain.  Because
of the number of variables (timing parameters, possiblydifferent
channel access protocols, different behavior of AX.25
versions,effect of other users on the channel, etc), it's hard
to analyze whathappens at this point.  Maybe single retries from
C to A and from B to Cwill do the trick, maybe not... but then
we're just set up for thecollision scenario to repeat itself
again.  Very messy business, this.The new PRIACK channel access
protocol would apparently solve thisproblem, by causing B to
defer transmitting until A has had a chance tosend its ACK to C.
 Trouble is, PRIACK is only available in TNC-2firmware, and the
vast majority of PBBS and other packet applications donot use
this firmware for their AX.25 support.  Until this protocol
isincorporated into other AX.25 implementations, I'm forced to
conclude thatfor links involving a single half-duplex packet
repeater, it's much betterto use it as a digipeater than as a
store-and-forward node.  Can anyonesee flaws in this (admittedly
simpleminded) analysis?  Any dissentingopinions?A related
question: in the older channel access technique involving theuse
of a fixed DWAIT interval (still in common use), digipeated
frames aregiven priority on the channel by automatically having
DWAIT set to 0.  Inthe various implementations which use
p-persistence (e.g., NET/ROM, TAPR1.1.7, and applications like
KA9Q NET and BPQNODE which use KISS), isthere still some
preferential treatment given to digipeated frames?  Theanswer is
almost certainly NO in the case of NET and BPQ (w/KISS),
sincethe digipeat function is not handled by the firmware which
handles thechannel access.  I'm not so sure about the others,
though.One last question, and I'm outta here: is anyone looking
at adding PRIACKto KISS?Barry VE3JF---Barry McLarnon
Communications Research Center     Ottawa, ON
CanadaInternet: [e-mail]       UUCP:
...utzoo!dciem!nrcaer!dgbt!barryCI$: 71470,3651   PBBS:
VE3JF@VE3JF   AMPRnet: [e-mail]3jf [44.135.96.6]From
packet-radio-relay  Mon Apr  2 11:31:44 1990Received: by
ucsd.edu; id AA14159    sendmail 5.61/UCSD-2.0-sun    Mon, 2 Apr 90
11:31:47 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA14154    sendmail 5.61/UCSD-2.0-sun via SMTP    Mon, 2 Apr 90
11:31:44 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA20189; Mon, 2 Apr 90 11:27:15 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 27 Mar 90 07:58:36 GMTFrom:
eru!luth!sunic!mcsun!cernvax!chx400!ethz!ethz-inf!muellerm@bloom-
beacon.mit.edu  (Markus Mueller)Organization: Informatik ETH
ZurichSubject: Compiling KA9Q NET with Turbo CMessage-Id:
<[e-mail]>Sender: [e-mail]:
[e-mail] having tested around a bit with
NET.EXE, I am also interested inrecompiling the sources of NET
in order to include stuff of my own. Iintend to use Borland's
Turbo C; however NET has been developped underMicrosoft C and
therefore some problems occur when recompiling the sources.1.
Has anybody already done this? Hints? Pitfalls?2. What memory
model is required for NET? Should I use Large?3. The files
'dirutil.c' and 'pcgen.c' are very system specific and need to
be rewritten from scratch for Turbo C. Anybody has already done
this?   Anybody willing to share sources with me?4. Assembled
parts: Do they work with programs compiled under Turbo C? As far
  as I know Turbo C is sufficiently compatible with Microsoft C
that it   should work.5. Assembler: All assembly routines
require the file 'lmacros.h'. What is   this? I cannot find such
a file in my NET sources.   Markus Mueller   Gruppe
Kommunikationssysteme   Institut fuer technische Informatik und
Kommunikationsnetze   Eidgenoessische Technische Hochschule
CH-8092 Zurich   Switzerland   SWITCH/ARPA/BITNET :
[e-mail]   UUCP               :
[e-mail]   X.400              :
S=mueller;OU=komsys;OU=tik;O=ethz;P=ethz;A=arcom;C=chFrom
packet-radio-relay  Mon Apr  2 11:48:39 1990Received: by
ucsd.edu; id AA14865    sendmail 5.61/UCSD-2.0-sun    Mon, 2 Apr 90
11:49:13 -0700Received: from andy.bgsu.edu by ucsd.edu; id
AA14848    sendmail 5.61/UCSD-2.0-sun via SMTP    Mon, 2 Apr 90
11:48:39 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by andy.bgsu.edu (5.61/3.4)        id
AA18324 ; Mon, 2 Apr 90 14:53:27 -0400Date:  Mon, 2 Apr 90
14:53:27 -0400From: Louis Graue<[e-mail]>Message-Id:
<[e-mail]>To: [e-mail],

snorkelwacker!usc!pollux.usc.edu![e-mail]
t: Re: stacking yagis From packet-radio-relay  Mon Apr  2
15:31:16 1990Received: by ucsd.edu; id AA26359    sendmail
5.61/UCSD-2.0-sun    Mon, 2 Apr 90 15:31:19 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA26351    sendmail
5.61/UCSD-2.0-sun via SMTP    Mon, 2 Apr 90 15:31:16 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA06355; Mon, 2 Apr 90
15:24:31 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 2 Apr 90 22:01:04 GMTFrom:
shlump.nac.dec.com!leftlane.ucs.dec.com![e-mail]
(Mark Curtis)Organization: Digital Equipment CorporationSubject:
RE: Bmailer "going blank".Message-Id:
<[e-mail]>References:
<[e-mail]>Sender: [e-mail]:
[e-mail] don't use double-dos or desqview.   BM
was only program I had loaded inmemory, I wasn't shelling out of
net to run it.  Using a sub shell wouldn'twork well, any traffic
on the freq while in a subshell isn't handled.  Thetnc's buffers
would overflow and data would be lost.  I always exitednet and
ranBM, then restarted net.  Having to exit net to read or
compose mail is amajor painif you receive any real amount of
mail.  I have tried to keep my machine on asmuch as possible so
that other stations can make use of it.  Having totake it
downall the time to deal with mail makes this impossible.Now I
just use NOS.  I telnet to my own system and send mail with the
(S)endcommand.  No, it doesn't have all the nice features, but I
don't have toshutdownthe network to do it.  Shutting down the
network is totallyunacceptible.  Havingto wait a couple of hours
to read my mail while a friend's FTP completesat 1200baud
doesn't thrill me.  I'll take the simple mailer in NOS over that
anyday.NOS the only way to fly, except for a total lack of
documentation, its a greatprogram.  I know read the source, I
have and my eyes are killing me after thisweekend.MarkFrom
packet-radio-relay  Mon Apr  2 16:25:49 1990Received: by
ucsd.edu; id AA29607    sendmail 5.61/UCSD-2.0-sun    Mon, 2 Apr 90
16:25:52 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA29603    sendmail 5.61/UCSD-2.0-sun via SMTP    Mon, 2 Apr 90
16:25:49 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA09193; Mon, 2 Apr 90 16:08:15 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 2 Apr 90 19:23:25 GMTFrom:
idacrd![e-mail]  (Robert McGwier)Organization: idacrd,
princeton, njSubject: HF Modems, DSP, etc.Message-Id:
<[e-mail]>Sender: [e-mail]:
[e-mail]:I am working on DSP based modems for
HF.  This work is being done on aMotorola DSP56001 hooked to a
HD64180(protocol engine).  This modem usesmultiple carrier QPSK,
and for now at least, I use a pilot tone, N dB downfrom the
other carriers, where N is still being played with.  The idea,
is tohave few Hz wide first order PLL's track the data channels
and awider second order PLL track the pilot tone and supply the
freq offset tothe narrow PLL's.  I am using 4 carriers at 75
baud, I will see ifI can get 8 carriers at 37.5 baud.  The idea
is to beat most multipath,get  600 bps and occupy less than 800
Hz.  So far, it meets thesecriteria in THEORY.  I am instituting
tests with N6VV, W3IWI, andVE3GYQ as soon as the production
units come off the line.  With 2 Khzspacing already on HF, this
700-ish Hz of used spectrum should notcause any heartaches.  I
have not done a thing about the crest factorproblem and sideband
radios other than divide the power on eachcarrier to the point
where this will not occur.  This will probably beunacceptable in
the final version,  even though I believe their willbe no way to
set this in reality as guys will have their `mike gains'set from
rear end to appetite and anything I do to beat it, will be
overcomeby operator intervention ;-).  We'll see what the trials
give us in the wayof feedback on this.  The reason for choosing
these stations is that theyare currently on the air with super
active HF stations and have lotsof traffic to pass and are
technically competent to hook this stuffup `in parallel' with
the existing gear (all are running PK-232's)and give a
comparison.  Because of the <<LLLLOOONNNGGG>>> symbol
timescompared to the required sampling rate (aliasing, Nyquist
and all that),I will be using IIR filters in the Costas loops
for the data since FIR'sjust require too many taps to get the
narrow bandwidths and thesesampling rates (probably 7000-ish).
This test set up will allowseamless operation, as the DSP box
runs AEA interface code, and themodems can be changing from 300
bps, 200 Hz shift, FSK to mac-modemwith a simple command
(probably set up in their forwarding files)modem ##where ## is
the number of the modem in the directory of modems storedin ROM.
 The modems currently residing in ROM in addition to theseare(1)
Bel-202.(2) HF packet (subset of BEL-103).(3) All RTTY modes,
including AMTOR.(4) Morse.(5) Satellite modems, all currently
operating birds, including a    quick hack that seems to work
for Oscar 14 (9600 bps K9NG/G3RUH    compatible) with the
discriminator output from my IC-471H.  I will    add adaptive
equalization to this (remember satellite signals are    around
`forever' and slow adaption, even if blind, buys you a lot).
Demod ONLY for AO-13.(6) WEFAX (APT and HF), the recent article
in QST inspired me to emulate    this in software.(7) BPSK.(8)
KPC-2400 style QPSK (this one actually seems to work ;-)To be
finished, hopefully before Dayton:SSTVHF modem just describedI
would like to work on 4800 bps duobinary and modified
duobinary(HAPN compatible without the tradeoffs is duobinary).
I likemodified duobinary as a possibility for plug and play with
mostexisting radios (FM) since it has no DC component and has a
zero inits spectrum at the bit rate.  This means this can fit
into anexisting FM radio if the phase group delay is not just
unbelievablyawful (should be more successful than the 9600 bps
schemes used now).This appears to be a more sane approach to
using existing radiosat a sacrifice in speed over the 9600 but
plug and play.  If I cannotmake it `plug and play' I see no
advantage over the G3RUH 9600 modem.The goal is put it in the
mike jack and speaker jack and go 4800 bpswithout impossibly
long lock up times such as in using PSK.  Modifiedduobinary is
controlled intersymbol interference and 0 excess bandwidthIN
THEORY.After the HF modem work, I hope that VE3JF, W3IWI, and a
few otherswill begin thinking about a new synchronous protocol,
adapted forHF and its vagaries.  I intend to make the modem
adaptive eventuallybut for now I would like to shoot for a
single workable HF modem at practicalbit rates.I apologize if
this was too dry for most.  Just wanted to keep several ofthe
readers here informed and I don't have time to write all of
themindividually.  I find all this exciting and for all my years
of doingDSP, I still get exciting goingUpload MODEMto my new
toy.If you have any bright ideas you would like for me to
consider, pleaselet me know.  WARNING WARNING:  Unless
explicitly prohibited, theseideas could be used in a commercial
product with the above hardware andI don't have the time and
patience for intellectual property games.  If youdon't want me
using it, don't bring it up.BobP.S. Regardless of the harsh
words, and the current topic at their nextmeeting, this HF modem
can and should run on the AMRAD board shown inthe latest QEX as
well as those I am working on.  Actually they probablyneed a bad
guy to inspire them to finish something for a change ;-).--
_________________________________________________________________
___________    My opinions are my own no matter    |    Robert W.
McGwier, N4HY    who I work for! ;-)            |    CCR, AMSAT,
etc.-------------------------------------------------------------
---------------From packet-radio-relay  Mon Apr  2 17:53:27
1990Received: by ucsd.edu; id AA06988    sendmail
5.61/UCSD-2.0-sun    Mon, 2 Apr 90 17:53:39 -0700Received: from
pgd.adp.wisc.edu by ucsd.edu; id AA06972    sendmail
5.61/UCSD-2.0-sun via SMTP    Mon, 2 Apr 90 17:53:27 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: from
kd9uu.ampr.org by pgd.adp.wisc.edu with SMTP    id AA11818 ; Mon,
02 Apr 90 18:37:58 CSTDate: Mon, 02 Apr 90 18:55:53
CSTMessage-Id: <[e-mail]>From: [e-mail]
(Pat Davis, Wis AMPR IP Address Coord.)Reply-To:
[e-mail]:
[e-mail]: BM RAM..In reply
to Patty Winter who writes:>Is it true that the DOS version of
BM really takes up that much>memory? The Mac version recommends
128K; I've actually been>running it happily at 96K>Pat--how big
is a mail file you call "big"? Maybe if I stored 100>or more
messages, I'd need more memory. Seems unlikely it would>balloon
up to 255K, though.>PattyIt's been some time since we (Madison,
WI. HAMS) have hashed this out..The thing is, as you play with
things and tweak the memory available to BMdownward, eventually,
you loose all your mail in the process.  Yes, I coulddo more
testing and maybe get it down to 150K or somthing, but I have
aworkable/nontechnical solution.  I just throw RAM at it *and*
also back upthe mailfile automatically.  "BIG" mailfiles for me
are maybe 300k by-the-way.. ( I still run LIST.COM  against my
BIG/long mail files manually..  It's a hard method to beat. )As
to my suggestion that DOS people try VIEW from HAMSTER, I
suppose Ishould warn folks that it probably isn't any less
likely to loose mailwhen out of RAM either... I should ask Mark
Bramwell about that.  On that note, I shouldsay that Mark has
been busy over the weekend with enhancements to the VIEWmailer..
 Interested parties should GET ALLFILES.ARC and MAILBOOK.EXEfrom
Hamster.business.uwo.ca 129.100.22.100 .  The price is right!Do
I sound like I'm from "Secular Humanists for no BM"? :-)..  I
like VIEWbecause I like LIST.COM from Vernon D. Buerg..  Nuf
[e-mail] 128.104.198.22P.S., I
still run BM (frequently) myself..  It's a lot better than any
mailer I could write!From packet-radio-relay  Mon Apr  2
21:10:39 1990Received: by ucsd.edu; id AA20918    sendmail
5.61/UCSD-2.0-sun    Mon, 2 Apr 90 21:10:43 -0700Received: by
ucsd.edu; id AA20915    sendmail 5.61/UCSD-2.0-sun    Mon, 2 Apr 90
21:10:39 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listMessage-Id:
<[e-mail]>Received: from CUNYVM.BITNET by
ucsd.edu for [e-mail] with BSMTP (1.2);    Tue, 3 Apr 90
04:10:38 GMTReceived: by CUNYVM (Mailer R2.03B) id 8555; Tue, 03
Apr 90 00:04:46 EDTDate:         Tue, 03 Apr 90 00:01:06
EDTFrom: Joseph Skoler <[e-mail]>Subject:
MsysTo: [e-mail] know what the latest version
of Msys is and where I can FTPit from?  I'm pretty sure there's
a version after1.06, but could be wrong.Also, Regarding View, Is
there a source other than Hamster.business.uwo.cafrom which I
can FTP it?  For some reason I haven't been able to establishan
FTP session with Hamster.Thanks and 73, Joe, kc2yu,
[e-mail], [e-mail], SKOHC@CUNYVMFrom
packet-radio-relay  Tue Apr  3 00:17:01 1990Received: by
ucsd.edu; id AA04906    sendmail 5.61/UCSD-2.0-sun    Tue, 3 Apr 90
00:17:05 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA04899    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 3 Apr 90
00:17:01 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA10664; Tue, 3 Apr 90 00:12:10 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 2 Apr 90 15:08:40 GMTFrom:
voder!pyramid!prls!philabs!briar.philips.com![e-mail].
EDU  (Robert Casey)Subject: Switching RS232 lines w/o
glitchesMessage-Id: <[e-mail]>Sender:
[e-mail]: [e-mail] you
need to switch your computer between two RS232 devices (like
amodem and a TNC (amateur radio "radio modem"), and don't want
to spenda lot of money on those switches you see in Inmac,
Misco, etc catalogs,do this:  (I'm assuming that you are using
XON/XOFF mode, where onlypins 2 and 3 are active).  Get a DPDT
toggle switch.  I used a smallswitch, and mounted it inside the
DB25 hood of one of the RS232connectors in one installation.
That avoided the problem of mountingthe switch inside a seperate
loose box.  Wiring the switch is simpleenough, wire the wire to
be the common to the center posts of theswitch, and the A's and
B's go to the outer posts.  You just need to bea little careful
that you don't get one line switching to A and theother
switching to B, or some such.  (It doesn't take a
rocketscientist to get this right! :-)  ).  Now for the grounds:
Just tie allthe pin 1's together, and tie all the pin 7's
together.  these are thegrounds, and you don't need to or really
want to switch these.  I, inone place, tried using one of those
Inmac switch boxes that switch all25 lines.  And I kept getting
glitches when I threw this switch.  Ifixed that by strapping pin
1's together and pin 7's together insidethe box.  (make a note
on the back of the box if you do this, so youwill know later
when you use the box for something else later on!).                ._____
pin 2 of A  pin 2 of common ________./                ._____ pin 2 of B
                         ._____ pin 3 of A pin 3 of
common__________./                ._____ pin 3 of Btie pin 1 of common to
pin 1 of A and pin 1 of Btie pin 7 of common to pin 7 of A and
pin 7 of B(yea, this is trivial, but I've seen people spend a
lot of money on those bigswitch boxes where the above is cheap
and easy)From packet-radio-relay  Tue Apr  3 02:51:04
1990Received: by ucsd.edu; id AA20947    sendmail
5.61/UCSD-2.0-sun    Tue, 3 Apr 90 02:51:07 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA20943    sendmail
5.61/UCSD-2.0-sun via SMTP    Tue, 3 Apr 90 02:51:04 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA18590; Tue, 3 Apr 90
02:35:44 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 2 Apr 90 20:29:27 GMTFrom:
eru!luth!sunic!tut!santra!kolvi.hut.fi![e-mail]
(Kaj Wiik)Organization: Helsinki University of Technology,
FinlandSubject: RUDAK-2Message-Id: <[e-mail]>Sender:
[e-mail]: [e-mail] Msg# TS
Size TO     @ BBS  From   Date    Subject28844 B $  1630 AMSAT
@WW     DB2OS  02-Apr  RUDAK-2: Launch delayed!de DB2OS @
DK0MAVThe launch of RUDAK-2 and RADIO-M1 (RS-14), which was
plannedfor 12 April 1990, is delayed until July 1990 due to a
problemin the scientific GEOS satellite. All analog and
digitaltransponders of the new RS bird are tested and ready
forlaunch.The Downlink frequency of RUDAK-2 is  145.983 MHz
with nominal output power of 2 Watts HF PEP (max. 12
Watts).Uplinks are on 435.016 MHz for 1200 Bit/s Manchester
FSK(FUJI, PACSAT) modulation,  435.155 MHz for 2400 Bit/s
BPSK,435.193 MHz for 4800/9600 Bit/s RSM modulation and 435.041
MHzfor Digital Signal Processing (DSP) experiments.Please do NOT
use these Uplink-Frequencies until RUDAK-2 isfully commissioned
by the RUDAK commandstations.Detailed informations about the
RUDAK-2 system were published in the latest AMSAT-DL Journal.
The english translatedversion will be soon published too in the
OSCAR-NEWS of AMSAT-UK, AMSAT-NA News Service and other
sources.Vy 73s Peter DB2OSAMSAT-DL/RUDAK-GroupFrom
packet-radio-relay  Tue Apr  3 02:51:32 1990Received: by
ucsd.edu; id AA20973    sendmail 5.61/UCSD-2.0-sun    Tue, 3 Apr 90
02:51:33 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA20969    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 3 Apr 90
02:51:32 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA18551; Tue, 3 Apr 90 02:35:31 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 2 Apr 90 20:27:16 GMTFrom:
eru!luth!sunic!tut!santra!kolvi.hut.fi![e-mail]
(Kaj Wiik)Organization: Helsinki University of Technology,
FinlandSubject: DOVE newsMessage-Id: <[e-mail]>Sender:
[e-mail]: [e-mail]:
Sun, Mar 18, 1990   5:45 PM GMT              Msg:
KGJA-4199-1727From:   BMCGWIERTo:     dcowdin, msatcmd, amsatCC:
    wmccaaSubj:   DOVE RECOVEREDHowdy: W5UN and/or NK6K reset
the DOVE CPU and got the transmitter off last night.Dave
Blaschke, W5UN, is the owner of the world's largest privately
owned2 meter antenna.  With 32.5 dBi gain, and nearly 2
megawatts of EIRP, hehas been transmitting the reset sequence
for several days.  The batteriesbegan flattening out and we were
alerted by Alberto Zagni, I2KBD, that thetransmitter power was
dropping significantly at the end of the eclipse.Alerted to this
fact, I had a planning session with W5UN as to the twobest times
to reset the spacecraft CPU and turn the transmitter off.
Thefirst was at the end of the eclipse period, when transmitter
power wouldbe at its lowest point.  If it turned out that the
battery voltage was toolow to maintain the GASFET preamp in the
receiver, then the next time totry was just as the transmitter
power was falling off (soon after it leftthe sun and started the
voltage descent in eclipse).  The latter was thetime which
turned out to be successful.  Almost immediately following
thereset, NK6K sent charging rate commands and transmitter state
commands.This morning, I sent the S band transmitter on command.
 It immediatelycame on and K0RZ relayed acked packets, etc. to
me over the phone (Idon't have S band capability YET).  Bill
claims that the S band signalvaries from about 20-30 dB out of
the noise.  IMPORTANT!!:  If you haveS band capability and copy
a series of short packets, this will containvital telemetry,
please preserve it for us.  YOU MUST CAPTURE RAW FRAMES,and this
is usually done by using KISS and some binary capture
routine.TLMDC.EXE, the microsat telemetry can capture, but not
decode these frames.This has been a harrowing experience (for
many) and once again, theserobust little cubes take a lickin and
keep on tickin! 73 Bob(relayed from TeleMail by I2KBD - ITAMSAT
Project)From packet-radio-relay  Tue Apr  3 02:51:35
1990Received: by ucsd.edu; id AA20979    sendmail
5.61/UCSD-2.0-sun    Tue, 3 Apr 90 02:51:37 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA20975    sendmail
5.61/UCSD-2.0-sun via SMTP    Tue, 3 Apr 90 02:51:35 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA18597; Tue, 3 Apr 90
02:35:54 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 2 Apr 90 20:33:26 GMTFrom:
eru!luth!sunic!tut!santra!kolvi.hut.fi![e-mail]
(Kaj Wiik)Organization: Helsinki University of Technology,
FinlandSubject: Webersat modulationMessage-Id:
<[e-mail]>Sender: [e-mail]:
[e-mail]: Sun, Mar 18, 1990   6:20 PM GMT
         Msg: NGJA-4199-1758From:   UOSATTo:     AMSATSubj:
Some WEBER "Raised Cosine" NotesDumped on 17 Mar 90 00:00:08
Saturday  by ELE093 From: JAMES MILLER G3RUH via TMAIL Address:
UOSAT Date: 1990 Mar 16                           =====
-------------------------------------------------
     RAISED COSINE SPECTRUM ETC
--------------------------                       by James Miller
G3RUH WEBER is using different transmit waveform filtering than
the others.The baseband shape of a Weber bit is    D(t)*(1+Cos
2*pi*t/T)   where:  D(t) is the data, = +1 for logic "1", = -1
for logic "0",  T is the bit period  t is time - runs from -T/2
to +T/2 for each bit.This is the "raised cosine shaping" you
hear being discussed.  If you plotout the formula A = 1 + COS(X)
, with X = -180 TO +180 deg, this should bequite clear.The
spectrum of this signal is -3db at +/-1200 Hz, -11.5 db at
+/-1800 Hz,NIL at +/-2400 Hz, and the first sidelobe is a
negligible -32db at +/-3000Hz.In contrast, the shape of PACSAT,
and LUSAT is approximately  D(t), whichis "straight PSK".  Each
bit is rectangular. Most of the energy iscontained between the
first nulls at +/-1200 Hz.  The first sidelobe is-13db at
+/-1800 Hz.So roughly speaking, the Weber modulation spreads
some +/-2400Hz whereasthe others are +/-1200 Hz.  You'd expect
this because the Weber bits are"narrower" than 1 bit;  compare
your 1+COS(X) sketch with an enclosingrectangle.H Now the
receiver 3 db bandwidth is typically 3 kHz, i.e. only +/- 1500
Hz,so a certain amount of Weber energy is lost on reception.  Or
lookedanother way, the transient phase response of a typical SSB
receiver toWeber data will show transient loss of coherence.
This is why the LOCKLED flickers in some systems, and the bit
error rate can be higher -insufficient receiver bandwidth.The
theoretical minimum RF bandwidth required to transmit 1200 bps
binaryPSK is 1200 Hz, i.e. +/-600 Hz. A practical minimum, which
is achieved bythe sort of technique I use in the 9600 baud modem
TX secti  is approx+/- 900 Hz.Weber uses a look-up table on a
bit by bit basis; it's a "1 bit finiteimpulse response" shaping
filter or F.I.R.  The 9600 baud modem which ison UOSAT-D/UO-14
looks-up over a span of 8 bits.  So the audio spectrum
iscorrespondingly tighter, and by design has sidelobes at least
50 db down.The waveform is the same as my eprom TXBETA1's
Selection 0By the way, you could also use my 9600 baud modem to
drive a balancedmodulator to generate very sweet 9600 bps PSK.
The RF bandwidth would beabout 15 kHz. 73 de James G3RUH @
GB7SPV 1990 Mar 16P.S. Sorry if you knew all this already.  I've
had many enquiries, so thisresponse seemed appropriate.  I
haven't seen it published elsewhere.(relayed from TeleMail by
I2KBD - ITAMSAT Project)From packet-radio-relay  Tue Apr  3
19:00:47 1990Received: by ucsd.edu; id AA01494    sendmail
5.61/UCSD-2.0-sun    Tue, 3 Apr 90 19:00:50 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA01490    sendmail
5.61/UCSD-2.0-sun via SMTP    Tue, 3 Apr 90 19:00:47 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA20154; Tue, 3 Apr 90
18:57:07 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 3 Apr 90 06:07:45 GMTFrom:
microsoft![e-mail]  (Joseph HOLMAN)Organization:
Microsoft Corp., Redmond WASubject: SAREX STS-35Message-Id:
<[e-mail]>Sender: [e-mail]:
[e-mail]    i'm disappointed to read in the the AMSAT
Journal    that the SAREX STS-35 mission will only have a
28.5    inclination - making direct communications to Seattle    47.7
latitude impossible...    is anybody out there going to be
digipeating someway,    somehow, so us poor out o' luck northerners
will have    a way to make contact with the packet set-up ???    Joe
Holman,
KA7LDN    [e-mail]    uw-beaver!microsoft!joehol    206-882-8
921    cq space shuttle ? ! ?From packet-radio-relay  Tue Apr  3
21:45:50 1990Received: by ucsd.edu; id AA12178    sendmail
5.61/UCSD-2.0-sun    Tue, 3 Apr 90 21:45:52 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA12168    sendmail
5.61/UCSD-2.0-sun via SMTP    Tue, 3 Apr 90 21:45:50 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA00446; Tue, 3 Apr 90
21:39:41 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 4 Apr 90 04:38:47 GMTFrom:
[e-mail]  (Patty Winter)Organization: Apple Computer
Inc, Cupertino, CASubject: Re: SAREX STS-35Message-Id:
<[e-mail]>References: <[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail] (Joseph HOLMAN)
writes:>    i'm disappointed to read in the the AMSAT Journal>    that
the SAREX STS-35 mission will only have a 28.5>    inclination -
making direct communications to Seattle>    47.7 latitude
impossible...>>    is anybody out there going to be digipeating
someway,>    somehow, so us poor out o' luck northerners will
have>    a way to make contact with the packet set-up ???Joe--As
previously announced in the AMSAT bulletins that Phil Karn
posts,AMSAT will have an extensive redistribution network active
duringboth of the next two SAREX missions.Patty--
*****************************************************************
************ Patty Winter N6BIS                        INTERNET:
[e-mail]: [44.4.0.44]                     UUCP:
{decwrl,nsc,sun}!apple!winter************************************
***************************************** From
packet-radio-relay  Wed Apr  4 03:45:57 1990Received: by
ucsd.edu; id AA08273    sendmail 5.61/UCSD-2.0-sun    Wed, 4 Apr 90
03:45:59 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA08264    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 4 Apr 90
03:45:57 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA18637; Wed, 4 Apr 90 03:45:41 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 3 Apr 90 18:40:32 GMTFrom:
hpcc01!col![e-mail]  (Bdale Garbee)Organization: HP
Colorado Springs DivisionSubject: Re: Compiling KA9Q NET with
Turbo CMessage-Id: <[e-mail]>References:
<[e-mail]>Sender: [e-mail]:
[e-mail] net development is now under Turbo C
2.0.BdaleFrom packet-radio-relay  Wed Apr  4 09:08:18
1990Received: by ucsd.edu; id AA26745    sendmail
5.61/UCSD-2.0-sun    Wed, 4 Apr 90 09:08:22 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA26739    sendmail
5.61/UCSD-2.0-sun via SMTP    Wed, 4 Apr 90 09:08:18 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA06141; Wed, 4 Apr 90
09:00:47 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 4 Apr 90 12:20:09 GMTFrom:
zaphod.mps.ohio-state.edu!hp-sdd!ncr-sd!ncrcae!secola!mechling@tu
t.cis.ohio-state.edu  (Randy Mechling)Organization: NCR Comten
ColumbiaSubject: Digital CommunicationsMessage-Id:
<[e-mail]>Sender:
[e-mail]: [e-mail] am
planning to do some work in the area of digital communications
over aradio link for my Master's Thesis in Computer Science.  In
particular I planto develop a comm package similar to Amtor that
would use all the latesttricks in error detection/correction and
packing of data to increase theoverall through-put.Can anyone
tell me more about the inner workings of Amtor?  What protocol
does it use and what methods of error detection and correction
does it use?With a weak link or lots of QRM Amtor seems to have
to retransmit severaltimes to get the packet across.  It may be
that not too much correction isbeing done.  If someone could set
me straight on this I would appreciate it.I feel the biggest
part of Ham Radio is communication.  This may be usingCW, phone
or more and more some type of digital signal.  The
possibilitiesusing digital methods are very exciting.  Let's
encourage more research inthis area.Randy Mechling
[e-mail] packet-radio-relay
Wed Apr  4 09:24:21 1990Received: by ucsd.edu; id
AA28081    sendmail 5.61/UCSD-2.0-sun    Wed, 4 Apr 90 09:24:50
-0700Received: from WSMR-SIMTEL20.ARMY.MIL by ucsd.edu; id
AA28046    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 4 Apr 90
09:24:21 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listMessage-Id:
<[e-mail]>Received: from paxrv-nes.navy.mil
by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 4 Apr 90 10:24:02
MDTDate: 4 Apr 90 12:13:00 EDTFrom: "SWEIGERT, DAVID"
<[e-mail]>Subject: WET NET, Packet Radio for
USNTo: "packet-radio"
<[e-mail]>From:David
SweigertTo:Interested PacketeersRef:Navy's Use of Shipboard
Packet Systems  A technical abstract is being created to provide
appropriateofficials within the US Navy telecommunications
community withan explanation of packet radio and how it may be
utilized tomove non-tactical mission support (supply and
maintenance) datafrom ship to shore based host computers.  I am
serving as the coordinator for this effort representinga
coalition of packet enthusiasts.  My interest is scholarly,
Iwant to see US Navy shipboard telcommunications improved.  I am
requesting individuals with appropriate contributions toE-mail
me your comments and ideas (so far I have received verygood
feed-back).  I will be broadcasting draft abstracts to
allowinterested parties a chance to chop on the document.  The
Navy is interested and wants to hear more, let's organizea top
notch document.Sincerely,Dave SweigertWB9VKOAnnapolis, MD From
packet-radio-relay  Wed Apr  4 09:24:59 1990Received: by
ucsd.edu; id AA28117    sendmail 5.61/UCSD-2.0-sun    Wed, 4 Apr 90
09:25:22 -0700Received: from WSMR-SIMTEL20.ARMY.MIL by ucsd.edu;
id AA28094    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 4 Apr 90
09:24:59 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listMessage-Id:
<[e-mail]>Received: from paxrv-nes.navy.mil
by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 4 Apr 90 10:24:23
MDTDate: 4 Apr 90 12:03:00 EDTFrom: "SWEIGERT, DAVID"
<[e-mail]>Subject: WET NET, US Navy and
PacketsTo: "packet-radio"
<[e-mail]>From:David
SweigertTo:Interested PacketeersRef:Navy's Use of Shipboard
Packet Systems  A technical abstract is being created to provide
appropriateofficials within the US Navy telecommunications
community withan explanation of packet radio and how it may be
utilized tomove non-tactical mission support (supply and
maintenance) datafrom ship to shore based host computers.  I am
serving as the coordinator for this effort representinga
coalition of packet enthusiasts.  My interest is scholarly,
Iwant to see US Navy shipboard telcommunications improved.  I am
requesting individuals with appropriate contributions toE-mail
me your comments and ideas (so far I have received verygood
feed-back).  I will be broadcasting draft abstracts to
allowinterested parties a chance to chop on the document.  The
Navy is interested and wants to hear more, let's organizea top
notch document.Sincerely,Dave SweigertWB9VKOAnnapolis, MD From
packet-radio-relay  Wed Apr  4 10:17:18 1990Received: by
ucsd.edu; id AA02682    sendmail 5.61/UCSD-2.0-sun    Wed, 4 Apr 90
10:17:22 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA02668    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 4 Apr 90
10:17:18 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA10661; Wed, 4 Apr 90 10:06:57 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 4 Apr 90 17:06:27 GMTFrom:
zaphod.mps.ohio-state.edu!wuarchive!cec2![e-mail]-sta
te.edu  (Scott Eric Keller)Organization: Washington University,
St. Louis, MOSubject: Packet info wantedMessage-Id:
<[e-mail]>Sender:
[e-mail]: [e-mail]    I have
convinced my professor in my "Computer Communications" classthat
a paper on amateur packet radio would be an appropriate project
for hisclass. However, I now have the task of explaining the
workings, use, and problems concerning packet radio.
Unfortinately, packet is not a mode that Iam intimately familiar
with. I know we have many Packet Gods out here,so I would like
any reccommendations on books, sources, papers, articles,
people, etc. that would aid my endeavor. I only need to fill
about 10-15 pages,but I would like to learn as much as I can.
(Plus I'll find out what I want to buy when I get out in
May....)    I already have the AX.25 book, Gateway book, and
Computer NetworkingConference books from the ARRL on order.
Other reccomendations would be appreciated.                    Reply by mail,
TNX in advance...                        Scott --     Scott Keller (KA0WCH) -
Permanent Undergrad - Dept. of Computer Science        Wa$hington
Univer$ity - St. Louis, Mo. USAInternet: [e-mail]
    UUCP:ihnp4!wucec2!sek9424 (I think...)      The opinions
represented here are mine and mine alone, not Wa$h. U's.From
packet-radio-relay  Wed Apr  4 14:36:51 1990Received: by
ucsd.edu; id AA24638    sendmail 5.61/UCSD-2.0-sun    Wed, 4 Apr 90
14:36:55 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA24628    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 4 Apr 90
14:36:51 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA27416; Wed, 4 Apr 90 14:23:28 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 4 Apr 90 22:06:05 GMTFrom:
ncelvax![e-mail]  (Geoff Dann)Organization: Naval Civil
Engineering Lab, Port HuenemeSubject: ka9q over Sytek 4140
EthernetMessage-Id: <[e-mail]>Sender:
[e-mail]: [e-mail] anyone
out there run ka9q over Sytek Ethernet (or PC-NETbroadband)
cards?  I've seen references to it here, but haven't madeit work
yet.  Sytek software on hand includes MPD4140.EXE and
MPDINIT.EXE  (MPD means "multi-protocol driver".)In one of the
manuals, i've seen reference to FTP Software, Inc, whichmakes me
think that maybe the Sytek drivers should conform to the FTPInc.
packet driver spec.  However, KA9Q's software doesn't find
adriver, when I enter an "attach packet 0x61 5 1500" command.
The"PKTCHK" program distributed with the Clarkson drivers can't
find apacket driver.  I tried using the "nb" packet driver from
Clarkson, and the ethernetcard transmits something.  Think it's
802.3 packets instead of DIXethernet packets.  The sequence that
got me this far is:    mpd4140    ipx    netbios    nb 0x7a 192.9.200.101
1500I've looked at the BYU instructions for resolving the
802.3/DIXethernet packet issue.  Looks like that requires
modifying thesoftware on the Novell servers, which I don't want
to do.  For now,all I want is for the Sytek hardware to talk to
ka9q.
Thanks......            [e-mail]3cf
x@w8akf-1From packet-radio-relay  Wed Apr  4 15:47:00
1990Received: by ucsd.edu; id AA00952    sendmail
5.61/UCSD-2.0-sun    Wed, 4 Apr 90 15:47:02 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA00948    sendmail
5.61/UCSD-2.0-sun via SMTP    Wed, 4 Apr 90 15:47:00 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA02383; Wed, 4 Apr 90
15:36:31 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 4 Apr 90 20:47:37 GMTFrom:
ubc-cs!alberta!atha!aurora.AthabascaU.CA![e-mail]
ton.edu  (Lyndon Nerenberg)Organization: Athabasca
UniversitySubject: Re: HF packet modems...Message-Id:
<[e-mail]>References:
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail] (Dennis
S. Breckenridge) writes:   One of the downsides is that the TB
works like a spread spectrum   audio channel, I don't know whats
going to happen with fading etc...You're going to have all kinds
of trouble. If the modem desides to"retrain" based on selective
fading, you're going to lose that portionof the audio channel.
While this is all well and good when the linktakes a dive, the
modem doesn't "retrain" when conditions *improve*therefore
selective fading could eventually reduce your throughputto
zero.--Lyndon Nerenberg  CF6BBM / Computing Services / Athabasca
University     {alberta,decwrl}!atha!lyndon ||
[e-mail] packet-radio-relay  Wed Apr  4
21:33:24 1990Received: by ucsd.edu; id AA26638    sendmail
5.61/UCSD-2.0-sun    Wed, 4 Apr 90 21:33:26 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA26634    sendmail
5.61/UCSD-2.0-sun via SMTP    Wed, 4 Apr 90 21:33:24 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA22982; Wed, 4 Apr 90
21:26:21 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 5 Apr 90 01:10:37 GMTFrom:
kd4nc!km4ba![e-mail]  (Alan Barrow)Organization: km4ba's
packet radio gateway, Atlanta GA.Subject: Re: Packet(?) on
commercial bandsMessage-Id: <[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender:
[e-mail]:
[e-mail]@ka9q.bellcore.com (Phil Karn)
writes:>In article <[e-mail]>
[e-mail] (Henry Mensch) writes:>>finally, DES has been
broken a variety of times by a variety of>>people; not all of
these people have been highly-skilled scientists,>>either
8-]>Please back up this statement. There have been no known,
proven cases in>which DES has been "broken" in the sense that
the key was derived from>ciphertext alone (or even some matching
cipertext/plaintext pairs) except>for cases where the key was
trivially chosen (e.g., an English word), making>a brute-force
key search feasible.stuff deleted....Unfortunately, the recent
hacker gang from West Germany was ableto  defeat the encryption
used in Unix systems, (Is this DES???)if the account that I read
was accurate. It *did* involve the assumption of common language
words as passwords, combined with leading and trailing ascii
charecters.(IE: camel1, 4pony, etc.) It also involved being able
to look at /etc/passwd, which in most newer systems does not
divulge anything.Users seem to have favorite words as names to
use as passwords, andattempts by Unix to make them more secure
usually result in addingsimple non-alphabetic chars. to their
favorite word.Bottom line.... Unskilled, but clever hackers with
pc's and modemsfound lots of holes, and used them to "back into"
secure passwords.They could not do it every time, but they were
able to back intoenough passwords to do their "thing". The
ironic thing is that they would have been easy victims oftheir
techniques! (I guess that is why they got caught by
anastronomer/physics type!) 8->Anyway, the account was
interesting reading, and I am sure everyone has heard of it. But
it was an example of peopledefeating, if not breaking
encryption. (Kind of like kickingin a door that has 2 strong
deadbolts on it. doesn't make muchdifference if the door frame
isn't strong also!)No claims to cryptography (or spelling)
expertise here! (so don't flame too hard!  :-> )73Alan Barrow
km4ba..!gatech!kd4nc!km4ba!alan..!hplabs!hpfcse!hpuagai!alanFrom
packet-radio-relay  Thu Apr  5 10:03:29 1990Received: by
ucsd.edu; id AA19494    sendmail 5.61/UCSD-2.0-sun    Thu, 5 Apr 90
10:03:32 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA19481    sendmail 5.61/UCSD-2.0-sun via SMTP    Thu, 5 Apr 90
10:03:29 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA07362; Thu, 5 Apr 90 09:52:09 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 5 Apr 90 16:17:59 GMTFrom:
idacrd![e-mail]  (Robert McGwier)Organization: idacrd,
princeton, njSubject: Re: DOVE newsMessage-Id:
<[e-mail]>References: <[e-mail]>Sender:
[e-mail]: [e-mail]
article <[e-mail]>, by [e-mail] (Kaj Wiik):>
Posted: Sun, Mar 18, 1990   5:45 PM GMT              Msg:
KGJA-4199-1727> From:   BMCGWIER>  > Dave Blaschke, W5UN, is the
owner of the world's largest privately owned> 2 meter antenna.
With 32.5 dBi gain, and nearly 2 megawatts of EIRP, he>Not any
more.  I am awfully sad to have to let you know that Dave loss
theentire array to a tornado.  It is a total loss.  One of the
great personalachievements in ham radio gone, probably
forever.Bob --
_________________________________________________________________
___________    My opinions are my own no matter    |    Robert W.
McGwier, N4HY    who I work for! ;-)            |    CCR, AMSAT,
etc.--------------------------------------

--------------------------------------From packet-radio-relay
Thu Apr  5 16:16:56 1990Received: by ucsd.edu; id
AA20512    sendmail 5.61/UCSD-2.0-sun    Thu, 5 Apr 90 16:17:00
-0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA20500    sendmail 5.61/UCSD-2.0-sun via SMTP    Thu, 5 Apr 90
16:16:56 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA03131; Thu, 5 Apr 90 16:08:40 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 3 Apr 90 11:51:49 GMTFrom:
att!tsdiag!nn2z!@ucbvax.Berkeley.EDU  (Dave Trulli)Organization:
NN2Z Packet GatewaySubject: Re: BM RAM..Message-Id:
<[e-mail]>References: <[e-mail]>Sender:
[e-mail]: [e-mail] is a
smalll model program, on DOS and takes us around 94k of memoryif
you set the size of the mailbox to about 400 message. The sizeof
the object file is about 33k and even if it used all its
datasection the that would be another 64k so I would say the way
I haveit written its wont use more that 96k. If its crashing its
must bedue to some other problem so mail me some more
details.How many message are in you mail box ?Dave
[e-mail] or [e-mail]
packet-radio-relay  Thu Apr  5 16:34:15 1990Received: by
ucsd.edu; id AA22209    sendmail 5.61/UCSD-2.0-sun    Thu, 5 Apr 90
16:34:19 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA22193    sendmail 5.61/UCSD-2.0-sun via SMTP    Thu, 5 Apr 90
16:34:15 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA03909; Thu, 5 Apr 90 16:19:54 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 5 Apr 90 21:59:28 GMTFrom:
van-bc!ubc-cs!alberta!atha![e-mail]  (Richard
Loken)Organization: Athabasca UniversitySubject: CP/M sofware
for packet radio and TCP/IPMessage-Id:
<[e-mail]>Sender:
[e-mail]: [e-mail]
question has been asked, and I wasn't interested at the time.Is
there any software around?  I know that there is a version of
tcp/ip somewhere and I understand Phil Karn wrote his eary stuff
on CP/M.  Does somebodyhave the early Karn package?  Assuming it
exists of course.I sort of hope there isn't any, then I will
have to write some.  Build aninterface and shoot for 56k :)
*********        73    **********        Richard Loken VE6BSV   .
****          ..      ****        Athabasca University ....     ****
  Athabasca, Alberta Canada..........****
[e-mail]    {alberta|decwrl}!atha!techFrom
packet-radio-relay  Fri Apr  6 01:11:52 1990Received: by
ucsd.edu; id AA27233    sendmail 5.61/UCSD-2.0-sun    Fri, 6 Apr 90
01:12:13 -0700Received: from WSMR-SIMTEL20.ARMY.MIL by ucsd.edu;
id AA27227    sendmail 5.61/UCSD-2.0-sun via SMTP    Fri, 6 Apr 90
01:11:52 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: from chx400.switch.ch ([130.59.1.2])
by WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 6 Apr 90 02:10:56
MDTReceived: by chx400.switch.ch (5.57/Ultrix2.4-C)    id AA23919;
Fri, 6 Apr 90 08:56:47 +0200Received: from zit.cigy  by
cgch.cigy     id AA23073; Fri, 6 Apr 90 08:52:39 +0200
(4.0/SMI-3.2-CG-1.0G) Received: by zit.cigy      id AA18253; Fri, 6
Apr 90 08:52:24 mes  (15.11/SMI-3.2-CG-1.0A) Message-Id:
<[e-mail] >Subject: Re: DOVE newsTo:
[e-mail]: Fri, 6 Apr 90 8:52:22
MESZFrom: Joseph C. Pistritto <cgch!jcp>Cc:
cgch!bpistrIn-Reply-To: <[e-mail]>;
from "Robert McGwier" at Apr 5, 90 4:17 pmMailer: Elm [revision:
64.9]Gee that's really awful.  (The tornado taking his antenna
out).What about getting together a net-wide collection for
reconstructionfunds.  After all, that system was an asset that
AMSAT used torecover a very expensive satellite, and it might be
needed again.I don't know he owner personally, but such an array
must have costa fortune to construct.  (Was this the one that
appeared in theARRL antenna book a couple of years ago?)  If we
get an estimateof how much it will cost to put back together,
I'm willing to signup to contribute...--Joseph C. Pistritto
([e-mail] -or- cgch![e-mail]) Ciba Geigy AG,
R1241.1.01, Postfach CH4002, Basel, Switzerland Tel: [phone]
6155 (work) [phone] (home)   GMT+2hrs!From
packet-radio-relay  Fri Apr  6 06:08:25 1990Received: by
ucsd.edu; id AA19029    sendmail 5.61/UCSD-2.0-sun    Fri, 6 Apr 90
06:08:33 -0700Received: from WSMR-SIMTEL20.ARMY.MIL by ucsd.edu;
id AA19006    sendmail 5.61/UCSD-2.0-sun via SMTP    Fri, 6 Apr 90
06:08:25 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listMessage-Id:
<[e-mail]>Received: from mitvma.mit.edu by
WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 6 Apr 90 07:07:58
MDTReceived: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP
R1.2.1MX) with BSMTP id 2316; Fri, 06 Apr 90 09:07:17
EDTReceived: from SMCVAX.BITNET (GOODWIN) by MITVMA.MIT.EDU
(Mailer R2.05) with BSMTP id 7492; Fri, 06 Apr 90 09:07:16
EDTDate: Fri, 6 Apr 90 07:58 EDTFrom:
[e-mail]: Packet S/W on DEC
PCsTo: [e-mail]-Vms-To:
IN%"[e-mail]"Is anyone successfully
running packet on a DEC Rainbow?  I have one availableto me with
both DOS & CP/M, 512K.  If anyone knows of software that works
withthis machine, I'd appreciate any information you can send me
about
it.Thanx...======================================================
====================Dave Goodwin
 |Coordinator, PC Support/User Services         | To err is
human.VAX System Manager                            | To really
foul things up,----------------------------------------------|
You need a computer.BitNet/CREN : Goodwin@Smcvax
 |Ma Bell     : [phone] X2220             |Pony Express:
Saint Michael's College         |              Department of
Computer Services |              Winooski Park
|              Colchester, VT 05439
|================================================================
==========From packet-radio-relay  Fri Apr  6 08:36:32
1990Received: by ucsd.edu; id AA28687    sendmail
5.61/UCSD-2.0-sun    Fri, 6 Apr 90 08:37:03 -0700Received: from
WSMR-SIMTEL20.ARMY.MIL by ucsd.edu; id AA28616    sendmail
5.61/UCSD-2.0-sun via SMTP    Fri, 6 Apr 90 08:36:32 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listMessage-Id:
<[e-mail]>Received: from CUNYVM.CUNY.EDU by
WSMR-SIMTEL20.ARMY.MIL with TCP; Fri, 6 Apr 90 09:35:38
MDTReceived: from DEARN by CUNYVM.CUNY.EDU (IBM VM SMTP
R1.2.2MX) with BSMTP id 1658; Fri, 06 Apr 90 11:34:58
EDTReceived: from DBSTU1 (C0033003) by DEARN (Mailer R2.03B)
with BSMTP id 0022; Fri, 06 Apr 90 17:33:23 CETDate:
Fri, 06 Apr 90 17:30:51 MEZFrom: "Detlef J. Schmidt"
<[e-mail]>Subject:
availability of TheNetNodeTo: Packet-radio
<[e-mail]>There was a tremendous
amount of requests for the new TheNetNode.So here is the answer
to all those questions asking for availability.Please forgive me
if I couldn't reply to all individual requests.For all those
netlanders who didn't caught the first intro ofTheNetNode here
is some short info ( again ).                     TheNetNode
               by NORD><LINKThis new Version runs entirely
inside a PC or Atari computer and usesTNC2s with a special KISS
Eprom as an "intelligent interface".New features are: - up to
255 Channels on one Computer - Call forwarding (just connect
MYBOX, the node will know what call   to connect you with and
how to get there. If a BBS is down the sysop   may set a route
to an adjacent box. - Converse Mode - Monitor Heard list - Help
system expandable by sysop - Software updating thru radio -
Watchdog hardware for TNC and Computer (simple) - Sysop has full
remote access do DOS - sophisticated statistics done for every
channel ( quality, thruput, etc) - written in C (we use Turbo-C
2.0) - TNC-KISS firmware with TOKEN-RING protocolHardware? Only
standard items (plus simple watchdog). The PC and all TNCsare
connected together in a token ring.Fortunatly some kind OM
offered to translate the german version of thedoc to an english
version. This might take some days.TheNetNode will be uploaded
to some servers / mailers. As I don'thave direct access to
SIMTEL20 this will be done by that OM too.Like before all
software of NORD><LINK is priced at 00.00 $. It may beused
freely for any amateur application, modified, and
redistributedunder the same conditions. But there are
restrictions forcommercial users.If you don't like to wait for
the software to be available on a serveryou might get it via
regular mail. Any PC size disk may be supplied.Send your request
to               NORD><LINK e.V.             Hinter dem Berge 5
          D-3300  Braunschweig                   F.R.G.Remember:
the software comes at no charge, but you have to care for
theexpense of postage, air mail costs, floppies, etc. So be
shure to includesufficient IRCs or dollar bills at your choice
to cover the costs.A mailing label with your own address would
be very helpfull.More details will be available soon.Detlef (
dk4eg ).From packet-radio-relay  Fri Apr  6 12:03:24
1990Received: by ucsd.edu; id AA15433    sendmail
5.61/UCSD-2.0-sun    Fri, 6 Apr 90 12:03:30 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA15425    sendmail
5.61/UCSD-2.0-sun via SMTP    Fri, 6 Apr 90 12:03:24 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA11588; Fri, 6 Apr 90
11:57:42 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 4 Apr 90 15:31:44 GMTFrom:
cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nas
a.gov!peregrine!ccicpg!cci632!rit!ritcsh!ultb![e-mail]
o-state.edu  (C.E. Piggott)Organization: Information Systems and
Computing @ RIT, Rochester, New YorkSubject: Re: Channel access,
node vs digiMessage-Id: <[e-mail]>References:
<[e-mail]>Sender:
[e-mail]: [e-mail] this
part of the country, a LOT of work has been done with theNET/ROM
and TheNet systems.  What you say is DEFINITELY true; youwill
get a much better response by using a single-port node as
adigipeater than as a single-port node.  This is true for both
reasonsyou noted: hidden-transmitter, and the fact that the
"node" is no longera digipeater leaves us with the fact that it
is another stationcompeting for air-time.  Throw into this an
occasional nodes broadcastand things get worse.HOWEVER, make it
multiport and it's a different story.  On amultiport node
(usually three transmitters: a user uplink, abackbone link going
in one direction, and a backbone link goingin the other
direction) the TNC's are separate and can
transmitsimultaneously.  While it's ACK'ing you back on the
uplink, yourpacket is going out.  For this reason, a club has a
lot ofmotivation to chip in for their higher-speed modems on
thebackbone links rather than all individually upgrading as
users.One statistic that comes up time and time again with the
N.E.D.A.experiments is in the arrangement of backbone links.
Even if theselinks are hidden-transmitter-free, if you've only
got two stationson frequency, you get a FIVE-TO-ONE IMPROVEMENT
over adding justONE MORE transmitter.  We can prove this with
channel-usageanalysis quite easily, and it's also quite logical
(I'll continueif there's interest in this topic).The point I'm
trying to make is that single-port nodes are, in mostcases, not
only completely useless but actually damage the channelmore than
a plain vanilla digipeater would.  IN MOST CASES.Chris n2jgw----
Christopher E. Piggott, N2JGW
[e-mail]
       [e-mail] [44.69.0.1]Rochester Institute of
Technology               N2JGW @ WB2WXQAmateur Radio Club K2GXT
                      [e-mail]
packet-radio-relay  Fri Apr  6 16:01:59 1990Received: by
ucsd.edu; id AA04997    sendmail 5.61/UCSD-2.0-sun    Fri, 6 Apr 90
16:02:01 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA04993    sendmail 5.61/UCSD-2.0-sun via SMTP    Fri, 6 Apr 90
16:01:59 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA27759; Fri, 6 Apr 90 16:01:16 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 6 Apr 90 15:44:56 GMTFrom:
vsi1!zorch!tandem![e-mail]  (Kevin J.
Rowett)Organization: Tandem Computers, Inc.Subject: Re: ka9q
over Sytek 4140 EthernetMessage-Id:
<[e-mail]>References:
<[e-mail]>Sender: [e-mail]:
[e-mail] article <[e-mail]>
[e-mail] (Geoff Dann) writes:>Has anyone out there run
ka9q over Sytek Ethernet (or PC-NET>broadband) cards?  I've seen
references to it here, but haven't made>it work yet.  >Geoff,You
can pick up a packet driver for these cards from tandem.com
~ftp/hamradio/pclana.arcThis packet driver was never sent to
Russ for general distribution,since I was hoping these darn
cards would disappear from the faceof the earth.Just one of the
problems encountered is the card consistently advertises buffers
it doesn't have.However, N6GN and I were able to use a pair of
them as part of a 2Mbps10 GHz packet radio link.  See the Dec
'89 issue of Ham [e-mail]
packet-radio-relay  Fri Apr  6 16:48:18 1990Received: by
ucsd.edu; id AA08931    sendmail 5.61/UCSD-2.0-sun    Fri, 6 Apr 90
16:48:20 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA08926    sendmail 5.61/UCSD-2.0-sun via SMTP    Fri, 6 Apr 90
16:48:18 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA29805; Fri, 6 Apr 90 16:32:47 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 6 Apr 90 22:44:48 GMTFrom:
jupiter![e-mail]  (Phil R. Karn)Organization: Bell
Communications Research, IncSubject: Re: CP/M sofware for packet
radio and TCP/IPMessage-Id:
<[e-mail]>References:
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail] (Richard
Loken) writes:>This question has been asked, and I wasn't
interested at the time.>>Is there any software around?  I know
that there is a version of tcp/ip some>where and I understand
Phil Karn wrote his eary stuff on CP/M.  Does somebody>have the
early Karn package?  Assuming it exists of course.>>I sort of
hope there isn't any, then I will have to write some.  Build
an>interface and shoot for 56k :)Yes, my code did indeed begin
life on CP/M, specifically the Xerox 820.But this was five years
ago, and much has happened in the meantime to PCclone pricing
and availability to make me wonder why anybody would stillbe
interested in CP/M. With XT clone boards having bottomed out at
$60or so, and with a well-established and highly competitive
supplier networksupporting PC technology, why bother with Z-80s
and CP/M? I just don't seethe point.PhilFrom packet-radio-relay
Fri Apr  6 16:48:47 1990Received: by ucsd.edu; id
AA08965    sendmail 5.61/UCSD-2.0-sun    Fri, 6 Apr 90 16:48:51
-0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA08961    sendmail 5.61/UCSD-2.0-sun via SMTP    Fri, 6 Apr 90
16:48:47 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA29746; Fri, 6 Apr 90 16:31:51 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 6 Apr 90 22:25:05 GMTFrom:
jupiter![e-mail]  (Phil R. Karn)Organization: Bell
Communications Research, IncSubject: Re: Channel access, node vs
digiMessage-Id: <[e-mail]>References:
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail]
(Barry McLarnon DGBT/DIP) writes:>Recently, one of the users of
my PBBS commented to me that he seemed to get>much better
response when connected to the BBS via a NET/ROM node, if
he>used the node simply as a digi rather than connecting to it
first, and>then downlinking to the BBS.Barry,Yes, this
phenomenon is quite real. At the ARRL conference a few yearsago
(when NET/ROM was still fairly new) I used exactly the situation
youdescribe (replacing a digipeater with a NET/ROM node) to
illustrate thefallacy in Software 2000's marketing claims that
hop-by-hopacknowledgements are all that's needed to solve
amateur packet radio'scollision problems. In some cases, such as
the one you describe, theaddition of hop-by-hop acknowledgements
only makes things worse becauseof the synchronized ack/data
collisions (not to mention the extraoverhead of the acks
themselves).Of course, digipeaters aren't ideal either, as it
was their poorperformance that motivated the development of
NET/ROM in the firstplace. PRIACK is a step in the right
direction, but it's just aheuristic that doesn't solve the
fundamental problem: finding some wayto either avoid collisions
or limit their impact on channel throughput.Several such schemes
have been proposed, ranging from full duplexrepeaters that
eliminate hidden terminals and allow for collisiondetection
(CSMA/CD) if the user terminals are also made full duplex,
toabandoning multiple access schemes altogether and relying
exclusively onpoint-to-point or point-to-multipoint schemes.
I've suggested some ofthese myself, and N6GN is now probably the
most vocal proponent of thepoint-to-point approach.However, if
you believe (as I do) that even with lots of point-to-pointlinks
there will still be a need and a place for multiple
accessoperation, then we still need a better solution to the
collisionproblem. Yet another possible scheme would be CSMA/CA
(collisionavoidance) modeled after Apple's Localtalk network.
Basically eachstation sends a short "request to send" (RTS)
message to the destinationstation and waits for a "clear to
send" (CTS) reply before sending theactual data.Stations hearing
a CTS would stay off the channel even if they had notheard the
RTS that caused it. This is the key feature of the algorithm,as
it causes hidden terminals to remain silent until the traffic
can besent. (The RTS messages would indicate the amount of
traffic to be sent,and the CTS message would echo this so the
other stations would know howlong to stay off the channel.)It is
still possible for collisions to occur, but they should
happenonly between RTS messages. These are much shorter than
data packets, sonot as much channel time should be wasted by
them. Obviously this schemeworks best when the stations have
lots of traffic to send in eachRTS/CTS/data cycle, and there
should be a bypass mechanism to allow asmall amount of data to
be sent without the RTS/CTS overhead. (Youwould, however, still
have to obey the CTS holdoff rules).There are also some nifty
extensions that you could make to this schemefor power control.
If the CTS message includes a relative S-meterindication, then
the sender could determine how much power is necessaryto reach
that station. By caching the responses in a table, the
sendercould use different amounts of power depending on how much
was needed toreach a given destination. This alone should result
in a considerableincrease in system throughput when a single
channel is used by manystations over a wide area (e.g., 145.01
MHz in many areas).I would really like to see people analyze
this protocol further and giveit a try. I think it would help
performance on single-channel networks muchmore than hop-by-hop
acks and PRIACK.PhilFrom packet-radio-relay  Fri Apr  6 16:46:57
1990Received: by ucsd.edu; id AA08846    sendmail
5.61/UCSD-2.0-sun    Fri, 6 Apr 90 16:47:00 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA08841    sendmail
5.61/UCSD-2.0-sun via SMTP    Fri, 6 Apr 90 16:46:57 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA29765; Fri, 6 Apr 90
16:32:05 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 6 Apr 90 22:27:30 GMTFrom:
jupiter![e-mail]  (Phil R. Karn)Organization: Bell
Communications Research, IncSubject: Re: Compiling KA9Q NET with
Turbo CMessage-Id: <[e-mail]>References:
<[e-mail]>Sender: [e-mail]:
[e-mail] article <[e-mail]>
[e-mail] (Markus Mueller) writes:>After having
tested around a bit with NET.EXE, I am also interested
in>recompiling the sources of NET in order to include stuff of
my own. I>intend to use Borland's Turbo C; however NET has been
developped under>Microsoft C and therefore some problems occur
when recompiling the sources.>1. Has anybody already done this?
Hints? Pitfalls?Eh??!! I've been using Turbo-C (version 2.0
Professional) to develop mycode for perhaps two years now. You
must have a *very* old version of thecode that dates from when I
used Aztec C as my development base.>2. What memory model is
required for NET? Should I use Large?I've been using the "large"
model (large data + large code) for quite sometime.PhilFrom
packet-radio-relay  Fri Apr  6 16:48:30 1990Received: by
ucsd.edu; id AA08946    sendmail 5.61/UCSD-2.0-sun    Fri, 6 Apr 90
16:48:32 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA08942    sendmail 5.61/UCSD-2.0-sun via SMTP    Fri, 6 Apr 90
16:48:30 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA29775; Fri, 6 Apr 90 16:32:21 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 6 Apr 90 22:39:44 GMTFrom:
jupiter![e-mail]  (Phil R. Karn)Organization: Bell
Communications Research, IncSubject: Re: Packet(?) on commercial
bandsMessage-Id: <[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender: [e-mail]:
[e-mail] article <[e-mail]> [e-mail]
(Alan Barrow) writes:>Unfortunately, the recent hacker gang from
West Germany was able>to  defeat the encryption used in Unix
systems, (Is this DES???)>if the account that I read was
accurate. It *did* involve the >assumption of common language
words as passwords, combined >with leading and trailing ascii
charecters. [...]Conventional UNIX systems use DES in a "one-way
function" mode so thatonly encoded passwords need be stored
anywhere on a system. There is noknown way to reverse the
one-way encoding (which depends on the securityof DES to
known-plaintext attack) BUT an attacker can try to brute
forcethe system by trying large numbers of keys to see if any
produce thesame encoded result as the one they're trying to
determine.I'm thoroughly familiar with this type of attack, as I
have done itmyself for some time as a way to find weak passwords
and get themchanged before the hackers discover them. That's why
I specificallyqualified my statement about DES. The keys MUST be
chosen from a largeenough space that they cannot be found by a
brute force search. Thebest-built combination lock in the world
is worthless if people set thecombinations to "obvious"
values.For more details on this whole subject, see the paper by
my colleagueDave Feldmeier (AD3J, btw) and myself that we
published in the proceedingsof the Crypto '89
conference.PhilFrom packet-radio-relay  Fri Apr  6 20:31:31
1990Received: by ucsd.edu; id AA24245    sendmail
5.61/UCSD-2.0-sun    Fri, 6 Apr 90 20:31:33 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA24241    sendmail
5.61/UCSD-2.0-sun via SMTP    Fri, 6 Apr 90 20:31:31 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA12735; Fri, 6 Apr 90
20:03:19 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 7 Apr 90 02:44:27 GMTFrom:
cs.utexas.edu!news-server.csri.toronto.edu!utgpu!watserv1!ria!uwo
vax![e-mail]: <None>Message-Id:
<[e-mail]>Sender:
[e-mail]: [e-mail]
following is a relatively easy modification that allows reliable
19.2K baud on the serial port and radio port of most TAPR TNC-2
boxes.***** FIRST AND FOREMOST *****Replace U3 (LM324 op amp)
with a TL084CN or TL094 if no TL084CN or eqiv.  Thisis a high
speed JFET hi-Z op amp.  Just that fix alone will allow you
torun 9600 baud on the serial port to your computer.  I found
that the TAPR1.1.6. code WITH the PMS ran without any serial
port misbehaving BUT it wassluggish.  The 1.1.6. code (or lower)
without PMS is quite a bit quicker.***** 19.2 K *****Cut the PC
trace that goes to pin 2 of divider U1 about 1/8" from U1.  Runa
short jumper from pin 10 of the divider U1 to the side of the
trace youjust cut that goes to the SW2 baud rate switch.  This
is the side of thecut opposite to pin 2 on U1.  This supplies a
307.2 K clock to pin 1 andpin 6 of the SW2 which NO LONGER
SELECTS 300 BAUD.The 307.2 K is 19.2K/16 which is fine and
dandy.  To run 19.2K on theserial port, turn SW2 switch 1 on.
SW2 switch 6 selects 19.2 K to theMODEM port, switch 7 selects
1200 baud to the modem port and switch 8selects 9600 baud to the
modem port.( keep in mind to leave switch 7 on unless you have
installed a higher  speed modem in your TNC )We are running 19.2
K serial and 9600 baud radio with G3RUH modems andkantronics DVR
2-2 radios with excellent results.  Next step is to upthe G3RUH
boards to 19.2 K by replacing a couple of capacitors.OHHH WHAT A
FEELING.......de  Anthony Varga VE3ZAV    Kellogg Canada Inc
London, Ontario, Canada    519 455 9660  Vmx 367    519 681 1650
 HomeFrom packet-radio-relay  Sat Apr  7 16:31:37 1990Received:
by ucsd.edu; id AA06770    sendmail 5.61/UCSD-2.0-sun    Sat, 7 Apr 90
16:31:40 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA06766    sendmail 5.61/UCSD-2.0-sun via SMTP    Sat, 7 Apr 90
16:31:37 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA11183; Sat, 7 Apr 90 16:29:25 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 7 Apr 90 02:46:58 GMTFrom:
mcgill-vision!clyde.concordia.ca!news-server.csri.toronto.edu!utg
pu!watserv1!ria!uwovax![e-mail]:
TAPR TNC-2 High Speed (19.2K) Serial Port
ModificationMessage-Id: <[e-mail]>Sender:
[e-mail]: [e-mail] screwed
up with the title on my posting for the TAPR TNC-2 serial
port19.2 K baud modification.  Read message entitled    <NONE>de
 Anthony Varga  VE3ZAV    Kellogg Canada Inc    London, Ontario,
Canada    519 455 9660  vmx 367From packet-radio-relay  Sat Apr
7 22:02:20 1990Received: by ucsd.edu; id AA25089    sendmail
5.61/UCSD-2.0-sun    Sat, 7 Apr 90 22:02:23 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA25084    sendmail
5.61/UCSD-2.0-sun via SMTP    Sat, 7 Apr 90 22:02:20 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA27324; Sat, 7 Apr 90
21:48:23 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 8 Apr 90 00:11:08 GMTFrom:
n8emr![e-mail]  (Gary Sanders)Organization:
Ham BBS, 614-895-2553 (1200/2400/9600(v.32)/PEP with MNP
L5Subject: RTTY DX Notes, 4/6/90Message-Id:
<[e-mail]>Sender: [e-mail]:
[e-mail]============================================
==================|         Relayed from packet radio via
  || N8EMR's Ham BBS, 614-895-2553 1200/2400/9600/V.32/PEP/MNP5
|==============================================================SB
 ALL @ ALLUSA $RTDX0604RTTY DX Notes, 1of3, 4/6/90 RTTY DX Notes
for Weekending 6th April 1990.Part 1 of 3.BID: $RTDX0604 Oh
dear.  Just when we thought that we had all the frequency
problemssolved with the packet chaps, here we go again.  Now,
because of QRM,the ARRL wants the FCC to give them their own
special frequencies forunattended operation, at the expense of
the RTTY/CW operators.  But Ithought it was an error free
system, or has someone been telling melies again?  Why don't
they dash off to 10, 18 or 24 MHz and leave thegentlemen alone?
Write to the FCC and ARRL and point out the error oftheir
thinking, but do so before April 23, and make it good andstrong.
Our thanks this week go to G0ABI, I5FLN, I5ICY, I5IGD, OD5NG,
TG9VT,VK2EG, VK4DXN, W1DA, WA1URA, W2JGR, W0LHS and the
Tri-State DXAssociation VHF packet cluster.  Thanks chaps for
all the information.It's really appreciated.  Bandpass: Friday
30:SU1HN       14089  at  0000ZJY9SR       14090  at
0550ZCE0ZIG      21083  at  0610ZRO4OV       21090  at
1320ZHL1ST       14083  at  1350Z3B8QS       14089  at  1850Z
Saturday 31:ZP6DN       14088  at  0125ZHI8BG       14086  at
1205ZA41SK       14085  at  1303ZJ28TY       28084  at
1315Z5N8ALE      28075  at  1325ZVS6VC       21090  at
1331ZUZ3AYR      21089  at  1335ZUZ9CWA      21094  at
1430ZFR5FI       14090  at  1716ZBZ1RDX      21086  at
1850Z6W6JX       21086  at  1857ZEA9MY       14089  at
2130ZFM5WD       14086  at  2135ZUA0SK       21089  at  2250Z
Z18UC1AWW      14088  at  2250ZUO4OWQ      14086  at  2303Z
Continued in part 2./EXSB ALL @ ALLUSA $RTDX0704RTTY DX Notes,
2of3, 4/6/90 RTTY DX Notes for Weekending 6th April 1990.Part 2
of 3.BID: $RTDX0704  Sunday 1:UA0SK       21090  at  0018ZSU1HN
     14086  at  0030ZAA6TT/V2    14090  at  0203ZHC8VB
14083  at  0310ZUZ9CWA      14091  at  0315ZUO4OWQ      14082
at  0400ZUC1AWW      14090  at  0600ZEA9MY       21094  at
1525ZTA2DE       28088  at  1530ZVU2JX       28091  at
1530ZZP6DM       28095  at  1530ZRO4OV       21086  at
1536Z9J2AL       28093  at  1755ZJ28TY       14085  at
1847ZHI8BG       14090  at  2033ZFM5FA       21085  at
2045ZCU3LB       21083  at  2213Z Monday 2:ZP6DN       14081  at
 0056ZUY5EG       14091  at  0355ZJ28SI       14084  at  0430Z
QSLBY9GA       21088  at  0647ZA51JS       14088  at  1230Z
QSL/NoteYB0IKI      21091  at  1415ZUC1AWW      14088  at  2045Z
Tuesday 3:EA6MQ       14092  at  0540ZUW1YY       14092  at
0545ZHL1SX       21083  at  1028ZFM5WD       14090  at  1040Z
50BD4K2OT       14090  at  1042Z  50BD3B8CZ       14074  at
1500Z  FECA51JS       14083  at  1(26ZEA9MY       14097  at
2250Z Wednesday 4:BY4WNG      21087  at  0930ZTA3D        21090
at  1200ZVS6VC       21083  at  1506Z5V7DP       21083  at
1713ZUI8FM       14083  at  1805Z Thursday 5:BY1QH       14078
at  0920Z  ARQUA0SK       21090  at  1006Z  QSL Information: We
are a little light in this area this week.  Sorry about that.
J28SI was Heinrich on his way back from A15.  QSL to DJ6JC.
A51JS will QSL on his return to VK9NS. Continued in part 3./EXSB
ALL @ ALLUSA $RTDX0804RTTY DX Notes, 3of3, 4/6/90 RTTY DX Notes
for Weekending 6th April 1990.Part 3 of 3.BID: $RTDX0804  Notes
Of Interest: Ron, ZL1AMO reports that he will be signing ZK2RW
this coming week fora two week stint.  QSL to his home address.
Aves Island is still on schedule, and should appear on 11th
Aprilthrough 15th April, all digital modes, RTTY, AMTOR and
packet.  RTTYwill be on 087 on all bands, and they will listen
on 090 to 099 KHz.Packet and AMTOR will be on the normal
frequencies for these modes. Jarvis Island is also on schedule,
they should appear on 13th Apriluntil 23rd April.  Their calls
may be either AH3C/KH5J or AH3C/KH4J.It is believed that they
will be OK for DXCC. Burma was supposed to show on March 24th,
but nothing heard.  Maybe itwill not occur. Spratley seems to be
going fine, though there have been no reports forsome weeks.
Keep your fingers crossed. VU7JX, JS, reports that he had 6500
contacts from the Laccadives.  JSsays that he has answered all
cards received, but if you want a card,please send a SASE before
the end of June.  After that date all blankcards will be
destroyed. Packet in China.  BZ1FB reports that he has a packet
BBS in Beijing on21101 KHz from 0900Z until 1500Z and on 14105
KHZ from 1500Z until2400Z. Jim, A51JS, has some small problems,
like snow, power failures, andhis hosts being overly kind, but
he keeps trying to get on the air.So be patient, he will make
it. GL DE DX1 (VK2SG) VIA TG9VT. Relayed by Tad, KT7H @
N7HFZ.WA.USA.NA/EXFrom packet-radio-relay  Mon Apr  9 08:48:09
1990Received: by ucsd.edu; id AA02031    sendmail
5.61/UCSD-2.0-sun    Mon, 9 Apr 90 08:48:13 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA02025    sendmail
5.61/UCSD-2.0-sun via SMTP    Mon, 9 Apr 90 08:48:09 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA11974; Mon, 9 Apr 90
08:34:31 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 9 Apr 90 13:10:17 GMTFrom:
genrad![e-mail]  (Diana L. Syriac)Subject: Packet
help with PK232 & Kenwood TM-221AMessage-Id:
<[e-mail]>Sender: [e-mail]:
[e-mail]'m looking for anyone who thinks they can
help resolve problems I'm havingconnecting a PakRatt PK232 TNC
to a Kenwood TM-221A 2-meter radio.The cable I created is
home-brew and does NOT contain the same "color" wiresas the
standard PK232 cable, but it should be adequate.  It is shielded
"4-pair" standard computer cable, containing two twisted wire
pairs: one iswhite / black, the other is red / black.  Standard
berg connectors is used on the TNC end and an 8-pin DIN is used
on the radio side.There is no close match that I could determine
from the Appendix K "Radioconnections" section of the PK 232
manual....the closest one was the Kenwood8 pin....and as far as
I can tell, it's not sufficient.  Anyway, I used thedescriptions
supplied in the PK232 manual/schematics and the
descriptionssupplied in the TM-221A manual to come up with these
connections:TNCpin    PK232 color   My color   TNC function   Radio
function   Radiopin1       GREEN         Black(wh)  RX Audio
  RX detector O/P  62       WHITE         White      TX Audio
   Microphone Audio 13       BLACK         Black(red) Squelch
    ?                N/C4       BROWN         Shield     Ground
       GND (Microphone) 75       RED           Red        PTT
        PTT (stby)       24*      SHIELD        Shield
Ground         GND (PTT)        8N/C
                DOWN             3N/C
                 UP               4N/C
                  8V/Max 15mA      5*I assume that Shield and
Brown are wired together in the standard PK232 cable....in any
case, used the Shield in place of the Brown and write radio pins
7 and 8 together at the Din connector.The only description
supplied in the PK232 manual for connection to "Kenwood8 pin"
connectors shows:        PK232 color
                 Radiopin        White
                         1        Red
                          2        Shield
                           7        Brown
                            8with this at the bottom of the
page:NOTE: On all radios, the shield should go to the same place
as the brownwire, unless otherwise noted.With this cable setup,
I find that I can transmit (I can see the S meter onthe radio go
to full scale), but I can't seem to receive.  There is
soundcoming out of the speaker on the radio, so I can hear
signals coming in, butthere is no response from my computer, and
the threshold leds on the TNC dono flicker.  It's almost as if
there is a broken wire on the receive side....but I did check
the cable with an Ohmmeter, and it's ok.Now, the TM-221A manual
shows that the pin 6, which is the RX detector outputhas only
approximately 150 mV/600 ohms.  I'm not entirely sure what that
means, but I'd think that 150 mV would be sufficient signal.
The only otherthing I can think of doing is to open up the 2
meter radio and run a wiredirect from the speaker.....the catch
is, it's not my radio, so this isn'ta viable solution.Has anyone
out there had any experience with TM-221A as a 2-meter
packetstation?  If so, could you tell me how you wired your
cable?Thanks for your help in advance.Diana->Diana L. Syriac
CAP: SM, Freedom 690 Mobile    Ham: KC1SP(1 super
pilot)<-->USmail:   GenRad Inc., Mail Stop 6, 300 Baker Ave,
Concord, Mass.  01742  <-->usenet:
{decvax,mit-eddie}!genrad!dls      or [e-mail]         <-->tel:
   [phone] x2459    I'D RATHER BE FLYING!!!            <-From
packet-radio-relay  Mon Apr  9 10:02:06 1990Received: by
ucsd.edu; id AA07329    sendmail 5.61/UCSD-2.0-sun    Mon, 9 Apr 90
10:02:09 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA07321    sendmail 5.61/UCSD-2.0-sun via SMTP    Mon, 9 Apr 90
10:02:06 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA16600; Mon, 9 Apr 90 09:50:35 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 7 Apr 90 06:09:45 GMTFrom:
snorkelwacker!usc!wuarchive!swbatl![e-mail]
(Mike R. Kraml)Organization: Southwestern Bell Tele. Co. -
Advanced Technology Lab - St. LouisSubject: Re: CP/M sofware for
packet radio and TCP/IPMessage-Id:
<[e-mail]>References: <[e-mail]>,
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail] (Phil R.
Karn) writes:>In article <[e-mail]>
[e-mail] (Richard Loken) writes:>>This question has
been asked, and I wasn't interested at the time.>>>>Is there any
software around?  I know that there is a version of tcp/ip
some>>where and I understand Phil Karn wrote his eary stuff on
CP/M.  Does somebody>>have the early Karn package?  Assuming it
exists of course.>>>>I sort of hope there isn't any, then I will
have to write some.  Build an>>interface and shoot for 56k
:)>>Yes, my code did indeed begin life on CP/M, specifically the
Xerox 820.>But this was five years ago, and much has happened in
the meantime to PC>clone pricing and availability to make me
wonder why anybody would still>be interested in CP/M. With XT
clone boards having bottomed out at $60>or so, and with a
well-established and highly competitive supplier
network>supporting PC technology, why bother with Z-80s and
CP/M? I just don't see>the point.>>PhilWell Phil, I too have a
desire to run a tcp/ip package on my cpm system.My reasons
are:A. I have a Televideo TS802H (10 meg hard drive) still in
excellent condition   and I can't think of a better use for
it.B. I have invested several thousand dollars in my current
development system   and can't afford to let the thing run day
and night for packet.C. I have no real desire to own a pc clone
at any price.So, if you do still have some CPM code laying
around that would run on an oldCPM box I am sure a lot of those
good old CPM boxes cound use the work out.Thanks, and 73, Mike
WQ0N--
=================================================================
============  Mike Kraml - Manager-Separations MECHANIZATION -
SWBT - (The Techies)  UUCP: {uunet, bellcore,
texbell}...!swbatl!slims!ammrk
=================================================================
============From packet-radio-relay  Mon Apr  9 15:18:35
1990Received: by ucsd.edu; id AA03710    sendmail
5.61/UCSD-2.0-sun    Mon, 9 Apr 90 15:18:38 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA03696    sendmail
5.61/UCSD-2.0-sun via SMTP    Mon, 9 Apr 90 15:18:35 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA06141; Mon, 9 Apr 90
15:08:53 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 9 Apr 90 22:27:50 GMTFrom:
m2c!wpi![e-mail]  (John C Whitson
KB2GNC)Organization: Worcester Polytechnic Institute, Worcester,
Mass.Subject: THANKS TO ALL!!Message-Id:
<[e-mail]>Sender: [e-mail]:
[e-mail]    Thanks to all of you for your great help,
in particular with the    R-C hack to get my TNC to work with my
ICOM 2AT. The last obstacle    to hurdle happened last night ... I
turned down the volume on the    HT and *bingo*, I got a
connection!! Anyway, I'm in business.-- ----------  If at first
you don't succeed,  so much for skydiving ---------John Whitson:
  Internet: [e-mail]  Bitnet:
[e-mail]73's from KB2GNC/1
UUCP: uunet!wpi.wpi.edu!jwhitson----------  Anything with this
tag on it is purely my own opinion ---------From
packet-radio-relay  Mon Apr  9 15:19:46 1990Received: by
ucsd.edu; id AA03894    sendmail 5.61/UCSD-2.0-sun    Mon, 9 Apr 90
15:20:17 -0700Received: from WSMR-SIMTEL20.ARMY.MIL by ucsd.edu;
id AA03841    sendmail 5.61/UCSD-2.0-sun via SMTP    Mon, 9 Apr 90
15:19:46 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listMessage-Id:
<[e-mail]>Received: from paxrv-nes.navy.mil
by WSMR-SIMTEL20.ARMY.MIL with TCP; Mon, 9 Apr 90 16:19:00
MDTDate: 9 Apr 90 17:48:00 EDTFrom: "SWEIGERT, DAVID"
<[e-mail]>Subject: US NAVY PACKET RADIOTo:
"packet-radio" <[e-mail]>There has
been much communication and discussion in recent weeks
concerning DAEDALEAN's proposal for transmission of
non-tacticalADP mission support data for the US Navy.  DAEDALEAN
is expandingthe original proposal to include packet radio.Why
?The time is right to explain packet radio technology to the
appropriate Navy planners who are tasked with understanding
emerging technology.DAEDALEAN has two proposals on the table
being reviewed by theSpace and Naval Warfare Command for
utilizing INMARSAT L-Band(1556 Mhz) satellite channels as a
network backbone for thetransmission of mission support data
(logistics and maintenance).DAEDALEAN's interest is to see the
efficiency of this new technology promoted to the military as a
method of modernizingexisting fleet ADP communications
channels.More data shall be forth coming---David Sweigert9017
Red Branch RdColumbia, MD  21045From packet-radio-relay  Mon Apr
 9 15:51:35 1990Received: by ucsd.edu; id AA00267    sendmail
5.61/UCSD-2.0-sun    Mon, 9 Apr 90 15:51:41 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA00256    sendmail
5.61/UCSD-2.0-sun via SMTP    Mon, 9 Apr 90 15:51:35 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA07787; Mon, 9 Apr 90
15:34:45 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 9 Apr 90 20:58:26 GMTFrom:
mcsun!hp4nl!nikhefk![e-mail]  (Henk Peek)Organization:
Nikhef-K, Amsterdam (the Netherlands).Subject: International
Packet-meeting in FrankfurtMessage-Id: <[e-mail]>Sender:
[e-mail]:
[e-mail] Packet-meeting in FrankfurtIn
cq-DL 3/90 is a small announcement about the 6th International
Packet-Radiomeeting 21 and 22 April at the university of
Frankfurt, Robert-Mayer Str. 2-4,Frankfurt. Both days start at
10.I am located in Holland and couldn't find more
information.Before I will go to this meeting, I must have more
information.Is there a program, hotels, etc??  I haven't an
email address of someonenear the organization (UUCP, Bitnet,
Hamradio packet).Henk Peek, PA0HZP,  UUCP: [e-mail],
Hampacket: PA0HZP@PA0RYS                    Mail: H.Z.Peek,
PB329, 1440AH Purmerend, Holland.Ps: We are with a small
group.From packet-radio-relay  Mon Apr  9 19:03:31 1990Received:
by ucsd.edu; id AA14971    sendmail 5.61/UCSD-2.0-sun    Mon, 9 Apr 90
19:03:33 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA14966    sendmail 5.61/UCSD-2.0-sun via SMTP    Mon, 9 Apr 90
19:03:31 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA19934; Mon, 9 Apr 90 18:48:21 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 9 Apr 90 16:49:11 GMTFrom:
spock![e-mail]  (Dave Perry)Organization: Mitel.
Kanata (Ontario). Canada.Subject: Need hints on Z8530
SCCMessage-Id: <2956@sx200d>Sender:
[e-mail]: [e-mail] is my
first posting, so if I mess up don't flame me too badly.I am
currently trying to build a synchronous interface card for
IBMcompatibles, specifically to drive the WA4DSY modem at 56Kbs.
I knowthat the "Awsome IO" card is coming, but I wanted to try
it myselfand perhaps make something a bit simpler.  The card
uses an 8530 SCCand uses a DMA channel in the PC in half duplex,
single transfermode.  It works most of the time, but here is my
problem:To transmit, I program the DMA controller, unmask it and
select TXDMA in the 8530.  Then I reset the end of packet flag
so a CRC willbe generated when the DMA stops feeding bytes to
the SCC.  An externalstatus interrupt occurs at the end of
message, and I use this to endthe transmission (after a delay to
allow the CRC and flag to clear thechip).  The problem is, it
seems sometimes I don't get the interruptat the end of the
packet, and the transmitter stays on, hanging things.If anybody
has run into this or has any ideas, I'd appreciate hearingfrom
you. PS. The problem only happens when the card is busy, like
when usingFTP (I have written a driver for Phil Karns' NET
package).  If trafficis sparse, as when pinging the other
machine (I have two of these setup for testing), things work
fine.  It is probably some silly bug on my part, but I've put in
several hourson this so it doesn't hurt to ask. 8-).Dave Perry
VE3IFBFrom packet-radio-relay  Mon Apr  9 19:03:36 1990Received:
by ucsd.edu; id AA14985    sendmail 5.61/UCSD-2.0-sun    Mon, 9 Apr 90
19:03:38 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA14976    sendmail 5.61/UCSD-2.0-sun via SMTP    Mon, 9 Apr 90
19:03:36 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA20428; Mon, 9 Apr 90 18:56:03 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 9 Apr 90 17:52:47 GMTFrom:
spock![e-mail]  (Dave Perry)Organization: Mitel.
Kanata (Ontario). Canada.Subject: Need hints on Z8530
SCCMessage-Id: <2957@sx200d>Sender:
[e-mail]: [e-mail], my
apologies if you get two copies of this - I'm still learning!I
am currently trying to build a synchronous interface card for
IBMcompatibles, specifically to drive the WA4DSY modem at 56Kbs.
I knowthat the "Awesome IO" card is coming, but I wanted to try
it myselfand perhaps make something a bit simpler.  The card
uses an 8530 SCCand uses a DMA channel in the PC in half duplex,
single transfermode.  It works most of the time, but here is my
problem: To transmit, I program the DMA controller, unmask it
and select TXDMA in the 8530.  Then I reset the end of packet
flag so a CRC willbe generated when the DMA stops feeding bytes
to the SCC.  An externalstatus interrupt occurs at the end of
message, and I use this to endthe transmission (after a delay to
allow the CRC and flag to clear thechip).  The problem is, it
seems sometimes I don't get the interruptat the end of the
packet, and the transmitter stays on, hanging things. If anybody
has run into this or has any ideas, I'd appreciate hearingfrom
you. PS. The problem only happens when the card is busy, like
when usingFTP (I have written a driver for Phil Karns' NET
package).  If trafficis sparse, as when pinging the other
machine (I have two of these setup for testing), things work
fine. It is probably some silly bug on my part, but I've put in
several hourson this so it doesn't hurt to ask. 8-). Dave Perry
VE3IFB From packet-radio-relay  Tue Apr 10 06:33:05
1990Received: by ucsd.edu; id AA03558    sendmail
5.61/UCSD-2.0-sun    Tue, 10 Apr 90 06:33:07 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA03553    sendmail
5.61/UCSD-2.0-sun via SMTP    Tue, 10 Apr 90 06:33:05 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA27055; Tue, 10 Apr 90
06:20:31 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 9 Apr 90 21:01:25 GMTFrom:
wa3wbu!compnect![e-mail]  (Dave Ratcliffe)Organization:
John Core at home, Harrisburg,PASubject: Re: CP/M sofware for
packet radio and TCP/IPMessage-Id:
<[e-mail]>References: <[e-mail]>,
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]>, karn@jupiter..bellcore.com (Phil
R. Karn) writes:> In article <[e-mail]>
[e-mail] (Richard Loken) writes:> >This question
has been asked, and I wasn't interested at the time.> >> >Is
there any software around?  I know that there is a version of
tcp/ip some> >where and I understand Phil Karn wrote his eary
stuff on CP/M.  Does somebody> >have the early Karn package?
Assuming it exists of course.> > Yes, my code did indeed begin
life on CP/M, specifically the Xerox 820.> But this was five
years ago, and much has happened in the meantime to PC> clone
pricing and availability to make me wonder why anybody would
still> be interested in CP/M. With XT clone boards having
bottomed out at $60> or so, and with a well-established and
highly competitive supplier network> supporting PC technology,
why bother with Z-80s and CP/M? I just don't see> the
point.Phil, maybe he likes it! I have a Molecular Mod. 9 in my
little room with 2Seiko 8610's nearby. All operational, all
(gasp) CP-MP/M or N-Star and allmulti-user. Nice machines, fun
to hack on and just play with. There isLOTS I'd like to find for
these 2 (Seiko and Molecular) machines aswell. Also have a PC
next to the Seiko's. The Seiko's are more fun. I'dlike to find a
terminal program that will run on the Seiko's 8086. Maybeeven
something for the Mole's 8080. Maybe you don't see the point
nowbut lots of us still like to play around with admittedly
older butsometimes more intriguing systems. BTW, if anyone DOES
have any term program that'll run on either of these'old
technology' :-) machines, I'll be happy to hear from you.
     *>> Dave <<*[------: Dave Ratcliffe :---------:---: UUCP:
uunet!wa3wbu!compnect!dave :----]:
  :           The Data Factory BBS            ::
                :   Data: [phone] - [phone]
:[.................................:.............................
..............]From packet-radio-relay  Tue Apr 10 07:02:01
1990Received: by ucsd.edu; id AA05350    sendmail
5.61/UCSD-2.0-sun    Tue, 10 Apr 90 07:02:03 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA05343    sendmail
5.61/UCSD-2.0-sun via SMTP    Tue, 10 Apr 90 07:02:01 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA28804; Tue, 10 Apr 90
06:48:28 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 10 Apr 90 13:44:17 GMTFrom:
[e-mail]  (Andrew Payne)Organization:
Cornell Theory Center, Cornell University, Ithaca NYSubject: Re:
CP/M sofware for packet radio and TCP/IPMessage-Id:
<[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender: [e-mail]:
[e-mail] article <[e-mail]>
[e-mail] (Mike R. Kraml) writes:>In article
<[e-mail]> [e-mail] (Phil R.
Karn) writes:>>clone pricing and availability to make me wonder
why anybody would still>>be interested in CP/M. With XT clone
boards having bottomed out at $60                                     ^^^    This item
joggled my memory about a question I've been meaning to ask for
a while.  What's the smallest PC system configuration you can
get away with?  I had in mind:  motherboard, drive controller,
drive, power supply, and any necessary packet I/O boards.  No
display card, display, keyboard.    Motivation being setting up a
dedicated packet switch.  It surewould be cheaper than
outfitting a full system and would be less powerhungry.    I know
my BIOS would balk right away at no display and keyboard, butI
was wondering if anyone had tried such a configuration?    Any
comments appreciated.-- =  =  =  =  =  =  =  =  =  =  =  =  =  =
 =  =  =  =  =  =  =  =  =  =  =  =  =Andrew C. Payne, N8KEI
   UUCP:  ...!cornell!batcomputer!payne
INTERNET:  [e-mail] packet-radio-relay
Tue Apr 10 07:32:54 1990Received: by ucsd.edu; id
AA07306    sendmail 5.61/UCSD-2.0-sun    Tue, 10 Apr 90 07:33:04
-0700Received: from dgbt.crc.dnd.ca by ucsd.edu; id
AA07294    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 10 Apr 90
07:32:54 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by dgbt.crc.dnd.ca
(5.57/smail2.5/12-02-88)    id AA02753; Tue, 10 Apr 90 10:31:49
EDTDate: Tue, 10 Apr 90 10:31:49 EDTFrom: [e-mail]
(Barry McLarnon DGBT/DIP)Message-Id:
<[e-mail]>To:
[e-mail]: Re: Channel access, node vs
digiCc: [e-mail] to Phil and Chris for their
comments.  I agree that new approachesto CSMA are needed... we
will likely pursue the collision detectionapproach on our 56kbs
MAN, and the Localtalk collision avoidance protocoloffers some
intriguing possibilities for dealing with hidden
transmitters.Right now, though, I'm concerned with the
short-term problem of helpingthose poor blighters in the 1200bps
trenches :-).  Any performance tweakswhich can be easily
implemented and offer a significant improvement inchannel usage
are worthwhile, I think.  The TAPR DCD upgrade is one
such.PRIACK could be another, but if it cannot be applied to
nodes, BBS's, andmany of the user stations, it won't have much
impact.  It appears to methat adding PRIACK to KISS would be a
rather difficult hack, so maybe itwould be better to put the
effort into other CSMA strategies.It seems clear to me that,
whatever else we do, we should strive towardshaving *only*
full-duplex repeaters on multiple-access channels.  Thiswill
never happen with the present 1200bps frequencies, but should be
keptfirmly fixed in mind as users start to gravitate to 9600bps
and new MANsget set up to accommodate them.  Repeat after me: "I
will NOT put up a9600bps half-duplex node/digi".  Let's not
repeat our past mistakes.BarryFrom packet-radio-relay  Tue Apr
10 08:17:43 1990Received: by ucsd.edu; id AA10384    sendmail
5.61/UCSD-2.0-sun    Tue, 10 Apr 90 08:17:46 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA10371    sendmail
5.61/UCSD-2.0-sun via SMTP    Tue, 10 Apr 90 08:17:43 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA04234; Tue, 10 Apr 90
08:14:35 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 10 Apr 90 15:11:13 GMTFrom:
samsung!sdd.hp.com!elroy.jpl.nasa.gov!hydra![e-mail]  (Jon
T. Adams)Organization: Jet Propulsion Laboratory, Pasadena,
CaliforniaSubject: Re: CP/M sofware for packet radio and
TCP/IPMessage-Id:
<[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail]
(Andrew Payne) writes:>In article <[e-mail]>
[e-mail] (Mike R. Kraml) writes:>>In article
<[e-mail]> [e-mail] (Phil R.
Karn) writes:>>>clone pricing and availability to make me wonder
why anybody would still>>>be interested in CP/M. With XT clone
boards having bottomed out at $60>                                     ^^^>>    This item
joggled my memory about a question I've been meaning to >ask for
a while.  What's the smallest PC system configuration you can
get >away with?  I had in mind:  motherboard, drive controller,
drive, power >supply, and any necessary packet I/O boards.  No
display card, display, >keyboard.>    Motivation being setting up a
dedicated packet switch.  It sure>would be cheaper than
outfitting a full system and would be less power>hungry.>    I know
my BIOS would balk right away at no display and keyboard, but>I
was wondering if anyone had tried such a
configuration?>...>Andrew C. Payne, N8KEI        UUCP:
...!cornell!batcomputer!payneOur group in the Los Angeles /
Southern California area has been buildingup low-cost PCs for
packet switching nodes for the last year or so.  Beingin SoCal,
the land of the cheap clone and 100000000000000000 Chinese
computervendors, there's quite a good selection of components at
cheap prices.  And,if the stuff doesn't work right, the vendors
are usually local.Anyway, a 10MHz XT mother board w/ 0k RAM can
be had for as little as $53;I've even seen a few 12MHz boards
for $50, but that's a rarity.  RAM costsabout $1.70 per chip for
256-10 stuff, sometimes a bit more.  Nine of thoseget you the
minimum 256k RAM; eighteen are preferable.Power supplies new are
$25 to $35; an old (but fully working) 65 watt supplymay be as
little as $10.  Cases are 10 to 20 bucks, new maybe 25.
Monochromeboards are 15 to 20.  Dual port serial cards (if you
plan on using yourstandard external TNC2 modem) are as little as
$10 with one port stuffed, or18 to 20 with both ports
stuffed.Most BIOSes that I have seen don't require a keyboard
for properoperation; the majority of them will beep and imform
you of a system errorbut will merrily go onward and continue to
boot.  If you set the switches onthe motherboard for an EGA
video display, the AMI BIOSes (at least) willhappily work
without a display board.So, let's add up what it would cost (on
the average ) for a very basic PCif purchased on any given
Saturday at the Chinese computer Show.10MHz XT board w/BIOS and
0k RAM :   $58256k RAM                         :   $19Power
Supply and Case            :   $40Dual-Port Serial Card
  :   $19                         total   :  $136Oh, add six
bucks for the admission fee; add a few bucks for gas and
parking, and driving time...  Then, if you want me to get this
stuff for you,add my commission and the total will be about
$35,000 @:)...Adios and 73 -  Jon--Jon Trent Adams, NW6H
 | "Amateur Radio isn't Everything;[e-mail]
 |  It's the ONLY thing..." - JTAThese are just OPINIONS, ok?!?
| Ladies! >Single homeowner w/convertible<"Shove it into RUN-8
and we'll see what this baby can do!" - JTAFrom
packet-radio-relay  Tue Apr 10 10:02:17 1990Received: by
ucsd.edu; id AA17069    sendmail 5.61/UCSD-2.0-sun    Tue, 10 Apr 90
10:02:20 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA17063    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 10 Apr 90
10:02:17 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA10542; Tue, 10 Apr 90 09:48:08 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 10 Apr 90 14:07:38 GMTFrom:
hpcc01!col![e-mail]  (Bdale Garbee)Organization: HP
Colorado Springs DivisionSubject: Re: BM RAM..Message-Id:
<[e-mail]>References: <[e-mail]>Sender:
[e-mail]: [e-mail] has not
ceased to amaze me how many people have tried to use BM as a
serious mailer.  It has amazed me even more how many people have
succeeded.I wrote it as a quick hack to test out SMTP handling
in NET, and to demonstratehow one might interface a mail user
agent to NET.I suppose it's a tribute to Dave Trulli, NN2Z, who
has been the caretaker ofBM for some time... I tried to
discourage him early on, but...  :-)And Phil tried to suggest
that calling it 'BM' would keep people from wantingto use "my
<bleep>y little mailer"... :-)End of aside... Bdale, amused as
usualFrom packet-radio-relay  Tue Apr 10 11:34:55 1990Received:
by ucsd.edu; id AA22628    sendmail 5.61/UCSD-2.0-sun    Tue, 10 Apr
90 11:34:58 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu;
id AA22624    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 10 Apr 90
11:34:55 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA17046; Tue, 10 Apr 90 11:23:30 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 10 Apr 90 17:58:03 GMTFrom:
unmvax!ariel!carina.unm.edu![e-mail]
(aNk1ez)Organization: University of New Mexico,
AlbuquerqueSubject: Re: CP/M sofware for packet radio and
TCP/IPMessage-Id: <[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender: [e-mail]:
[e-mail] article <[e-mail]>
[e-mail] (Dave Ratcliffe) writes:>In article
<[e-mail]>, karn@jupiter..bellcore.com (Phil
R. Karn) writes:>> In article <[e-mail]>
[e-mail] (Richard Loken) writes:>> >This question
has been asked, and I wasn't interested at the time.>> >>> >Is
there any software around?  I know that there is a version of
tcp/ip some>> >where and I understand Phil Karn wrote his eary
stuff on CP/M.  Does somebody>> >have the early Karn package?
Assuming it exists of course.>> >> Yes, my code did indeed begin
life on CP/M, specifically the Xerox 820.>> But this was five
years ago, and much has happened in the meantime to PC>> clone
pricing and availability to make me wonder why anybody would
still>> be interested in CP/M. With XT clone boards having
bottomed out at $60>> or so, and with a well-established and
highly competitive supplier network>> supporting PC technology,
why bother with Z-80s and CP/M? I ju st don't see>> the point

.>>Phil, maybe he likes it! I have a Molecular Mod. 9 in my
little room with 2>Seiko 8610's nearby. All operational, all
(gasp) CP-MP/M or N-Star and all>multi-user. Nice machines, fun
to hack on and just play with. There is>LOTS I'd like to find
for these 2 (Seiko and Molecular) machines as>well. Also have a
PC next to the Seiko's. The Seiko's are more fun. I'd>like to
find a terminal program that will run on the Seiko's 8086.
Maybe>even something for the Mole's 8080. Maybe you don't see
the point now>but lots of us still like to play around with
admittedly older but>sometimes more intriguing systems. >>BTW,
if anyone DOES have any term program that'll run on either of
these>'old technology' :-) machines, I'll be happy to hear from
you. >Hmm... It might help to know what kind of I/O you're
using. My system is aZ80b-6MHz (Mostly CompuPro stuff) CPU-Z
board,with 3 RAM17 boards (64k thatsupports the extended 24bit
addressing for 192k system ram) , cCompuPro SMB-2 board for boot
and some I/O, Fulcrum Tech.'s VIO-X1 video boardconnected to a
Samsung Amber Digital monitor, a ComputerWatch RTC, Two
GodBoutDISK1 boards (running 2 MPE 1.2mb 8" drives and 4 360k
DDDS 5.25" drives respectivly) a DISK2 board connected to a
Segate 80mb harddrive (some hack,huh? I'm proud of it!) SSM's
IO4 and IO5 boards for lotsa RS232 and Parallel(been working on
making this old TRS80 into a parallel terminal(ish) thing
sincethese parallel ports are all Bi-Directional. would be cool)
A Tarbell 8" controller that is hooked up to one (wouldn't want
more) 256k 8" floppy(only thing its used for is formatting and
transfering data to/from thepdp11/34's rx01 drive.. (damn DEC.
can't even make their drives able toformat a floppy. thanks a
lot.)  and tto top it off, Jade's "Bus Probe" anda homebuilt Hex
display for address/IO... oh, its also using an IBM clone101 key
keyboard (Better than that old IMSAI IKB-1 anyday!) I'm quite
proud of my box, as ya can tell..  anyways, coupla
questions...(oh, if you've got a standard Z80SIO, i've got a
great home-hacked commprogram.. (well, I'm not responsible for
writing it.. My cohort "Dent" is.. full featured and its under 3
K. Great for ROMing.. (It even has SCROLLBACK!! heh. i'll have
him post the source.)  anyways, coupla questions.I have another
S100 machine that is sitting in my garage waitingto be
reassembled. there are quite a few Z80a CPU boards out there.(As
in 4 of them. and one 8080 board) i was wondering if anyone
knewof anyone else | has info on how to hook up more than one
processor toa S100 bus... I'd really enjoy having a
multiprocessor Z80 machine lying around, and i could apply the
same trick to Leviathan (the bigUzi / CP/M machine described
above).. would be a righteous hack.Thanx in advance, if theres
anyone to thank.Techs / [e-mail]        aNk1e ByT0rz
k1Ub common accountInsert disclaimer of your choice here. This
Disclaimer Space IntentionallyLeft Blank.. From
packet-radio-relay  Tue Apr 10 11:33:51 1990Received: by
ucsd.edu; id AA22555    sendmail 5.61/UCSD-2.0-sun    Tue, 10 Apr 90
11:33:54 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA22550    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 10 Apr 90
11:33:51 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA16926; Tue, 10 Apr 90 11:22:09 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 10 Apr 90 17:11:03 GMTFrom:
van-bc!ubc-cs!alberta!atha![e-mail]  (Richard
Loken)Organization: Athabasca UniversitySubject: Re: CP/M
sofware for packet radio and TCP/IPMessage-Id:
<[e-mail]>References:
<[e-mail]>Sender:
[e-mail]: [e-mail]
article <[e-mail]>, by
karn@jupiter..bellcore.com (Phil R. Karn):> Yes, my code did
indeed begin life on CP/M, specifically the Xerox 820.> But this
was five years ago, and much has happened in the meantime to PC>
clone pricing and availability to make me wonder why anybody
would still> be interested in CP/M. With XT clone boards having
bottomed out at $60> or so, and with a well-established and
highly competitive supplier network> supporting PC technology,
why bother with Z-80s and CP/M? I just don't see> the point.> >
PhilBecause I own a CP/M box.Because I like to see how how much
can be done with 64k and 4MHz.Because I don't like 80xx
boxes.Because I feel like it.Because this is a hobby and
economic justification is irrelevant.     *********        73
**********        Richard Loken VE6BSV   .      ****          ..
****        Athabasca University ....     ****        Athabasca,
Alberta Canada..........****
[e-mail]    {alberta|decwrl}!atha!techFrom
packet-radio-relay  Tue Apr 10 12:17:51 1990Received: by
ucsd.edu; id AA25111    sendmail 5.61/UCSD-2.0-sun    Tue, 10 Apr 90
12:17:53 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA25107    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 10 Apr 90
12:17:51 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA19966; Tue, 10 Apr 90 12:07:38 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 10 Apr 90 19:01:38 GMTFrom:
[e-mail]  (Martha S. Rose)Organization: MIT, EE/CS
Computer Facilities, Cambridge, MASubject: packet from
handhelds, help for novice packeteerMessage-Id:
<[e-mail]>Sender:
[e-mail]: [e-mail]'m going
to be traveling around the country starting sometime in thefall,
and hope to get personal email and limited file transfers
viapacket, and (if possible) run a mobile packet BBS or TCP/IP
node BBSfor techno-nomads.  I'm very very new to all this,
having barelycreased the binding on my just-purchased Q & A
reference.  I shouldhave my Tech license by June, along with a
lot more savvy about allthis, but best to start asking questions
now!My current plan is to try to find a good deal on a used
dual-bandhandheld (146/440) at Hosstraders in a few weeks.  I
want to get onethat has the requisite connectors (or
modifiability) to hook up forpacket.  I'd also like to keep an
eye out for a good deal on a packetmodem.  Unfortunately, I'm
still so new at it that I don't know whatto look for or what to
stay away from.  Can some of you experiencedhands give me a good
beginning equipment list-of-suggestions?(Notes: Of course, I
*can* wait until the Fall HossTraders if I haveto, but I'd like
to be able to snag components that I'll definitelyneed if I see
an exceptional deal!  I want dual band because most ofmy friends
in Boston/MIT and the Bay Area are on 440 (including theMIT
packet link), but there'll be many many more folks on 2-meter
inthe non-urban areas where I expect to spend most of my
time.)Constraints: (flag any that seem unreasonable!)     -
assemble complete system (except computer & power) for under
$2K    - use Mac SE which I already own (though I will get a PC if
I gotta)    - use handheld dual-band which I can remove to carry
around    - at least 1200 baud link, faster is nicer!    - able to use
satellite, repeaters, or whatever to reach    San Fran/Bay Area or
MIT W1MX packet-to-Internet links    - able to deal with Packet
TCP/IP (this is a big black hole that    I've only read about here
and don't know the details of)    - assembly possible by someone
(me!) who can solder, use a multi-    meter, and read (slowly)
simple circuit diagrams without understanding    them very well.  I
have a StuDly EE Housemate who could help me    etch & load a PC
card if that's the One True Way, but I'd prefer    to stick with
off-the-shelf subsystems where possible/affordable.    - can be
reasonably contained & antennaed within the scope of my    18-foot
Airstream (shouldn't be a problem, but can't use any 30    foot
stationary towers, for instance!)  Will I need a mini-dish?    Or
can I get by with a long antenna along the side which I'd
raise    when parked?Thanks very very much for assistance and
input!  I'm going to collectall this stuff I'm learning into one
central reference and put it inHypercard after I'm set up, share
the gift of knowledge and all that.I'm especially interested in
hearing from any full-time nomads outthere. If they're reading
this they're probably doing exactly what Iwant to
do!73,_Strata****************************************************
*******************M. Strata Rose, Systems
Manager            [e-mail] Center for Cognitive
Science        [e-mail]10-244                        617-253-7892**********
*************************************************************From
 packet-radio-relay  Tue Apr 10 15:10:30 1990Received: by
ucsd.edu; id AA05146    sendmail 5.61/UCSD-2.0-sun    Tue, 10 Apr 90
15:10:45 -0700Received: from WSMR-SIMTEL20.ARMY.MIL by ucsd.edu;
id AA05138    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 10 Apr 90
15:10:30 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listMessage-Id:
<[e-mail]>Received: from
CORNELLC.cit.cornell.edu by WSMR-SIMTEL20.ARMY.MIL with TCP;
Tue, 10 Apr 90 16:10:13 MDTReceived: from MEMSTVX1.BITNET by
CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id
8843; Tue, 10 Apr 90 17:45:46 EDTDate: Tue, 10 Apr 90 16:24
CDTFrom: Suresh Kagoo N9GSA
<[e-mail]>Subject: Packet
Access from the NetworksTo:
[e-mail]-Vms-To:
IN%"[e-mail]"I am Electrical
Engineering Student at Memphis State University in
MemphisTennessee. I would like to know if there are any Gateways
on the Networksthat allow you to send and receive packet mail.I
do belive that someone from Little Rock AR. ( WD5B maybe) had
such a gateway.Any Info on this subject welcome.Suresh Kagoo
N9GSA/4S7???          Internet : [e-mail]
State University             Bitnet   : SKAGOO@MEMSTVX1Memphis,
Tennessee.                  VHF      : 146.82 224.42 W4BS/R
                               UHF      : 444.000  WA4ADT/RFrom
packet-radio-relay  Tue Apr 10 15:32:09 1990Received: by
ucsd.edu; id AA06429    sendmail 5.61/UCSD-2.0-sun    Tue, 10 Apr 90
15:32:12 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA06424    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 10 Apr 90
15:32:09 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA02528; Tue, 10 Apr 90 15:19:06 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 10 Apr 90 21:52:21 GMTFrom:
freezer![e-mail]  (Gary Duzan)Organization:
University of Delaware -- 040 Smith Sun LabSubject: KA9Q on an
Excelan EthernetMessage-Id: <[e-mail]>Sender:
[e-mail]: [e-mail]   I am
trying to get KA9Q running on a 286 with an Excelan card. Any
hints?Thanx.                                        Gary Duzan
                                     Time  Lord
                  Third Regeneration--
[e-mail]      _o_
--------------------------                 _o_    [|o o|]
"My field is blood and guts programming." -- Me    [|o o|]
|_O_|      "Don't listen to me; I never do." -- Doctor Who
|_O_|From packet-radio-relay  Tue Apr 10 16:34:36 1990Received:
by ucsd.edu; id AA09567    sendmail 5.61/UCSD-2.0-sun    Tue, 10 Apr
90 16:34:38 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu;
id AA09563    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 10 Apr 90
16:34:36 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA06668; Tue, 10 Apr 90 16:20:04 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 10 Apr 90 23:18:24 GMTFrom:
m2c!wpi![e-mail]  (John C Whitson
KB2GNC)Organization: Worcester Polytechnic Institute, Worcester,
Mass.Subject: TNC1KISS.whatever helpMessage-Id:
<[e-mail]>Sender: [e-mail]:
[e-mail]    Someone please tell me what I am doing
wrong? Please!?    I did the following:    1)    Got 3 2764A EPROMS, took
the file TNC_TNC1.ARC from        SIMTEL20.ARPA, and burned 3 proms
with the three        files TNC1KISS.MOT, TNC1BOOT.MOT, and
TNC1CAL.MOT.        The EPROM burner did not complain, and they
verified        fine.    2)    I popped open my HD-4040 TNC, took out the
prom at        E000-FFFF, put in my PROM for KISS, and powered on        the
TNC. Nada. Nothing. Not even the C000 ROM that        normally loads.
No signon, no message. NET.EXE didn't        like it either on my
PC.    It isn't as simple as it looks, I guess. Here is what I
have:    IBM PC/AT Compatible, and NET.EXE (this boots up
fine).    HEathkit HD-4040 with the WA8DED Roms, Version 1.1    The
new KISS and BOOT and CAL roms from SIMTEL20.ARPA and        Gerard
VanderGrinten, PA0GRI.    COuld someone tell me what I am missing?
The new roms claim    to ignore the NOVRAM, so that shouldn't do
anything.    Thanks again for everyone's help!!!! Life is but a
series of    steps (or packets, or state transitions, or whatever!
thanks!)-- ----------  If at first you don't succeed,  so much
for skydiving ---------John Whitson:   Internet:
[e-mail]  Bitnet: [e-mail]73's from
KB2GNC/1                         UUCP:
uunet!wpi.wpi.edu!jwhitson----------  Anything with this tag on
it is purely my own opinion ---------From packet-radio-relay
Tue Apr 10 20:32:46 1990Received: by ucsd.edu; id
AA20551    sendmail 5.61/UCSD-2.0-sun    Tue, 10 Apr 90 20:32:48
-0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA20546    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 10 Apr 90
20:32:46 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA22612; Tue, 10 Apr 90 20:26:24 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 11 Apr 90 03:25:06 GMTFrom:
[e-mail]  (Steven L. Finberg)Organization:
Massachusetts Institute of TechnologySubject: Spring FLEA at MIT
 Sunday April 15  Camb MA   HAM SWAPFESTMessage-Id:
<[e-mail]>Sender:
[e-mail]: [e-mail]***** 50
cent buyers discount with hardcopy of this notice
********COMPUTERS - ELECTRONICS - HAM RADIO - COMPUTERS -
ELECTRONICS                   SPRING FLEA AT MIT
Sunday, April 15, 1989                         9AM-4PMCome to
the city for a great flea - plenty of free parking.        MIT's
semi-annual electronics and ham radio        flea will take
place on the Sunday of Patriot's        Day weekend again this
year.        There is tailgate space for over 200 sellers and
    free, off-street parking for 1000 cars!        Buyers
admission is $1.50 (you get 50c off if        you're lucky
enough to have a copy of our add)        and sellers spaces are
$6.00-each at the gate        The flea will be held at the
corner of Albany and        Main streets in Cambridge; right in
the Kendall        Square area from 9AM to 4PM, with sellers
set-up        time starting at 7AM.  Have no fear of rain, a
   covered tailgate area is available (6'8" clearance).
Talk-in: 146.52 and W1XM/R-449.725/444.725 (PL 114.8/2A).
Sponsors: MIT Electronics Research Society                  MIT
UHF Repeater Association (W1XM)                  MIT Radio
Society (W1MX)    For more info / advanced reservations 617 253
3776******** 50 cent  buyers discount with hard copy of this
notice ************From packet-radio-relay  Tue Apr 10 20:47:08
1990Received: by ucsd.edu; id AA21155    sendmail
5.61/UCSD-2.0-sun    Tue, 10 Apr 90 20:47:10 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA21151    sendmail
5.61/UCSD-2.0-sun via SMTP    Tue, 10 Apr 90 20:47:08 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA23195; Tue, 10 Apr 90
20:35:52 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 11 Apr 90 01:22:52 GMTFrom:
shlump.nac.dec.com!phdsr1![e-mail]  (Karl Harris -
N0ACO)Organization: Digital Equipment CorporationSubject: Packet
at Trenton???Message-Id: <[e-mail]>Sender:
[e-mail]: [e-mail]'s
going on with the packet presentations this year at Trenton
ComputerFestival?I think the site has changed, I've been told
the festival is going to be atMercer County Commmunity College.
Can anyone verify this?Thanks, in advance!KarlFrom
packet-radio-relay  Tue Apr 10 21:17:26 1990Received: by
ucsd.edu; id AA22481    sendmail 5.61/UCSD-2.0-sun    Tue, 10 Apr 90
21:17:28 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA22465    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 10 Apr 90
21:17:26 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA25032; Tue, 10 Apr 90 21:05:48 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 10 Apr 90 15:50:57 GMTFrom:
zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!texbell!uudell!helps!
bongo![e-mail]  (Julian
Macassey)Organization: The Hole in the Wall  Hollywood
California U.S.A.Subject: Daisy-chained RS-232 cableMessage-Id:
<[e-mail]>Sender: [e-mail]:
[e-mail]    I would like to join the serial ports of
several computers together so I can run KA9Qs SLIP between then.
Sort of poor man's Ethernet. I know that a similar trick is used
to join several TNCs together for multi NET-ROM use. The trick
involves resistors and diodes I believe.    Does anyone have
details on how to daisy-chain RS-232 ports?Yours in eager
anticipation-- Julian Macassey, n6are  [e-mail]
ucla-an!denwa!bongo!julianN6ARE@K6IYK (Packet Radio)
n6are.ampr.org [44.16.0.81] voice [phone]From
packet-radio-relay  Tue Apr 10 21:36:32 1990Received: by
ucsd.edu; id AA23229    sendmail 5.61/UCSD-2.0-sun    Tue, 10 Apr 90
21:36:34 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA23224    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 10 Apr 90
21:36:32 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA26468; Tue, 10 Apr 90 21:27:55 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 10 Apr 90 22:27:40 GMTFrom:
vsi1!zorch!tandem![e-mail]  (Kevin J.
Rowett)Organization: Tandem Computers, Inc.Subject: Re: Channel
access, node vs digiMessage-Id:
<[e-mail]>References:
<[e-mail]>,
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail] (Phil R.
Karn) writes:>>However, if you believe (as I do) that even with
lots of point-to-point>links there will still be a need and a
place for multiple access>operation, then we still need a better
solution to the collision>problem. Yet another possible scheme
would be CSMA/CA (collision>avoidance) modeled after Apple's
Localtalk network. Basically each>station sends a short "request
to send" (RTS) message to the destination>station and waits for
a "clear to send" (CTS) reply before sending the>actual
data.>>Stations hearing a CTS would stay off the channel even if
they had not>heard the RTS that caused it. This is the key
feature of the algorithm,>as it causes hidden terminals to
remain silent until the traffic can be>sent. (The RTS messages
would indicate the amount of traffic to be sent,>and the CTS
message would echo this so the other stations would know
how>long to stay off the channel.)>At the risk of Flames,
another alternative is to have a master station,and *poll*.  I
know this imposes the requirement of a master ( buildtwo if your
worried about single point of failure ), but masters haveworked
pretty well for the voice FM repeater crowd.  Consider
construction of a cell of users ( this scales nicely, in
eitherdirection) that have a master.  The master polls each
member of the cell.  The master would also have links (
preferrably pt-pt ) going toother cells.  This way, a master
could be moving traffic in and outof a cell duplexed with
intra-cell traffic. N6RCEFrom packet-radio-relay  Wed Apr 11
00:37:31 1990Received: by ucsd.edu; id AA01305    sendmail
5.61/UCSD-2.0-sun    Wed, 11 Apr 90 00:37:41 -0700Received: from
WSMR-SIMTEL20.ARMY.MIL by ucsd.edu; id AA01300    sendmail
5.61/UCSD-2.0-sun via SMTP    Wed, 11 Apr 90 00:37:31 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: from
chx400.switch.ch ([130.59.1.2]) by WSMR-SIMTEL20.ARMY.MIL with
TCP; Wed, 11 Apr 90 01:27:15 MDTReceived: by chx400.switch.ch
(5.57/Ultrix2.4-C)    id AA11993; Wed, 11 Apr 90 09:27:17
+0200Received: from zit.cigy  by cgch.cigy     id AA23537; Wed, 11
Apr 90 09:10:55 +0200  (4.0/SMI-3.2-CG-1.0G) Received: by
zit.cigy      id AA27451; Wed, 11 Apr 90 09:10:42 mes
(15.11/SMI-3.2-CG-1.0A) Message-Id: <[e-mail]
>Subject: Re: TNC1KISS.whatever helpTo:
[e-mail]: Wed, 11 Apr 90 9:10:39
MESZFrom: Joseph C. Pistritto <cgch!jcp>In-Reply-To:
<[e-mail]>; from "John C Whitson
KB2GNC" at Apr 10, 90 11:18 pmMailer: Elm [revision: 64.9]I have
exactly the same configuration.  I burned TNC1KISS.MOTinto a
prom (by itself), replaced the Prom in the HD4040, andvoila,
first time.  I didn't bother to hook up a terminal tosee what
happened, just ran NET straight away.  Note thatTNC1KISS and
TNC1BOOT are different programs, you can't burnthem both into
the same prom.  TNC1KISS will 'come up' in KISSmode, at 4800
baud I believe (link from the TNC->PC).  You mayjust have the
speed wrong.
-jcp-PS: you are correct, NOVRAM is not used by TNC1KISS--Joseph
C. Pistritto ([e-mail] -or- cgch![e-mail]) Ciba
Geigy AG, R1241.1.01, Postfach CH4002, Basel, Switzerland Tel:
[phone] (work) [phone] (home)   GMT+2hrs!From
packet-radio-relay  Wed Apr 11 02:50:25 1990Received: by
ucsd.edu; id AA10324    sendmail 5.61/UCSD-2.0-sun    Wed, 11 Apr 90
02:50:36 -0700Received: from WSMR-SIMTEL20.ARMY.MIL by ucsd.edu;
id AA10278    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 11 Apr 90
02:50:25 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listMessage-Id:
<[e-mail]>Received: from CUNYVM.CUNY.EDU by
WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 11 Apr 90 03:49:44
MDTReceived: from DEARN by CUNYVM.CUNY.EDU (IBM VM SMTP
R1.2.2MX) with BSMTP id 3887; Wed, 11 Apr 90 05:48:53
EDTReceived: from DBSTU1 (C0033003) by DEARN (Mailer R2.03B)
with BSMTP id 7547; Wed, 11 Apr 90 11:48:55 CETDate:
Wed, 11 Apr 90 11:41:50 MEZFrom: "Detlef J. Schmidt"
<[e-mail]>Subject:      re:
channel access, node vs digiTo: Packet-radio
<[e-mail]>X-Acknowledge-To:
<C0033003@DBSTU1>on>Date:         Tue, 10 Apr 90 22:27:40
GMT>From:         "Kevin J. Rowett"
<vsi1!zorch!tandem![e-mail]>writes>Subject:      Re:
Channel access, node vs digi> ..............>>At the risk of
Flames, another alternative is to have a master station,>and
*poll*.  I know this imposes the requirement of a master (
build>two if your worried about single point of failure ), but
masters have>worked pretty well for the voice FM repeater
crowd.some kind of non flame here:what you described is exactly
how some satellite uplinks for mobilestations are working to
avoid collisions.And if the 'poll' is encapsulated inside of the
regularframe this principle would not even avoid additional
overhead it willavoid some empty ACK frames which would have to
be sent otherwise.Some nice description about this could be
found in   IEEE journal on selected areas on communicationof the
preveous years.An adaption to AX.25 of this access method ( DAMA
) was described in lastyear's proceedings of the ARRL's
meeting.If the neccessity of a master is just a pain or the
strongest successis mostly a problem of your point of view. If a
cellular backbone networkis build ( using exclusive links on
dedicated freqs ) a master stationfor all uplinks is neccessary
anyway. So there are good reasonsto manage the channel access by
this station|Some ideas about other collision avoidance
technics.A full-duplex channel does not avoid collisions, it
just reduces themsomewhat. The dead-time-clobbering effect could
not be solved this way.And there are other problems. But it
wastes bandwidth.Transposing APPLE's localtalk to PR could help
a little bit but doesn'tsolve the problem in general. Because no
station can make shure toget it's RTS frame through and no CTS
sending station can make shureto stop ALL other stations if some
are hidden related to the CTS sendingstation. Only a master
station up on a hill has a chance to be heard byall others.I
guess Localtalk wasn't designed to solve hidden station
problems( there are no hidden stations on a wire ). So
transposing this methodto PR wouldn't bring us a general
solution. But it will bring us anotherprotocol which would be
incompatible to AX.25Detlef ( dk4eg ).From packet-radio-relay
Wed Apr 11 05:17:40 1990Received: by ucsd.edu; id
AA18038    sendmail 5.61/UCSD-2.0-sun    Wed, 11 Apr 90 05:17:42
-0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA18034    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 11 Apr 90
05:17:40 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA23904; Wed, 11 Apr 90 05:12:22 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 11 Apr 90 08:23:10 GMTFrom:
ka9q.bellcore.com![e-mail]  (Phil Karn)Organization:
Secular Humanists for No-CodeSubject: Re: CP/M sofware for
packet radio and TCP/IPMessage-Id:
<[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail]
(Andrew Payne) writes:>    This item joggled my memory about a
question I've been meaning to >ask for a while.  What's the
smallest PC system configuration you can get >away with?  I had
in mind:  motherboard, drive controller, drive, power >supply,
and any necessary packet I/O boards.  No display card, display,
>keyboard.>    Motivation being setting up a dedicated packet
switch.  It sure>would be cheaper than outfitting a full system
and would be less power>hungry.I'm doing exactly this right
here. I have a stripped XT that runs my code asa dedicated IP
gateway between my shack Ethernet and a 220.55 MHz 56kbpacket
channel. It consists of a case, power supply, XT motherboard,
single360K floppy drive, Ethernet interface and DRSI PCPA card
(to talk to themodem). When I turn it on, it boots
automatically. I leave it on 24hours/day. I can't remember what
all the parts cost, but just go to one ofthe PC computer shows
and you can certainly price a comparable system veryquickly.>    I
know my BIOS would balk right away at no display and keyboard,
but>I was wondering if anyone had tried such a configuration?My
BIOS doesn't balk, as long as I set up the config switches
properly. Mysystem does have a display adaptor, monitor and
keyboard mainly because Ialready had them sitting around, but
the system will run just fine if Idisconnect them.PhilFrom
packet-radio-relay  Wed Apr 11 05:17:25 1990Received: by
ucsd.edu; id AA17998    sendmail 5.61/UCSD-2.0-sun    Wed, 11 Apr 90
05:17:28 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA17994    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 11 Apr 90
05:17:25 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA23887; Wed, 11 Apr 90 05:12:15 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 11 Apr 90 08:18:40 GMTFrom:
ka9q.bellcore.com![e-mail]  (Phil Karn)Organization:
Secular Humanists for No-CodeSubject: Re: Channel access, node
vs digiMessage-Id: <[e-mail]>References:
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail]
(Barry McLarnon DGBT/DIP) writes:>It seems clear to me that,
whatever else we do, we should strive towards>having *only*
full-duplex repeaters on multiple-access channels.Even though
I'm an advocate of this approach, I'm not sure that it's theonly
way to go. The more I look at cellular telephone systems the
more I'mbothered by the traditional amateur approach of finding
the tallest buildingor mountain in the area and sticking the
highest-powered repeater you canafford on top. This causes a
given channel (or channel pair) to be limitedto one user at any
instant over a very wide area. And then we wonder whyit's so
hard to get channels.One of the potential advantages of the
CSMA/CA scheme, especially ifautomatic power control is
incorporated, is its inherent ability to exploitspatial reuse of
a common channel. Working against this, of course, is theadded
overhead of the RTS/CTS dialog. What I would really like to see
is theresult of some simulations that compare the two techniques
for a variety ofrealistic configurations.PhilFrom
packet-radio-relay  Wed Apr 11 05:32:14 1990Received: by
ucsd.edu; id AA18635    sendmail 5.61/UCSD-2.0-sun    Wed, 11 Apr 90
05:32:16 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA18630    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 11 Apr 90
05:32:14 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA24136; Wed, 11 Apr 90 05:17:24 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 11 Apr 90 08:28:40 GMTFrom:
ka9q.bellcore.com![e-mail]  (Phil Karn)Organization:
Secular Humanists for No-CodeSubject: Re: CP/M sofware for
packet radio and TCP/IPMessage-Id:
<[e-mail]>References:
<[e-mail]>,
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail] (Richard
Loken) writes:>Because I own a CP/M box.>Because I like to see
how how much can be done with 64k and 4MHz.>Because I don't like
80xx boxes.>Because I feel like it.>Because this is a hobby and
economic justification is irrelevant.Fine. My code is freely
available to any and all hams. It's mostly in C andshould be
reasonably easy to port, assuming you can cram what
currentlytakes 277K on the PC (not counting data space) into 64K
(counting dataspace). Consider also that most Z-80 C compilers
seem to generate objectcode that's roughly twice as large as on
the 8086.Have at it!PhilFrom packet-radio-relay  Wed Apr 11
06:42:30 1990Received: by ucsd.edu; id AA21077    sendmail
5.61/UCSD-2.0-sun    Wed, 11 Apr 90 06:42:43 -0700Received: from
WSMR-SIMTEL20.ARMY.MIL by ucsd.edu; id AA21072    sendmail
5.61/UCSD-2.0-sun via SMTP    Wed, 11 Apr 90 06:42:30 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: from
chx400.switch.ch ([130.59.1.2]) by WSMR-SIMTEL20.ARMY.MIL with
TCP; Wed, 11 Apr 90 07:42:03 MDTReceived: by chx400.switch.ch
(5.57/Ultrix2.4-C)    id AA18630; Wed, 11 Apr 90 15:26:32
+0200Received: from zit.cigy  by cgch.cigy     id AA26586; Wed, 11
Apr 90 15:14:48 +0200  (4.0/SMI-3.2-CG-1.0G) Received: by
zit.cigy      id AA02131; Wed, 11 Apr 90 15:14:14 mes
(15.11/SMI-3.2-CG-1.0A) Message-Id: <[e-mail]
>Subject: Re: Channel access, node vs digiTo:
[e-mail]: Wed, 11 Apr 90 15:14:04
MESZFrom: Joseph C. Pistritto <cgch!jcp>Cc:
cgch!bpistrIn-Reply-To: <[e-mail]>;
from "Phil Karn" at Apr 11, 90 8:18 amMailer: Elm [revision:
64.9]To get really good spatial reuse, you'd have to reduce
power A LOT.In particular, it's worth noting that cellular
systems RARELY reusethe 'setup' channels between cells, (there
are like 30-40 of theseper carrier).  The voice channels are
reused, because many cellshave sectorized antenna systems, and
you know which sector  the mobileis in.If you had a bunch of
linked packet stations, accessing one database,then you'd pretty
much have to use geography, and use of differentfrequencies by
adjacent 'cells' to allow sufficient reuse to makeit worthwhile.
 Also, the central node would have to FORCE theconnection to be
handled by the nearest node on the frequency, whichis a bit
beyond the concepts we have installed now.  I can think
ofsituations where this would work well, and also really
pathologicalones.  (One of the most pathological cell systems is
Los Angeles, wheremost of the cells can 'hear' each other).
Chicago was the first reallyhard one (its really flat).I'm sure
a lot of queuing theory models have been done of the
cellularsystem, but it has the advantage of being able to 'park'
your connectiononto a different channel than you make the
initial contact on.  Perhaps thiswould be a useful feature for a
'packet radio?'.Very few cellular systems out their actually
implement power cutbacks, (atleast two years ago this was true
on the east coast).  My cellphone had'diagnostic mode' where you
could see all this, and you practically had tobe on top of the
cell site (100-200 meters) before it would cut power.  Thiswas
Bell Atlantic and Cell One in Baltimore, DC, New York, and
Phila.
-jcp---Joseph C. Pistritto ([e-mail] -or-
cgch![e-mail]) Ciba Geigy AG, R1241.1.01, Postfach
CH4002, Basel, Switzerland Tel: [phone] (work) +41 61
692 1728 (home)   GMT+2hrs!From packet-radio-relay  Wed Apr 11
07:39:33 1990Received: by ucsd.edu; id AA23754    sendmail
5.61/UCSD-2.0-sun    Wed, 11 Apr 90 07:39:53 -0700Received: from
dgbt.crc.dnd.ca by ucsd.edu; id AA23745    sendmail
5.61/UCSD-2.0-sun via SMTP    Wed, 11 Apr 90 07:39:33 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
dgbt.crc.dnd.ca (5.57/smail2.5/12-02-88)    id AA16595; Wed, 11 Apr
90 10:38:29 EDTDate: Wed, 11 Apr 90 10:38:29 EDTFrom:
[e-mail] (Barry McLarnon DGBT/DIP)Message-Id:
<[e-mail]>To:
[e-mail]: Re: Packet at Trenton???Snarfed
from Compu$erve:#: 13398 S9/Packet Radio    04-Apr-90
20:39:47Sb: Trenton Packet MeetingFm: Jon Pearce, WB2MNF
70206,421To: AllArrangements are being finalized for the packet
radio seminar to be held atthe Trenton Computerfest on April 21.
 This year the 'fest will be held atMercer County College, since
the load became too great for Trenton State. Since we're going
to be in new facilities we've scaled down the
formalpresentations to allow more informal communications, side
meetings, andflea-marketing.  The topic schedule and preliminary
time slots are as follows:   Digital Signal Processing (DSP) -
10:00 to 11:00 by N4HY and friends   Working the Digital
Satellites - 12:00 to 1:00 by WB2MNF   Setting Up Your TCP/IP
Station - 2:00 to 3:00This should give you a chance to hear
about the NEW advances in DSP - severalmanufacturers will have
DSP boards on display at Dayton, and this technologypromises to
touch virtually EVERY digital communication mode.  Hear N4HY
tellhow he used DSP and a Commodore 64 at work to decode the
digital signals in"Star Trek IV" (I THINK it was a C64 - I
remember that it started with a "C").This was an astonishing
year for amateur satellites with SEVEN new birdslaunched since
new years.  WB2MNF has been active on most of the newsatellites
and will present an overview of the satellites, how you can
usethem, and what you need to work them.TCP/IP has been
presented at several TCF meetings; however mostly at
atheoretical and developmental level.  This seminar will discuss
the proceduresthat you need to follow to get a station on the
air - the meanings of thecommands, proper station configuration,
etc.  The speaker team is beingassembled.The meetings will be in
Room 210 of the Math and Science Building.  A talk-infrequency
will be announced later.Further information will follow.  Hope
to see you there.Jon Pearce, WB2MNF@WB2MNF- Barry VE3JF---Barry
McLarnon      Communications Research Center     Ottawa, ON
CanadaInternet: [e-mail]       UUCP:
...utzoo!dciem!nrcaer!dgbt!barryCI$: 71470,3651   PBBS:
VE3JF@VE3JF   AMPRnet: [e-mail]3jf [44.135.96.6]From
packet-radio-relay  Wed Apr 11 09:33:05 1990Received: by
ucsd.edu; id AA02378    sendmail 5.61/UCSD-2.0-sun    Wed, 11 Apr 90
09:33:08 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA02372    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 11 Apr 90
09:33:05 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA10264; Wed, 11 Apr 90 09:29:05 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 11 Apr 90 13:30:13 GMTFrom:
gvlv2!gvlv3.gvl.unisys.com![e-mail]  (Ed
Naratil)Organization: Unisys Defense Systems, Great Valley Labs,
Paoli, PaSubject: No Code - My two cents worthMessage-Id:
<[e-mail]>Sender:
[e-mail]: [e-mail]
follows my opinion on the so-called "NO CODE LICENSE"In the
beginning there was spark gap and CW, or to be more
correctinterrupted continuous wave (ICW).  Therefore there was a
need totest would-be amateur radio operators in rules,
regulations, *AND*operating proficiency in ICW.This is 1990.  We
have not only ICW available, but also AM, FM,SSB, NBFM, RTTY,
PACKET, MCW, etc., etc.Therefore, I propose that the amateur
bands be broken up intoexclusive segments for each mode of
operation.  No longer willCW be allowed anywhere in a band.I
also propose, that the would-be amateur radio operator
berequired to take a test for *HIS* mode of operation in
additionto the required test in rules and regulations.Call signs
would be issued based on the mode of operation in orderto police
the bands. i.e.  PA3xxxx for Packet License in the 3rdcall area.
 CW3xxxx for CW License in the 3rd call area. etc. Theprefix
would designate the mode of operation.  Naturally to
avoidconfusion with calls of other countries a complete
world-widere-issuance of call signs would be needed.I think this
would appease those who claim "my call is like my name,I don't
want to change it." (shades of incentive licensing).  But,just
think, if you operate three different modes, you'll have
threedifferent calls.....just like a - first name - middle name
- andlast name.Note to possible ARRL officials:Please consider
the above when next attending a League policymeeting.  Thank
you.Ed Naratil,  W3BNR @ N3LA.#EPA.PA.USAARRL LIFE Member,  QCWA
LIFE MemberFrom packet-radio-relay  Wed Apr 11 11:35:10
1990Received: by ucsd.edu; id AA07681    sendmail
5.61/UCSD-2.0-sun    Wed, 11 Apr 90 11:36:08 -0700Received: from
WSMR-SIMTEL20.ARMY.MIL by ucsd.edu; id AA07608    sendmail
5.61/UCSD-2.0-sun via SMTP    Wed, 11 Apr 90 11:35:10 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: from
ria.ccs.uwo.ca by WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 11 Apr
90 12:33:44 MDTReceived: from hydra.uwo.ca by ria.ccs.uwo.ca
with SMTP;    (id AA08219) Wed, 11 Apr 90 14:32:32 -0400Message-Id:
<[e-mail]>Received: from
HAMSTER.business.uwo.ca by uwovax.uwo.ca with SMTP;    (pid e14)
Wed, 11 Apr 90 14:32:29 EDTDate: Wed, 11 Apr 90 12:16:20
ESTFrom: "Mark Bramwell, VE3PZR"
<[e-mail]>To:
<[e-mail]>Reply-To:
<[e-mail]>Subject: In-Reply-To: Re:
TNC1KISS.whatever help

=================================================================
=============Message-id: <[e-mail]> > Date:
   Wed, 11 Apr 90 09:10:39 MESZ> Reply-To:
[e-mail]> Sender: Packet Radio
<[e-mail]>> From: "Joseph C. Pistritto"
<cgch![e-mail]>> Subject:      Re: TNC1KISS.whatever help>
TO:  University of Western Ontario, School of Business
Administration> In-Reply-To:
<[e-mail]>; from "John C Whitson
KB2GNC">               at Apr 10, 90 11:18 pm> > I have exactly
the same configuration.  I burned TNC1KISS.MOT> into a prom (by
itself), replaced the Prom in the HD4040, and> voila, first
time.  I didn't bother to hook up a terminal to> see what
happened, just ran NET straight away.  Note that> TNC1KISS and
TNC1BOOT are different programs, you can't burn> them both into
the same prom.  TNC1KISS will 'come up' in KISS> mode, at 4800
baud I believe (link from the TNC->PC).  You may> just have the
speed wrong.>
-jcp-I have not been able to get tnc1kiss working.  However, I
did not spendmuch time on it.  If would be interested in the
switched settings, andwhat speed net wants with the kiss chip.
Also, what type of eprom areyou using?  I have a burner at
home.> > PS: you are correct, NOVRAM is not used by TNC1KISS> >
--> Joseph C. Pistritto ([e-mail] -or-
cgch![e-mail])>  Ciba Geigy AG, R1241.1.01, Postfach
CH4002, Basel, Switzerland>  Tel: [phone] (work) +41 61
692 1728 (home)   GMT+2hrs!>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=Mark Bramwell, VE3PZR                Located in
sunny London, OntarioInternet: [e-mail]  IP
Address: 129.100.22.100  Packet:  VE3PZR @ VE3GYQ
UWO Phone: [phone]From packet-radio-relay  Wed Apr 11
11:47:20 1990Received: by ucsd.edu; id AA08709    sendmail
5.61/UCSD-2.0-sun    Wed, 11 Apr 90 11:47:23 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA08702    sendmail
5.61/UCSD-2.0-sun via SMTP    Wed, 11 Apr 90 11:47:20 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA19064; Wed, 11 Apr 90
11:32:53 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 11 Apr 90 18:13:29 GMTFrom:
[e-mail]  (Andrew Payne)Organization:
Cornell Theory Center, Cornell University, Ithaca NYSubject:
Cheap synchronous serial for packetMessage-Id:
<[e-mail]>Sender:
[e-mail]: [e-mail]
brainstorm:        To get a synchronous serial port for packet,
why not retrofit a Zilog SCC to fit into an 8250 UART socket?
    Why bother?  Low cost:  serial cards are a dime a dozen.
I'd guess that with a little scrounging and some
not-too-difficult modification work, you could end up with a
dual port (or maybe even a four port:  2 SCCs) card for about
$30.  Plug in a cheap '3105 based 1200 baud modem and/or your
latest 56kb toy, hack a driver for Phil's TCP/IP, and off you
go!        Anyone care to comment on this?  I've got the specs
on the SCC and the 8250 datasheets are on order.  From what I
can remember about the 8250, it doesn't look that difficult:
just a matter of swizling the pins around.-- =  =  =  =  =  =  =
 =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
=Andrew C. Payne, N8KEI        UUCP:
...!cornell!batcomputer!payne                          INTERNET:
 [e-mail] packet-radio-relay  Wed Apr 11
12:02:24 1990Received: by ucsd.edu; id AA09998    sendmail
5.61/UCSD-2.0-sun    Wed, 11 Apr 90 12:02:26 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA09994    sendmail
5.61/UCSD-2.0-sun via SMTP    Wed, 11 Apr 90 12:02:24 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA20065; Wed, 11 Apr 90
11:48:50 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 11 Apr 90 14:02:40 GMTFrom:
hpcc01!col![e-mail]  (Bdale Garbee)Organization: HP
Colorado Springs DivisionSubject: Re: CP/M sofware for packet
radio and TCP/IPMessage-Id: <[e-mail]>References:
<[e-mail]>Sender:
[e-mail]: [e-mail]>> With XT
clone boards having bottomed out at $60>> or so, and with a
well-established and highly competitive supplier network>>
supporting PC technology, why bother with Z-80s and CP/M? I just
don't see>> the point.>>Because I own a CP/M box.Great!  So do
I... anyone want to buy an Ampro Little Board?>Because I like to
see how how much can be done with 64k and 4MHz.Great!  Take
Phil's current sources and go for it!  The CP/M world willrevere
you...>Because I don't like 80xx boxes.None of us do, when
compared to workstations.  When compared to CP/M boxes,you're at
least two-sigma from the norm.>Because I feel like it.Great!
Take Phil's current sources and go for it!  The CP/M world
willrevere you...>Because this is a hobby and economic
justification is irrelevant.Agreed.  But given the choice of
writing for an inefficient cpu with 64k ofcode space, or a
slightly less inefficient (but still nasty) cpu with 640kof
space, which would you rather do?  It's clear that Phil goes for
the latter.It's clear that you prefer the former... great, the
world is big enough forboth of you...If your environment is
really that great, and you enjoy it that much, andyou want
Phil's code to run in it... noone is stopping you!73 - BdaleFrom
packet-radio-relay  Wed Apr 11 12:32:31 1990Received: by
ucsd.edu; id AA11862    sendmail 5.61/UCSD-2.0-sun    Wed, 11 Apr 90
12:32:34 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA11856    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 11 Apr 90
12:32:31 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA21684; Wed, 11 Apr 90 12:18:34 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 11 Apr 90 18:57:20 GMTFrom:
[e-mail]  (Brian Kantor)Organization: The Avant-Garde of
the Now, Ltd.Subject: Re: Cheap synchronous serial for
packetMessage-Id: <[e-mail]>References:
<[e-mail]>Sender:
[e-mail]:
[e-mail]@tcgould.tn.cornell.edu (Andrew Payne)
writes:>Minor brainstorm:>        To get a synchronous serial
port for packet, why not retrofit a Zilog >SCC to fit into an
8250 UART socket?You can get a PC-compatable wirewrap breadboard
card for about $20, andit already has complete address decoding
and bus buffering on it.  (JDRMicrodevices and elsewhere.)To add
a pair of SCCs to this is really trivial.One $6 monolithic
oscillator, a little bit of TTL glue, some RS232 levelshifters
for the ports that need it, and you've got it.  Real cheap.    -
BrianFrom packet-radio-relay  Wed Apr 11 14:04:34 1990Received:
by ucsd.edu; id AA18562    sendmail 5.61/UCSD-2.0-sun    Wed, 11 Apr
90 14:04:38 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu;
id AA18558    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 11 Apr 90
14:04:34 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA26979; Wed, 11 Apr 90 13:47:35 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 11 Apr 90 18:39:35 GMTFrom:
ka9q.bellcore.com![e-mail]  (Phil Karn)Organization:
Secular Humanists for No-CodeSubject: Re: Channel access, node
vs digiMessage-Id: <[e-mail]>References:
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> kevinr@tandem (Kevin J.
Rowett) writes:>At the risk of Flames, another alternative is to
have a master station,>and *poll*.  I know this imposes the
requirement of a master ( build>two if your worried about single
point of failure ), but masters have>worked pretty well for the
voice FM repeater crowd.  There are two main problems I can see
with polling schemes on packet radio.The first is one common to
all polling schemes: the overhead required inpolling a lot of
stations when only a few of them have any traffic. To getgood
performance in this situation you need to set up algorithms
fordynamically inserting and removing stations from the poll
list, and these canget very complex.The second drawback is that
the master station has to have a solid RF pathto every station
that it polls. This may not always be practical on asimplex
channel. If you use a repeater you don't have this problem,
butthen you might as well use CSMA/CD.The one place where
polling might make sense is if you build the repeater,are unable
to implement CD at the user nodes, and you invoke the
pollingtechnique only when the traffic load goes above some
threshold. Below thethreshold stations simply contend randomly
for the channel; when things getbusy you start polling. But the
algorithms to do this are decidedlynon-trivial.PhilFrom
packet-radio-relay  Wed Apr 11 20:02:55 1990Received: by
ucsd.edu; id AA13956    sendmail 5.61/UCSD-2.0-sun    Wed, 11 Apr 90
20:02:57 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA13951    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 11 Apr 90
20:02:55 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA19545; Wed, 11 Apr 90 20:01:35 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 12 Apr 90 02:42:34 GMTFrom:
pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sunybcs!bowe
[e-mail]  (Devon E Bowen)Organization: State
University of New York at Buffalo/Comp SciSubject: Re: CP/M
sofware for packet radio and TCP/IPMessage-Id:
<[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]>, [e-mail] (PhilKarn)
writes:> Fine. My code is freely available to any and all
hams.Does this sound snotty to anyone else or is it just me? The
original postasked a very simple question. He just wanted to
know if anyone had done anywork with TCP on CP/M or whether the
original stuff and been maintained toany degree. And instead of
a polite "no, no one is working on that but youare welcome to if
you like" he gets this lecture on how his computer isn'tworth
using and he should buy a PC. When he says he likes his computer
hegets another reply telling him if he wants it he should write.
Like he wascomplaining or something. But he never did
complained! In fact, he said:> I sort of hope there isn't any,
then I will have to write some.Anyone in this hobby that says
something like this in this day and age doesnot deserve the shit
this guy is getting back for it. And he's getting itfrom those
people pushing the most for a no-code license to get more
doersinto ham radio!!! [not meant to imply I am pro-code]This is
no fun anymore.DevonFrom packet-radio-relay  Wed Apr 11 21:19:09
1990Received: by ucsd.edu; id AA19075    sendmail
5.61/UCSD-2.0-sun    Wed, 11 Apr 90 21:19:12 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA19071    sendmail
5.61/UCSD-2.0-sun via SMTP    Wed, 11 Apr 90 21:19:09 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA24086; Wed, 11 Apr 90
21:13:22 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 11 Apr 90 21:47:20 GMTFrom:
hpcc01!col![e-mail]  (Bdale Garbee)Organization: HP
Colorado Springs DivisionSubject: Re: Daisy-chained RS-232
cableMessage-Id: <[e-mail]>References:
<[e-mail]>Sender: [e-mail]:
[e-mail]>    I would like to join the serial ports of
several computers together >so I can run KA9Qs SLIP between
then. Sort of poor man's Ethernet. I >know that a similar trick
is used to join several TNCs together for >multi NET-ROM use.
The trick involves resistors and diodes I believe.>>    Does anyone
have details on how to daisy-chain RS-232 ports?I'm not
precisely familiar with the N/R approach, but clearly for any
kind ofreasonable performance with the data rates involved,
you'll want to build awidget that provides a CTS or similar
input to hardware flow control the TXline on each PC, so they
don't mash each other on the wire.  The serial portcode in
NET/NOS as shipped does not use any kind of hardware flow
control inany form, though the folks in Japan have tweaked a
version to do incoming flowcontrol, and report it wasn't a very
big change to Phil's driver.Either PE1CHL or PA0GRI told me
about a board that had been fashioned in Hollandto drive the CTS
or whatever line on N/R-equipped TNC's in a round-robin
fashionto allow more equal sharing of TX time between the TNC's,
and to help eliminatethis collision problem, but I confess I
don't recall the exact details... maybe one of them or their
friends will hop in and tell us the specifics...73 - BdaleFrom
packet-radio-relay  Thu Apr 12 03:10:24 1990Received: by
ucsd.edu; id AA14723    sendmail 5.61/UCSD-2.0-sun    Thu, 12 Apr 90
03:10:40 -0700Received: from WSMR-SIMTEL20.ARMY.MIL by ucsd.edu;
id AA14688    sendmail 5.61/UCSD-2.0-sun via SMTP    Thu, 12 Apr 90
03:10:24 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listMessage-Id:
<[e-mail]>Received: from CUNYVM.CUNY.EDU by
WSMR-SIMTEL20.ARMY.MIL with TCP; Thu, 12 Apr 90 04:10:10
MDTReceived: from DEARN by CUNYVM.CUNY.EDU (IBM VM SMTP
R1.2.2MX) with BSMTP id 7255; Thu, 12 Apr 90 06:09:03
EDTReceived: from DBSTU1 (C0033003) by DEARN (Mailer R2.03B)
with BSMTP id 7827; Thu, 12 Apr 90 11:03:15 CETDate:
Thu, 12 Apr 90 11:00:35 MEZFrom: "Detlef J. Schmidt"
<[e-mail]>Subject:      re:
daisy-chained RS232 cableTo: Packet-radio
<[e-mail]>>I would like to join the
serial ports of several computers together>so I can run KA9Qs
SLIP between then. Sort of poor man's Ethernet. I>know that a
similar trick is used to join several TNCs together for>multi
NET-ROM use. The trick involves resistors and diodes I
believe.>>Does anyone have details on how to daisy-chain RS-232
ports?A simple approach to connect several RS232s together is
described inthe doc of TheNet. It uses some diodes crosswired
between all Ports.Up to ( about ) 5 ports may be connected
together in this fashion.The manual is available on several
servers.A more sophisticated solution was designed at the
NORD><LINK groupby DG9FU about 1 1/2 year ago. This version
utilized a ring counterwhich enabled / disabled all connected
ports ( via CTS pin ). Two (?)prototypes have been working and
this idea was catched by pa0apa.So he redesigned the circuitry
by replacing some CMOSs  by a FPLAand designed a PC-board around
it.This idea was given up meanwhile because every enable/disable
cyclefor a nonrequesting TNC produces 2 interrupts in the
firmware. Thisproduced a lot of additional load to the TNC's CPU
if theauto-enable feature of the interface is not used.So I
developed another circuitry that avoids all of these
problems.There are no unneccessary 'polls' to the TNCs. So there
is no additionalinterrupt load for the CPU ( unfortunatly the
TNC's SIO may only beoperated in software enable/disable mode in
the required context ).The circuit operates in a way of channel
interlock which allways grantsexclusiv bus access and avoids
collisions. A kind OM around here offeredto produce some pc
boards of this circuit. But I haven't got any inputof him since
quite a long time ( I hope he's still alive ).But meanwhile
there's a 4th version en vogue here. It is utilized inthe newest
development of NORD><LINK's TheNetNode. All RS232s areconnected
in serial, which means every TXD is connected to the nextRXD
etc. Access is handled in a way of a TOKEN RING. This
avoidsinternal collisions by it's nature. But it requires TOKEN
RINGsupport in the software of all connected TNCs or PCs ( of
course ).Detlef ( dk4eg ).From packet-radio-relay  Thu Apr 12
08:19:15 1990Received: by ucsd.edu; id AA29982    sendmail
5.61/UCSD-2.0-sun    Thu, 12 Apr 90 08:19:19 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA29964    sendmail
5.61/UCSD-2.0-sun via SMTP    Thu, 12 Apr 90 08:19:15 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA29181; Thu, 12 Apr 90
08:10:19 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 12 Apr 90 14:59:43 GMTFrom:
[e-mail]  (Andrew Payne)Organization:
Cornell Theory Center, Cornell University, Ithaca NYSubject: Re:
Daisy-chained RS-232 cableMessage-Id:
<[e-mail]>References:
<[e-mail]>Sender: [e-mail]:
[e-mail] article <[e-mail]>
[e-mail] (Julian Macassey) writes:>>    I would like to
join the serial ports of several computers together >so I can
run KA9Qs SLIP between then. Sort of poor man's Ethernet. I
>know that a similar trick is used to join several TNCs together
for >multi NET-ROM use. The trick involves resistors and diodes
I believe.>>    Does anyone have details on how to daisy-chain
RS-232 ports?>        I've got some docs here on hooking Net/Rom
nodes back to back.  It lists a product called a ".. TJP Octopus
which is a diode matrix board that allows up to 8 TNCs to be
tied together with minimum hassle.  The board is available from
      John Painter        7 Jefferson Street        Nashua, NY
03060        for $15.  Information on the board may be gotten
for a S.A.S.E at the same address."        I have neither used
nor seen the card.        Digging through the TheNET
DOCUMENTATION, I found the following diagrams which may be of
use:***** Start of excerpt
*****------------------------------------------------------------
--------------              Connector Cable for 2 TNCs Interlink
OperationTNC 1                                        TNC 2
signal+----+                                       +----+I 1
I---------------------------------------I 1  I    prot. groundI
  I                                       I    II 2
I-------------.    .--------------------I 2  I    Tx dataI    I
           .----+----.               I    II 3
I------------------.    .---------------I 3  I    Rx dataI    I
                                     I    II 5  I---
                    ---I 5  I    CTSI    I
                I    II 20 I---
---I 20 I    DTRI    I                                       I
 II 7  I---------------------------------------I 7  I    signal
groundI    I                                       I    II 10
I---.                               .---I 10 I    V-I    I   I
                            I   I    II 23 I---.
              .---I 23 I    DRSI    I
           I    I+----+
+----+-----------------------------------------------------------
---------------              Connector Cable for 3 TNCs
Interlink OperationTNC 1+----+I    II 1  I--------.I    I
II 2
I--------+---------------------------------------------------X---
-.I    I        I
   I    II 3
I--------+----------------------------------------X------.   I
 II    I        I                                        I
I   K    KI 5  I--------+-----------X--------------.
I      I   A    AI    I        I           I              I
       I      I   I    II 20
I--------+-----------+--------------+-----X---.   I      I   I
 II    I        I           I              I     I   I   I
I   I    II 7  I--------+---.       I              I     I   I
I      I   I    II    I        I   I       I              I
A   A   I      I   I    II 10 I---.    I   I       I
 I     K   K   I      I   I    II    I   I    I   I       I
        I     I   I   I      I   I    II 23 I---.    I   I
I              I     I   I   I      I   I    II    I        I
I       I              I     I   I   I      I   I    I+----+
   I   I       I              I     I   I   I      I   I    I
          I   I       I              I     I   I   I      I   I
  I              I   I       I              I     I   I   I
I   I    I              I   I       I              I     I   I
I      I   I    ITNC 2         I   I       I              I
I   I   I      A   I    I+----+        I   I       I
 I     I   I   I      K   I    II    I        I   I       I
        I     I   I   I      I   I    II 1  I--------X   I
I              I     I   I   I      I   I    II    I        I
I       I              I     I   I   I      I   I    II 2
I--------+---+-------+--------------+-----+---+---+------X   I
 II    I        I   I       I              I     I   I   I
I   I    II 3
I--------+---+-------+--------------+-----+---+---+--X---+---.
 II    I        I   I       I              I     I   I   I  I
I        II 5  I--------+---+--X----+--------------+-----.   I
I  I   I        II    I        I   I  I    I              I
   I   A  A   I        II 20
I--------+---+--+----+--------------X----.    I   K  K   K
 II    I        I   I  I    I                   I    I   I  I
A        II 7  I--------I---X  I    I                   I    I
I  I   I        II    I        I   I  I    I                   I
   I   I  I   I        II 10 I---.    I   I  I    I
     I    I   I  I   I        II    I   I    I   I  I    I
            A    I   I  I   I        II 23 I---.    I   I  I
K                   K    I   I  I   I        II    I        I
I  I    A                   I    I   I  I   I        I+----+
   I   I  K    I                   I    I   I  I   I        I
          I   I  A    I                   I    I   I  I   I
  I              I   I  I    I                   I    I   I  I
I        ITNC 3         I   I  I    I                   I    I
I  I   I        I+----+        I   I  I    I                   I
   I   I  I   I        II    I        I   I  I    I
     I    I   I  I   I        II 1  I--------.   I  I    I
            I    I   I  I   I        II    I            I  I
I                   I    I   I  I   I        II 2
I------------+--+----+-------------------+----+---X--.   I
 II    I            I  I    I                   I    I
I        II 3
I------------+--+----+------------------+----+----------X--------

.I    I            I  I    I                   I    II 5
I------------+--+----+-------------------X---.II    I
I  I    II 20 I------------+--X----.I    I            II 7
I------------.I    II 10 I---.                                 X
= connectionI    I   I                                 + = cross
overI 23 I---.                                 A = anode of a
4148 diodeI    I                                     K = cathode
of a 4148 diode+----+***** End of excerpt        Looking at the
diagram for the 3-node interconnect I notice that they are using
CTS and DTR (pins 5 & 20).  From the way they are
interconnected, I'd guess that these lines are used for a
activity indicator, much in the same way the Carrier Detect is
used on the air.        I do not know if the SLIP code does this
as well, so you may be at the mercy of probability: a node has
no way to check if the serial line is already in use before
transmitting.        Comments?-- =  =  =  =  =  =  =  =  =  =  =
 =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =Andrew C. Payne,
N8KEI        UUCP:  ...!cornell!batcomputer!payne
          INTERNET:  [e-mail]
packet-radio-relay  Thu Apr 12 09:34:01 1990Received: by
ucsd.edu; id AA05372    sendmail 5.61/UCSD-2.0-sun    Thu, 12 Apr 90
09:34:04 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA05365    sendmail 5.61/UCSD-2.0-sun via SMTP    Thu, 12 Apr 90
09:34:01 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA04128; Thu, 12 Apr 90 09:22:44 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 12 Apr 90 09:50:08 GMTFrom:
sgi![e-mail]  (Rob
Warnock)Organization: Silicon Graphics, Inc., Mountain View,
CASubject: Re: Channel access, node vs digiMessage-Id:
<[e-mail]>References:
<[e-mail]>,
<[e-mail]>,
<[e-mail].>Sender:
[e-mail]: [e-mail] article
<[e-mail].> [e-mail] (Joseph C.
Pistritto)writes:+---------------| Very few cellular systems out
their actually implement power cutbacks, (at| least two years
ago this was true on the east coast).  My cellphone had|
'diagnostic mode' where you could see all this, and you
practically had to| be on top of the cell site (100-200 meters)
before it would cut power.  This| was Bell Atlantic and Cell One
in Baltimore, DC, New York, and Phila.+---------------A guy I
met the other day works for PacTel Mobile Services here in the
BayArea (they're a reseller for Cellular One, which is owned by
PacBell -- yougo figure), and he would agree with you. He said
that the power cutback ismostly to protect the cell site's
receiver from overload, and he said thesame thing, "have to
almost be right under the cell site to cut back". EXCEPTthat
what they really hate is people who have full 3-watt (car-based)
mobilesand then go and add "high-gain" (5 dB?) antennas. He said
that if they didn'thave power cutback they'd get input overload
and cross-channel bleed all overthe place when one of those
puppies got close to the cell. And the customerwould blame the
cellular carrier...Also... In article
<[e-mail]> kevinr@tandem(Kevin J.
Rowett) writes:+---------------| At the risk of Flames, another
alternative is to have a master station,| and *poll*.  I know
this imposes the requirement of a master ( build| two if your
worried about single point of failure ), but masters have|
worked pretty well for the voice FM repeater crowd.  | |
Consider construction of a cell of users ( this scales nicely,
in either| direction) that have a master.  The master polls each
member of the | cell.  The master would also have links (
preferrably pt-pt ) going to| other cells.  This way, a master
could be moving traffic in and out| of a cell duplexed with
intra-cell traffic. +---------------This is *exactly* the
architecture we finally came around to for Xerox/XTEN.(Remember
them? Late 1970's? Proposed nation-wide digital common carrier
basedon a 10.6 GHz cellular system for local distribution? 256
Kb/s data rate.)After looking at lots of fancy protocols for the
local cell's multi-accesscontrol, things like "Reservation TDMA
with a slotted-Aloha reservationchannel", we decided to use
simple polling (with a variable-rate pollingschedule depending
on recent station traffic history). But this was madeeasy by the
fact that the outgoing broadcast channel from the cell was onall
the time, so polling info could be slipped into the output data
streamat almost no cost.Do the FCC regs permit a full-duplex
repeater to key-down "forever"?If so, there's also another
ancient method that could be used here, calledBusy-Tone Multiple
Access (BTMA), which is just a form of CSMA using asidetone or
sub-carrier back out from the repeater to indicate
incomingcarrier detect at the repeater. The win here is that you
can be streaminguseful data out from the "repeater" (o.k., a
full-duplex "bridge") whileyou are doing the CSMA
resolution.There's a *lot* of ancient packet-radio
access-protocol technology from thelate 60's and the 70's
(mostly from DARPA reports) that probably could beusefully
dusted off and applied [with updates and file-to-fit] to
modernamateur packet. The whole issue of the hidden-transmitter
problem was studiedto death back then. Sounds like it's time to
do some literature searches...-Rob-----Rob Warnock,
MS-9U/510        [e-mail]        [e-mail] Graphics,
Inc.        [phone]        Protocol Engines, Inc.2011 N. Shoreline
Blvd.Mountain View, CA  94039-7311That is,From
packet-radio-relay  Thu Apr 12 10:04:37 1990Received: by
ucsd.edu; id AA07037    sendmail 5.61/UCSD-2.0-sun    Thu, 12 Apr 90
10:04:40 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA07031    sendmail 5.61/UCSD-2.0-sun via SMTP    Thu, 12 Apr 90
10:04:37 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA06285; Thu, 12 Apr 90 09:54:59 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 12 Apr 90 07:09:12 GMTFrom:
ka9q.bellcore.com![e-mail]  (Phil Karn)Organization:
Secular Humanists for No-CodeSubject: Re: channel access, node
vs digiMessage-Id: <[e-mail]>References:
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail] ("Detlef J.
Schmidt") writes:>what you described is exactly how some
satellite uplinks for mobile>stations are working to avoid
collisions.Satellites are a special case because of the long
propagation delay. CSMA/CDfalls apart very rapidly as
propagation delay is increased, because everybody"sees" the
channel as it was a quarter of a second ago, and anything theydo
won't be seen by the other stations for another quarter of a
second.>And if the 'poll' is encapsulated inside of the
regular>frame this principle would not even avoid additional
overhead it will>avoid some empty ACK frames which would have to
be sent otherwise.You still have the problem of either spending
time polling stations whodon't have any traffic, or allowing
those who do have traffic to contendfor the channel (and
possibly colliding).>Some nice description about this could be
found in>>   IEEE journal on selected areas on communication>>of
the preveous years.Another good reference is Tanenbaum's
"Computer Networks".>A full-duplex channel does not avoid
collisions, it just reduces them>somewhat.True, but even
"reduces somewhat" can make all the difference in the
world.Ethernet is a good example -- it is very stable even under
pathologicaloverload because of the collision detection feature
combined with backoff.>Transposing APPLE's localtalk to PR could
help a little bit but doesn't>solve the problem in general.
Because no station can make shure to>get it's RTS frame through
and no CTS sending station can make shure>to stop ALL other
stations if some are hidden related to the CTS sending>station.
Only a master station up on a hill has a chance to be heard
by>all others.You are correct that collisions between RTS frames
can happen, but rememberthat these are (ideally) much smaller
than the data frames, so the damage(in terms of lost channel
capacity) isn't as great. It's like Ethernet:collisions can
occur only during a relatively small window compared to thetotal
data packet duration. But CTS packets have a nice property in
thissystem: if you can hear one, then chances are that the
sender of the CTScould hear you as well, and you should stay off
the channel for theappropriate interval. But if you *don't* hear
the CTS, then it's probablyokay for you to transmit since he
probably won't hear you anyway.  Thisscheme is essentially a
time-domain analog to the Busy Tone Multiple Access(BTMA)
scheme.  Of course, if you're going to do automatic power
control oneach packet, then you've got to be more careful.As for
compatibility with AX.25, I see no need to change the AX.25
frameformat. You'd do everything "on top" of the existing frame
structure.  Ofcourse, the link control procedures are different
so you'd want to establisha separate channel that would be
limited to those agreeing to use the newprocedures. But I'm
willing to write the code...PhilFrom packet-radio-relay  Thu Apr
12 13:33:51 1990Received: by ucsd.edu; id AA19405    sendmail
5.61/UCSD-2.0-sun    Thu, 12 Apr 90 13:33:53 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA19401    sendmail
5.61/UCSD-2.0-sun via SMTP    Thu, 12 Apr 90 13:33:51 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA20507; Thu, 12 Apr 90
13:31:53 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 12 Apr 90 19:36:00 GMTFrom:
umich!pmsmam![e-mail]  (Bill Meahan)Organization: Ford
Motor Co EFHD Ypsilanti Plant, Ypsilanti MISubject: Re: channel
access, node vs digiMessage-Id:
<[e-mail]>References:
<[e-mail]>,
<[e-mail]>Sender:
[e-mail]: [e-mail] 802.4
(broadband) makes use of a token pass arrangement that
allowsunits to 'come and go' onto the network.  Any
applicability of a token-passing scheme?-- Bill Meahan            |
UUCP: uunet!mailrus!umich!pmsmam!wwm                | snail: 128 Factory
St., Ypsilanti, MI 48197#include <disclaimer.std>    | voice: +1
313 484 9320/* witty */            |packet: wa8tzg @ wa8ooh.mi.usa.naFrom
packet-radio-relay  Thu Apr 12 14:06:55 1990Received: by
ucsd.edu; id AA21082    sendmail 5.61/UCSD-2.0-sun    Thu, 12 Apr 90
14:06:57 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA21078    sendmail 5.61/UCSD-2.0-sun via SMTP    Thu, 12 Apr 90
14:06:55 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA22267; Thu, 12 Apr 90 13:57:53 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 12 Apr 90 21:18:44 GMTFrom:
m2c!wpi![e-mail]  (John C Whitson
KB2GNC)Organization: Worcester Polytechnic Institute, Worcester,
Mass.Subject: WA8DED Proms and TNC1s in generalMessage-Id:
<[e-mail]>Sender: [e-mail]:
[e-mail]    Can anyone make a comment on how TNC-1s
are organized, in    particular the following information: (assume
Heath HD-4040)    1)    Which parts of the memory map are used by the
TNC,        What is the hard-reset start address, and where do        the
code sections fall within the ROM? There is a        C000 8K prom and
an E000 8K prom ... what parts of        the code fall where? Thanks
....    2)    Can anyone tell me where I can get full
documentation        on Ronald Raikes WA8DED proms, version 1.0? And
whether        they will work with the TNC1.HEX file off of
the        SIMTEL20.ARPA::PD3:<MISC.KA9Q-TCPIP>TNC1.HEX ????        More
thanks ....    3)    Can anyone tell me why the TNC1*.ASM files from
the        TNC_TNC1.ARC files on SIMTEL20.ARPA don't compile? I        tried
to assemble them using Motorola's Standard        Field Development
Assembler, AS9 for the 6809, and it        choked on two unknown
opcodes: TAB and CLI.    4)    And finally, can anyone tell me if
there is a pin-equivalent        EEPROM (Electrically-Erasable PROM)
for the 2764 EPROM?    What happens is is that my TNC doesn't work
with the new proms, not    with all the reccomendations I have
gotten. I am trying to think of    every possible problem. If you
have any ideas, drop me a line! Just    about all comments are
helpful. (except for the "get a new TNC!" type).    Also, does
anyone have a TNC with the standard Heath Proms, and could    send
me a HEX file of the image? Or is that a copyright violation? I
bought    my TNC used with the WA8DED proms.            THANKS FOR ALL YOUR
HELP!!! -- ----------  If at first you don't succeed,  so much
for skydiving ---------John Whitson:   Internet:
[e-mail]  Bitnet: [e-mail]73's from
KB2GNC/1                         UUCP:
uunet!wpi.wpi.edu!jwhitson----------  Anything with this tag on
it is purely my own opinion ---------From packet-radio-relay
Thu Apr 12 16:34:49 1990Received: by ucsd.edu; id
AA29454    sendmail 5.61/UCSD-2.0-sun    Thu, 12 Apr 90 16:34:51
-0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA29447    sendmail 5.61/UCSD-2.0-sun via SMTP    Thu, 12 Apr 90
16:34:49 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA02630; Thu, 12 Apr 90 16:27:07 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 12 Apr 90 22:12:23 GMTFrom:
haven!aplcen!stda.jhuapl.edu![e-mail]  (Marshall
Jose)Organization: JHU-Applied Physics LaboratorySubject:
Innovators need thick skin (was: CP/M sofware...)Message-Id:
<[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]>           [e-mail]
(Devon E Bowen) writes:> [A great deal of umbrageous comments
about the responses to the question>  about running NET under
CP/M, then]>>Anyone in this hobby that says something like this
in this day and age does>not deserve the shit this guy is
getting back for it.This sort of "treatment" is the norm, and
you may take it to be abusiveor derisive only if you choose to.
By this time, most Usenet-ers understandthat it is unrealistic
to demand a well-phrased, erudite, and mannerlyresponse to their
questions.  Nor do they have any reason to expect them.(I am
referring to the general case, and am not making a judgement
callon any of the responses related to this posting.)  Since
most respondentshave limited time and are able only to pass on a
terse message inanswer, one should not read any more into them
than what is there.When someone posts a question on the Usenet,
he/she expects informationin return.  If editorial opinions
happen to be included with the response,most individuals are
familiar enough with grammar and meaning to separatethem out and
discard them if appropriate.Finally, even if a poster does
receive derisive responses to a question,it is no reason to
abandon the pursuit of the original goal.  To do sowould be
prideful and counterproductive.  When such things happen to me,I
take what information I did get, and go back to work on my
projectwithout any further communication with my
antagonists.>This is no fun anymore.That's regrettable.  So find
what IS fun to you, and pursue it.Marshall Jose
[e-mail]  ||
...mimsy!aplcen!aplvax!mjjFrom packet-radio-relay  Fri Apr 13
18:37:29 1990Received: by ucsd.edu; id AA13540    sendmail
5.61/UCSD-2.0-sun    Fri, 13 Apr 90 18:39:42 -0700Received: from
relay.cdnnet.ca by ucsd.edu; id AA13452    sendmail
5.61/UCSD-2.0-sun via SMTP    Fri, 13 Apr 90 18:37:29 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
relay.CDNnet.CA (4.1/1.14)    id AA15848; Fri, 13 Apr 90 18:37:10
PDTDate: 13 Apr 90 17:37 -0800From: Doug Collinge VE7GNU
<djc@[e-mail]>To: [e-mail]-To:
[e-mail]-Id:
<26260966.samisen@[e-mail]>Subject: Famous DCD
mod.>X-Mailer: Mush 6.5.6 (PC R6.3 22-Sep-89)I read the paper
about the DCD mod.  I don't get it.  I understand the
motivation:  voice-radio squelch circuits are slowbecause they
are optimized to reliably detect signals and not falselyopen on
noise.  So practically anything is better.The state-machine DCD
waits until it sees data before asserting DCD.So even if there
is a carrier out there it won't assert DCD until itis properly
modulated with data.I can't see why a brute-stupid IF squelch
would not be superior tothat.  It would presumably falsely open
frequently for short periodson noise bursts, etc. but we don't
care about than unless we actuallyare waiting to transmit and we
should not have to wait very long.If it is a long one perhaps we
don't care to transmit into it anyhow.Now a radio I have takes 5
ms to get a carrier on the air, then another30 ms to get data
onto it, and let's add another 5 ms for the state-machine to
lock.  That means that the state machine would assert DCD40 ms
after I decided to transmit.  If we assume that the IF
squelchcould do the job in (let's be generous) 1 ms (why not?)
then thestate-machine leaves me vulnerable to collisions for 40
ms versus 6 ms.Even if YOUR radio has data on it right away the
squelch is still doingtwice as well as the
state-machine.Reverently submitted to the net (and NET) gods for
your comments,and with 73s -    Doug-- /\/\/\/\/\/Doug
Collinge,    first try: [e-mail]        then try:
samisen![e-mail]7GNU        VE7GNU@VE7GNU.#VIC.BC.CA.NA        V
ictoria, BC, CanadaFrom packet-radio-relay  Sat Apr 14 22:34:31
1990Received: by ucsd.edu; id AA21512    sendmail
5.61/UCSD-2.0-sun    Sat, 14 Apr 90 22:34:34 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA21507    sendmail
5.61/UCSD-2.0-sun via SMTP    Sat, 14 Apr 90 22:34:31 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA06886; Sat, 14 Apr 90
22:31:17 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 13 Apr 90 04:41:43 GMTFrom:
rochester!rit!ultb![e-mail]  (C.E.
Piggott)Organization: Information Systems and Computing @ RIT,
Rochester, New YorkSubject: Re: Daisy-chained RS-232
cableMessage-Id: <[e-mail]>References:
<[e-mail]>, <[e-mail]>Sender:
[e-mail]: [e-mail] TJP
octopus works quite well...I've seen several of them, andALL of
the sites on the North East Digital Association network
usethem...it contains room for eight TNC's, comes as a kit, and
is veryneatly laid out.NEDA, for those who may not know, is VERY
large, covering probablythree fourths of New York State, and
with arms reaching deeply intoNew England, and growing every
day.  I am REALLY curious about whatother sizeable net/rom
networks are out there, and if there are anysuch umbrella
organizations as NEDA or if it's just chaos.Chris-- Christopher
E. Piggott, N2JGW
[e-mail]
       [e-mail] [44.69.0.1]Rochester Institute of
Technology               N2JGW @ WB2WXQAmateur Radio Club K2GXT
                      [e-mail]
packet-radio-relay  Sat Apr 14 22:49:03 1990Received: by
ucsd.edu; id AA22372    sendmail 5.61/UCSD-2.0-sun    Sat, 14 Apr 90
22:49:05 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA22362    sendmail 5.61/UCSD-2.0-sun via SMTP    Sat, 14 Apr 90
22:49:03 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA07672; Sat, 14 Apr 90 22:41:53 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 15 Apr 90 01:14:28 GMTFrom:
pilchuck!ssc![e-mail]  (Tad Cook)Organization: very
littleSubject: DAYTON!Message-Id: <[e-mail]>Sender:
[e-mail]: [e-mail]    USENET
MEETING PLACE AT DAYTON HAMVENTIONIt's that time of year again!
Year after year we see postings onUSENET asking, "Where can
USENET radio afficinados get together foran old fashioned
eyeball at the Dayton Hamvention?"In 1990 we have a place of our
own.Come to the Digital Suite on Friday, April 27 at the
downtown StouffersHotel, room 425.  I have a large suite
reserved for packet, RTTY, USENETand Fidonet hams, so we can all
get together and see what each otherlooks like (scary!).This is
at Stouffers, where many of the DX clubs host the
infamoushospitality suites. . .where you can gab with famous DX
and contesthams until the wee hours.  And now we have our own
hospitality suite!Show up after 8pm, room 425, downtown
Stouffers in Dayton, April 27th.BYOB and non-smoking, please.See
you there!Tad CookSeattle, WAPacket: KT7H @
N7HFZ.WA.USA.NAPhone: 206/527-4089 MCI Mail: 3288544 Telex:
6503288544 MCI UW  USENET:...uw-beaver!sumax!amc-gw!ssc!tador,
[e-mail] packet-radio-relay  Sat Apr 14 22:50:30
1990Received: by ucsd.edu; id AA22462    sendmail
5.61/UCSD-2.0-sun    Sat, 14 Apr 90 22:50:34 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA22458    sendmail
5.61/UCSD-2.0-sun via SMTP    Sat, 14 Apr 90 22:50:30 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA07301; Sat, 14 Apr 90
22:36:34 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 13 Apr 90 13:11:28 GMTFrom:
[e-mail]  (Brian Kantor)Organization: The Avant-Garde of
the Now, Ltd.Subject: Re: Innovators need thick skin (was: CP/M
sofware...)Message-Id: <[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender:
[e-mail]: [e-mail] needs
some more comment:I don't believe it is possible to fit NET or
NOS as it currentlyfunctions into a slow machine with only 8
bits and 64k of address spacewithout incredible contortions such
as overlays and a major gutting of itsfunctionality.  Even if it
were possible, I don't see how this can inany way be called
innovation.If someone wants to TRY, I can only shake my head in
wonderment andoffer them encouragement, whilst counseling that
beating a dead horseoffers little reward.  ("Have fun storming
the castle!")I can see a place for a stripped-down version of
NOS (just rip out thekitchen sink and all the other ornamental
clap-trap) that would be astupid IP router that you could stick
in a Xerox 820 or other similarsmall-brain machine.  That would
make a nifty little mountaintop router.But the economics of the
marketplace still apply: just because I happento have three of
the damn Ferguson/Xerox Z80 CP/M machines sitting inmy garage
doesn't make it a good platform for developing ANYTHING forthe
ham radio network.  Too many replications of the finished
productwill be needed to form the network for the use of
ANYTHING that can'tbe bought or made cheaply to be a good
choice.This replicability is the reason that the IBM-PClone was
chosen for NOSdevelopment.  In today's computer marketplace
there isn't ANY OTHERchoice for ham equipment that can even come
close to being as availableas are the pieces for building
PClones.We are NOT talking (or yelling, as the case may be)
about theonesie-twosie home station;  what I'm talking about is
the dedicatedAMPRNet network nodes.  Either they're going to be
a custom-built devicethat offers overwhelming performance or
else it ought to be somethingwe can buy for really cheap in
whatever numbers are required.In summary (for this has gone on
for far too long), if you are justinterested in doing something
for yourself, far be it from me to try todissuade you (except to
opine that you are wasting your time), butthose of us with a
large scope of goals really think we have betterthings to
do.Love and kisses,    - BrianFrom packet-radio-relay  Sun Apr 15
01:05:11 1990Received: by ucsd.edu; id AA29190    sendmail
5.61/UCSD-2.0-sun    Sun, 15 Apr 90 01:05:15 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA29186    sendmail
5.61/UCSD-2.0-sun via SMTP    Sun, 15 Apr 90 01:05:11 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA16137; Sun, 15 Apr 90
00:51:57 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 15 Apr 90 06:52:05 GMTFrom:
shelby!neon![e-mail]  (Marc T.
Kaufman)Organization: Computer Science Department, Stanford
UniversitySubject: Re: Innovators need thick skin (was: CP/M
sofware...)Message-Id:
<[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender: [e-mail]:
[e-mail] article <[e-mail]>
[e-mail] (C.E. Piggott) writes:.In article
<[e-mail]> [e-mail] (Brian Kantor) writes:.>But the
economics of the marketplace still apply- ... stuff
deleted-Sure, you're right, but there should be some
developement for the low--end of things...after all, that's
where most people are SUPPOSED to be.Why, pray tell?  What is
going on in people's minds that make us think that$589 for a
crummy handheld radio is OK, but $200 for a computer is not?-A
sun 3/50 running sunview wouldn't make a very good file server
for-ten other machines; a file server wouldn't suit me very well
on my-desk.Maybe not.  But a Heathkit DX-100 wouldn't,
either.Marc Kaufman ([e-mail])From
packet-radio-relay  Sun Apr 15 02:18:36 1990Received: by
ucsd.edu; id AA07925    sendmail 5.61/UCSD-2.0-sun    Sun, 15 Apr 90
02:18:40 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA07909    sendmail 5.61/UCSD-2.0-sun via SMTP    Sun, 15 Apr 90
02:18:36 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA19826; Sun, 15 Apr 90 02:12:37 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 13 Apr 90 02:07:51 GMTFrom:
m2c!wpi![e-mail]  (John C Whitson
KB2GNC)Organization: Worcester Polytechnic Institute, Worcester,
Mass.Subject: Things are better!Message-Id:
<[e-mail]>Sender: [e-mail]:
[e-mail]    Things are better for the packet station.
As it turned    out, the programmer I had did not understand
Motorola    S-Records starting at address F800 in a PROM that
addresses    0000 - 1FFF. I guess from TNC_TNC1.ARC what was
expected    was that one downloads the S-Record format. Anyway,
I    burned the KISS image in TNC1.HEX and VOILA, it worked!!    One
other tiny request ... could someone give me some    IP addresses
in the Central Massachusetts area that I    can talk to on 2
meters? The closer to Worcester the    better ... and THANKS A
MILLION YOU ALL!!-- ----------  If at first you don't succeed,
so much for skydiving ---------John Whitson:   Internet:
[e-mail]  Bitnet: [e-mail]73's from
KB2GNC/1                         UUCP:
uunet!wpi.wpi.edu!jwhitson----------  Anything with this tag on
it is purely my own opinion ---------From packet-radio-relay
Sun Apr 15 02:59:39 1990Received: by ucsd.edu; id
AA12830    sendmail 5.61/UCSD-2.0-sun    Sun, 15 Apr 90 02:59:41
-0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA12819    sendmail 5.61/UCSD-2.0-sun via SMTP    Sun, 15 Apr 90
02:59:39 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA22181; Sun, 15 Apr 90 02:43:05 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 15 Apr 90 09:39:05 GMTFrom:
usc!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.ui
uc.edu![e-mail]: DAYTON!Message-Id:
<[e-mail]>Sender:
[e-mail]: [e-mail] is
getting closer.  Here are the suggested frequencies
wherebyrec.ham-radio and info-hams people can communicate.  Of
course therewill be lots of QRM especially at the Hara Arena on
2 meters.  Threefrequencies are suggested just in case someone
is stuck on one band.        223.600        445.600
145.600If you can get on 223.600, that should be the first place
to try.Second will be 445.600, and finally if you must and can
get through,go for 145.600.  The first of these frequencies was
suggested a whileback and I added the UHF suggestion then.  With
this posting I amadding the 2 meter suggestion for those stuck
on that band.        PL 118.8 (2B)If you can transmit a PL/CTCSS
tone, I suggest everyone use 118.8 hz (2B).That way those of us
who can do tone squelching can cut out some of theQRM.  This
will be especially useful for those who are stuck on 2
meters.Outside of the Hara Arena, simplex might not hit
everybody.  Perhaps youcan try all three bands depending on your
capabilities.  The fallback isto call on repeaters.  I suggest
the primary keyword to say and to listenfor be "usenet".  Others
such as "rec ham radio", "fidonet", and "info hams"might work,
but might also be a bit more misleading to others.  Due to
thelow number of repeaters for the significan ham crowd in
Dayton, suggestinga particular one would probably be
futile.--Phil Howard, KA9WGN-- | Individual CHOICE is
fundamental to a free society<[e-mail]> | no matter
what the particular issue is all about.From packet-radio-relay
Sun Apr 15 07:54:32 1990Received: by ucsd.edu; id
AA27575    sendmail 5.61/UCSD-2.0-sun    Sun, 15 Apr 90 07:54:34
-0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA27569    sendmail 5.61/UCSD-2.0-sun via SMTP    Sun, 15 Apr 90
07:54:32 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA06801; Sun, 15 Apr 90 07:46:07 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 13 Apr 90 14:25:17 GMTFrom:
bu.edu!mirror!ssi3b1!shyoon!tegra![e-mail]  (Johnathan
Vail)Organization: Tegra-Varityper, Inc., Billerica, MASubject:
Re: Cheap synchronous serial for packetMessage-Id:
<[e-mail]>References:
<[e-mail]>, <[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail] (Brian Kantor) writes:
[e-mail] (Andrew Payne) writes:   >Minor
brainstorm:   >        To get a synchronous serial port for
packet, why not retrofit a Zilog    >SCC to fit into an 8250
UART socket?   You can get a PC-compatable wirewrap breadboard
card for about $20, and   it already has complete address
decoding and bus buffering on it.  (JDR   Microdevices and
elsewhere.)   To add a pair of SCCs to this is really trivial.
One $6 monolithic oscillator, a little bit of TTL glue, some
RS232 level   shifters for the ports that need it, and you've
got it.  Real cheap.       - BrianI have designed just such a board
for a digital repeater project.  Ican send postscript or orcad
schematics and PAL equations to anyonewho asks.  This is
supposed to be an "Eagle" compatible board, atleast as far as
the driver for NET is concerned.  Email me at one ofthe address
below or FTP 'em from n1dxg.ampr.org if you are
local.73char*p="char*p=%c%s%c;main(){printf(p,34,p,34);}";main(){
printf(p,34,p,34);} _____|     | Johnathan Vail |
tegra![e-mail] |Tegra| [phone] |
N1DXG@448.625-/29.62(WorldNet) -----  [e-mail]
{...sun!sunne ..uunet}!tegra!n1dxgFrom packet-radio-relay  Sun
Apr 15 08:19:07 1990Received: by ucsd.edu; id AA28795    sendmail
5.61/UCSD-2.0-sun    Sun, 15 Apr 90 08:19:09 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA28788    sendmail
5.61/UCSD-2.0-sun via SMTP    Sun, 15 Apr 90 08:19:07 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA08589; Sun, 15 Apr 90
08:10:54 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 13 Apr 90 18:37:45 GMTFrom:
ndsuvm1!plains![e-mail]  (Roger
Egeberg)Organization: North Dakota State University,
FargoSubject: Re: Daisy-chained RS-232 cableMessage-Id:
<[e-mail]>References: <[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail] (Julian Macassey) writes:>>
    I would like to join the serial ports of several computers
together>so I can run KA9Qs SLIP between then. Sort of poor
man's Ethernet. I>know that a similar trick is used to join
several TNCs together for>multi NET-ROM use. The trick involves
resistors and diodes I believe.>>       Does anyone have details
on how to daisy-chain RS-232 ports?Back in 1981 or 1982 there
was an article in Byte magazine about hookingseveral
microcomputers together with serial ports.  A couple of
simplecircuits were shown, and the software necessary to
implement a simplenetwork was described.  It was called ULCNET
(Ultra Low Cost NETwork).I don't know what it would take to
convert the SLIP driver to use this,but thought it might at
least give you some ideas.The magazines are at home, but I'm
almost sure it was in an October issue,either from 1981 or 1982.
 I can find out for sure if you can't find it andare
interested.--Roger EgebergNDSU Extension Service
BITNET:    [e-mail] Dakota State University
     Internet:  [e-mail] packet-radio-relay
Sun Apr 15 08:18:34 1990Received: by ucsd.edu; id
AA28703    sendmail 5.61/UCSD-2.0-sun    Sun, 15 Apr 90 08:18:37
-0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA28687    sendmail 5.61/UCSD-2.0-sun via SMTP    Sun, 15 Apr 90
08:18:34 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA08152; Sun, 15 Apr 90 08:04:53 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 13 Apr 90 21:58:19 GMTFrom:
mcsun!hp4nl!nikhefk![e-mail]  (Henk Peek)Organization:
Nikhef-K, Amsterdam (the Netherlands).Subject: Re: Cheap
synchronous serial for packetMessage-Id:
<[e-mail]>References:
<[e-mail]>Sender:
[e-mail]: [e-mail]>Minor
brainstorm:>>        To get a synchronous serial port for
packet, why not retrofit a Zilog >SCC to fit into an 8250 UART
socket?>        Why bother?  Low cost:  serial cards are a dime
a dozen.  I'd guess >that with a little scrounging and some
not-too-difficult modification work, you>could end up with a
dual port (or maybe even a four port:  2 SCCs) card for >about
$30.  Plug in a cheap '3105 based 1200 baud modem and/or your
latest 56kb>toy, hack a driver for Phil's TCP/IP, and off you
go!>        Anyone care to comment on this?Get a copy of 8th
ARRL data  conference proceedings. Read the article ofa four
channel IBMPC board with 2 * 8530's. The output is opto isolated
currentloop. The output signals of each channel are RXD, TXD,
RTS, DCD.  There is alsoa cheap external TCM3105 based modem.
The all the schematics are included.When you want more channels,
you can use more boards on the same interrupt!I have printed
circuit boards of the IBMPC board (~$20), 1200 baud modem
(~$3)and also components. After a long beta test period, the
distribution in theNetherlands started a few weeks ago. I
haven't started with the delivery tothe sign up list from the
conference. The driver is already in NOS and in PE1CHL's version
of NET.Henk  PA0HZP     [e-mail] packet-radio-relay
Sun Apr 15 11:20:19 1990Received: by ucsd.edu; id
AA08607    sendmail 5.61/UCSD-2.0-sun    Sun, 15 Apr 90 11:20:21
-0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA08603    sendmail 5.61/UCSD-2.0-sun via SMTP    Sun, 15 Apr 90
11:20:19 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA21293; Sun, 15 Apr 90 11:04:32 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 14 Apr 90 16:44:43 GMTFrom:
rochester!rit!ultb![e-mail]  (C.E.
Piggott)Organization: Information Systems and Computing @ RIT,
Rochester, New YorkSubject: Re: Innovators need thick skin (was:
CP/M sofware...)Message-Id: <[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender: [e-mail]:
[e-mail] article <[e-mail]> [e-mail]
(Brian Kantor) writes:>... a>stupid IP router that you could
stick in a Xerox 820 or other similar>small-brain machine.  That
would make a nifty little mountaintop router.It's
coming...that's one of the 3 projects that are going on here,and
it's just waiting for a _DECENT_ Z-80
cross-assembler/simulator.>But the economics of the marketplace
still apply ... stuff deleted>We are NOT talking (or yelling, as
the case may be) about the>onesie-twosie home station;  what I'm
talking about is the dedicated>AMPRNet network nodes.Sure,
you're right, but there should be some developement for the
low-end of things...after all, that's where most people are
SUPPOSED to be.A sun 3/50 running sunview wouldn't make a very
good file server forten other machines; a file server wouldn't
suit me very well on mydesk.  Right now, we've got a bunch of
fully-functioning pieces ofthe network, and it's easy to say:
"The network is just being born;let's make as much of it
'complete' as we can _NOW_".So, then, let's clarify something
here that I've had on my mind forsome time: What's the
difference between a "network node" and an"end user" as it
relates to IP?  And just where are these "end users"?I've always
thought it would be neat to put an EPROM into a TNC2(cheap,
available, etc.) that would give you, say, FTP and TELNET,or
maybe even just TELNET, to let the unfortunate ax.25-only
usersget into things from a dumb terminal.  Keep in mind that
there isstill a LOT of resistance to TCP/IP in some parts of the
country,for a variety of reasons.  It behooves us to ease the
masses intothings when we know that we _will not_ survive on our
own.>Love and kisses,>    - Brian"Later, dooooooood"        Chris--
Christopher E. Piggott, N2JGW
[e-mail]
       [e-mail] [44.69.0.1]Rochester Institute of
Technology               N2JGW @ WB2WXQAmateur Radio Club K2GXT
                      [e-mail]
packet-radio-relay  Sun Apr 15 11:36:59 1990Received: by
ucsd.edu; id AA09454    sendmail 5.61/UCSD-2.0-sun    Sun, 15 Apr 90
11:37:02 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA09448    sendmail 5.61/UCSD-2.0-sun via SMTP    Sun, 15 Apr 90
11:36:59 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA22844; Sun, 15 Apr 90 11:25:57 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 14 Apr 90 05:17:42 GMTFrom:
hp-pcd!hpspkla![e-mail]  (Joseph L.
Dubner)Organization: Hewlett Packard Company, Spokane,
Wa.Subject: Re: WA8DED Proms and TNC1s in generalMessage-Id:
<[e-mail]>References:
<[e-mail]>Sender: [e-mail]:
[e-mail] Whitson ([e-mail]) asks
about " WA8DED Proms and TNC1sin general"John, you asked 4
questions and I have 1.5 answers for you :-)   I usedthe WA8DED
code in a TNC-1 but it was a long time ago.  However, the6809
will always remain a fond memory and I still faintly remember
someof its specifics.>     Can anyone make a comment on how
TNC-1s are organized, in>     particular the following
information: (assume Heath HD-4040)>     1)      Which parts of
the memory map are used by the TNC,>             What is the
hard-reset start address, and where do>             the code
sections fall within the ROM? There is a>             C000 8K
prom and an E000 8K prom ... what parts of>             the code
fall where? Thanks ....This is the "half an answer".  The 6909's
reset vector is at $FFFE -$FFFF.  Obviously, it'll lie at the
very top of the E000 8K EPROM.  Itpoints to the startup code and
other vectors (NMI, IRQ, etc.) are at$FFF2 through $FFFC.  Some
of them also point to code.  But I can't beless vague about how
the code is organized; sorry.>     3)      Can anyone tell me
why the TNC1*.ASM files from the>             TNC_TNC1.ARC files
on SIMTEL20.ARPA don't compile? I>             tried to assemble
them using Motorola's Standard>             Field Development
Assembler, AS9 for the 6809, and it>             choked on two
unknown opcodes: TAB and CLI.TAB and CLI are 6800 mnemonics and
don't exist in the 6809.  "Real" 6809code wouldn't use them, of
course.  But they're convenient and many 6809assemblers allow
their use and convert them to the applicable 6809instructions,
either in a "hard wired" fashion or by use of macros.  Youcan
get the same effect if you substitute ANDCC #$EF for CLI
(ClearInterrupt Mask) and TFR A,B for TAB (transfer A to B).
There are awhole slew of other 6800 mnemonics that have 6809
"equivalents" too.>     4)      And finally, can anyone tell me
if there is a pin-equivalent>             EEPROM
(Electrically-Erasable PROM) for the 2764 EPROM?The 2864 comes
to mind, but I've never actually tried one.When I had my TNC-1,
I had both the 4 standard TAPR and 2 WA8DED EPROMsinstalled in a
piggy-back fashion, with a toggle switch to select the CE(chip
enable) lines on the appropriate EPROMs.  Another set of
contactson the switch selected alternating banks of the NOVRAM.
This allowedeasy changing back and forth.  I don't take credit
for thisconfiguration; KB7G told me about it.Hope this helps.
Good luck with it.73, Joe,
K7JD-------------------------------------------------------------
-------------Joe Dubner     K7JD  |  Hewlett Packard Company  |
[e-mail]                     |  TAFC-34
M.S. 2I  |  [phone] (work)                     |
Spokane, WA  99220       |  [phone]
(home)-----------------------------------------------------------
---------------From packet-radio-relay  Sun Apr 15 12:03:27
1990Received: by ucsd.edu; id AA10948    sendmail
5.61/UCSD-2.0-sun    Sun, 15 Apr 90 12:03:29 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AB10943    sendmail
5.61/UCSD-2.0-sun via SMTP    Sun, 15 Apr 90 12:03:27 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA24805; Sun, 15 Apr 90
11:53:22 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 14 Apr 90 21:26:44 GMTFrom:
unmvax!ariel![e-mail]  (News supported
software)Organization: The third person on the left INC.Subject:
Re: Multiple Z80 processors and righteous hacks.Message-Id:
<[e-mail]>References: <[e-mail]>,
<[e-mail]>, <[e-mail]>Sender:
[e-mail]: [e-mail] :
noneFrom: [e-mail] (aNk1ez)Path:
carina.unm.edu!cs2591aqBack aways Techs mentioned multiple Z80
processors....I wanted to know, how can you keep 2 z80
processors from fightingon one S100 bus?  any ideas?About the
NewComm program, its a small little thing, (under 2 k still)
thata fairly well featured comm program for its size.  The only
problem is thatyou have to hack the code to christs grave and
back to get it to work onyour machine because I wasnt think
portability when I wrote it, just,I Need a com program.AghDent /
[e-mail] From packet-radio-relay  Sun Apr 15
12:14:35 1990Received: by ucsd.edu; id AA11511    sendmail
5.61/UCSD-2.0-sun    Sun, 15 Apr 90 12:14:38 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA11507    sendmail
5.61/UCSD-2.0-sun via SMTP    Sun, 15 Apr 90 12:14:35 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA25342; Sun, 15 Apr 90
12:00:28 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 15 Apr 90 12:16:39 GMTFrom:
ogicse!emory!rsiatl!kd4nc!ke4zv![e-mail]  (Gary
Coffman)Organization: noneSubject: Re: Innovators need thick
skin (was: CP/M sofware...)Message-Id:
<[e-mail]>References: <[e-mail]>,
<[e-mail]>, <[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail] (C.E. Piggott)
writes:>[stuff deleted]>>So, then, let's clarify something here
that I've had on my mind for>some time: What's the difference
between a "network node" and an>"end user" as it relates to IP?
And just where are these "end users"?A network node only needs
to route packets so you can leave out allthe application
protocols like smtp, telnet, ftp, etc. All you musthave is the
link protocol and ip protocol handlers in a net node. Auser
station on the other hand would be pretty useless without
theapplication protocols aboard. In practice we don't bother to
stripout the application protocols in our switches since we
don't needthe extra free memory and it makes onsite debugging
easier. However,we do make sure that the servers for the mbox
and such are left disabled. It is very frustrating to find the
switch down becausesome "poor dumb users " have connected to the
mbox and left connectionshanging to the point of exceeding max
session. The mbox is no substitutefor a real lan bbs.Where are
the end users? At both ends of a session of course! -)We have
Unix boxes in people's homes, dos boxes in people's homes, anda
few crazys with laptops in their cars.>>I've always thought it
would be neat to put an EPROM into a TNC2>(cheap, available,
etc.) that would give you, say, FTP and TELNET,>or maybe even
just TELNET, to let the unfortunate ax.25-only users>get into
things from a dumb terminal.  Keep in mind that there is>still a
LOT of resistance to TCP/IP in some parts of the country,>for a
variety of reasons.  It behooves us to ease the masses
into>things when we know that we _will not_ survive on our
own.>THIS IS A VERY BAD IDEA!!! First, one of the most valuable
things about tcp/ip is that part ofthe network lives INSIDE your
computer. This makes possible end-to-endintegrity of file
transfers. If you attempt to put the protocol inan external box,
there is no way to guarantee that the data arrivesintact on the
destination user's disk.Second, the economics of dumb terminals
is absurd. Like in the discussionon porting the ka9q code back
to cpm, PCs ARE CHEAPER THAN TERMINALS!>73 Gary KE4ZVFrom
packet-radio-relay  Sun Apr 15 19:03:09 1990Received: by
ucsd.edu; id AA16668    sendmail 5.61/UCSD-2.0-sun    Sun, 15 Apr 90
19:03:12 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA16664    sendmail 5.61/UCSD-2.0-sun via SMTP    Sun, 15 Apr 90
19:03:09 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA17074; Sun, 15 Apr 90 18:53:28 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 16 Apr 90 01:16:48 GMTFrom:
dsl.pitt.edu!pitt!speedy.cs.pitt.edu![e-mail]  (Ken
Mitchum)Organization: Univ. of Pittsburgh Computer
ScienceSubject: Re: Cheap synchronous serial for
packetMessage-Id: <[e-mail]>References:
<[e-mail]>, <[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail] (Brian Kantor)
writes:>[e-mail] (Andrew Payne)
writes:>>Minor brainstorm:>>        To get a synchronous serial
port for packet, why not retrofit a Zilog >>SCC to fit into an
8250 UART socket?>>You can get a PC-compatable wirewrap
breadboard card for about $20, and>it already has complete
address decoding and bus buffering on it.  (JDR>Microdevices and
elsewhere.)I got a blank PC board for the PC-100 for $25 from
Paccomm, and the lasttime I talked to the people at Paccomm,
they had LOTS of boards aroundunsold. The PC-100 is very similar
to the DRSI, and has space for onboardmodems. This is more
cost-effective than wire-wrapping something. Ken Mitchum KY3B
[e-mail] packet-radio-relay  Sun Apr 15 22:48:03
1990Received: by ucsd.edu; id AA29486    sendmail
5.61/UCSD-2.0-sun    Sun, 15 Apr 90 22:48:11 -0700Received: from
elroy.jpl.nasa.gov by ucsd.edu; id AA29473    sendmail
5.61/UCSD-2.0-sun via SMTP    Sun, 15 Apr 90 22:48:03 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
elroy.jpl.nasa.gov (4.1/SMI-4.0+DXR)    id AA08306; Sun, 15 Apr 90
22:48:02 PDTReceived: by moc.jpl.nasa.gov (5.57/2.1)    id AA25610;
Sun, 15 Apr 90 22:46:39 PDTReceived: by miranda.uucp
(4.0/SMI-3.0DEV3)    id AA28278; Sun, 15 Apr 90 22:33:26 MSTDate:
Sun, 15 Apr 90 22:33:26 MSTFrom:
[e-mail] (Marc Sarrel)Message-Id:
<[e-mail]>To:
[e-mail]: RF questionPardon me for posting a
question that is only tangentially related topacket radio, but I
don't have access to Internet and can only get alimited number
of mailing lists.Here is my problem.  I have an HT, a power
supply and a TNC.  Theproblem only involves the first two.  I'm
getting RF interferenceproblems when I transmit on high power (6
watts) off the power supply.In fact, the HT just turns itself
off.  I have to cycle to power onthe power supply to restart.  I
have already added a counterpoise cutto 1/4 wave for 146 MHz to
the chassis of the power supply and I'vealso wrapped the DC
supply line from the power supply to the HT tenturns around a
pair of RF chokes that I got at radio shack.  I live ina third
floor apartment, so a real "earth ground" in not feasible.
Infact, it seems as though the problem has gotten worse since
Ive triedthese things.Am I in danger of doing harm to my radio?
What further steps can Itake to eliminate this
problem?advTHANKSance,MarcN7OLIMarc A.
Sarrel            [e-mail]    |   "Oh,
_lightweight_
Alpaca..."..!sun!sunburn!miranda!sarrel        |        -Blanche DuBoisFrom
packet-radio-relay  Mon Apr 16 02:18:27 1990Received: by
ucsd.edu; id AA14513    sendmail 5.61/UCSD-2.0-sun    Mon, 16 Apr 90
02:18:33 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA14498    sendmail 5.61/UCSD-2.0-sun via SMTP    Mon, 16 Apr 90
02:18:27 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA07905; Mon, 16 Apr 90 02:09:18 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 16 Apr 90 04:46:47 GMTFrom:
ka9q.bellcore.com![e-mail]  (Phil Karn)Organization:
Secular Humanists for No-CodeSubject: Re: Innovators need thick
skin (was: CP/M sofware...)Message-Id:
<[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender: [e-mail]:
[e-mail] article <[e-mail]>
[e-mail] (C.E. Piggott) writes:>So, then, let's
clarify something here that I've had on my mind for>some time:
What's the difference between a "network node" and an>"end user"
as it relates to IP?  And just where are these "end users"?The
distinction is more clear in the "real" Internet, where you
usually haverouters ("network nodes") that switch IP packets
between networks, and hosts("end users") that generate and
consume IP packets.  In Internet parlance,my host code has
"imbedded gateway functionality", so a single machine canhandle
both functions. (BSD UNIX-based systems also have imbedded
gatewayfunctionality, even though most aren't used that way.)
Anyway, it's up toyou to decide whether you want to dedicate a
set of machines to act asrouters or if you prefer to have the
user nodes share this function.>I've always thought it would be
neat to put an EPROM into a TNC2>(cheap, available, etc.) that
would give you, say, FTP and TELNET,>or maybe even just TELNET,
to let the unfortunate ax.25-only users>get into things from a
dumb terminal.Telnet can already be used from a plain AX25 TNC
by means of the SM0RGV"mailbox" module in NOS. One of the
commands that Anders added a few monthsago is a "gateway"
feature that allows you to connect to the mailbox usingstraight
AX.25 and then initiate a TELNET connection to an Internet
host.But "FTP on a TNC2" doesn't make much sense; how do you use
a file transferprotocol on a system that doesn't have a file
system?> Keep in mind that there is>still a LOT of resistance to
TCP/IP in some parts of the country,>for a variety of reasons.
It behooves us to ease the masses into>things when we know that
we _will not_ survive on our own.The real issue is a basic
difference in network philosophies. The TNC isfundamentally
designed to connect a "dumb terminal" to a packet network soit
can talk to other dumb terminals; it is patterned after the X.25
"PAD" ofthe middle 1970s. (Even though most TNCs are probably
now connected to hostcomputers, the "dumb terminal model" still
applies, unless the TNC isrunning in KISS mode.)In contrast,
TCP/IP is for COMPUTER (not terminal) networking.  That is,it's
designed to support computers instead of terminals at the end
nodes.So TCP/IP has little to offer to the ham who doesn't have
a personalcomputer in his shack.  But as more and more hams get
computers, they'lldiscover the advantages in networking them.
That's when they'll getinterested in TCP/IP.PhilFrom
packet-radio-relay  Mon Apr 16 06:03:23 1990Received: by
ucsd.edu; id AA28925    sendmail 5.61/UCSD-2.0-sun    Mon, 16 Apr 90
06:03:25 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA28920    sendmail 5.61/UCSD-2.0-sun via SMTP    Mon, 16 Apr 90
06:03:23 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA17414; Mon, 16 Apr 90 05:51:38 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 16 Apr 90 12:45:25 GMTFrom:
[e-mail]  (The Crouton Man)Organization:
University of Colorado, boulderSubject: Re: Multiple Z80
processors and righteous hacks.Message-Id:
<[e-mail]>References: <[e-mail]>,
<[e-mail]>, <[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail] (aNk1ez)
writes:>Keywords : none>From: [e-mail]
(aNk1ez)>Path: carina.unm.edu!cs2591aq>>Back aways Techs
mentioned multiple Z80 processors....>I wanted to know, how can
you keep 2 z80 processors from fighting>on one S100 bus?  any
ideas?>>Dent / [e-mail]> funny, but Norstar did
this 10 years ago (or more) with there Horizon, not with 2
Z80's, but with 4... i am not sure how they got around it, but
as i recall, it was thru the wonder of timesharingthe io... it
has 4 seperate CPU baords in it, all sharing the io board,each
with 64k of memory for that processor... you might want to look
into how they handled it... Later.-=- The Crouton Man -=-
[e-mail] -=-From packet-radio-relay  Mon Apr 16
11:03:17 1990Received: by ucsd.edu; id AA19870    sendmail
5.61/UCSD-2.0-sun    Mon, 16 Apr 90 11:03:20 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA19865    sendmail
5.61/UCSD-2.0-sun via SMTP    Mon, 16 Apr 90 11:03:17 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA06238; Mon, 16 Apr 90
10:55:40 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 16 Apr 90 17:25:19 GMTFrom:
simasd!pnet07![e-mail]  (Don Maslin)Organization:
People-Net [pnet07], San Diego, CASubject: Re: Multiple Z80
processors and righteous hacks.Message-Id:
<[e-mail]>Sender: [e-mail]:
[e-mail] the easiest way is with a master
and multiple slave processorsoperating under TurboDOS in an
IEEE-696 environment. UUCP: {nosc ucsd crash
ncr-sd}!pnet07!donmARPA: simasd!pnet07![e-mail]:
[e-mail] packet-radio-relay  Mon Apr 16 12:19:09
1990Received: by ucsd.edu; id AA26706    sendmail
5.61/UCSD-2.0-sun    Mon, 16 Apr 90 12:19:15 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA26687    sendmail
5.61/UCSD-2.0-sun via SMTP    Mon, 16 Apr 90 12:19:09 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA10685; Mon, 16 Apr 90
12:04:46 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 16 Apr 90 18:58:05 GMTFrom:
[e-mail]  (Brian Kantor)Organization: The Avant-Garde of
the Now, Ltd.Subject: Re: RF questionMessage-Id:
<[e-mail]>References:
<[e-mail]>Sender:
[e-mail]: [e-mail]'s not
clear from your description whether the power supply isshutting
down or whether the HT is dying.  (Remember that the pilotlight
in most supplies just tells you that the power switch is on,
notwhether you have any output from the supply or not.)If it's
the supply that's shutting down, you probably have RF
gettinginto the regulator circuit and you need to add a bunch of
bypasscapacitors to the AC input and DC output connections.
.001 uF 1 KVdisk ceramic capacitors are a good way to start, and
they're quitecheap.  (The value isn't critical; anything from
.001 to .01 ought towork just fine.)Put them from each side of
the input and output to chassis ground in thesupply; that means
you'll need four of them (three if the negativesupply output is
grounded already).  Or get someone to do it for you ifyou doubt
your technical skill.If it's the HT that's dying, you need to
use some test equipment and seeif the power supply is holding
the proper voltage when you key up.Again, bypassing is probably
the answer.    - BrianP.S.  I mailed you a response to this, but we
couldn't find a route toyour posting site.  Apparently it's not
in the uucp maps, which yoursystem administrator should
remedy.From packet-radio-relay  Mon Apr 16 12:23:46
1990Received: by ucsd.edu; id AA27062    sendmail
5.61/UCSD-2.0-sun    Mon, 16 Apr 90 12:23:57 -0700Received: from
ibm.com by ucsd.edu; id AA27041    sendmail 5.61/UCSD-2.0-sun via
SMTP    Mon, 16 Apr 90 12:23:46 -0700 for /usr/lib/sendmail -oc
-odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: from POKVMCP2 by IBM.COM (IBM VM SMTP
R1.2.1MX) with BSMTP id 3289; Mon, 16 Apr 90 12:24:54 PDTDate:
Mon, 16 Apr 90 15:22:55 EDTFrom: "Robert P. Bellini PE  (N2IGU)
[e-mail]" <[e-mail]>To:
[e-mail]-Id:
<[e-mail]>Subject: RF ProblemsCheck the
current rating of the power supply. It sounds like you may
bedrawing more that it has and causing it to shut down!Bob
Bellini  N2IGU  [e-mail]     [e-mail]
packet-radio-relay  Mon Apr 16 12:24:54 1990Received: by
ucsd.edu; id AA27148    sendmail 5.61/UCSD-2.0-sun    Mon, 16 Apr 90
12:24:57 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA27141    sendmail 5.61/UCSD-2.0-sun via SMTP    Mon, 16 Apr 90
12:24:54 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA11464; Mon, 16 Apr 90 12:16:32 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 16 Apr 90 17:08:28 GMTFrom:
[e-mail]  (The Bounty Hunter)Organization: Apple
Computer Inc, Cupertino, CASubject: Re: Innovators need thick
skin (was: CP/M sofware...)Message-Id:
<[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail] (Marshall Jose)
writes:> By this time, most Usenet-ers understand>that it is
unrealistic to demand a well-phrased, erudite, and
mannerly>response to their questions.  Nor do they have any
reason to expect them.Say what?? Unless Usenet participants want
to define themselves as alower life form, I see no reason why I
shouldn't expect the same sort ofcivilized conversation here as
I would in person. It shows a lack ofrespect for one's own ideas
as well as for the reader when someone doesn't take the time to
communicate a message clearly. And I'd think it takes extra
effort to include unmannerly remarks, so it should beeasier to
be civil. :-) > Since most respondents>have limited time and are
able only to pass on a terse message in>answer, one should not
read any more into them than what is there.Does this imply that
the hundreds of people who *read* the postingdon't have limited
time? Why should they have to spend extra timedecoding the
meaning of the posting because the writer didn't takean extra
couple of minutes to be clear?I know, for instance, that Phil
Karn averages over a hundred incomingemail messages a day; then
add all the newsgroup messages he reads.Yet I've seen him spend
ten minutes on a reply that someone else mightdash off in one,
just to make sure that he's expressing himself clearlyand
accurately. Phil is just one example; I'm sure that many other
people on the netare similarly conscientious. They're the ones
whose opinions I givecredence to. I've had to give up reading
postings by some people whomight have some decent ideas simply
because I couldn't find the goodidea buried in all the sloppy
writing.Anyway....followups should probably go elsewhere; pick a
suitablenewsgroup and go for it.Patty--
*****************************************************************
************ Patty Winter N6BIS                        INTERNET:
[e-mail]: [44.4.0.44]                     UUCP:
{decwrl,nsc,sun}!apple!winter************************************
***************************************** From
packet-radio-relay  Mon Apr 16 14:47:09 1990Received: by
ucsd.edu; id AA09172    sendmail 5.61/UCSD-2.0-sun    Mon, 16 Apr 90
14:47:23 -0700Received: from elroy.jpl.nasa.gov by ucsd.edu; id
AA09157    sendmail 5.6 1/UCSD-2.0-sun via SMTP

Mon, 16 Apr 90 14:47:09 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by elroy.jpl.nasa.gov
(4.1/SMI-4.0+DXR)    id AA10757; Mon, 16 Apr 90 14:47:04
PDTReceived: by moc.jpl.nasa.gov (5.57/2.1)    id AA18446; Mon, 16
Apr 90 14:17:23 PDTReceived: by miranda.uucp
(4.0/SMI-3.0DEV3)    id AA28965; Mon, 16 Apr 90 13:49:55 MSTDate:
Mon, 16 Apr 90 13:49:55 MSTFrom:
[e-mail] (Marc Sarrel)Message-Id:
<[e-mail]>To:
mocvax!elroy!IBM.COM![e-mail]:
[e-mail]-Reply-To: "Robert P. Bellini PE  (N2IGU)
[e-mail]"'s message of Mon, 16 Apr 90 15:22:55 EDT
<[e-mail]>Subject: RF ProblemsThanks, but
the power supply is rated at 5 amps continuous and 7
ampsintermittent.  The HT draws 1.9 amps on high power and the
TNC draws0.9 amps.  Thanks anyway...marcN7OLIMarc A.
Sarrel            [e-mail]    |   "Oh,
_lightweight_
Alpaca..."..!sun!sunburn!miranda!sarrel        |        -Blanche DuBoisFrom
packet-radio-relay  Mon Apr 16 15:35:21 1990Received: by
ucsd.edu; id AA13350    sendmail 5.61/UCSD-2.0-sun    Mon, 16 Apr 90
15:35:26 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA13330    sendmail 5.61/UCSD-2.0-sun via SMTP    Mon, 16 Apr 90
15:35:21 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA24058; Mon, 16 Apr 90 15:31:06 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 16 Apr 90 16:25:18 GMTFrom:
cs.utexas.edu!execu!sequoia!rpp386![e-mail]
 (Aubrey McIntosh)Organization: vima, Austin TXSubject: Re:
Daisy-chained RS-232 cableMessage-Id:
<[e-mail]>References: <[e-mail]>,
<[e-mail]>Sender: [e-mail]:
[e-mail] article <[e-mail]>
[e-mail] (Roger Egeberg) writes:>>In article
<[e-mail]> [e-mail] (Julian Macassey) writes:>>>>
      I would like to join the serial ports of several computers
together>>so I can run KA9Qs SLIP between then. Sort of poor
man's Ethernet. I>>know that a similar trick is used to join
several TNCs together for>>multi NET-ROM use. The trick involves
resistors and diodes I believe.I wanted to make some sort of
plug in device for the back of an XT, justas a first hardware
project.  This evolved to aspirations of making apoor man's
ethernet, thence to using, I think, 422 cards.  I am leadto
believe that this is the device used for Appletalk, and that it
ismultidrop.  I've put this over in the blue sky file for a
while now.Any comments about 422?-- Aubrey McIntosh      "Find
hungry samurai." -- The Old Man        1502 Devon Circle
comp.os.minix, comp.lang.modula2         Austin, TX 78723
1-(512)-452-1540  (v)From packet-radio-relay  Mon Apr 16
22:22:08 1990Received: by ucsd.edu; id AA10766    sendmail
5.61/UCSD-2.0-sun    Mon, 16 Apr 90 22:22:13 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA10756    sendmail
5.61/UCSD-2.0-sun via SMTP    Mon, 16 Apr 90 22:22:08 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA12065; Mon, 16 Apr 90
20:11:41 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 16 Apr 90 13:38:22 GMTFrom:
philmtl!philabs!briar.philips.com![e-mail]  (Robert
Casey)Subject: Re: RF questionMessage-Id:
<[e-mail]>References:
<[e-mail]>Sender:
[e-mail]: [e-mail] in the
power supply:  Have you tried installing capacitors across
thepower supply inputs, outputs, and to the metal case of the
supply?  Use 0.01uf@ 1.4KV or higher on the powerline end of
things.  0.01 @ 50v should be OK onthe 12v output.  If that
doesn't do it, try putting caps (0.01 @ 1kv) acrossthe rectifier
diodes (if it's a switching power supply) on the 'hot'
side.Nothing critical about the value 0.01uf, any disk ceramic
near that sizeshould be fine.hope this helps  WA2ISEFrom
packet-radio-relay  Mon Apr 16 22:22:02 1990Received: by
ucsd.edu; id AA10750    sendmail 5.61/UCSD-2.0-sun    Mon, 16 Apr 90
22:22:06 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA10742    sendmail 5.61/UCSD-2.0-sun via SMTP    Mon, 16 Apr 90
22:22:02 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA11982; Mon, 16 Apr 90 20:09:34 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 16 Apr 90 20:42:41 GMTFrom:
hpcc01!col![e-mail]  (Bdale Garbee)Organization: HP
Colorado Springs DivisionSubject: Re: Channel access, node vs
digiMessage-Id: <[e-mail]>References:
<[e-mail]>Sender:
[e-mail]: [e-mail]>As for
compatibility with AX.25, I see no need to change the AX.25
frame>format. You'd do everything "on top" of the existing frame
structure.  Of>course, the link control procedures are different
so you'd want to establish>a separate channel that would be
limited to those agreeing to use the new>procedures. But I'm
willing to write the code...Hmmm.  This makes me wonder if
RTS/CTS frames are *really* going to be thatmuch smaller than
data frames in an interactive environment.  For filetransfer,
yes... but... comments?BdaleFrom packet-radio-relay  Mon Apr 16
23:18:43 1990Received: by ucsd.edu; id AA14988    sendmail
5.61/UCSD-2.0-sun    Mon, 16 Apr 90 23:18:45 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA14982    sendmail
5.61/UCSD-2.0-sun via SMTP    Mon, 16 Apr 90 23:18:43 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA22411; Mon, 16 Apr 90
23:06:29 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 16 Apr 90 22:30:45 GMTFrom:
att!cbnewsh![e-mail]
(j.gordon.beattie)Organization: AT&T Bell LaboratoriesSubject:
TCF Talk-around for PacketMessage-Id:
<[e-mail]>Sender: [e-mail]:
[e-mail] Radio Amateur Telecommunications
Society will provide a talk-aroundstation for amateurs attending
this weekend's TCF (old Trenton ComputerFest)at Mercer County
College on a frequency of 144.46 SIMPLEX.  There will bea 250W
station with a good antenna listening most of the day for folks
who need to have a friend called, or who want to know where and
when the packetsessions will be held, etc.  This station will
also provide talk-in on an"as available" basis.  Feel free to
use the frequency for chit-chat withyour fellow packeteers
anytime through the day.If you have any questions contact:
                   J. Gordon Beattie, Jr.
  201-615-4168 (O)                          201-387=8896 (H)
                     [e-mail]
 [e-mail]
[e-mail].S.  Don't forget to come by the RATS table
in the lobby of the      building where the packet sessions are
to be held.  Software      distribution and demonstrations will
be available all day.      RATS is also organizing a "RATS
Packet Supper" for early      Saturday evening (4:30 PM) after
the sessions are over.           See you there!From
packet-radio-relay  Mon Apr 16 23:19:40 1990Received: by
ucsd.edu; id AA15042    sendmail 5.61/UCSD-2.0-sun    Mon, 16 Apr 90
23:19:43 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA15036    sendmail 5.61/UCSD-2.0-sun via SMTP    Mon, 16 Apr 90
23:19:40 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA22386; Mon, 16 Apr 90 23:06:08 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 16 Apr 90 22:18:15 GMTFrom:
att!cbnewsh![e-mail]
(j.gordon.beattie)Organization: AT&T Bell LaboratoriesSubject:
Re: Channel access, node vs digiMessage-Id:
<[e-mail]>References:
<[e-mail]>,
<[e-mail]>, <[e-mail]>Sender:
[e-mail]: [e-mail] has
been some discussion about BTMA (Busy-Tone Multi-Access)packet
systems here on the net and so I thought I'd throw my two-cents
in!The Radio Amateur Telecommunications Society has been using
with this typeof access for its backbone using a single 440 MHz
voice-grade machine withgood results.  The purpose of this
system is to provide connectivity for some of the ROSE X.25
Switches in the OSI-type packet network operatedby RATS here in
the NY/NJ/CT/PA/DE region.We have installed a receiver and
transmitter at a high siteaccessable from anywhere within about
100 miles (minimum) of New York City.The controller is a TNC-2
that runs the digital regenerator software.The controller
"listens" for packets and sends out a busy tone (HDLC Flags) on
the output to inhibit other stations.  As valid frames are
received, they start out the trasnmitter FIFO-style with a one
frame delay.  The code will be enhanced in the future to include
general polling and "recent/most active user" polling algorithms
as experience dictates.  The Xanthus Regenerator Code can be
purchased for a small fee from:              PAC-COMM Packet
Radio Systems               +1.813.874.2980                Ask
for Tom Moulton.If you would like more information on this, or
other RATS Open SystemsEnvironment (ROSE) networking tools
(packet switches, servers, BBSs)contact:              Gordon
Beattie, n2dsy              +1.201.651.4168 (Office)
 +1.201.387.8896 (Home)              [e-mail]
     [e-mail]
[e-mail] packet-radio-relay  Tue Apr 17 01:05:29
1990Received: by ucsd.edu; id AA20650    sendmail
5.61/UCSD-2.0-sun    Tue, 17 Apr 90 01:05:32 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA20645    sendmail
5.61/UCSD-2.0-sun via SMTP    Tue, 17 Apr 90 01:05:29 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA28973; Tue, 17 Apr 90
01:03:13 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 17 Apr 90 07:38:55 GMTFrom:
ka9q.bellcore.com![e-mail]  (Phil Karn)Organization:
Secular Humanists for No-CodeSubject: Re: Channel access, node
vs digiMessage-Id: <[e-mail]>References:
<[e-mail]>,
<[e-mail]>Sender: [e-mail]:
[e-mail] article <[e-mail]>
[e-mail] (Bdale Garbee) writes:>Hmmm.  This makes me
wonder if RTS/CTS frames are *really* going to be that>much
smaller than data frames in an interactive environment.  For
file>transfer, yes... but... comments?It depends, of course, on
how large the data frames are. Small interactivepackets are
always less efficient to handle in a contention environment
thanlarge packets, but then the large packets usually account
for the bulk ofthe load (and the overload) on such networks.I
think my scheme could support an optional "unguaranteed" data
frame.  Itwould be sent without the RTS/CTS handshake, but the
transmitter would stillbe obliged to defer to RTS and CTS
packets it hears from other stations. Ifyou use this feature to
send character-at-a-time TELNET packets, then anylost data will
automatically be retransmitted along with subsequent datawithout
too much extra overhead since the headers dominate anyway. At
somepoint, of course, the link could switch back to handshake
mode if thingsjust aren't getting through. The choice could be
made by the link driveritself (by looking at the size of the
link transmit queue in bytes) orcontrolled by TCP/IP by setting
the "reliability" type-of-service bit aftersome number of
unsuccessful retries.Of course, one could always ban
character-at-a-time TELNET...I've also been analyzing the
power-controlled variant of my scheme. Itshould work as long as
CTS packets are always sent at full power, which mustbe the same
for all stations. This is necessary to ensure that
everyonewithin radio range of a given receiver is made aware
that it is about toreceive something. RTS packets could be sent
at a power level appropriatefor the intended receiver, or at
full power if this level is unknown.Whenever you overhear a RTS
or CTS frame not addressed to you, you set atemporary limit on
your own transmitter power. The level and duration of thelimit
is chosen according to the sender of the RTS or CTS frame such
thatyou can't clobber that station's receiver when it listens
for a response(either a CTS or data frame).  If the amount of
power needed to reach thesender of the RTS or CTS frame is
unknown, then the power limit is set atzero.  You are free to
send any traffic you may have during anotherstation's transfer
as long as the power required doesn't exceed whateverlimit is in
effect. (Note that this may inhibit you from sending CTS
frames,since they are always sent at full power.)The power limit
is lifted after allowing enough time for an RTS frame to
beanswered with a CTS, or for a CTS to be answered with the
specified amountof data.  Note that hearing a data frame does
NOT inhibit your transmitterin any way -- the preceeding CTS
frame should have already set whateverpower limitation is
appropriate to keep you from clobbering its intendedrecepient.
This is how you can solve the "exposed terminal"
problemfrequently encountered by hilltop digipeaters.The more I
think about this scheme, the more I think it may actually
work.PhilFrom packet-radio-relay  Tue Apr 17 01:05:22
1990Received: by ucsd.edu; id AA20641    sendmail
5.61/UCSD-2.0-sun    Tue, 17 Apr 90 01:05:26 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA20637    sendmail
5.61/UCSD-2.0-sun via SMTP    Tue, 17 Apr 90 01:05:22 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA28959; Tue, 17 Apr 90
01:02:53 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 17 Apr 90 07:10:07 GMTFrom:
ka9q.bellcore.com![e-mail]  (Phil Karn)Organization:
Secular Humanists for No-CodeSubject: Re: RF questionMessage-Id:
<[e-mail]>References:
<[e-mail]>,
<[e-mail]>Sender:
[e-mail]: [e-mail]
RFI in power supplies: don't overlook the power cord. I've
foundthat much RFI gets into (and out of) equipment this way,
and it's actuallyquite easy to stop. At almost every hamfest
I've attended over the past fiveyears I've found people selling
surplus AC power line filters made byCorcom, Delta, CDE, Potter,
etc. They seldom cost more than $5, and they canwork wonders.
Because they are constructed in sealed metal boxes, they
havemuch better isolation than most filters made from discrete
components.It's best to put them inside your equipment if you
have the room. If yourequipment uses an IEC standard power
connector (like those used on IBM PCsand clones) an excellent
approach is to replace it with an integrated RFIfilter/IEC
connector. Not only is this usually the easiest approach, but
youget the benefit of blocking the RFI right at the point where
it enters (orexits) the equipment cabinet. In general, the lower
an RFI filter's current rating and the larger it isphysically,
the better the RF attenuation will be. So use the largest
filteryou can fit into the available space, and don't use a 20
amp unit for a 1amp load if a lesser-rated unit is available.
(Obviously, the unit must berated to carry the actual
load!)Every time I buy a PC clone, I immediately install a power
line filterinside the power supply. It really does make a
difference, especially on theAM broadcast band.PhilFrom
packet-radio-relay  Tue Apr 17 11:14:11 1990Received: by
ucsd.edu; id AA06418    sendmail 5.61/UCSD-2.0-sun    Tue, 17 Apr 90
11:14:15 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA06413    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 17 Apr 90
11:14:11 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA02299; Tue, 17 Apr 90 10:48:47 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 17 Apr 90 17:40:54 GMTFrom:
[e-mail]  (Andrew Payne)Organization:
Cornell Theory Center, Cornell University, Ithaca NYSubject: Re:
Innovators need thick skin (was: CP/M sofware...)Message-Id:
<[e-mail]>References: <[e-mail]>,
<[e-mail]>, <[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail] (Gary Coffman) writes:>In
article <[e-mail]> [e-mail] (C.E.
Piggott) writes:>A network node only needs to route packets so
you can leave out all>the application protocols like smtp,
telnet, ftp, etc. All you must>have is the link protocol and ip
protocol handlers in a net node. A>user station on the other
hand would be pretty useless without the>application protocols
aboard. In practice we don't bother to strip>out the application
protocols in our switches since we don't need>the extra free
memory and it makes onsite debugging easier. However,>we do make
sure that the servers for the mbox and such are left >disabled.
It is very frustrating to find the switch down because>some
"poor dumb users " have connected to the mbox and left
connections>hanging to the point of exceeding max session. The
mbox is no substitute>for a real lan bbs.    Sometimes "poor dumb
users" are at the mercy of a "slow dumbnetwork".>Where are the
end users? At both ends of a session of course! -)>We have Unix
boxes in people's homes, dos boxes in people's homes, and>a few
crazys with laptops in their cars.>>>>I've always thought it
would be neat to put an EPROM into a TNC2>>(cheap, available,
etc.) that would give you, say, FTP and TELNET,>>or maybe even
just TELNET, to let the unfortunate ax.25-only users>>get into
things from a dumb terminal.  Keep in mind that there is>>still
a LOT of resistance to TCP/IP in some parts of the country,>>for
a variety of reasons.  It behooves us to ease the masses
into>>things when we know that we _will not_ survive on our
own.>>>THIS IS A VERY BAD IDEA!!!     I disagree completely.  See
below.>First, one of the most valuable things about tcp/ip is
that part of>the network lives INSIDE your computer. This makes
possible end-to-end>integrity of file transfers. If you attempt
to put the protocol in>an external box, there is no way to
guarantee that the data arrives>intact on the destination user's
disk.    True, but not really applicable.  Point-to-point
NON-networkprotocols exist that handle file transfers with
integrity just fine:  Kermit,XMODEM, and even an AX.25 text
stream.>Second, the economics of dumb terminals is absurd. Like
in the discussion>on porting the ka9q code back to cpm, PCs ARE
CHEAPER THAN TERMINALS!    Not true.  Get near any university or
large computer company and terminals are a dime a dozen.  I've
seen good Z-19s w/ modems for $50.  Or,go to a yardsale and pick
up a Commodore 64.    Most of the above points are minor ones, but
they collectively raised some feelings that have been stewing
inside of me for a long time:    First and foremost, plain old
AX.25 text streams will be with us fora long, long time.  Its
the lowest common denominator for just about all of amateur
packet radio.  It is also the simplest packet "mode" to
understand:just "CONNECT" and off you go.  Given these two
facts, I claim that plainold AX.25 text streams are and will
continue to be the most popular "mode".    Second, it has been
claimed that, in general, more equipment isrequired to run
TCP/IP over plain old AX.25 text streams (hereafter
"POATS").While this may be true, I do not believe that it is an
inhibiting factorfor people running TCP/IP.    Instead, I claim
that the main inhibiting factor for TCP/IP is ignorance.  People
avoid what they don't understand.  Relatively few peoplehave
seen TCP/IP running, and even those that have can be in the
dark.  I've talked to people on packet that they want to replace
AX.25 with TCP/IP forincreased throughput on file transfers.  I
quickly explained how IP packetswere shoved over AX.25 links,
and how TCP and IP added overhead to eachpacket.    Also, in
supposrt of this point, compare the implementation of Net/Rom to
TCP/IP.  Unlike TCP/IP, few people have network nodes in
theirhouse.  Rather, Net/Rom nodes are erected for public use,
with POATSup and downlinks.  Because of this, the general
knowledge of Net/Rom (and other networks configured in the same
way:  ROSE & TexNet) by averageusers is much greater than the
knowledge of TCP/IP.    Finally, (and sadly), politics is a major
problem in packet radionetworking.  You have the TCP/IP,
Net/Rom, ROSE, TexNet, DX Cluster, andPOATS camps.  The less
each knows about the other, the more "racist" thepolitics
problem becomes.    In light of the above observations, I think the
networks should be designed with the lowest common denominator
in mind:  POATS.  Sure, havingthe network terminate at the user
is better for various reasons ("file transfer integrity..."),
but I think that's a luxury that some can afford(and understand)
and some can't.  I wish I had a Sun or VAX in the basement with
a dedicated line, but I don't and Kermit and XMODEM work just
fine.    I like the direction the NOS MBOX is going in.  A POATS
user canconnect and play around with TCP/IP, just like is
currently done with Net/Rom.He/she can observe: "Hey!  I get
pretty reliable connections with this TELNET thing..." or "The
mail here seems a lot more reliable.."  I thinkall MBOXes SHOULD
be enabled.*** Flame on    I get incensed at people who claim (and
it has been done) thatI ham somehow inferior because I'm not
running TCP/IP.  When I explain to themthat I'm running a
software TNC with a modem hanging off my parallel portand that I
wrote the software myself because I originally couldn't afforda
TNC, they back off.  I think TCP/IP offers the best networking
currentlyavailable, and I'll get into it when I get the time and
means.    There is a lot of exciting work being done on the "front
line" ofpacket radio with high-speed modems, networking, etc.
However, the "rearguard" of people running Digicom>64, my
program, or some other POATS seemneglected.  I argue that they
MUST NOT be neglected, because it is theirdemand that ultimately
drives packet radio development.    Case in point:  the NEDA
network in New England.  This large networkwas not driven by
technology (they are using TheNET nodes with TNCs connectedback
to back), but by POATS user DEMAND.  Pure and simple.    I'm
working on a very long range proposal to cut NEDA over to
TCP/IP.However, the current configuration would be maintained:
POATS up and downlinks, with TCP/IP (instead of Net/Rom) between
network nodes.  Such a schemeoffers the most benefit to the most
users.  You could, of course, run TCP/IPfrom your house, but it
shouldn't be a requirement.** Flame off    As usual, comments?-- =
=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
 =  =  =  =Andrew C. Payne, N8KEI        UUCP:
...!cornell!batcomputer!payne                          INTERNET:
 [e-mail] packet-radio-relay  Tue Apr 17
20:19:57 1990Received: by ucsd.edu; id AA20034    sendmail
5.61/UCSD-2.0-sun    Tue, 17 Apr 90 20:20:03 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA20009    sendmail
5.61/UCSD-2.0-sun via SMTP    Tue, 17 Apr 90 20:19:57 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA09649; Tue, 17 Apr 90
20:17:45 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 18 Apr 90 03:04:16 GMTFrom:
jupiter![e-mail]  (Phil R. Karn)Organization: Bell
Communications Research, IncSubject: Re: Innovators need thick
skin (was: CP/M sofware...)Message-Id:
<[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender:
[e-mail]: [e-mail] article
<[e-mail]> [e-mail]
(Andrew Payne) writes:>    Instead, I claim that the main
inhibiting factor for TCP/IP is >ignorance.  People avoid what
they don't understand.Agreed. There is no such thing as a free
lunch, and even when thesoftware for a powerful networking
system like TCP/IP is free, you stillhave to understand how to
set it up and use it. But things areimproving.> Relatively few
people>have seen TCP/IP running, and even those that have can be
in the dark.  I've >talked to people on packet that they want to
replace AX.25 with TCP/IP for>increased throughput on file
transfers.  I quickly explained how IP packets>were shoved over
AX.25 links, and how TCP and IP added overhead to
each>packet.Yes and no. The per-packet overhead of POATS is
already so large thatadding TCP/IP headers makes little
incremental difference. Moreimportant factors are the
differences in protocol behavior andimplementation such as
retransmission, backoff and packetizationstrategies. I would
argue that TCP/IP running atop AX.25 in the UI(connectionless)
mode usually achieves better overall channel throughputthan most
plain old connected-mode AX.25 channels because TCP deals
muchmore efficiently with lost and duplicated packets, and
because the datapacket sizes are generally more reasonable (why,
oh why does it seemthat every BBS in the world sends no more
than one text line per frame,even when the lines are 2
characters long??)>    Also, in supposrt of this point, compare the
implementation of >Net/Rom to TCP/IP.  Unlike TCP/IP, few people
have network nodes in their>house.Everybody who has run my
package for the past few years has had both aTCP/IP *and* a
NET/ROM node, thanks to the efforts of W9NK (the originalauthor
of the NET/ROM implemenation in my package) and SM0RGV
(whoported it to NOS).>  Rather, Net/Rom nodes are erected for
public use, with POATS>up and downlinks.  Because of this, the
general knowledge of Net/Rom >(and other networks configured in
the same way:  ROSE & TexNet) by average>users is much greater
than the knowledge of TCP/IP.With the "mailbox gateway" feature
now in NOS (again courtesy ofSM0RGV), there is really no
fundamental difference between a "networknode erected for public
use, with POATS up and downlinks" that speaksTCP/IP on the
"network" side and one that speaks NET/ROM, ROSE or TexNeton the
network side. Any differences in general knowledge are
probablydue instead to the relative popularity of a given
system.>    Finally, (and sadly), politics is a major problem in
packet radio>networking.  You have the TCP/IP, Net/Rom, ROSE,
TexNet, DX Cluster, and>POATS camps.  The less each knows about
the other, the more "racist" the>politics problem becomes.Yes,
politics is a problem. But TCP/IP is unique in demonstrating
thatit can work with and build on the facilities provided by
these othernetworking "camps". IP datagrams are routinely sent
across NET/ROMbackbones, and the incorporation of NET/ROM
functionality into NOSallows what are nominally "TCP/IP nodes"
to handle "pure" NET/ROMtraffic. No other "camp" in amateur
packet radio has demonstrated thisflexibility. That's why TCP/IP
is called an "internetworking" protocol.>    In light of the above
observations, I think the networks should be >designed with the
lowest common denominator in mind:  POATS.This is amateur radio,
and our networks are being designed and built byvolunteers.
Since they aren't paid (and in many cases have to dig intotheir
own pockets for funding) it seems a little unfair to
criticizethem for building the network as they see fit. If you
disagree, you aremore than free to build a network the way YOU
want it, as long as youraise your own funding. In fact, you
should feel free to build theservice you want on top of the
network I have built.Assuming we can use our spectrum reasonably
efficiently, there should beenough room in amateur radio for
everyone with an idea of how a networkshould be built.PhilFrom
packet-radio-relay  Tue Apr 17 20:26:43 1990Received: by
ucsd.edu; id AA20504    sendmail 5.61/UCSD-2.0-sun    Tue, 17 Apr 90
20:27:18 -0700Received: from relay.cdnnet.ca by ucsd.edu; id
AA20460    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 17 Apr 90
20:26:43 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by relay.CDNnet.CA (4.1/1.14)    id
AA00467; Tue, 17 Apr 90 16:27:51 PDTDate: 17 Apr 90 15:25
-0800From: Doug Collinge VE7GNU <djc@[e-mail]>To:
[e-mail]-To:
[e-mail]-Id:
<262b2a16.samisen@[e-mail]>Subject: Famous
article missing?>X-Mailer: Mush 6.5.6 (PC R6.3 22-Sep-89)Did
anyone see an article posted by me entitled "Famous DCD mod."?73
Doug-- /\/\/\/\/\/Doug Collinge,    first try:
[e-mail]        then try:
samisen![e-mail]7GNU        VE7GNU@VE7GNU.#VIC.BC.CA.NA        V
ictoria, BC, CanadaFrom packet-radio-relay  Tue Apr 17 20:34:38
1990Received: by ucsd.edu; id AA20981    sendmail
5.61/UCSD-2.0-sun    Tue, 17 Apr 90 20:34:41 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA20976    sendmail
5.61/UCSD-2.0-sun via SMTP    Tue, 17 Apr 90 20:34:38 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA10320; Tue, 17 Apr 90
20:27:50 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 18 Apr 90 03:24:07 GMTFrom:
snorkelwacker!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.e
du!xanth![e-mail]  (Robert L.
Bailey)Organization: Old Dominion University, Norfolk
Va.Subject: Re: Multiple Z80 processors and righteous
hacks.Message-Id: <[e-mail]>References:
<[e-mail]>Sender: [e-mail]:
[e-mail] article <[e-mail]>
[e-mail] (Don Maslin) writes:>Probably the easiest
way is with a master and multiple slave processors>operating
under TurboDOS in an IEEE-696 environment. Indeed!  A few years
back I used a Sierra Data Sciences S-100 system withthat exact
configuration running TurboDos.  It was quite a system for
itstime!  I believe that the way the bus sharing was
accomplished was byhaving the master processor poll each slave
for I/O requests.  The onlyjob the master had to do was to check
each slave in turn and if theslave requested I/O then the master
performed the requested function.  I'msure that there was some
sort of time slice algorithm too, because wenever had any
problems with one of the slaves 'hogging' the I/O. Like I said,
it was quite a dynamite little system with 1 master/4
slaves.Each slave had its own terminal port, and did we ever
keep that littlesucker busy! The master controlled all I/O to
the hard & floppy disks.  Italso maintained a print spooler to
organize print requests.  We evenhad an 8748 emulator board &
cross compiler for doing software developmentfor embedded
microprocessor systems.  When we ran the emulator, there wassome
bus contention, and we had to limit the system to a single slave
to avoid crashes while emulating.Bob Bailey ([e-mail])From
packet-radio-relay  Tue Apr 17 22:19:07 1990Received: by
ucsd.edu; id AA28307    sendmail 5.61/UCSD-2.0-sun    Tue, 17 Apr 90
22:19:11 -0700Received: from ucbvax.Berkeley.EDU by ucsd.edu; id
AA28297    sendmail 5.61/UCSD-2.0-sun via SMTP    Tue, 17 Apr 90
22:19:07 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by ucbvax.Berkeley.EDU (5.61/1.41)    id
AA16969; Tue, 17 Apr 90 22:15:32 -0700Received: from USENET by
ucbvax.Berkeley.EDU with netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 17 Apr 90 21:57:42 GMTFrom:
hpcc01!col![e-mail]  (Bdale Garbee)Organization: HP
Colorado Springs DivisionSubject: Re: Daisy-chained RS-232
cableMessage-Id: <[e-mail]>References:
<[e-mail]>Sender: [e-mail]:
[e-mail], I remember the ULCNET article... will
have to dig that back out of thepile...>I don't know what it
would take to convert the SLIP driver to use this,>but thought
it might at least give you some ideas.As I recall, that also
involved using a small circuit to drive either DTR orCTS on the
serial port, or maybe it was DCD... as an indication of
activityon the cable.  All that would be needed I think is to
change the initializationfor the 8250/16450/16550 serial port IC
in the asynch driver code to turn onhardware flow control
outbound, so that the PC wouldn't transmit when the cablewas in
use.  I think it'd be a near-trivial mod, but I don't have time
to pursue it.Bdale, N3EUAFrom packet-radio-relay  Wed Apr 18
01:51:52 1990Received: by ucsd.edu; id AA10122    sendmail
5.61/UCSD-2.0-sun    Wed, 18 Apr 90 01:51:58 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA10103    sendmail
5.61/UCSD-2.0-sun via SMTP    Wed, 18 Apr 90 01:51:52 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA26784; Wed, 18 Apr 90
01:37:01 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 18 Apr 90 05:12:21 GMTFrom:
agate!helios.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!swrinde!e
mory!rsiatl![e-mail]  (John G. De
Armond)Organization: Radiation Systems, Inc. (a thinktank,
motorcycle, car and gun works facility)Subject: Re:
BTMAMessage-Id: <[e-mail]>References:
<[e-mail]>, <[e-mail]>,
<[e-mail]>Sender: [e-mail]:
[e-mail][e-mail] (j.gordon.beattie)
writes:>There has been some discussion about BTMA (Busy-Tone
Multi-Access)>packet systems here on the net and so I thought
I'd throw my two-cents in!>The Radio Amateur Telecommunications
Society has been using with this type>of access for its backbone
using a single 440 MHz voice-grade machine with>good results.
The purpose of this system is to provide connectivity >for some
of the ROSE X.25 Switches in the OSI-type packet network
operated>by RATS here in the NY/NJ/CT/PA/DE region.>We have
installed a receiver and transmitter at a high site>accessable
from anywhere within about 100 miles (minimum) of New York
City.>The controller is a TNC-2 that runs the digital
regenerator software.>The controller "listens" for packets and
sends out a busy tone (HDLC Flags) >on the output to inhibit
other stations.  As valid frames are received, >they start out
the trasnmitter FIFO-style with a one frame delay.  >The code
will be enhanced in the future to include general polling and
>"recent/most active user" polling algorithms as experience
dictates.  But BTMA is at best, a patch, and at worst, a
resource hog.  Assumingyour channel is full duplex at the node,
it makes no sense to throwaway half of the available thruput
transmitting a busy tone when datacould occupy the same slot.  I
also fail to see how digital regenerationbuys one anything
either.  Even if an incomming packet is corrupt, thebusy tone
must be transmitted for the duration in order to prerventthe
next station in line from also trashing its packet in
collision.Here in Atlanta, we run a full duplex digi/switch on
146.73/13.  Westarted out with busy tone and quickly realized
that we were throwingaway half of our thruput potential.  The
switch currently has a simplehardware bit repeater grafted to
the modem disconnect of a TNC-2.This is still a suboptimal
solution since the bit repeater tends toaccentuate the clock
jitter produced by the TNC-2 clock recovery state machine.An
optimum configuration would probably have the transmitter keyed
all the time.  Flags would be transmitted the instant RF carrier
isdetected in the receiver which busys the channel until the
transmittingstation can stabilize and start data transmission.
A simple audiopath between the receiver and transmitter is
probably more than adequateand demonstrates a high KISS factor.
Voice users are excluded throughadministrative or military
means.  This would, of course, requiretrue DCD on the users'
stations.John-- John De Armond, WD4OQC  | We can no more blame
our loss of freedom on congressRadiation Systems, Inc. | than we
can prostitution on pimps.  Both simplyAtlanta, Ga             |
provide broker services for their
customers.{emory,uunet}!rsiatl!jgd|  - Dr. W Williams |
      **I am the NRA**  From packet-radio-relay  Wed Apr 18
03:34:07 1990Received: by ucsd.edu; id AA22868    sendmail
5.61/UCSD-2.0-sun    Wed, 18 Apr 90 03:34:09 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA22863    sendmail
5.61/UCSD-2.0-sun via SMTP    Wed, 18 Apr 90 03:34:07 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA02828; Wed, 18 Apr 90
03:29:07 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 17 Apr 90 17:35:40 GMTFrom:
rochester!rit!cci632![e-mail]  (Just another hired gun
(n2hkd))Organization: Ring Ring... The number isSubject: Re:
Daisy-chained RS-232 cableMessage-Id:
<[e-mail]>References: <[e-mail]>,
<[e-mail]>Sender: [e-mail]:
[e-mail] article <[e-mail]>
[e-mail] (Bdale Garbee) writes:>>    I would like to join
the serial ports of several computers together >>so I can run
KA9Qs SLIP between then. Sort of poor man's Ethernet. I >>know
that a similar trick is used to join several TNCs together for
>>multi NET-ROM use. The trick involves resistors and diodes I
believe.>>>>    Does anyone have details on how to daisy-chain
RS-232 ports?>I have used (in the past) a multi-drop
configuraution, but not usingrs232. The rs232 was converted to
5Volt differential drivers andand thus bused together. ( I don't
have any of this handy, but I stillhave some of the WW boards to
llok up the parts, schematics). Thisallowed up to 30ish users on
the same 4 wire system. Doesn't rs422or one or one of those (I
don't recall) specs allow multidrop??Anyway these converters
were cheap to build, and worked fine t 56KB.-- email:
cb@cci632  or !rochester!kodak!n2hkd!curtis  Curtis Braun,
N2HKD, Computronics, PO Box 1002 Fairport NY, 14450  From
packet-radio-relay  Wed Apr 18 06:38:54 1990Received: by
ucsd.edu; id AA02602    sendmail 5.61/UCSD-2.0-sun    Wed, 18 Apr 90
06:39:15 -0700Received: from WSMR-SIMTEL20.ARMY.MIL by ucsd.edu;
id AA02579    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 18 Apr 90
06:38:54 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listMessage-Id:
<[e-mail]>Received: from CUNYVM.CUNY.EDU by
WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 18 Apr 90 07:38:08
MDTReceived: from DEARN by CUNYVM.CUNY.EDU (IBM VM SMTP
R1.2.2MX) with BSMTP id 3313; Wed, 18 Apr 90 09:36:41
EDTReceived: from DBSTU1 (C0033003) by DEARN (Mailer R2.03B)
with BSMTP id 7770; Wed, 18 Apr 90 15:36:14 CETDate:
Wed, 18 Apr 90 15:34:50 MEZFrom: "Detlef J. Schmidt"
<[e-mail]>Subject:      re:
Innovators need thick skinTo: Packet-radio
<[e-mail]>on>Date:         Tue, 17
Apr 90 17:40:54 GMT>From:         Andrew Payne
<[e-mail]>writes:>Subject:      Re:
Innovators need thick skin (was: CP/M sofware...)>
[.............]>>    Second, it has been claimed that, in general,
more equipment is>required to run TCP/IP over plain old AX.25
text streams (hereafter "POATS").>While this may be true, I do
not believe that it is an inhibiting factor>for people running
TCP/IP.>>    Instead, I claim that the main inhibiting factor for
TCP/IP is>ignorance.  People avoid what they don't understand.
Relatively few people>have seen TCP/IP running, and even those
that have can be in the dark.  I've>talked to people on packet
that they want to replace AX.25 with TCP/IP for>increased
throughput on file transfers.  I quickly explained how IP
packets>were shoved over AX.25 links, and how TCP and IP added
overhead to each>packet.This might be one good explanation. But
I guess it's not the only one.We had a little 'burst' of TCP/IP
activity around here about a year ago( maybe 1 1/2 ?). I
organized the IP-address scheme for northern Germanyand managed
requests for IP-addresses. Everyone who requested has gotTCP/IP
( CMU, KA9Q, NCSA ) from me for his
tests/QSOs/installation/etc.But since about one year no more
requests dropped in here. Most TCP/IPactivity around here
vanished. Even those stations formerly workingon TCP/IP changed
over to different systems. So it could hardly bea problem of
ignorance ( even though there is allways some ).But what are the
reasons?My answer is simple: There is no simple answer|Maybe
some HAMs treat TCP/IP as a dying standard. Most
internationalcommitees expressed their intention not to
establish any new TCP/IPversion. Instead an OSI conforming
standard shall be supported ( whateverit may be some times).
Maybe some HAMs are waiting for a AMPR versionof such a
standard. I understood RATS was going that way.(This does NOT
relate to the fact that TCP/IP is still the only reliableand
independent standard on an ETHERNET for all different kind of
machines.)Maybe other HAMS feel TCP/IP was developed for another
world wheresome criteria is totaly different from a HAM world (
reliable nodes,stabil links, coordinated management, etc ).Maybe
some HAMs don't know how to spell it,or whatever else....But
these are only individual opinions NOT to use TCP/IP, but what
arethe reasons to use other systems?The summe of different
aspects could bring some explanation.At the user site we have
some fine terminal programms around here. Theseprogramms allow
to 'TELNET' to other station(s) on one or more
channels,transfer files on another channel, and route/connects
through thenetwork on a 3rd ( 4th, 5th,...) channel. TURBOPR (
for PCs, by dl1bho)or DIGICOM ( for c64s or c128s, by dl8mbt )
are some good examples.Even subconnects through these programms
to 3rd stations arepossible ( or to another frequency/band ).On
the network site we have a system of several hundreds of (
mostly)TheNet nodes.  TheNetNode is catching up right now.  So
users might asktheir node what other TheNet nodes in Denmark,
Netherlands, Belgium, France,Swiss, Austria, Hungary, etc, etc
are active right now and connect through( if the coresponding
RF-links are reliable ).And there are BBSs in this cellular
network. Meanwhile NORD><LINK'sTheBox ( by df3av) became
somekind of standard right now in westernEurope. It supports
several TNCs, individual language per user,multiconnects,
gateway functions PR/AMTOR,
auto-forwarding,remote-sysop-maintenance, file compression on
forwarding links, lifetime management, help menue, etc, etc.All
of these items are designed to work together in a network
andsupport each other. So if one looks at just one of the items
the comparisonsto other systems will allways be a miss. But if
you look at it togetherthis maybe an answer why other HAMs
prefer other systems.Maybe...Detlef ( dk4eg ).From
packet-radio-relay  Wed Apr 18 08:55:05 1990Received: by
ucsd.edu; id AA12436    sendmail 5.61/UCSD-2.0-sun    Wed, 18 Apr 90
08:55:26 -0700Received: from WSMR-SIMTEL20.ARMY.MIL by ucsd.edu;
id AA12408    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 18 Apr 90
08:55:05 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listMessage-Id:
<[e-mail]>Received: from CUNYVM.CUNY.EDU by
WSMR-SIMTEL20.ARMY.MIL with TCP; Wed, 18 Apr 90 09:21:48
MDTReceived: from DEARN by CUNYVM.CUNY.EDU (IBM VM SMTP
R1.2.2MX) with BSMTP id 4879; Wed, 18 Apr 90 11:20:39
EDTReceived: from DBSTU1 (C0033003) by DEARN (Mailer R2.03B)
with BSMTP id 3847; Wed, 18 Apr 90 17:07:49 CETDate:
Wed, 18 Apr 90 16:38:36 MEZFrom: "Detlef J. Schmidt"
<[e-mail]>Subject:      re:
innovators need thick skin (was: CP/M software...)To:
Packet-radio <[e-mail]>on>Date:
  Wed, 18 Apr 90 03:04:16 GMT>From:         "Phil R. Karn"
<jupiter![e-mail]>writes:>>>[..................]>strateg
ies. I would argue that TCP/IP running atop AX.25 in the
UI>(connectionless) mode usually achieves better overall channel
throughput>than most plain old connected-mode AX.25 channels
because TCP deals much>more efficiently with lost and duplicated
packets, and because the data>packet sizes are generally more
reasonableThis has to be one of the main 'requisitions':as long
as an IP layer runs it's own protokoll including checks forerror
recovery ( because it doesn't rely on it's layer 2 ) theprotocol
overhead would be tremendous.>(why, oh why does it seem>that
every BBS in the world sends no more than one text line per
frame,>even when the lines are 2 characters long??)This is one
good reason to run NORD><LINK's TheBox. It doesn't onlyfill up
the frames up to the parameterized limit, additionaly acompress
modus could be switched on. So up to the double amount ofbytes
could be squezed out of one I-frame.Detlef ( dk4eg ).From
packet-radio-relay  Wed Apr 18 10:15:20 1990Received: by
ucsd.edu; id AA19346    sendmail 5.61/UCSD-2.0-sun    Wed, 18 Apr 90
10:15:46 -0700Received: from [128.189.97.41] by ucsd.edu; id
AA19300    sendmail 5.61/UCSD-2.0-sun via SMTP    Wed, 18 Apr 90
10:15:20 -0700 for /usr/lib/sendmail -oc -odb
-oQ/var/spool/lqueue -oi -fpacket-radio-relay
packet-radio-listReceived: by relay.CDNnet.CA (4.1/1.14)    id
AA15845; Wed, 18 Apr 90 10:15:15 PDTDate: 18 Apr 90  9:16
-0800From: Doug Collinge VE7GNU <djc@[e-mail]>To:
[e-mail]-To:
[e-mail]-Id:
<262c2776.samisen@[e-mail]>Subject:
Repeaters>X-Mailer: Mush 6.5.6 (PC R6.3 22-Sep-89)> John (**I am
the NRA**) De Armond, WD4OQC  > An optimum configuration would
probably have the transmitter keyed > all the time. I don't
think this is necessary; DPLLs in the RX clock recovery
circuitscould maintain coherence with the TX clock for quite a
long time, dependingon the bit rate.  For 9600 bps I calculated
that a DPLL based on a one ppm crystal oscillator could maintain
the phase OK if the TX beaconsonce every idle minute.> Flags
would be transmitted the instant RF carrier is> detected in the
receiver which busys the channel until the transmitting> station
can stabilize and start data transmission.  > A simple audio
path between the receiver and transmitter ...These two concepts
seem incompatible to me because the phase of theflags would be
incoherent with the phase of the received data.However, if using
a bit-regenerating type of repeater, and if the RXand TX clock
in the repeater were tied together (i.e., no RX clockrecovery
circuit) , it would be possible for a user to synchronize
thephase of his TX to the repeater's RX by using his own RX
clock(recovered from the repeater's TX) as his TX clock and
adding a phaseshift to account for the round-trip speed-of-light
delay to and fromthe repeater.  This scheme would eliminate
synchronization delaysaltogether except for when a station first
went on the air.This would probably work only at lower bit rates
like 9600, where thewavelength of half a bit is sufficiently
large to swamp phase changesdue to multipath and other things.
Users could find the necessaryphase shift between their RX and
TX with the aid of a map showing therequired phase shift in
rings around the repeater site.  Or else bygood old just
tweaking it until it worked.Does anyone do this?  What is the
loss of efficiency due to syncronization?73 Doug--
/\/\/\/\/\/Doug Collinge,    first try:
[e-mail]        then try:
samisen![e-mail]7GNU        VE7GNU@VE7GNU.#VIC.BC.CA.NA        V
ictoria, BC, CanadaFrom packet-radio-relay  Wed Apr 18 13:20:43
1990Received: by ucsd.edu; id AA06511    sendmail
5.61/UCSD-2.0-sun    Wed, 18 Apr 90 13:20:48 -0700Received: from
ucbvax.Berkeley.EDU by ucsd.edu; id AA06488    sendmail
5.61/UCSD-2.0-sun via SMTP    Wed, 18 Apr 90 13:20:43 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listReceived: by
ucbvax.Berkeley.EDU (5.61/1.41)    id AA03917; Wed, 18 Apr 90
13:18:15 -0700Received: from USENET by ucbvax.Berkeley.EDU with
netnews    for [e-mail]
([e-mail])    (contact [e-mail] if
you have questions)Date: 18 Apr 90 12:02:11 GMTFrom:
sdd.hp.com!ncr-sd!ncrlnk!ciss![e-mail]  (Don
Montgomery)Organization: NCR Corp. Information Systems &
ServicesSubject: BADGES FROM BARC AT THE HAMVENTIONMessage-Id:
<[e-mail]>Sender:
[e-mail]: [e-mail]
BELLBROOK AMATEUR RADIO CULB (BARC) WILL HAVE BADGES AVAILABLEAT
THE DAYTON HAMVENTION.  STOP BY BOOTH 168 AND GET YOURS.ALL
PROCEEDS WILL BE USED FOR BARC PROJECTS.  THANK YOU FORYOUR
SUPPORT. 73, DON,  W8PLQ--
*****************************************************************
*************| Don Montgomery       NCR Corp.  Dayton OH  45479
  PCD-6  [phone]    | Worldwide Network Planning Services
 [e-mail]
*****************************************************************
*************From packet-radio-relay  Wed Apr 18 14:26:29
1990Received: by ucsd.edu; id AA12692    sendmail
5.61/UCSD-2.0-sun    Wed, 18 Apr 90 14:26:49 -0700Received: from
WSMR-SIMTEL20.ARMY.MIL by ucsd.edu; id AA12644    sendmail
5.61/UCSD-2.0-sun via SMTP    Wed, 18 Apr 90 14:26:29 -0700 for
/usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi
-fpacket-radio-relay packet-radio-listMessage-Id:
<[e-mail]>Received: from
CORNELLC.cit.cornell.edu by WSMR-SIMTEL20.ARMY.MIL with TCP;
Wed, 18 Apr 90 15:26:12 MDTReceived: from CALSTATE.BITNET by
CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id
8387; Wed, 18 Apr 90 17:01:09 EDTReceived: by
CCS.CSUSCC.CALSTATE.EDU from Mail by CSUMailer (1.4);
Wed, 18 Apr 90 13:59:25 PDTDate:     Wed, 18 Apr 90 13:59:23
PDTFrom: [e-mail]:
Dayton HamventionTo: [e-mail] IS
the Hamvention? Where is Dayton =) ?[e-mail]:
Thu, 19 Apr 90 04:00:02 PDTFrom: Brian Kantor (List Maintainer)
<[e-mail]>Reply-To: [e-mail]:
Packet-Radio Digest V1 #1To: packet-radioPacket-Radio Digest
    Thu, 19 Apr 90       Volume 90 : Issue   1Today's Topics:
             administrivia - Packet-Radio Digest
         Dayton Hamvention        Re: Innovators need thick skin
(was: CP/M sofware...)                             RF
questionSend Replies or notes for publication to:
<[e-mail]>Send requests of an administrative nature
(addition to, deletion from thedistribution list, et al) to:
<[e-mail]>Archives of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".Digest files are named
Vv.n where v=volume and n=number in volume.Digests will be
issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET
PEOPLE: UCSD.EDU is an internet site.  TheInternet-to-BITNET
mail gateway systems would prefer that you insteadadd yourself
to a BITNET redistribution of this list; you may addyourself to
the list by sending the following command:      SUBSCRIBE
I-PACRAD your full nameto LISTSERV@UIUCVMD.  You can send that
in an interactive if your systemsupports them (e.g. the CMS TELL
command), or in the body of a mail message(*not* the subject
line).Please note:  Although you'll be receiving Packet-Radio
mailing from thenetwork address I-PACRAD@UIUCVMD,
[e-mail] the source.  Any contributions from you
should be sent to UCSD.The mailing list is in the form of a
digest.  It is not edited, justa convenient envelope for
multiple messages to reduce netmail load.If your mail reader
does not have an "undigestify" option, contactKeith Petersen
W8SDZ  <[e-mail]> and he'll sendyou
C-language source for one.73,    -
Brian        ([e-mail])------------------------------------------
----------------------------Date: Wed, 18 Apr 90 16:35:44
-0700From: brian (Brian Kantor)Subject: administrivia -
Packet-Radio DigestTo: packet-radio-digestWell, if I did
everything right, the packet radio mailing list will bearriving
as a daily digest from now on for those of you receiving itby
mail.  (Usenet people will still get messages as separate
articlesin the rec.ham-radio.packet newsgroup.)The archives will
have the digests in them, from now on, not monthlycollections of
messages.I know I'd promised to do this earlier.  I'm sorry it
took so long.    - Brian------------------------------Date: Wed, 18
Apr 90 13:59:23 PDTFrom:
[e-mail]: Dayton
HamventionTo: [e-mail] IS the
Hamvention? Where is Dayton =)
?[e-mail]------------------------------Date: 18 Apr
90 17:12:47 GMTFrom: hpcc01!col![e-mail]  (Bdale
Garbee)Subject: Re: Innovators need thick skin (was: CP/M
sofware...)To: [e-mail]>I've always thought it
would be neat to put an EPROM into a TNC2>(cheap, available,
etc.) that would give you, say, FTP and TELNET,>or maybe even
just TELNET, to let the unfortunate ax.25-only users>get into
things from a dumb terminal.Last night, I got the 900411 release
of NOS (much butchered) limping along onthe new Kantronics Data
Engine (a V40-based dual port TNC, sort of - likely toprice out
about in the KAM ballpark, whatever that means).  A couple of
comments.The V40 object is a touch over 180k of EPROM using
Turbo C 2.0 and ParidigmLOCATE.  I've got 128k of RAM in the
board right now, which leaves about 67kof heap space.  I'm sure
I can reclaim *some* RAM later, but...I won't pretend that this
is perfectly optimized, but those are real numbersfor a NOS cut
that includes only telnet and finger clients, plus the
AX.25mailbox code (soon to be an AX.25 "terminal server" for the
IP switch this issupposed to become), and the NET/ROM support
(not very big).  The only device driver is the PE1CHL code for
the 8530, non-DMA.  I'd also love to see a "TNC-2 Telnet"
implementation, but I think it's goingto be *hard*.  I hope
anyone who attempts it really loves Z80 assembler.This and other
toys on display Friday week at the packet forum in Dayton.73 -
Bdale, N3EUA------------------------------Date: 18 Apr 90
19:51:14 GMTFrom: bu.edu!mirror!necntc!necis![e-mail]  (
NM1D)Subject: RF questionTo: [e-mail] One *large*
problem that I have seen (and experienced myself) with usinga
Hand-held radio with a TNC for packet radio operation is that RF
"gets" intoeverything.  Most people in this situation are using
(or attempting) to usethe "flexible antenna" that comes with the
hand-held radio. A "fairly simple" solution to the problem, and
one that helps a lot morethan you would think is to use a better
antenna.   This does NOT have to bea commercial (sp?) antenna...
but can be one that you build yourself. Sometimes the problem
comes from the fact that the hand-held radio has aplastic
chassie, and therefore radiates a significant amount of RF
directlyfrom the case... this is not "very" common, but could
happen.  To solve the antenna problem (and get MUCH better
results from your station),contruct either a 1/4 wave ground
plane, or a 1/2 wave dipole antenna, and"install" it as high,
and as far away from your TNC/computer as you can.  Ofcourse,
the longer the feed lines, the higher the losses, so be
reasonable.To make a 1/4 wave ground plane, I have used a SO-239
chassie mount connectorand then soldered a 1/4 wave length of
wire as the radiator, and 4 1/4 wave(that is four separate 1/4
wave long wires) to each corner of the SO-239chassie connector.
These "ground plane radials" should be set to a 45 degreeangle.
 Connect the feed line to the SO-239, and hang the assemble from
yourceiling or in the attic.                           |
                  |                           |
         |                           #
/ \                        /     \                      /
 \                    /             \  Or build a 1/2 wave
dipole, and suspend it vertically, instead of horizontallywith
the feed line going at a right angle to the antenna for a short
distance,and then to your radio.   Keep this as high as possible
and as far away fromyour TNC/computer as you can. If you *must*,
use a commercial antenna... (it is MUCH more fun to buildyour
own, not to mention, less expensive)...  Some have had sucess in
usinga mobile magnetic mount antenna placed on top of a "large"
metal object(refrigerator, metal cookie sheets, balcony
railings, etc)...  Large in thiscase means a circle of at least
1/4 wave in radius.     Hope this information is of some
help,            Rich--
/****************************************************************
**********\ * Rich Bono (NM1D)    If I could only 'C' forever!!
  [e-mail] *  * [phone]          NEC
Technologies Inc.                NM1D@WB1DSW *
\****************************************************************
**********/------------------------------End of Packet-Radio
Digest******************************Date: Fri, 20 Apr 90
04:00:03 PDTFrom: Brian Kantor (List Maintainer)
<[e-mail]>Reply-To: [e-mail]:
Packet-Radio Digest V1 #2To: packet-radioPacket-Radio Digest
    Fri, 20 Apr 90       Volume 90 : Issue   2Today's Topics:
                           DAYTON!
innovators need new skin                      Innovators need
thick skin          innovators need thick skin (was: CP/M
software...)                     Microwave oscillator sources
  PR with PC and modem only! BAYCOM (=DIGICOM ported to PC)!
                        RF question                       TCP/IP
in anticomputersSend Replies or notes for publication to:
<[e-mail]>Send requests of an administrative nature
(addition to, deletion from thedistribution list, et al) to:
<[e-mail]>Archives of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".Digest files are named
Vv.n where v=volume and n=number in volume.Digests will be
issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET
PEOPLE: UCSD.EDU is an internet site.  TheInternet-to-BITNET
mail gateway systems would prefer that you insteadadd yourself
to a BITNET redistribution of this list; you may addyourself to
the list by sending the following command:      SUBSCRIBE
I-PACRAD your full nameto LISTSERV@UIUCVMD.  You can send that
in an interactive if your systemsupports them (e.g. the CMS TELL
command), or in the body of a mail message(*not* the subject
line).Please note:  Although you'll be receiving Packet-Radio
mailing from thenetwork address I-PACRAD@UIUCVMD,
[e-mail] the source.  Any contributions from you
should be sent to UCSD.The mailing list is in the form of a
digest.  It is not edited, justa convenient envelope for
multiple messages to reduce netmail load.If your mail reader
does not have an "undigestify" option, contactKeith Petersen
W8SDZ  <[e-mail]> and he'll sendyou
C-language source for one.73,    -
Brian        ([e-mail])------------------------------------------
----------------------------Date: 19 Apr 90 22:03:00 GMTFrom:
swrinde!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!br
utus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
ubject: DAYTON!To: [e-mail]> >        223.600> >
    445.600> >        145.600> > > Just a really really dumb
thought....> If anyone were to have a crosband repeat dual
bander (ie 731/631,th75),. all three bands could be linked.> >
IMHO Actually it probably isn't that dumb an idea, since I
usually> set up my 721 at most hamfest to cross band 440 and 140
for handheld> use :-). There are also the low power freq areas
for use if you use 5w.> or less to get away from the norm.At
Dayton, I would suggest NOT repeating what is on two meters
because ofthe massive QRM and intermod present on that band in
the arena area.  MAYBEa tone squelch on it MIGHT reduce it.  How
about leaving these frequenciesas the simplex only ones, and
pick some others for crossbanding, such as:145.700  <-->
223.700  <-->  445.700--Phil Howard, KA9WGN-- | Individual
CHOICE is fundamental to a free society<[e-mail]> |
no matter what the particular issue is all
about.------------------------------Date: 20 Apr 90 06:01:24
GMTFrom: van-bc!ubc-cs!nebulus![e-mail]
(Dennis S. Breckenridge)Subject: innovators need new skinTo:
[e-mail], What about running real IP packets on
the air. Turn the trailers on, put the call-sign after the
trailer and let the code dump it on reception. I have been
toying with this for a while and it  makes sense.
Experimentation shows if I reduce the times required for ACKs
then I win. --
-----------------------------------------------------------------
------------Dennis S. Breckenridge  [phone]
[e-mail]           VE7TCP               Still brain
dead after all these years :-)
-----------------------------------------------------------------
------------------------------------------Date: 20 Apr 90
00:04:48 GMTFrom: jupiter![e-mail]  (Phil R.
Karn)Subject: Innovators need thick skinTo:
[e-mail] article <[e-mail]>
[e-mail] ("Detlef J. Schmidt") writes:>Maybe some
HAMs treat TCP/IP as a dying standard. Most
international>commitees expressed their intention not to
establish any new TCP/IP>version. Instead an OSI conforming
standard shall be supported ( whatever>it may be some times).For
a "dying" standard, TCP/IP is doing awfully well in the
commercialworld. Interop last fall drew something like 10,000
people to a showthat was primarily devoted to TCP/IP and related
protocols, when severalyears earlier the first such show drew
only a few hundred.  Lots ofpeople (not all of them Americans)
are beginning to question therelevance of OSI (at least the
lower layers) given the almost universalacceptance of TCP/IP as
a de-facto, if not official, standard. And now Isee that TCP/IP
has been submitted to ANSI for consideration as anAmerican
National Standard. In the "expected useful life" section
theproposal reads "several decades".As the (Norwegian) moderator
of a panel session I participated in at theNORDUNET meeting in
Stockholm last fall said, "If OSI is the solution,then what is
the problem?"> Maybe some HAMs are waiting for a AMPR version>of
such a standard. I understood RATS was going that way.Despite
all the lofty promises and OSI cheerleading from RATS, I haveyet
to see anything actually come out of that group that even
resembleswhat the commercial OSI "camp" is also promising. By
that I mean a suiteof working protocol implementations designed
for directcomputer-to-computer networking, including TP-4 and
CLNP and all the"basic" applications (FTAM, VTP, X.400, etc). So
far, beneath all thevapor, ROSE seems to be essentially a
NET/ROM "lookalike" - differentprotocols, perhaps, but running
on the same inadequate hardware (TNC-2)and providing the same
outdated service model (dumb terminalconnections). Dave Clark of
MIT once described the OSI community asrunning after the
Internet (T CP/IP) community shouti

ng "Wait for me!Wait for me!". I guess similiar things could be
said about ROSE andNET/ROM.>Maybe other HAMS feel TCP/IP was
developed for another world where>some criteria is totaly
different from a HAM world ( reliable nodes,>stabil links,
coordinated management, etc ).A lot of people might dispute your
description of the "real" TCP/IPworld as having reliable nodes,
stable links and coordinated management.:-) TCP/IP was designed
for networking environments that are a bit more,uh, "dynamic"
than your average stodgy PTT service that gave you X.25and most
of the OSI vaporware protocols. In fact, the whole motivationfor
developing TCP/IP in the first place was to interconnect the
ARPANETwith the early DARPA packet radio networks (this was
before Ethernet,which the early papers described as "packet
radio on a cable"). It seemsfitting that we hams have now
brought TCP/IP full circle.But be that as it may, you are
getting somewhat closer to the truth. AsI said before, TCP/IP
has little to offer unless you have a computer.When I started
this project five years ago, the only popular "ham
shackcomputer" in the US with enough power (just barely) to run
a highlystripped TCP/IP was the Xerox 820, a Z-80 CP/M machine.
PCs were stillout of reach of most hams. Knowing how fast the
computer industry moves,I made a conscious decision to develop
something that would pay off inthe long term, not a hack that
would be rendered obsolete in a year ortwo.This meant designing
a networking system for the machines that wouldbecome popular
several years in the future, plus the much faster modemsthat
would be widely deployed by then. Although PCs are now
widelyavailable at cheap prices and are even making it into many
ham shacks,most hams are still sputtering along with the same
1200 baud modems thatwere already obsolete in 1979.Who knows,
one can always hope...Phil------------------------------Date: 20
Apr 90 00:16:57 GMTFrom: jupiter![e-mail]  (Phil R.
Karn)Subject: innovators need thick skin (was: CP/M
software...)To: [e-mail] article
<[e-mail]> [e-mail] ("Detlef J.
Schmidt") writes:>as long as an IP layer runs it's own protokoll
including checks for>error recovery ( because it doesn't rely on
it's layer 2 ) the>protocol overhead would be tremendous.I
challenge you to quantify "tremendous".This is an old argument,
but it keeps coming up so it must be answered.Figure out how
many bytes are spent on each of the protocol layers in anactual
system, including the number of byte times spent on
collisions,keying up the modem, etc. I think you'll find that in
most systems theoverhead due to upper level protocols is tiny
compared to the overheadin the lower layers.If you're still
bothered by the size of a TCP/IP header, you can use VanJacobson
header compression to reduce the average header size to 5
bytes*without* giving up the major advantages of a protocol like
TCP: robustend-to-end error checking and flow control. (I like
to think of Van'swork as the "final nail" in the coffin of the
virtual-circuit-networkcamp.)Phil------------------------------Da
te: 18 Apr 90 19:28:30 GMTFrom:
cs.utexas.edu!usc!brutus.cs.uiuc.edu!rpi!crdgw1!ge-dab!tarpit!peo
ra!tsdiag![e-mail]  (Dave Tiller
N2KAU)Subject: Microwave oscillator sourcesTo:
[e-mail] anyone had any experience with
converting a microwave oven magnetron to Amateur use?  Are there
any problems with needing to'bend' it down slightly from 2.450
GHz to make it into the Hamband?  What are the power
requirements?  I noticed that MCM sellsreplacement magnetrons -
could this be a source for cheep packetbackbone oscillators?
Inquiring minds gots'ta know...Any helpwould be greatly
appreciated.PS - I don't intend to run one of these at ~600-1200
Watts aimed     at the general public.  A couple of Watts (<10)
would be more     resonable.-- David E. Tiller
[e-mail]  | Concurrent Computer Corp.FAX:
201-870-5952      Ph: [phone] (w) | 2 Crescent Place, M/S
117UUCP: ucbvax!rutgers!petsd!tsdiag!davet        | Oceanport
NJ, 07757ICBM: 40 16' 52" N      73 59' 00" W           | N2KAU
@ NN2Z------------------------------Date: 19 Apr 90 07:51
PSTFrom: Ralf Werner
<[e-mail]>Subject: PR with PC
and modem only! BAYCOM (=DIGICOM ported to PC)!To:
[e-mail]
PRE-ANNOUNCEMENT:                              -----------------
                        For all those of you who wondered, "why
not make PR with a simple modem andsome cleverly written
software like the DIGICOM folks on their C64" - here'sthe good
news:        BAYCOM - as it will be called - is about to be
released!        The writer of BAYCOM is Flori, DL8MBT, who had
also written DIGICOM! BAYCOMwill include all features of DIGICOM
(remote commands, screen editor etc.)plus many features
more.What do you need to be QRV with BAYCOM?Simple question -
simple answer: all you need is a PCompatible computer anda
serial port - and a modem. The modem is built around the TCM
3105 modemchip and gets it's power out of the RS232 from the PC.
Costs: < $30 !!!BAYCOM will be officially demonstrated on
Saturday, April 21st at the Frank-furt PR-meeting.I will post
more accurate information on BAYCOM as soon as Flori, DL8MBT
andJohannes, DG3RBU, will tell me about this exciting new
product.If you have some questions to DL8MBT and/or DG3RBU, you
can write them tome - I'll relay them to Flori and
Johannes.REMEMBER - THIS IS ONLY AN ANNOUNCEMENT! DG3RBU told
me, that BAYCOM willwill be tested for about one month before
the first "official" release leavestheir test benches.
    Have fun with PR! Vy 73 de Ralf, DF1RW
([e-mail])BTW: if
you are wondering about "BAYCOM" - the "BAY" stands for BAYern
  (Bavaria. Maybe the name will change...)
:-)------------------------------Date: 19 Apr 90 07:16:46
GMTFrom: cs.utexas.edu!helps!bongo![e-mail]
 (Julian Macassey)Subject: RF questionTo:
[e-mail] article <[e-mail]>,
[e-mail] (Phil Karn) writes:>     Good advice deleted
> Every time I buy a PC clone, I immediately install a power
line filter> inside the power supply. It really does make a
difference, especially on the> AM broadcast band.>     At the risk
of being flamed yet again for not knowing what I am talking
about, allow me two whip in my $0.02 worth.    The biggest source
of "conducted" and low to medium freq RFI from Personal
Computers seems to be the switching power supplies. As they come
from the Asian manufacturers, these things universally seem to
need filtering. Phil's suggestion of wiring in a commercial
filter is certainly a cheap and effective method - assuming you
get the filters as scrap or surplus.     These supplies can have
acceptable levels of emitted crud when the manufacturers take
the trouble to add a couple of caps and chokes in the power
line. But alas, most manufacturing these days seems to be "What
you can get away with".    Now if only we could get the
manufacturers of all those $5.00 light dimmers to do something
about the crud they radiate on the AM Broadcast band.-- Julian
Macassey, n6are  [e-mail]
ucla-an!denwa!bongo!julianN6ARE@K6IYK (Packet Radio)
n6are.ampr.org [44.16.0.81] voice (213)
653-4495------------------------------Date: 19 Apr 90 16:01:21
GMTFrom: [e-mail]  (Andrew Payne)Subject:
TCP/IP in anticomputersTo: [e-mail] article
<[e-mail]> [e-mail] (C.E. Piggott)
writes:>Now, it doesn't seem fair to say "tough" to the
end-users, and it>doesn't seem reasonable to say to them "if you
want to use the network,>you have to go through an AX.25<->TCPIP
gateway (like GRI or RGV)".    Why is a gateway not reasonable?
The current network uses gatewaysin the form of Net/Rom nodes:
AX.25<-->Net/Rom, if you want to look at it that way.
Relatively few people have their "own" Net/Rom nodes:  most usea
gateway.-- =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
=  =  =  =  =  =  =  =  =Andrew C. Payne, N8KEI        UUCP:
...!cornell!batcomputer!payne                          INTERNET:
 [e-mail]------------------------------End
of Packet-Radio Digest******************************Date: Sat,
21 Apr 90 04:00:02 PDTFrom: Packet-Radio Mailing List and
Newsgroup <[e-mail]>Reply-To:
[e-mail]: Packet-Radio Digest V1 #3To:
packet-radioPacket-Radio Digest         Sat, 21 Apr 90
Volume 90 : Issue   3Today's Topics:               Fixmail 1.09
now posted :128.104.198.22          Innovators need thick skin
(was: CP/M sofware...)                   KISS Mode -- How Fast?
(2 msgs)                Microwave oscillator sources (3 msgs)
                 USENET at Dayton HamventionSend Replies or
notes for publication to: <[e-mail]>Send requests
of an administrative nature (addition to, deletion from
thedistribution list, et al) to:
<[e-mail]>Archives of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".Digest files are named
Vv.n where v=volume and n=number in volume.Digests will be
issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET
PEOPLE: UCSD.EDU is an internet site.  TheInternet-to-BITNET
mail gateway systems would prefer that you insteadadd yourself
to a BITNET redistribution of this list; you may addyourself to
the list by sending the following command:      SUBSCRIBE
I-PACRAD your full nameto LISTSERV@UIUCVMD.  You can send that
in an interactive if your systemsupports them (e.g. the CMS TELL
command), or in the body of a mail message(*not* the subject
line).Please note:  Although you'll be receiving Packet-Radio
mailing from thenetwork address I-PACRAD@UIUCVMD,
[e-mail] the source.  Any contributions from you
should be sent to UCSD.The mailing list is in the form of a
digest.  It is not edited, justa convenient envelope for
multiple messages to reduce netmail load.If your mail reader
does not have an "undigestify" option, contactKeith Petersen
W8SDZ  <[e-mail]> and he'll sendyou
C-language source for one.73,    -
Brian        ([e-mail])------------------------------------------
----------------------------Date: Fri, 20 Apr 90 08:09:59
GMTFrom: [e-mail] (Pat Davis)Subject: Fixmail 1.09
now posted :128.104.198.22To: [e-mail],
[e-mail] 1.09 is posted on pgd.adp.wisc.edu for
anonymous FTP.1.09 fixes a bug that would allow FIXMAIL to
END/TERMINATE if/when therewas no more mail to censor..  That's
right, censor..  Fixmail,by Bryan HI-Q Biggers N9GBJ, manages
SMTP mail from NET/NOS.  It has somevery attractive features.
FIXMAIL is Desqview "aware"..The file you want is FIXM109.ZIP,
you might find more helpful files inFIXM106.ZIP
too...KD9UU------------------------------Date: 20 Apr 90
16:18:00 GMTFrom: att!cbnewsh![e-mail]
(j.gordon.beattie)Subject: Innovators need thick skin (was: CP/M
sofware...)To: [e-mail]>    First and foremost, plain
old AX.25 text streams will be with us for> a long, long time.
Its the lowest common denominator for just about all of >
amateur packet radio.  It is also the simplest packet "mode" to
understand:> just "CONNECT" and off you go.  Given these two
facts, I claim that plain> old AX.25 text streams are and will
continue to be the most popular "mode".I can agree with this
point that the simple "CONNECT and go" user (POATS user)is, and
will be the major user type in the packet network for a long
time to come.I would just like to point out that the ROSE X.25
Switch software supports "POATS" users simply by appearing to
the user as a pairof digipeaters.  There's no extra user
hardware or software to buy/install/configure/hassle-with to use
a ROSE X.25 network.  In fact, the ROSE X.25 Switch will route
you through the network withoutthe hassle that the NoNodes put
you through of "connect, connect,connect..connect, voila..the
destination!"  This is somewhat akinto asking a sequence of "n"
telephone operators to route your telephone call...computers do
a better job of this in less time!As far as interoperability
goes, you can call between a NoNodesnetwork and a ROSE X.25
network by simply connecting using thestandard connection method
for either network (C Destination v ...).TCP/IP is no problem to
a ROSE X.25 network either:  just make a level 2 call through a
ROSE X.25 network (like any POATS user)and send your IP
datagrammes through the network...simple!In any case, I'd like
to see more integration of networks, butlet's first realize that
simplicity of a tool (or a network)can often be the most
attractive feature to users.73,Gordon Beattie,
[e-mail]+1.201.615.4168--------------------------
----Date: 20 Apr 90 01:16:22 GMTFrom:
bionet!hayes![e-mail]: KISS Mode -- How Fast?To:
[e-mail]     I have one of the April 90 versions of
NOS running on two differentPC compatibles.  I can't seem to
communicate reliably faster than 4800baud.  One machine is a 12
MHZ 286 with an 8250B.  The other machine is alaptop with a 4.77
MHz 80C88 and I presume the ASIC equivalent of an 8250.Hardwired
connection between the two machines with KISS mode at 4800
baudseems reliable but 9600 baud is very spotty.     Now the
interesting thing is that the 286 machine is known to operateto
at least 38400 with an unsophisticated interrupt routine written
in TurboPascal.  The laptop operates well at 9600 baud with
various terminal emulators.Why is NOS slower and what can I do
about it?  The 8250B in the 286 machineis socketed but there is
little I can do with the laptop, which is probablythe culprit.
Mostly I want to know how fast can I run KISS mode on the
286machine.     The reason I bring this up is that I am working
on a 2 chip packetassembler/disassembler that is good to 1 Mbps
(half-duplex) but I need adecently fast way to interface it to
the host computer.  4800 baud isn'tgood enough.Philip Munts
N7AHLUniversity of Alaska,
Fairbanks------------------------------Date: 21 Apr 90 05:47:43
GMTFrom: ka9q.bellcore.com![e-mail]  (Phil
Karn)Subject: KISS Mode -- How Fast?To: [e-mail]
article <[e-mail]>
[e-mail] writes:>     I have one of the April
90 versions of NOS running on two different>PC compatibles.  I
can't seem to communicate reliably faster than 4800>baud.Fetch
the latest stuff off flash.bellcore.com using anonymous ftp
andgive it a try. If it isn't any better, let me know. I've been
doing somework on the 8250/16550 driver lately that should help
improve performanceand I want to make sure that I haven't
already fixed your problem beforelooking at it
again.Phil------------------------------Date: 20 Apr 90 14:04:33
GMTFrom: rochester!rit!cci632![e-mail]  (David
Hallidy)Subject: Microwave oscillator sourcesTo:
[e-mail] article <[e-mail]>,
[e-mail] (Dave Tiller N2KAU) writes:> > Has anyone
had any experience with converting a microwave oven > magnetron
to Amateur use?  Are there any problems with needing to> 'bend'
it down slightly from 2.450 GHz to make it into the Ham> band?
What are the power requirements?  I noticed that MCM sells>
replacement magnetrons - could this be a source for cheep
packet> backbone oscillators?  Inquiring minds gots'ta
know...Any help> would be greatly appreciated.> > PS - I don't
intend to run one of these at ~600-1200 Watts aimed>      at the
general public.  A couple of Watts (<10) would be more>
resonable.Dave-Check out _RF DESIGN_ for March of 1989, there
was an article aboutusing a microwave oven as a high powered RF
source for 2450 MHzATV. It will work down into the ham band at
the upper end of the"13cm" segment- from 2390 to 2450 MHz.
Problem is, I don't thinkthe stability of the mag will be very
good- this may not be criticalin your application, certainly for
wideband TV experimenting it'sprobably not too important.The
other problem is, you mentioned wanting to run low power- Idon't
think you can with this type of setup. A magnetron, by
itsnature, generates high levels of RF. It's a self excited
device, andif you try to just "lower the voltage" or reduce the
intensity ofthe magnetic field around the tube, it just won't
oscillate. The waythe microwave ovens run at "reduced" power is
to turn the tube onand off for varying periods of time- this has
the effect, on food,of reducing the heating by reducing the
amount of time the food isexposed to the RF. The level of RF
when the mag is running is alwaysat full power (>600 Watts,
usually).I do think it might be worthwhile to experiment with
injection-lockingof the magnetron to stabilize its output
frequency. This would makefor a very cheap source of extremely
high power on the band, useablefor modes other than wideband TV.
Let me know if you try any of thisand any success (or failure)
you may have.Hope this helps you some.73           Dave H.
KD5RO/2------------------------------Date: 20 Apr 90 20:01:56
GMTFrom:
swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!t
urnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.c
om![e-mail]  (Dana H. Myers)Subject: Microwave oscillator
sourcesTo: [e-mail] article <[e-mail]>
[e-mail] (Dave Tiller N2KAU) writes:>>Has anyone
had any experience with converting a microwave oven >magnetron
to Amateur use?  Are there any problems with needing to>'bend'
it down slightly from 2.450 GHz to make it into the Ham>band?
What are the power requirements?  I noticed that MCM
sells>replacement magnetrons - could this be a source for cheep
packet>backbone oscillators?  Inquiring minds gots'ta know...Any
help>would be greatly appreciated.  Look in the 1989 index for
73 magazine - a cover article detailedconversion of a surplus
oven to ATV/FM use, a $200 700W exciter !I'll try to get the
date or possibly someone else can post
it.**************************************************************
**** Dana H. Myers WA6ZGB        | Views expressed here are    ** (213)
337-5136        | mine and do not necessarily    ** [e-mail]        |
reflect those of my
employer    ********************************************************
**********------------------------------Date: 21 Apr 90 02:15:45
GMTFrom: usc!pollux.usc.edu![e-mail]  (Kenneth J.
Hendrickson)Subject: Microwave oscillator sourcesTo:
[e-mail] article <[e-mail]>
[e-mail] (Dave Tiller N2KAU) writes:>Has anyone had
any experience with converting a microwave oven >magnetron to
Amateur use?It's already been done.  Somebody in Illinois did it
on ATV.  There wasa skimpy write-up about it in one of the RF
trade rags about Fall of'88.  I can't remember which magazine,
but I think it might have been"RF & Microwaves".  Don't waste
your time looking for the magazine,however, there wasn't any
more information in it than I have postedhere.  It was kind of
like the ARRL's current publication of microwaveinformation in
QST.Ken Hendrickson N8DGN/6      [e-mail]
...!uunet!usc!pollux!kjh------------------------------Date: 20
Apr 90 02:34:52 GMTFrom:
usc!cs.utexas.edu!execu!sequoia!attdso!ssc![e-mail]  (Tad
Cook)Subject: USENET at Dayton HamventionTo:
[e-mail] ONE more reminder. . . .If you are
going to the Dayton Hamvention,USENET folks will be getting
together at Stouffers on Friday night insuite 425, at the
DIGITAL SUITE.  Stouffers is downtown at Fifth andJefferson.See
you there!Tad CookSeattle, WAPacket: KT7H @
N7HFZ.WA.USA.NAPhone: 206/527-4089 MCI Mail: 3288544 Telex:
6503288544 MCI UW  USENET:...uw-beaver!sumax!amc-gw!ssc!tador,
[e-mail]------------------------------End of Packet-Radio
Digest******************************Date: Sun, 22 Apr 90
04:00:02 PDTFrom: Packet-Radio Mailing List and Newsgroup
<[e-mail]>Reply-To: [e-mail]:
Packet-Radio Digest V1 #4To: packet-radioPacket-Radio Digest
    Sun, 22 Apr 90       Volume 90 : Issue   4Today's Topics:
                  Innovators need thick skin
Microwave oscillator sources                      Packet-Radio
Digest V1 #3Send Replies or notes for publication to:
<[e-mail]>Send requests of an administrative nature
(addition to, deletion from thedistribution list, et al) to:
<[e-mail]>Archives of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".Digest files are named
Vv.n where v=volume and n=number in volume.Digests will be
issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET
PEOPLE: UCSD.EDU is an internet site.  TheInternet-to-BITNET
mail gateway systems would prefer that you insteadadd yourself
to a BITNET redistribution of this list; you may addyourself to
the list by sending the following command:      SUBSCRIBE
I-PACRAD your full nameto LISTSERV@UIUCVMD.  You can send that
in an interactive if your systemsupports them (e.g. the CMS TELL
command), or in the body of a mail message(*not* the subject
line).Please note:  Although you'll be receiving Packet-Radio
mailing from thenetwork address I-PACRAD@UIUCVMD,
[e-mail] the source.  Any contributions from you
should be sent to UCSD.The mailing list is in the form of a
digest.  It is not edited, justa convenient envelope for
multiple messages to reduce netmail load.If your mail reader
does not have an "undigestify" option, contactKeith Petersen
W8SDZ  <[e-mail]> and he'll sendyou
C-language source for one.73,    -
Brian        ([e-mail])------------------------------------------
----------------------------Date: 21 Apr 90 22:42:34 GMTFrom:
sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!k
d4nc![e-mail]  (Gary Coffman)Subject: Innovators need
thick skinTo: [e-mail] article
<[e-mail]> [e-mail] (Phil R.
Karn) writes:>>But be that as it may, you are getting somewhat
closer to the truth. As>I said before, TCP/IP has little to
offer unless you have a computer.WORDS TO LIVE BY! I would also
add that packet in general has little tooffer unless you have a
computer. Contentless keyboard QSOs crawlingthrough the network
have little value after the thrill of doing it oncewears off.The
real value of packet radio is connecting computers together in
anetwork to perform a useful function. Things like Email, Remote
FileSharing, and distributed computing are possible only with
reliableend to end data transfer. Our current slow network
already carriesan important amount of Email. MUCH faster
networks will make the other things realistic. And there's the
rub, little Terminal Node Controllersaren't capable of
supporting faster modems. In fact, TERMINAL NodeController is a
concept whose time is past. It's time to return tothe PAD
(Packet Assembler Disassembler) now that it is a single
chip(8530) in the computer and attach that to a truly high speed
modem.High speed modems are available and affordable NOW at 56kb
and soonat megabit rates. LET'S NOT FALL INTO THE TRAP OF
HITCHING OURSELVES TO THE DEAD PASTWITH A NETWORK DESIGN THAT
CANNOT EASILY MIGRATE TOWARD OUR ULTIMATEGOALS.Gary
KE4ZV------------------------------Date: 20 Apr 90 00:27:03
GMTFrom:
snorkelwacker!bu.edu!mirror!otto!jimi!unsvax![e-mail]
(Mike Storke (N7MSD))Subject: Microwave oscillator sourcesTo:
[e-mail]  I'd also be very interested in knowing if
you can convert a microwave ovenmagnetron to amateur bands.
Unlike the guy who originated this, I *WOULD* useit at or near
it's full rated power.  This would be used for long-haul
packetlinks (~200+ miles, to be exact: Las Vegas-Bishop,
California-Reno; a 2M linkcurrently exists along this route, but
it's too loaded down).  Any info wouldbe appreciated.  Note that
these links are all on top of mountains > 8500 ft.high.  Thanks
and 73's, Mike, N7MSDP.S. I got a hold of a surplus house that
has traveling wave tubes for 2-4 gigsand 8-9.6 gigs.  Can the
8-9.6 be used at the 10 gig ham band?  A friend ofmine said no
because they are *very hard* to tune-he says they're
somethinglike a helical antenna at their center frequency.  Any
info appreciated asalways,
Mike------------------------------Date: Sat, 21 Apr 90 22:31
ESTFrom: LARRY KNEHR <[e-mail]>Subject:
Packet-Radio Digest V1 #3To:
[e-mail]------------------------------End of
Packet-Radio Digest******************************Date: Mon, 23
Apr 90 04:00:02 PDTFrom: Packet-Radio Mailing List and Newsgroup
<[e-mail]>Reply-To: [e-mail]:
Packet-Radio Digest V1 #5To: packet-radioPacket-Radio Digest
    Mon, 23 Apr 90       Volume 90 : Issue   5Today's Topics:
             Has NOS been ported to the Atari ST?
         TAPR TNC-2 for saleSend Replies or notes for
publication to: <[e-mail]>Send requests of an
administrative nature (addition to, deletion from
thedistribution list, et al) to:
<[e-mail]>Archives of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".Digest files are named
Vv.n where v=volume and n=number in volume.Digests will be
issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET
PEOPLE: UCSD.EDU is an internet site.  TheInternet-to-BITNET
mail gateway systems would prefer that you insteadadd yourself
to a BITNET redistribution of this list; you may addyourself to
the list by sending the following command:      SUBSCRIBE
I-PACRAD your full nameto LISTSERV@UIUCVMD.  You can send that
in an interactive if your systemsupports them (e.g. the CMS TELL
command), or in the body of a mail message(*not* the subject
line).Please note:  Although you'll be receiving Packet-Radio
mailing from thenetwork address I-PACRAD@UIUCVMD,
[e-mail] the source.  Any contributions from you
should be sent to UCSD.The mailing list is in the form of a
digest.  It is not edited, justa convenient envelope for
multiple messages to reduce netmail load.If your mail reader
does not have an "undigestify" option, contactKeith Petersen
W8SDZ  <[e-mail]> and he'll sendyou
C-language source for one.73,    -
Brian        ([e-mail])------------------------------------------
----------------------------Date: 23 Apr 90 01:34:39 GMTFrom:
swrinde!zaphod.mps.ohio-state.edu!samsung!umich!pmsmam!pmsmam.uuc
p![e-mail]  (Bill Meahan)Subject: Has NOS been ported to the
Atari ST?To: [e-mail] subject line says it
all.If not, why not?  Micro-RTX could easily provide the
requisite multi-taskingkernel if the one that's included in the
NOS source isn't suitable.We ST users wait with bated breath!
(especially we who still have older520's :-)  :-} )-- Bill
Meahan            |  UUCP: uunet!mailrus!umich!pmsmam!wwm                | snail: 128
Factory St., Ypsilanti, MI 48197#include <disclaimer.std>    |
voice: [phone]/* witty */            |packet: wa8tzg @
wa8ooh.mi.usa.na------------------------------Date: 22 Apr 90
06:54:54 GMTFrom: sumax!ole![e-mail]  (Ray
Berry)Subject: TAPR TNC-2 for saleTo: [e-mail]    I
have a TAPR TNC-2 built from a kit several yrs back I'd like
tosell.  It was built and tested, aligned, etc., but never used.
 The firmwareis at whatever level existed at the time the TNC-2
first shipped.     I'd like $100 for this thing.  I've never been
active in packet,so I don't know if this thing is already
obsolete or what... if the price sounds too high, please make an
offer.  Thanks.-- Ray Berry  kb7ht  uucp: ...ole!ray CIS:
73407,3152 /* "inquire within" */Seattle Silicon Corp. 3075
112th Ave NE. Bellevue WA 98004 (206)
828-4422------------------------------End of Packet-Radio
Digest******************************Date: Tue, 24 Apr 90
04:00:06 PDTFrom: Packet-Radio Mailing List and Newsgroup
<[e-mail]>Reply-To: [e-mail]:
Packet-Radio Digest V1 #6To: packet-radioPacket-Radio Digest
    Tue, 24 Apr 90       Volume 90 : Issue   6Today's Topics:
          Apple II Software for RTTY and Facsimile ?
               faster modems                          Getting
Started!?                        MFJ 1274 TNC for sale
            pulse on X-band (2 msgs)Send Replies or notes for
publication to: <[e-mail]>Send requests of an
administrative nature (addition to, deletion from
thedistribution list, et al) to:
<[e-mail]>Archives of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".Digest files are named
Vv.n where v=volume and n=number in volume.Digests will be
issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET
PEOPLE: UCSD.EDU is an internet site.  TheInternet-to-BITNET
mail gateway systems would prefer that you insteadadd yourself
to a BITNET redistribution of this list; you may addyourself to
the list by sending the following command:      SUBSCRIBE
I-PACRAD your full nameto LISTSERV@UIUCVMD.  You can send that
in an interactive if your systemsupports them (e.g. the CMS TELL
command), or in the body of a mail message(*not* the subject
line).Please note:  Although you'll be receiving Packet-Radio
mailing from thenetwork address I-PACRAD@UIUCVMD,
[e-mail] the source.  Any contributions from you
should be sent to UCSD.The mailing list is in the form of a
digest.  It is not edited, justa convenient envelope for
multiple messages to reduce netmail load.If your mail reader
does not have an "undigestify" option, contactKeith Petersen
W8SDZ  <[e-mail]> and he'll sendyou
C-language source for one.73,    -
Brian        ([e-mail])------------------------------------------
----------------------------Date: 23 Apr 90 15:29:50 GMTFrom:
ncs.dnd.ca!asterix.drev.dnd.ca![e-mail]  (Louis
Demers)Subject: Apple II Software for RTTY and Facsimile ?To:
[e-mail](I am posting this for a collegue, hope
this is the right place)A friend is looking for software for his
Apple II+ to receiveFacsimile (he already has the interface to
his radio) for exampleof wheather maps.  He would like also a
piece of software that implements the RTTY protocol.If software
is unavailable, we would settle for the algorytms.Please respond
through Email as this site doesn't receive any of therec.
groups.PPS: Please don't laugh, this is all foreign to me.-- |
Louis Demers              | DREV, Defence Research
Establishment,Valcartier || [e-mail] | POBox
8800, Courcelette,Quebec, CANADA, G0A 1R0 ||
(131.132.48.2) | Office: [phone]       fax [phone]
|+---------------------------+-----------------------------------
--------------+------------------------------Date: Mon, 23 Apr
90 14:34:34 MSTFrom: [e-mail] (Marc
Sarrel)Subject: faster modemsTo: [e-mail],
there has been some discussion recently here about how most
hamswith TNCs are using horribly outdated and slow equipment.
1200 baudseems to be the lowest common denominator.  And,
sometimes I get thefeeling that some hams don't have much desire
or incentive to move tohigher baud rates.  In fact, I spent a
while talking to the "packetexpert" at a local amateur radio
store recently.  I asked him aboutsome TNC that had a 2400 baud
modem vs one that had a 1200 baud modem.I asked wether 2400
would catch on, given my experience with land linemodems where
everyone was starved for speed.  He said "no."  Hisreasons
seemed pretty fuzzy to me, but he seemed to claim that 1)
2400baud wouldn't catch on because everyone already has 1200
baud modems,2) 1200 baud seemed fast enough to him, and 3) that
2400 baud wasn't_really_ twice as fast as 1200 because the extra
speed was usedinefficiently.  (But don't hold me to that, this
was a while ago.)Anyway, my question is this:  How can we "hams
in the know" encouragethe use of faster and more effecient
modems on the airwaves, giventhat we agree that "faster is
better."  One of this guy's argumentsholds weight in that there
is a lot of "hardware inertia" out there.Specifically what kind
of faster and more efficient modems areavailable and suitable
for packet-radio?  How fast is fast?  9600?19.2K? 56K?  How much
extra bandwidth do these faster modems require?What about FCC
regulations on speed?Is there such a thing as auto baud rate
recognition that would allow adigipeater to work a several
different speeds with different stationson the same frequency?
This would allow a smoother transition tofaster modems by giving
people incentive to buy them withoutimmediately obsoleting
everyone's 1200 baud equipment?Would it be a good idea to set up
digipeaters that work on severaldifferent speeds (and
frequencies) as a way of encouraging higher baudrates?Just
curious,--marc-=-Marc A.
[e-mail]    |   "Oh,
_lightweight_
Alpaca..."..!sun!sunburn!miranda!sarrel        |        -Blanche
DuBois------------------------------Date: 23 Apr 90 08:32:11
GMTFrom: usc!sdsu!crash![e-mail]  (Jim Burnes)Subject:
Getting Started!?To: [e-mail]!A friend of mine
and I want to get into packet radio.  We are not hams.We are
willing to jump through the necessary hoops.  We both are
software/hardware engineers and understand various amounts of
circuit theory.We would like to know:  1.  What is the highest
speed modem usable on standard packet frequen-      cies?  I
have heard of 9600 bps modems being used.  What about
Telebit Trailblazer spread-spectrum type modems?  2.   What
class of ham liscense is necessary to run packet?  What tests
  and theory must we have to get this liscense?  3.  How much
would a rig capable of 2400 bps operation cost (used)?      I
already have a 386 machine.  I would like to upgrade to
national/      international coverage (if that is applicable)
and also to higher      speeds.    4.  I have heard that you
cant upload messages/files to someones node      and then have
that information automatically forwarded through      a network.
 Someone told me humans had to intervene.  That sounded
silly.  Kinda defeats the whole purpose of a network, no?
Sorry..      since I'm mostly a pc hacker I not quite sure how
to ask a lot of      questions without sounding naive.  5.  What
is a good book to get started with?  6.  It seems like I have
been trying to get into packet/ham for the last      5 years or
so and always fail to clear the morse/test hurdles. I'd
like to remedy this as soon as possible.  Any ideas for making
the       transition easier?Yours in communications,Jim
Burnes-------------------I do not beleive in 'ismsI think, on
the whole, 'isms are a bad thingFerris Buehler
(paraphrased)--------------------------------------------------Da
te: 24 Apr 90 00:53:37 GMTFrom: psuvm![e-mail]
(Michael L. Sensor)Subject: MFJ 1274 TNC for saleTo:
[e-mail] sale once again:MFJ 1247 HF/VHF TNC.
Almost never used (yes it works).LED tuning display. Compatible
with MFJ WeFAX software (for PCs andMacintoshes).  Personal
mailbox.Comes with 5-lead RS232 cable and homebrew connector to
use on Icom IC2AT.Bought for $150.00 at Dayton.  Asking $125.00.
May trade or bargain.For more info:Mike Sensor KD3LR / AFA1UPBox
134 Oak HallPenn State Altoona CampusAltoona PA 16601-3760(814)
949-5439UNTIL MAY 4!2406 E 32 StErie PA 16510-2702(814)
899-8261AFTER MAY 4!C'mon, MFJ isn't *that* bad!Mike Sensor
MLS129 @ PSUVM------------------------------Date: 24 Apr 90
01:28:17 GMTFrom: usc!pollux.usc.edu![e-mail]  (Kenneth J.
Hendrickson)Subject: pulse on X-bandTo: [e-mail]
received some email from W3OTC that I responded to, and thought
aposting would be appropriate.  Here it is:% From: Robert
Carpenter <[e-mail]>% Am I missing
something?  It seemed to me that you wouldn't benefit from a%
low duty cycle when fighting a large path loss.   I would think
that some% synchronous system, with correlation detection of
some sort, would be the% best bet.  Of course you COULD build a
receiver that just listened during% the narrow pulses to ignore
the in-between noise.  I'd also worry a bit% about
pulse-spreading due to multipath.  Maybe a pseudo-random scheme
would% be a good approach, but would likely have a mid-to-high
duty cycle, and thus% not be pulse.It is a possibility to build
a receiver that only listens when a pulseis supposed to occur,
but that wasn't necessarily what I was thinkingabout.  The
advantage of using the high peak power of a pulse is that
itwould be EASILY DETECTABLE even with high path loss.  This
means that(in theory) you could set up a data link much like CW
is used with thehuman ear: the presence of a pulse has one
meaning, and the absence of apulse has another.  There is
probably even a better way to do it:consider what you could do
if you were to phase modulate the pulses.  Inother words,
control the time delay or latency between pulses.  A shorttime
delay could mean a 0 bit, and a long delay could mean a 1 bit.%
Or do you have a good source of low duty cycle 10 GHz power, and
want to% build a system around it?No, I don't have a 10 GHz
pulse source, but they are available.  Now ifwe could only use
them legally ...% Pardon the confused questions, but I don't
normally think of low-duty-cycle% pulse transmission and weak
signal operation as going together.Most people don't.
Certainly, I'm not suggesting that real timecommunications like
voice be sent this way.  I'm merely proposing thatthis might be
a good use for part of our microwave spectrum.  The packetguys
are in great need of high-speed inter-city links (among
otherthings).% Bob  W3OTC% PS. Look at the picture of the 10 GHz
SSB PHONE station in QST (I thought in% W3XO's column, but can't
find it.) I've seen and heard '3XO's video of it% operating over
a non-line-of-sight 25 mile path with excellent sigs.% The power
output was in the 20 - 100 mW range, I think.I've done better
than 40 miles over non-line-of-sight paths with only10 mW and
CRUDDY WIDEBAND FM!  This was with 2 foot dish antennas onboth
ends of the path at X-band.  Still, I'm not pooh-poohing
theirefforts; I'm just trying to show that even with simple
cheap equipmentyou can do a lot more than most people expect in
the SHF and EHFspectrum.Ken Hendrickson N8DGN/6      [e-mail]
     ...!uunet!usc!pollux!kjh------------------------------Date:
24 Apr 90 01:41:49 GMTFrom: usc!pollux.usc.edu![e-mail]
(Kenneth J. Hendrickson)Subject: pulse on X-bandTo:
[e-mail] article <[e-mail]>
[e-mail] (Glenn Elmore) writes:% Ken,%   I don't
think pulse privileges really are that much of an issue in%
preventing effective use of the band. As I see it, the main
advantage would be% in using surplus hardware.Yes, this would be
the advantage.  I'm not suggesting that we have anundue hardship
with the pulse restriction; I am suggesting that it isarbitrary
and capricious, and that if we didn't have the restriction,there
would be one more possible way that we could
effectivelycommunicate on the band.% However, moderate power
narrowband % equipment is no longer a difficult proposition.
Very long links and% OTH links require optimum use of the
resources; reasonably efficient% use of the spectrum (bps/Hz
numbers) and highly directional beams to% avoid waste and QRM;
as well as physically larger receive antenna apertures% to
recover the information. Even so I suspect that for reliable
networks and % comm.  channels we are likely to end up with a
larger number of shorter LOS % links instead of long haul OTH
ones.This may be true.  However, I don't think anybody has ever
experimentedwith using high-power low-duty-cycle signals to
build a packet switchedmicrowave network.  My idea might not pan
out to anything, but on theother hand, how will we know unless
somebody tries to do it?% Troposcatter is a fairly predictable %
propagation mechanism at 10 GHz (see my description of an%
experience with it on a 400+ mile path during the 1987 10 GHz
terrestrial % DX record outing in December 1987 QST) but long
haul links are inherently% lossier and less reliable than
shorter LOS ones.%   I strongly agree that we need to use our
microwave resources and in% particular 10 GHz but I think we
will end up finding that  for efficient% use of our amateur
resources we will start looking more like the telephone%
companies and common carrier folks when we solve the backbone
problem.% % Glenn Elmore -N6GN- N6GN @ K3MC
[e-mail] [e-mail] Sure, we might wind up
looking like the telephone companies.  Maybe theyhave already
tried the pulse idea.  On the other hand, I have neverheard of
it.  If nobody has yet tried it, to see what the results
are,what is wrong with us amateurs giving it a try.  It just
might beuseful.Ken Hendrickson N8DGN/6      [e-mail]
...!uunet!usc!pollux!kjh------------------------------End of
Packet-Radio Digest******************************Date: Thu, 26
Apr 90 08:27:52 PDTFrom: Packet-Radio Mailing List and Newsgroup
<[e-mail]>Reply-To: [e-mail]:
Packet-Radio Digest V1 #9To: packet-radioPacket-Radio Digest
    Thu, 26 Apr 90       Volume 90 : Issue   9Today's Topics:
                         DEC Rainbow
DOVE Satellite                            faster modems
           How decipher DOVE telemetry?
TAPR DCD on Heath 4040                       US Navy and packet
radioSend Replies or notes for publication to:
<[e-mail]>Send requests of an administrative nature
(addition to, deletion from thedistribution list, et al) to:
<[e-mail]>Archives of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".Digest files are named
Vv.n where v=volume and n=number in volume.Digests will be
issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET
PEOPLE: UCSD.EDU is an internet site.  TheInternet-to-BITNET
mail gateway systems would prefer that you insteadadd yourself
to a BITNET redistribution of this list; you may addyourself to
the list by sending the following command:      SUBSCRIBE
I-PACRAD your full nameto LISTSERV@UIUCVMD.  You can send that
in an interactive if your systemsupports them (e.g. the CMS TELL
command), or in the body of a mail message(*not* the subject
line).Please note:  Although you'll be receiving Packet-Radio
mailing from thenetwork address I-PACRAD@UIUCVMD,
[e-mail] the source.  Any contributions from you
should be sent to UCSD.The mailing list is in the form of a
digest.  It is not edited, justa convenient envelope for
multiple messages to reduce netmail load.If your mail reader
does not have an "undigestify" option, contactKeith Petersen
W8SDZ  <[e-mail]> and he'll sendyou
C-language source for one.73,    -
Brian        ([e-mail])------------------------------------------
----------------------------Date: 25 Apr 90 19:53:26 GMTFrom:
swrinde!cs.utexas.edu!samsung!xylogics!bu.edu!m2c!wpi!tmurphy@ucs
d.edu  (Tom [Chris] Murphy)Subject: DEC RainbowTo:
[e-mail] any luck, I'll be getting a Technician
licence this weekend andas soon as it comes in the mail, I plan
on trying some work with packetradio.  I may be inheriting a DEC
Rainbow, and was wondering what softwareexists for it to do TCP
based work, primarily mail although telnet andftp would be nice
also.  Thanks for the help in advance!Tom
[e-mail]------------------------------Date: 25
Apr 90 15:06:01 GMTFrom: idacrd![e-mail]  (Robert
McGwier)Subject: DOVE SatelliteTo: [e-mail]
article <[e-mail]>, by
[e-mail]:> I have been monitoring for DOVE for a
coupla days, and haven't heard a peep.>Kevin:It is alive and
well downlinking on 2401.100 Mhz +/- an unbelievable amountof
doppler.  There is no way the straight calculation can be as
impressiveas trying to track that stuff and copy data!  I am
reloading its softwareand its gonna do speech when it comes back
on.Bob --
_________________________________________________________________
___________    My opinions are my own no matter    |    Robert W.
McGwier, N4HY    who I work for! ;-)            |    CCR, AMSAT,
etc.-------------------------------------------------------------
---------------------------------------------Date: 26 Apr 90
02:10:11 GMTFrom:
sun-barr!newstop!texsun!texbell!splut![e-mail]  (Jay "you
ignorant splut!" Maynard)Subject: faster modemsTo:
[e-mail] article <[e-mail]>
[e-mail] (Phil Karn) writes:>I have done a *lot*
of thinking about this problem. Given that amateur radio>is a
voluntary, personally funded activity, you can't force hams to
buy new>hardware. But there's another approach: establishing a
frequency allocation>policy that encourages the use of more
efficient modulation and frequency>reuse techniques. The more
efficient your proposed use of the spectrum, the>more likely you
are to get an allocation.>Amateur frequency coordinators now
follow a first-come first-served policy,>and this *must* change.
In many areas like Los Angeles and New York, the>VHF/UHF bands
are nearly full with FM repeaters and conventional 1200
baud>packet, and there is little room to experiment with newer,
more efficient>techniques.(dig, dig...ok, I found it.) [putting
on President, Texas VHF-FM Society hat]You've beat this drum
before, and I've argued it before. While your ideahas merit in a
perfect society, it *cannot* work in the real ham
world.Frequency coordinators now serve in an advisory capacity.
You'd like usto tell people who have coordinations and are
currently operatingrepeaters on frequencies where they do not
experience regular,significant interference (the standard which
coordinators try tomaintain) that, all of a sudden, the rules
have changed, and that theymust either shut down entirely, or
accept unheard-of, and previouslyunacceptable, levels of
interference.They wouldn't listen to us.Instead, they'd keep on
operating on what they perceive as *their*frequency. You know
that they don't own it, I know it, but they don't -and they're
the only ones with the power to make such a change
work.Frequency coordination and spectrum management isn't just a
technicalproblem, but a highly political one as well. Come up
with a way toaccomplish your goal that *can* be accepted by the
population of currentFM voice system operators and users, and
your wish will come true, andI'll sign up to promote it. This
isn't the school debate society,though, where changes can be
implemented by fiat. You must account forthe mechanisms involved
in implementing the change, and _that_ is whereyour problem
lies.-- Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to
malice that which [e-mail]       (eieio)|
adequately be explained by stupidity.attctc, RIP. It was nice
knowing ya +----------------------------------------  "Flying is
a lot more fun than being in the Senate." -- Senator Jake
Garn------------------------------Date: 25 Apr 90 22:20:31
GMTFrom: deimos.cis.ksu.edu!harris.cis.ksu.edu![e-mail]
(Myron A. Calhoun)Subject: How decipher DOVE telemetry?To:
[e-mail] packet station can hear DOVE's
telemetry;now I'd like to know what it means.Is there a source
for software to decipher thehex stuff into meaningful-to-humans
information?Please reply by email.--Myron.--# Myron A. Calhoun,
Ph.D. E.E.; Associate Professor   [phone] home# INTERNET:
[e-mail]   (129.130.10.2)         532-6350 work#
UUCP: ...{rutgers, texbell}!ksuvax1!harry!mac
532-7004 fax# AT&T Mail:
attmail!ksuvax1!mac------------------------------Date: 25 Apr 90
20:27:41 GMTFrom:
sdd.hp.com!zaphod.mps.ohio-state.edu!sunybcs!uhura.cc.rochester.e
du!rochester!kodak!eastman!hpcore![e-mail]  (Paul
Gerwitz)Subject: TAPR DCD on Heath 4040To:
[e-mail] am posting this for someone who does not
have net access.  Please sendemail replies to him directly at
'uunet!atexnet!kodak!eastman!dieter'.----------------------------
-------------------------------------------Subject: HELP w/ TAPR
DCD Upgrade I recently built a TAPR 2211 DCD upgrade kit. It is
supposed to enhance DCDoperation. After installing the kit in my
Heath HD-4040, the DCD light in fact does seemto react much
better (less falsing, more constant when it does lock on).
Theonly problem is now my TNC will TRANSMIT EVEN WHEN THE DCD
LIGHT IS ON !!!! Ihave checked the assembly and the value of
most of the components. I cannotimagine how the thing can
transmit with the DCD light on. It's supposed toinhibit transmit
isn't it ? If anybody has any experience with this PLEASEHELP
!!! Leave a message, or call Mark at [phone]. Thanks
-----------------------------------------------------------------
---------
+----------------------------------------------------------------
------------+ | Paul F Gerwitz  WA2WPI  | SMTP:
[e-mail]                          | | Eastman Kodak Co
      | UUCP: ..rutgers!rochester!kodak!eastman!gerwitz  |
+----------------------------------------------------------------
------------+------------------------------Date: 25 Apr 90
16:08:00 EDTFrom: "SWEIGERT, DAVID"
<[e-mail]>Subject: US Navy and packet
radioTo: "packet-radio" <[e-mail]>
The U.S. Navy has commissioned a multi-media test of
ship-shoredata communications.  Particular media under test:    o
HF communications    o  Fleet SATCOM (2400 bit/second US Navy
satellites)    o  INMARSAT Commercial satellite channels  It is
believed the HF communications portion shall include a packet
radiotest.  SPAWAR Code PMW-156 (Capt. Joesph Price, USN) is
coordinating the testat the direction of VADM Jerry O. Tuttle,
USN, OPNAV Code 094.  The testingagent shall be the Naval
Engineering Center at Vallejo, CA.  The test platformsshall be
ships assigned out of San Diego, CA.  The test is lated to
beginthis summer.  Mission support data shall be transferred
from an aircraft carrier to shorebased NARDAC, Naval Regional
Data Automation
Center.cheers...WB9VKO------------------------------End of
Packet-Radio Digest******************************Date: Fri, 27
Apr 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup
<[e-mail]>Reply-To: [e-mail]:
Packet-Radio Digest V1 #10To: packet-radioPacket-Radio Digest
     Fri, 27 Apr 90       Volume 90 : Issue  10Today's Topics:
                 Ham Packet BBS on ATT UNIX PC?
      Universal M-610 wantedSend Replies or notes for
publication to: <[e-mail]>Send requests of an
administrative nature (addition to, deletion from
thedistribution list, et al) to:
<[e-mail]>Archives of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".Digest files are named
Vv.n where v=volume and n=number in volume.Digests will be
issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET
PEOPLE: UCSD.EDU is an internet site.  TheInternet-to-BITNET
mail gateway systems would prefer that you insteadadd yourself
to a BITNET redistribution of this list; you may addyourself to
the list by sending the following command:      SUBSCRIBE
I-PACRAD your full nameto LISTSERV@UIUCVMD.  You can send that
in an interactive if your systemsupports them (e.g. the CMS TELL
command), or in the body of a mail message(*not* the subject
line).Please note:  Although you'll be receiving Packet-Radio
mailing from thenetwork address I-PACRAD@UIUCVMD,
[e-mail] the source.  Any contributions from you
should be sent to UCSD.The mailing list is in the form of a
digest.  It is not edited, justa convenient envelope for
multiple messages to reduce netmail load.If your mail reader
does not have an "undigestify" option, contactKeith Petersen
W8SDZ  <[e-mail]> and he'll sendyou
C-language source for one.73,    -
Brian        ([e-mail])------------------------------------------
----------------------------Date: 27 Apr 90 02:31:18 GMTFrom:
zaphod.mps.ohio-state.edu!math.lsa.umich.edu!sharkey!lopez!flash@
tut.cis.ohio-state.edu  (Gary Bourgois)Subject: Ham Packet BBS
on ATT UNIX PC?To: [e-mail]'s the deal.  I am
the system administrator of a Public Access Unix BBS, and have
been running a BBS at the same phone number since 1983.  Being a
consultant by trade, and doing all of my work at home, I can run
the BBS, and also play ham radio day and night.  I have a
speaker from the ham rig in my computer room, and I have a video
feed from the BBS monitor in my ham shack.  The two hobbies sort
of meld.  I talk with other UNIX people on the ham bands, and
send email to ham friends on USENET.I am obsessive compulsive, I
admit it and I use it to an advantage.I do not have a packet
system.  Not today.  I always managed to put it off.The PBBS
that serves this area of Upper Michigan is going to be going
down soon.  They are looking for someone else to run one.A ham
from Lower Michigan said he would donate a TNC.  I agreed to
supply what equipment I can, and am mulling over what is the
best way to go.  I have an old XTAL type 2m rig and a spare
antenna to kick into the project.I also have an AT&T UNIX PC
with a 20 meg hard drive.  Not much, but probably enough to run
a PBBS.Why the UNIX PC? (also known as a 7300, or 3b1)Well I got
to thinking how easy it would be, while reading rec.ham.radio on
the console of the landline BBS, I could forward articles to the
Packet BBS with ease, using UUCP.Has anyone ever done this?Would
the 3b1 be up to the job?  If so, I will also donate that to the
project.  It would be a great service to the hams of Northern
Michigan to have selected articles from USENET ported over to
our local PBBS.  I will not do it if I have to haul floppies up
a flight of stairs (The USENET site is on the ground floor, and
my hamshack is one floor up)..  BUT using UUCP would be a
breeze.Our own BBS software on lopez is locally written, so I
can have any mods I want tossed in simply, and many I can write
myself (The software STARBASE, is very configurable, and will
eventually be made public)...The trick will be to link
everything together.  I am sure it could be done with a XENIX
type PC, but that route is beyond our meager budget.Any ideas,
thoughts, ponderings, musings, experiences welcome.Thanks, es
73Gary-- == 14.313 == Amateur Radio Forum Saturday 11:00AM
Eastern time == 14.313 ====  Gary Bourgois flash@lopez
(rutgers!sharkey!lopez!flash)  GWN UPLink  ====  3.950
Nationwide Amateur Radio Nightly after 0200z=Learning Channel
================= WB8EOH = The Eccentric Old Hippie = WB8EOH
================------------------------------Date: 26 Apr 90
13:50:56 GMTFrom:
portal!cup.portal.com![e-mail]: Universal
M-610 wantedTo: [e-mail] - the Universal
M-610 tuning scope and M-605 FDM box.             Please Email
me at Portal or call me at [phone]
       Lee   G8LCK------------------------------End of
Packet-Radio Digest******************************Date: Sat, 28
Apr 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup
<[e-mail]>Reply-To: [e-mail]:
Packet-Radio Digest V1 #11To: packet-radioPacket-Radio Digest
     Sat, 28 Apr 90       Volume 90 : Issue  11Today's Topics:
                         faster modems                    Ham
Packet BBS on ATT UNIX PC?                            Hams in
space?                             MFJ TNC sold
            Networking                      SAREX STS-35 space
shuttle                      shareware in packet radio
                    TeletextSend Replies or notes for
publication to: <[e-mail]>Send requests of an
administrative nature (addition to, deletion from
thedistribution list, et al) to:
<[e-mail]>Archives of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".Digest files are named
Vv.n where v=volume and n=number in volume.Digests will be
issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET
PEOPLE: UCSD.EDU is an internet site.  TheInternet-to-BITNET
mail gateway systems would prefer that you insteadadd yourself
to a BITNET redistribution of this list; you may addyourself to
the list by sending the following command:      SUBSCRIBE
I-PACRAD your full nameto LISTSERV@UIUCVMD.  You can send that
in an interactive if your systemsupports them (e.g. the CMS TELL
command), or in the body of a mail message(*not* the subject
line).Please note:  Although you'll be receiving Packet-Radio
mailing from thenetwork address I-PACRAD@UIUCVMD,
[e-mail] the source.  Any contributions from you
should be sent to UCSD.The mailing list is in the form of a
digest.  It is not edited, justa convenient envelope for
multiple messages to reduce netmail load.If your mail reader
does not have an "undigestify" option, contactKeith Petersen
W8SDZ  <[e-mail]> and he'll sendyou
C-language source for one.73,    -
Brian        ([e-mail])------------------------------------------
----------------------------Date: 25 Apr 90 18:57:01 GMTFrom:
vsi1!zorch!tandem![e-mail]  (Kevin J. Rowett)Subject:
faster modemsTo: [e-mail] article
<[e-mail]> [e-mail] (Robert McGwier) writes:>>I
believe that for hams in the US, it must be made into an
appliance.I completely agree Bob!>
                                     We>have also suffered
another set back with the Totally Awesome IO board
             ^^^^^^^^Bob, from the trenches, we don't really
view it as a set back.  Delay*maybe*, but Awesome I/O *is*
happenning! I'm staring at film rightnow ready to go to a board
maker....We do live in Silicon Valley, and getting cards made is
easier thanshopping for a car here.  The PacBell yellow pages
has three entirepages listing people who will make cards..We
realize there's more to getting a product out than just having
cards made, but it K3MC Awesome will happen.>project.  Its
commercial license was never completed and those efforts>have
now fallen through.  THis really sounds worse than it is.   K3MC
(Awesome ) has not died!  Only thearrangements with that
particular commericalizer.>
                Totally Awesome>IO from K3MC/N6RCE, 10
Ghz-megabit stuff from Glen Elmore, TCP-IP from>KA9Q, we have
ALL the technology we need to lead us into 21-st
century.>>BobN6RCE------------------------------Date: 27 Apr 90
21:24:51 GMTFrom: umich!sharkey!cfctech!ttardis![e-mail]
(Ron Wilson)Subject: Ham Packet BBS on ATT UNIX PC?To:
[e-mail] article
<[e-mail]>, [e-mail] (Gary
Bourgois) writes:>A ham from Lower Michigan said he would donate
a TNC.  I agreed to supply >what equipment I can, and am mulling
over what is the best way to go.  I >have an old XTAL type 2m
rig and a spare antenna to kick into the project.>>I also have
an AT&T UNIX PC with a 20 meg hard drive.  Not much, but
>probably enough to run a PBBS.>....>The trick will be to link
everything together.  I am sure it could be >done with a XENIX
type PC, but that route is beyond our meager
budget.>>GaryAnything thing you can do with Xenix on a PC, you
can do with the Unix-PC.A 20 meg disk might be too small - even
a minimal news feed requires a lotof disk space.There is program
written by the people at KA9Q called simply KA9Q.  It isa
program designed to implement protocols like Telnet (a terminal
emulator),FTP (file transfer protocol), and others over packet
radio.KA9Q does work on the Unix-PC.Using the KA9Q program and a
pty driver would enable any Unix system toreceive Telnet and FTP
connections over packet radio (not to mention
SLIP/SLFPconnections from other computers).Because of the pty
driver (psuedo terminal), any Telnet connection would loginto
the Unix system normally (via getty and login) just as through
theperson had called in with a modem.I'm sure other people on
the net can help you with technicalities in settingthis up (I
know nothing about packet radio other than what it is).Good
luck.- Ron------------------------------Date: Fri, 27 Apr 90
07:52:53 PDTFrom:
[e-mail]: Hams in
space?To: [e-mail] recall reading some months ago
that this summer, an astronaut on the SpaceShuttle will be doing
2 meter packet communications with earthlings.When will this
occur? On what frequency? Will it be possible for meto
communicate with them using my BIG 5 watts of power? do i need a
specialantenna or will my rinkydink ones made out of coathangers
do the trick?I expect QRM will be real bad, but the equiptment I
got is what I'm stuckwith ... I yam what I yam.All help
appreciated!                                          --
Kevin+----------------------------------------+  DISCLAIMER: I
assume no: KEVIN M. SAVETZ - KC6GWQ               :
responsibility for any messages: Bitnet:
[e-mail] :  that I post, expressed or: Internet:
  humbolt![e-mail] :  implied. Opinions expressed:
Fishnet:   [e-mail] :  by me are not
necessarily+----------------------------------------+  my own.

-30-------------------------------Date: 27 Apr 90 19:39:24
GMTFrom: psuvm![e-mail]  (Michael L.
Sensor)Subject: MFJ TNC soldTo: [e-mail] MFJ
1274 TNC I advertised here has been sold.Mike Sensor
MLS129@PSUVM------------------------------Date: 26 Apr 90
08:29:49 GMTFrom:
mcsun!ukc!stc!praxis!riemann![e-mail]  (Michael
Chace)Subject: NetworkingTo: [e-mail] All,I'd
like the benefit of people's experiences concerning what to do
whenyour local 2m 1200bps single channel based network begins to
overload.Our local packet network is at breaking point for about
50% of the time.To put the network under a more 'formal' basis
we had a meeting ofall local packeteers with the aim of creating
a group to maintain andenhance the network. Various suggestions
were made on how to solve things,some good, some bad.  Here's a
summary of the network as it stands:-NB - My local area is
Bath/Bristol/Cardiff (S/W England & S Wales)     Total
population ~1 million - Amateurs on packet ~30090% of traffic
sits on 144.650 all 1200bps - Local chats and node traffic.Some
links now exist on 70MHz - mainly for BBS forwarding.There are 2
major nodes on 2m - They are on very high sites running 25W
erpconsequently they hear a lot and lots can hear them.Perhaps a
greater problem is that most routes out of our area are poor
andthey also must talk to well-sited nodes. It not unusual to
have stationstelephoning node sysops because they think the node
is down - when its dueto the node hearing so much that its
squelch is permanently open!Most of the nodes in our area form
backbone links in all directions and theNTS Mailboxes rely on
them heavily.The basic idea is to move the well-sited nodes into
lower 'city' locationskeep them as the user access points and
then tie up these nodes on separatelinks (4m/70cms/23cms). Where
to put the links is a moot point - 4m has a source of cheap PMR
equipment but no bandwidth - 70cms more expensive, morechannels
but it's not a primary band - 23cms expensive but plenty of
wideopen space.What I'd like are your
thoughts/experiences/suggestions etc. Particularlywhy you chose
frequencies/data speed etc.As a final note - one of the things
that I noticed at the meeting and whiletalking to the local
users were :-    1) People need to learn that the packet system
needs to shunt data       fast. It's a serious network that moves
data regardless of what       the data is and how it gets from one
point to another.    2) People don't understand much about
protocols and the NET/ROM           system eg. NOT realising
that KA/NODES are not real nodes and           trying to explain
why p-persist will squeeze a few more % out           of the
network.Thanks for your time &
73,Mike****......................................................
.......................| ARPA   :  [e-mail]
       | Michael Chace            || JANET  :
[e-mail]                   | PraXis Systems
|| UUCP   :  ...!uunet!mcvax!ukc!praxis!mikec     | Manvers
Street           || AMPRNET:  [e-mail]
[44.131.20.3] | Bath,  Avon              || AX.25  :  G6DHU @
G6DHU-2 or G6DHU @ GB7SDN    | BA1 1PX           UK     || Phone
 :  (44) [0]225 444700                   |
   |........

.................................................................
....           ------------------------------Date: 27 Apr 90
16:38:43 GMTFrom: microsoft![e-mail]  (Joseph
HOLMAN)Subject: SAREX STS-35 space shuttleTo:
[e-mail]    i never got any direct replies, so i'll
try again...    is any body out there going to have a way for
use    people up in Seattle (latitude 47 deg.) to connect    to the
SAREX mission ?    i've heard rumors about people having KA-NODEs,
but    i haven't heard from the horses mouth yet...    anybody have
any names or callsigns of people doing/planning        this ????    joe
holman,
ka7ldn    uw-beaver!microsoft!joehol    [e-mail]    206-882-8
921 work------------------------------Date: Fri, 27 Apr 90
13:25:12 MSTFrom: [e-mail] (Marc
Sarrel)Subject: shareware in packet radioTo:
[e-mail] there an FCC policy or other generally
accepted rules regardingputting shareware on packet radio BBS's?
 Is transmitting sharewareconsidered a "business communication"?
 What about freeware?  Justcurious...--marc-=-Marc A.
[e-mail]    |   "Oh,
_lightweight_
Alpaca..."..!sun!sunburn!miranda!sarrel        |        -Blanche DuBoisNSA
fodder:Binary Chemical Weapon domestic disruption munitions FBI
CliffordStoll Soviet detonator fissionable KGB colonel $400
million in goldbullion genetic backsatter Pentagon
nuclear------------------------------Date: 27 Apr 90 15:01:26
GMTFrom: motcid![e-mail]  (Don Froula)Subject:
TeletextTo: [e-mail] anyone have information
about the fate of Teletext services in the US?This is an
information service that provides text and block color
graphicscapability on a home TV receiver equipped with a special
decoder.  The datais embedded in several unused TV lines in the
vertical blanking interval.The data repeats over and over in the
form of a magazine.  The decodersimply grabs pages as they come
by and stores them in a display buffer.The system is very
popular in the UK.Zenith used to offer an embedded decoder on
some of their sets.  Also, DickSmith electronics offered a kit a
few years back.Observations on several local broadcast and cable
channels show considerableactivity in the blanking interval.
Information on current status of Teletext and sources for
decoders wouldbe appreciated.Don
WD9DMP------------------------------End of Packet-Radio
Digest******************************Date: Sun, 29 Apr 90
04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup
<[e-mail]>Reply-To: [e-mail]:
Packet-Radio Digest V1 #12To: packet-radioPacket-Radio Digest
     Sun, 29 Apr 90       Volume 90 : Issue  12Today's Topics:
               AR-2002 scanner remote info wanted
            faster modems                    Ham Packet BBS on
ATT UNIX PC?                  Need help in radio data
communic.Send Replies or notes for publication to:
<[e-mail]>Send requests of an administrative nature
(addition to, deletion from thedistribution list, et al) to:
<[e-mail]>Archives of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".Digest files are named
Vv.n where v=volume and n=number in volume.Digests will be
issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET
PEOPLE: UCSD.EDU is an internet site.  TheInternet-to-BITNET
mail gateway systems would prefer that you insteadadd yourself
to a BITNET redistribution of this list; you may addyourself to
the list by sending the following command:      SUBSCRIBE
I-PACRAD your full nameto LISTSERV@UIUCVMD.  You can send that
in an interactive if your systemsupports them (e.g. the CMS TELL
command), or in the body of a mail message(*not* the subject
line).Please note:  Although you'll be receiving Packet-Radio
mailing from thenetwork address I-PACRAD@UIUCVMD,
[e-mail] the source.  Any contributions from you
should be sent to UCSD.The mailing list is in the form of a
digest.  It is not edited, justa convenient envelope for
multiple messages to reduce netmail load.If your mail reader
does not have an "undigestify" option, contactKeith Petersen
W8SDZ  <[e-mail]> and he'll sendyou
C-language source for one.73,    -
Brian        ([e-mail])------------------------------------------
----------------------------Date: 28 Apr 90 10:38:55 GMTFrom:
eru!luth!sunic!mcsun!hp4nl!dutrun!dutentb![e-mail]
U  (Kees Schot)Subject: AR-2002 scanner remote info wantedTo:
[e-mail]                   !! HELP !!For about one
year I'm looking for information on thecomputer interface of the
AR-2002 communications receiver.If someone has hard- or software
information aboutthis interface (or also about other interesting
aspects ofthis equipment) please send it to me by email to
[e-mail] on paper to:    C.A. Schot,    Grote
Kreek 45,    3079 CC Rotterdam,    The Netherlands.Even the name
and address of the (I thought Japanese)manufacturer of this
scanner can help me.Please, help me, because this is the last
hope for meto get this
information.------------------------------Date: 28 Apr 90
15:56:42 GMTFrom: [e-mail]  (Andrew
Payne)Subject: faster modemsTo: [e-mail] article
<[e-mail]> [e-mail] (Marc
Sarrel) writes:>expert" at a local amateur radio store recently.
 I asked him about>some TNC that had a 2400 baud modem vs one
that had a 1200 baud modem.>I asked wether 2400 would catch on,
given my experience with land line>modems where everyone was
starved for speed.  He said "no."  His>reasons seemed pretty
fuzzy to me, but he seemed to claim that 1) 2400>baud wouldn't
catch on because everyone already has 1200 baud modems,>2) 1200
baud seemed fast enough to him, and 3) that 2400 baud
wasn't>_really_ twice as fast as 1200 because the extra speed
was used>inefficiently.  (But don't hold me to that, this was a
while ago.)>    I also feel that 2400 baud will not catch on, but
my reasoning is much different.  2400 baud is just not that much
of a jump beyond 1200 to make it worth the trouble.  Go for 9600
baud or 56kb (though 4800 baud seemsto be a happy medium for
many because it supposedly works with more radios thanthe higher
speeds).>Anyway, my question is this:  How can we "hams in the
know" encourage>the use of faster and more effecient modems on
the airwaves, given>that we agree that "faster is better."  One
of this guy's arguments>holds weight in that there is a lot of
"hardware inertia" out there.    The first step in taking advantage
of higher speed modems is to usethem on the backbones.  The
backbones are where the heavy traffic is anyway,and there is
little "hardware inertia" involved.  You could run some
strangeI'm-not-compatible-with-anything protocol and modem on
the backbones and it wouldn't really matter.    Many of the UHF
backbone links of the network in Ohio are at 4800baud.  The NEDA
guys have many 4800 baud trunks and are quickly moving for 9600
baud.  Also, on the NEDA network, many of the high-volume users
(DX clusters, BBSs, TCP/IP) are using higher speed uplinks to
the backbone.    There is never going to be an overnight switch
away from 1200 baud.Like MS-DOS, it will dog us for a long, long
time.  Put the high-speed modemsin the places will they will
give maximum benefit and gradually people willmigrate beyond
1200 baud.-- =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
=  =  =  =  =  =  =  =  =  =Andrew C. Payne, N8KEI        UUCP:
...!cornell!batcomputer!payne                          INTERNET:
 [e-mail]------------------------------Date:
28 Apr 90 21:56:00 GMTFrom:
usc!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.
uiuc.edu![e-mail]: Ham Packet BBS on ATT UNIX
PC?To: [e-mail]>There is program written by the
people at KA9Q called simply KA9Q.Gee, Phil, I never knew you
were twins.... 8-)Kevin,
[e-mail]------------------------------Date: 28 Apr
90 00:08:00 GMTFrom:
swrinde!zaphod.mps.ohio-state.edu!uwm.edu!bionet!arisia!cdp!saff@
ucsd.eduSubject: Need help in radio data communic.To:
[e-mail],I work in a brazilian organization
who also givesupport for non-profits organizations. We work with
a similarorganization, here in San Francisco Bay Area. We are
about to getauthorization to use the PeaceSat, an old militar
satellite now usedfor pacific purposes, and we plan to use
initially to get a cheapand good link from our machines. I have
no experience in this area,so I am asking for help with some
(maybe dumb) questions: - Possible baud rates - Hardware
required - Places where look for hardwareThanks very much for
any help,Saliel Figueira FilhoChief ProgrammerIBASE{pyramid,
hplabs, ...}!cdp!saff------------------------------End of
Packet-Radio Digest******************************Date: Mon, 30
Apr 90 04:00:02 PDTFrom: Packet-Radio Mailing List and Newsgroup
<[e-mail]>Reply-To: [e-mail]:
Packet-Radio Digest V1 #13To: packet-radioPacket-Radio Digest
     Mon, 30 Apr 90       Volume 90 : Issue  13Today's Topics:
                 Ham Packet BBS on ATT UNIX PC?
    Looking for Packet "Maps"Send Replies or notes for
publication to: <[e-mail]>Send requests of an
administrative nature (addition to, deletion from
thedistribution list, et al) to:
<[e-mail]>Archives of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".Digest files are named
Vv.n where v=volume and n=number in volume.Digests will be
issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET
PEOPLE: UCSD.EDU is an internet site.  TheInternet-to-BITNET
mail gateway systems would prefer that you insteadadd yourself
to a BITNET redistribution of this list; you may addyourself to
the list by sending the following command:      SUBSCRIBE
I-PACRAD your full nameto LISTSERV@UIUCVMD.  You can send that
in an interactive if your systemsupports them (e.g. the CMS TELL
command), or in the body of a mail message(*not* the subject
line).Please note:  Although you'll be receiving Packet-Radio
mailing from thenetwork address I-PACRAD@UIUCVMD,
[e-mail] the source.  Any contributions from you
should be sent to UCSD.The mailing list is in the form of a
digest.  It is not edited, justa convenient envelope for
multiple messages to reduce netmail load.If your mail reader
does not have an "undigestify" option, contactKeith Petersen
W8SDZ  <[e-mail]> and he'll sendyou
C-language source for one.73,    -
Brian        ([e-mail])------------------------------------------
----------------------------Date: 30 Apr 90 02:48:22 GMTFrom:
n8emr![e-mail]  (Gary Sanders)Subject: Ham
Packet BBS on ATT UNIX PC?To: [e-mail] article
<[e-mail]> [e-mail] writes:>>There is
program written by the people at KA9Q called simply KA9Q.>Gee,
Phil, I never knew you were twins.... 8-)>Kevin, KE9TV
[e-mail] thats how Phil manages to make all of
theconferances and yet still work on the ka9q codeand do his
bellcore work.. He had himself duplicated a few times. Lets
see,1 for belcore, 1 for tapr, 1 or amsat,1 to sleep, 50 to
answer his email, 1 to code 8-)....-- Gary W. Sanders (gws@n8emr
or ...!osu-cis!n8emr!gws), 72277,1325N8EMR @ W8CQK (ip addr)
44.70.0.1 [Ohio AMPR address coordinator]HAM BBS
(1200/2400/9600/V.32/PEP/MNP=L5) 614-895-2553Voice: 614-895-2552
(eves/weekends)------------------------------Date: Sun, 29 Apr
90 12:45:45 -0900From: "Duncan C. Fowler, JSDCF2"
<[e-mail]>Subject: Looking
for Packet "Maps"To: [e-mail] wife and I will be
taking a cross country car campingtrip starting June 17th.  I
plan to haul a packet rig withme.  We have done the 2 meter
mobile packet routine in thepast and have enjoyed it.I would
appreciate receiving any packet maps of the areas wewill be
traveling thru.  From past experience, you findPBBS's in the
strangest places.  I would hate to miss onebecause I didn't have
their frequency.We will be driving down the Alaska Highway,
across Canada toManitoba, and eventually to Washington DC and
back homeagain the same way to Juneau Alaska.  We will drive
thruBritish Columbia, Alberta, Saskatchewan, Manitoba, N.
Dak,Minn, Iowa, Wisc, Ill, Indiana, Ohio, Penn, MD and West
VA.Send the packet maps to me via packet or BITNET.  Myaddresses
are KL7RH@KL7HFI or KL7RH@KL7AW by packet.  I canalso be reached
thru BITNET at [e-mail] Fowler,
KL7RH------------------------------End of Packet-Radio
Digest******************************Date: Tue,  1 May 90
04:00:04 PDTFrom: Packet-Radio Mailing List and Newsgroup
<[e-mail]>Reply-To: [e-mail]:
Packet-Radio Digest V1 #14To: packet-radioPacket-Radio Digest
     Tue,  1 May 90       Volume 90 : Issue  14Today's Topics:
                        9M2DX operation     DOVE3W13.ZIP - DOVE
Sat. Telemetry decoder for files or HAPN
   faster modems                    Ham Packet BBS on ATT UNIX
PC?                            Paul Flaherty
 shareware in packet radio                           TNC2 1.1.7
CodeSend Replies or notes for publication to:
<[e-mail]>Send requests of an administrative nature
(addition to, deletion from thedistribution list, et al) to:
<[e-mail]>Archives of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".Digest files are named
Vv.n where v=volume and n=number in volume.Digests will be
issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET
PEOPLE: UCSD.EDU is an internet site.  TheInternet-to-BITNET
mail gateway systems would prefer that you insteadadd yourself
to a BITNET redistribution of this list; you may addyourself to
the list by sending the following command:      SUBSCRIBE
I-PACRAD your full nameto LISTSERV@UIUCVMD.  You can send that
in an interactive if your systemsupports them (e.g. the CMS TELL
command), or in the body of a mail message(*not* the subject
line).Please note:  Although you'll be receiving Packet-Radio
mailing from thenetwork address I-PACRAD@UIUCVMD,
[e-mail] the source.  Any contributions from you
should be sent to UCSD.The mailing list is in the form of a
digest.  It is not edited, justa convenient envelope for
multiple messages to reduce netmail load.If your mail reader
does not have an "undigestify" option, contactKeith Petersen
W8SDZ  <[e-mail]> and he'll sendyou
C-language source for one.73,    -
Brian        ([e-mail])------------------------------------------
----------------------------Date: 30 Apr 90 23:59:10 GMTFrom:
psuvm![e-mail]: 9M2DX operationTo:
[e-mail] friends ---I will be returning home to
Kuala Lumpur, Malaysia, at the end of May.  I havebeen operating
N3FLX while in the States.  I plan to be active on the OSCARsand
Moonbounce from 9M2 land.If there are any hams out there who
would like to dispose of any items thatmay be useful to me, I
will greatly appreciate that.  I am looking for itemswould
enable a good satellite and moonbounce (2m and 70cm) stations to
besetup.  My moonbounce experience was gained at K3CR (Penn
State Amateur RadioClub station) and taught by AF1T (2m WAS
#100).  It is my dream to finallysetup a super-duper moonbounce
station.So, if anyone would like to donate any items of
interest, please e-maildirectly to me or through packet.  Until
then, 73 and hpe to cu soon.Ahmad, N3FLX/9M2DX.<<  AHMAD F. M.
ZAIN                   BITNET : AFZ1@PSUVM             >><<  316
COMM AND SPACE SCIENCE LAB     PACKET : [e-mail]
>><<  ELECTRICAL ENGINEERING EAST         RADIO
[e-mail]    >><<  PENNSYLVANIA STATE UNIVERSITY
AMPR.ORG : 44.080.0.133         >><<  UNIVERSITY PARK, PA 16802.
              "TIME IS LIFE"
>>------------------------------Date: Mon, 30 Apr 1990  14:59
MDTFrom: Keith Petersen <[e-mail]>Subject:
DOVE3W13.ZIP - DOVE Sat. Telemetry decoder for files or HAPNTo:
[e-mail][--forwarded message--]From:
lsuc!ncrcan!brambo![e-mail] (Warren W. Gay VE3WWG)I
have uploaded to SIMTEL20:pd1:<msdos.ham-radio>DOVE3W13.ZIP
DOVE Sat. Telemetry decoder for files or HAPN.This program
operates on all compatible video cards includingHercules.
Colour is also supported.  Input can come from a
previouslycaptured file or it may come directly from the
Hamilton Area PacketNetwork (H.A.P.N.) AX.25 card as the
satellite screams overhead.NK6KTLM format is also accepted
without editing.  Output can be aupdated screen display or to a
report file if output is redirected(format auto-adjusts).[--end
forwarded message--]Thanks, Warren!Keith--Keith
PetersenMaintainer of SIMTEL20's MSDOS, MISC & CP/M archives [IP
address 26.2.0.74]Internet: [e-mail],
[e-mail]  BITNET: w8sdz@NDSUVM1Uucp:
{ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil
!w8sdz------------------------------Date: 1 May 90 02:17:51
GMTFrom: thumper![e-mail]  (Phil R. Karn)Subject:
faster modemsTo: [e-mail] article
<[e-mail]> [e-mail] (John G. De Armond)
writes:>In terms of rules, before the great ARRL/FCC rules
rewrite, this type>modem [wa4dsy]>could be used at 220 mhz and
above.  Now that we've been "represented">again by the ARRL, 220
is out.  But anything 440 or above is fine.This is news to me.
I'm still running 56kbps on 220.55, and as far as Iknow it's
still entirely legal.Phil------------------------------Date: 30
Apr 90 23:18:18 GMTFrom:
usc!zaphod.mps.ohio-state.edu!mips!wyse![e-mail]  (Steve
Wilson xttemp dept303)Subject: Ham Packet BBS on ATT UNIX PC?To:
[e-mail] article <[e-mail]>
[e-mail] (Ron Wilson) writes:>There is program written
by the people at KA9Q called simply KA9Q.  It is>a program
designed to implement protocols like Telnet (a terminal
emulator),>FTP (file transfer protocol), and others over packet
radio.People at KA9Q?  Has Phil cloned himself?Steve
KA6S------------------------------Date: 30 Apr 90 15:39:49
GMTFrom: idacrd![e-mail]  (Robert McGwier)Subject: Paul
FlahertyTo: [e-mail]:Can't find your mailing
address.  We need to discuss the offer to AMSATyou made earlier.
 We have a need.  Please send me email.Bob--
_________________________________________________________________
___________    My opinions are my own no matter    |    Robert W.
McGwier, N4HY    who I work for! ;-)            |    CCR, AMSAT,
etc.-------------------------------------------------------------
---------------------------------------------Date: 30 Apr 90
18:51:04 GMTFrom:
usc!snorkelwacker!bu.edu!mirror!ssi3b1!shyoon!tegra![e-mail]
  (Johnathan Vail)Subject: shareware in packet radioTo:
[e-mail] article
<[e-mail]> [e-mail] (Marc
Sarrel) writes:   Is there an FCC policy or other generally
accepted rules regarding   putting shareware on packet radio
BBS's?  Is transmitting shareware   considered a "business
communication"?  What about freeware?  Just   curious...IMHO:
Any kind of shareware, begware or crippleware software
thatdepends on the user base to disseminate itself and compel
people to"register" or otherwise send money to the author is a
businesstransaction if transfered over amateur radio.  That is,
by usingpacket radio to distribute this kind software you are
providing aservice to people that are making money (or at least
transacting theirbusiness...) off this software.IMHO: Any kind
of public domain or copylefted software used foramateur purposes
is OK to transfer over amateur radio."Koukinaries" _____|     |
Johnathan Vail | tegra![e-mail] |Tegra| [phone]
| N1DXG@448.625-(WorldNet) -----  [e-mail]
{...sun!sunne
..uunet}!tegra!n1dxg------------------------------Date: 30 Apr
90 13:14:06 GMTFrom:
mcsun!ukc!stc!praxis!newton![e-mail]  (Michael
Chace)Subject: TNC2 1.1.7 CodeTo: [e-mail]
All,Have TAPR made the new 1.1.7 TNC2 Code available for
download yet ?If so, where/what
means.73,Mike****................................................
.............................| ARPA   :  [e-mail]
             | Michael Chace            || JANET  :
[e-mail]                   | PraXis Systems
|| UUCP   :  ...!uunet!mcvax!ukc!praxis!mikec     | Manvers
Street           || AMPRNET:  [e-mail]
[44.131.20.3] | Bath,  Avon              || AX.25  :  G6DHU @
G6DHU-2 or G6DHU @ GB7SDN    | BA1 1PX           UK     || Phone
 :  (44) [0]225 444700                   |

|................................................................
.............------------------------------End of Packet-Radio
Digest******************************