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

Text File | 1993-12-31 | 517.9 KB | 8,854 lines

Fri,  1 Nov 91 04:30:05 PSTFrom: Packet-Radio Mailing List and
Newsgroup </dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #281To: packet-radioPacket-Radio Digest         Fri,
1 Nov 91       Volume 91 : Issue 281Today's Topics:
   1200 MHz packet equipment in EuropeSend Replies or notes for
publication to: <[e-mail]>Send subscription
requests to: <[e-mail]>Problems you can't
solve otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 31 Oct 91 11:16:35 GMTFrom:
mcsun!fuug!news.funet.fi!cc.tut.fi![e-mail]:
1200 MHz packet equipment in EuropeTo: [e-mail]
while ago Larry Springsteen was asking here about 23 cm
packetequipment in Japan and Europe. I tried to mail him this
reply butthe mail bounces back. I suppose there is general
interest in23 cm high-speed packet, so here she goes:Hi Larry,I
suppose there are four breeds of hi-speed 23 cm packet radios
used here:1) The German 'Interlink' designThis is a very simple
semiduplex radio built on one card. It has a fixedoffset (35
MHz, I think). The Germans have lots of links built with it.We
found the design to be techically somewhat mediocre and do no
longerplan to use it.2) The YT3MV designThe Croatians have had
four 38400 bps nodes using this equipment. It isvery simple,
uses conventional parts like BFR96S, CA3089 etc. They areusing
direct manchester coded data modulation istead of FSK or RUH.
Thetransmitter is true FM so you can use whatever modem you want
to. See arecent issue of QEX for more details (the article was
also posted here).Unfortunately the only construction article
that is available is in Italian.3) Basic transceiversI have
heard that some of the big buck organisatios use basic FM
mobilerigs like the FT-912R or the IC-1200. In Helsinki they are
going to useIC-12GATs at 1200 bps for short links.4) Home
madeSome people utilize designs originally made for ATV (see
Radio Communications,the microwave, ATV, packet columns). Some
people just make it from scrap, justlike they do everything
else...:-).I have copies of the 1) and 2) articles. Some local
chaps here at OH3TR areprototyping the YT3MV transceiver right
now. If it works we are going toconnect the local nodes ans
bulletin boards together with such radios,maybe even build a
link to the next town.I have a copy of the original YT3MV
article in an Italian magazine *CQElletronica'. If you are
interested in the copies, please drop me a sae.Pentti Gronlund
OH3BKHaiharankatu 19 D 23SF-33710 TAMPEREFINLAND73 de Benjamin
OH3BK------------------------------Date: 31 Oct 91 17:27:40
GMTFrom:
ubc-cs!alberta!aunro!ve6mgs![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>ASubject : Re: Digital
Packet Repeater Info Wanted>[e-mail] (Mark G. Salyzyn
VE6MGS) writes (ME):>>The confuser should look after most of it,
the hardware is the least of>>the worries. Sending out RTS and
CTS packets require NO new hardware andAnd [e-mail] (Dana
H. Myers) replies:>  Err, the vast majority of packeteers use
TNCs with EPROMs inside. Sure,> ...> don't want to take the
cover off of the TNC. This isn't a reason nottouche', write this
off as me becoming real comfortable with my UNIX boxrunning
packet :-).However, I do beg to differ on this. In our city we
have 97 active packeteers.Of these, only ONE refused to do an
upgrade. They all are EAGER to get (orcopy, for shame) whatever
upgrade comes down the pike. The fearful amoungst usalways know
(or try to know) someone who is brave enough to turn a couple
ofscrews.I already feel left in the dust since many have already
got the new upgradefor their PK232s.The REAL problem here, is
that the system (The TNC and it's EPROM) isa closed design. If I
had access to the code, there is no telling what Iwould do with
it (If I could just figure a way of getting work to
stopinterfering with the hobby :-). However, I sit, thumbs
twiddling, waiting forsomeone who has the code to experiment
with the various protocol improvementspossible. Now, if the
programmer were on the Net and did what Thomas Moultindid,
release the code to the massive parallel programmer USENET, then
I amsure lots could be accomplished.Many of these protocol
improvements can be tested out playing with NET/NOS,but they do
not see light of day if they are not published or implementedin
the TNCs ...Ciao, 73 de VE6MGS/Mark
-sk-------------------------------Date: 31 Oct 91 18:45:57
GMTFrom:
qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To :
[e-mail] : Re: Digital Packet Repeater
Info WantedIn article <[e-mail]>,
[e-mail] (Dana H. Myers) writes:|> Since the kind of
revolutionary|> technology Phil mentions is not common or
particularly easy to build|> (keep in mind many packeteers have
trouble building the cable from the|> radio to the TNC, how can
they modify a modern FM radio for power|> control?),I don't
expect to convince many hams to modify their radios for
powercontrol. I *do* hope, however, to convince the
manufacturers ofdedicated digital radios (e.g., the Kantronics
9600 bps radio modemsand the WA4DSY 56kb modem) to add the
hardware hooks for powercontrol. An 8-bit D/A converter for
setting the transmit power levelplus an 8-bit A/D for reading
the receiver's agc is all I need.At some point amateur packet
radio will have to transition todedicated digital radios, as
voice radios with 1200 baud audio modemsare just not designed
for the job.Phil------------------------------Date: 31 Oct 91
18:54:00 GMTFrom:
qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To :
[e-mail] : Re: Digital Packet Repeater
Info WantedIn article <[e-mail]>,
[e-mail] (Mark G. Salyzyn VE6MGS) writes:|> Forget power
control, the cellular industry has it and it is never used|> (at
least in our area).This may be true for most present FM systems,
but it is certainly NOTtrue for the next generation digital
cellular system (Qualcomm'sCDMA).  Continuous power control is
absolutely essential to the properfunctioning of CDMA; all of
the mobiles must be kept within a smallnumber of dB of each
other at the cell site in order to maximize thesystem capacity.
Our mobiles do that in two ways: an "open loop"component based
on the received power level at the mobile (lessreceived power ->
more transmit power) and a "closed loop" correctioncomponent
sent from the cell site to the mobile. The open loopcomponent
does most of the work, and the closed loop component finetunes
it.Talking to the CDMA architects here at Qualcomm (and seeing
it inactual operation) has made me a BIG believer in transmitter
powercontrol. The result is a system that is 10-30x as
spectrally efficientas ordinary, non-power-controlled FM. It
really works!Phil------------------------------Date: 31 Oct 91
19:11:37 GMTFrom:
qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To :
[e-mail] : Re: Digital Packet Repeater
Info WantedIn article <[e-mail]>,
[e-mail] (Gary Coffman) writes:|> While many of the
problems caused by single frequency store and forward|> can be
*mitigated* by clever protocols and careful physical network|>
layout, practical limitations make the "bent pipe" superior in
many|> cases.It depends on your definition of "superior". I must
admit that mypersonal definition is strongly biased towards
maximizing spectralefficiency, i.e., designing a network that
maximizes the total numberof bits that can be moved per second
across a given distance, using agiven amount of spectrum in a
given geographical area. The "bent pipe"has the problem that
everyone's packets blanket the entiregeographical area covered
by the repeater, even if they are going tothe station next door.
 They also use twice as much spectrum.|> Some of the problems
with single frequency store and forward include|> reduced
thruput and increased system complexity. Store and forward|>
effectively cuts the channel baudrate in half for each hop even
if there |> are no collisions from hidden terminals. With bent
pipes the effective |> baud rate is not halved by repeating,
hidden terminals are removed, and|> system complexity is
centralized in one communal resource.Yes and no. Again, the
throughput must be normalized to the amount ofspectrum being
used, and the possibility that multiple
non-interferingtransmissions may occur simultaneously in
different parts of thenetwork can greatly increase the total
carrying capacity of thenetwork.  Of course, for this to occur
you need a) automatictransmitter power control, and b) a routing
algorithm that minimizesNOT the number of hops taken to reach
the destination, but the totalnumber of receivers that have to
be "captured" along the way. Thismeans choosing a relatively
long series of closely spaced, low powertransmitters (each
having a very small geographic coverage area) overa few high
power transmitters (that blanket much more geographicalarea).|>
In a service that has more unused bandwidth than money, use of
bent|> pipes is the most practical way to increase thruput.This
may well be true. But at some point I think we should place
somesignificant monetary value on spectral efficiency. The other
serviceswith which we compete for spectrum (e.g., cellular
radio) certainlydo.  Indeed, Qualcomm wouldn't be in business
developing CDMA if thecellular carriers could just go out and
get all the additionalspectrum they needed to expand their
existing analog FM systems.Don't get me wrong - I think there is
plenty of room for parallelapproaches to improving amateur
packet radio networks. The full duplexrepeater is certainly an
improvement, and it has the advantage ofbeing relatively simple
to understand. But I think thestore-and-forward digipeater has
gotten an unfair rap because of thebroken way we've implemented
it in amateur packet radio. Other packetradio networks, e.g.,
DARPA SURAN, have done a far better job and Ithink we can learn
a lot from them.Phil------------------------------End of
Packet-Radio Digest V91 #281******************************Date:
Sat,  2 Nov 91 04:30:07 PSTFrom: Packet-Radio Mailing List and
Newsgroup </dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #282To: packet-radioPacket-Radio Digest         Sat,
2 Nov 91       Volume 91 : Issue 282Today's Topics:
      56kb Packet; What's available? DCD Mod and Squelch busy
(Was Re: Info on packet repeaters) (2 msgs)
Digital Packet Repeater Info Wanted
Packet-Radio Digest V91 #281                     WANTED: TheNet
1.16 or laterSend Replies or notes for publication to:
<[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 1 Nov 91 16:24:35 GMTFrom:
ncar!virga.rap.ucar.edu![e-mail]: 56kb Packet;
What's available?To: [e-mail]    The title says it
all; I'm looking for whatever is out thereand running at 56kb.
Here at work we have a project with NASA that coulduse this kind
of capacity.  WHile I've heard that some 56kb devices arenot
certified for *commercial* use, this would be on government
frequenciesand I've been told that pretty much anything goes
there (I know for certainthat radios for government use do *not*
have to be type-certified, thoughmany are because they are
essentially comm. units).    We are planning to send contoured,
compressed radar images froma ground based radar to an aircraft
that will be penetrating candidatemicrobursts for testing an
on-board Doppler radar system.  When in Dopplermode, the flight
crew has no reflectivity information and so flies
essentiallyweather radar blind.  We currently have a display
system, intended for Air Traffic Control use, that could be
altered for use in the aircraft.  Tosend the data we need to go
faster than 2.4 kb, which is what the current boxescan do.    So,
what's put there that I can investigate?            73, Kim
Elmore            Assoc. Scientist, National Center for Atmospheric Res.*
 _._. __._ _.. _.._ _.. . _. ..... ___ .__. _. ..... ___ .__.
_.. _.._ _._  **   "All these *WIRES*!!  Why do they call it
'wireless'?"                    **        Doc Evans (NQ0I) commenting
on his ham radio shack.           **  _._. __._ _.. _.._ _.. .
_. ..... ___ .__. _. ..... ___ .__. _.. _.._ _._  *Replies to:
[e-mail] (wires)        44.28.0.67
[e-mail]
(radio)/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/\/\/\/\/\/\/\/\/\/------------------------------Date: 1 Nov
91 16:42:53 GMTFrom:
ubc-cs!unixg.ubc.ca!kakwa.ucs.ualberta.ca!alberta!aunro!ve6mgs!ma
[e-mail]: DCD Mod and Squelch busy
(Was Re: Info on packet repeaters)To: [e-mail]
e-mail response that I got from Pontus Hedman/VE3RPH [e-mail]
made itabundantly clear that I was not clear on a previous
statement about usingthe Squelch busy signal. So, to reduce
confusion, I would like to share witha paraphrase of my response
to Pontus.Pontus is using his squelch control to switch audio
going to his TNC. TheTNC (a PK-232) does not have a State
Machine DCD circuit and uses the fact thatthere is audio to
determine if the channel is `busy'. I own an HK-232, a
PK232lookalike from the now defunct Heathkit Company, but have
got my DCD StateMachine mod done.However, the squelch cutting
the audio to the TNC creates a major problem.  Therequirement
for a TXDELAY setting on average of 350ms to account for
thereceiver's slow squelch response. This is where the DCD State
machine mod(Available from T.A.P.R.) comes in. It requires NO
squelch at all to operateand detects signals that look like
packets. In our area, everyone (whomatters :-) has the DCD mod
so we set our TXDELAY to 0 because of this.  If youhave a mixed
base (DCD State machine is implemented in every TNC except
AEAand KAM) then you have problems. You can ask any MFJ-1270
owner to run withoutsquelch at all and it WILL work (with the
following gripe).However, this DCD state machine creates a
problem. Intermod, accidentalcarriers and non-fullquieting
packets are ignored. One can not receive packetsif one is
experiencing Intermod or accidental carriers, so why transmit?
Theweak signals ARE the hidden transmitters, so please do not
transmit over them.And, we have found some people have set the
AUDELAY setting, so a deadcarrier is transmitted for the first
part of the packet making life somewhatdifficult. These people
are using relay driven boat anchors and require itto not have
spurs triggering the various repeaters in our area. We `may'end
up transmiting over that as well since it is perceived to be
`not apacket'.Thus, we come full circle back to requiring the
squelch signal.Now, if we could all use the DCD mod to get back
some bandwidth (TXDELAY=0)AND use the squelch to prevent
transmission over Intermod/Weak packetsthen we will be almost
home. This is what, as a minimum, all stationsshould implement
in hardware. What a fight.I have implemented a squelch following
circuit that tries to adjust the squelchto a `break every 5-10
second when no signal rule' automatically as anenhancement on
the above. Thus, I prevent my station from affecting many of
thehidden transmitter. The only annoyance is that my station is
dead if astation near by (Hi Fern :-) accidentally locks it's
transmitters on, orsomeone using an HT for packet throws his HT
between his car seats andproduces a dead carrier ...I would like
to implement carrier control as well to make my station
evenfriendlier, and that is my next project. Keep in mind, that
a carrier 20dBdown can cause a signal to not be full quieting
(even though it has capturedthe receiver) thus destroying the
packet's inteligibility. Now, if I could`just' use enough power,
I will prevent my station from interfering withdistant stations.
If I had the code to the TNC, I would implement powercontrol AND
the MACA scheme of negotiating for channel to make one
`trick'system.Hope this helps you understand, Ciao, 73 de
VE6MGS/Mark -sk-------------------------------Date: 1 Nov 91
20:03:56 GMTFrom:
usc!sdd.hp.com!elroy.jpl.nasa.gov!orchard.la.locus.com!devnet.la.
locus.com![e-mail]: DCD Mod and Squelch busy (Was
Re: Info on packet repeaters)To: [e-mail] article
<[e-mail]> [e-mail] (Mark G.
Salyzyn VE6MGS) writes:>>However, the squelch cutting the audio
to the TNC creates a major problem.  The>requirement for a
TXDELAY setting on average of 350ms to account for
the>receiver's slow squelch response. This is where the DCD
State machine mod>(Available from T.A.P.R.) comes in. It
requires NO squelch at all to operate>and detects signals that
look like packets. In our area, everyone (who>matters :-) has
the DCD mod so we set our TXDELAY to 0 because of this.  If
you>have a mixed base (DCD State machine is implemented in every
TNC except AEA>and KAM) then you have problems. You can ask any
MFJ-1270 owner to run without>squelch at all and it WILL work
(with the following gripe).  Hurrah for everyone who uses State
Machine DCD! However, you probablycan not all run TXDELAY 0.
Why? Because the TXDelay actually is two differentdelays. One is
the *receiver active delay*, the other is the *transmitteractive
delay*.  Every transmitter, every single one, takes some time to
become functionalfrom the time PTT is asserted. For some of the
synthesized radios, this canbe quite long (the CPU in the radio
has to program the PLL with the correctparameters for transmit,
the PLL has to stabilize, then the transmitter isenabled). My
Kenwood TR-2600A require something like 150 mS for
thetransmitter to become active. A crystal radio is probably
most prone tocrystal oscillator startup time, likely to be below
20 mS, though the audioamplifier chain may also have some large
capacitors that need to chargeup before real audio is available.
Even if the receiver has 0 delay inrecognizing the packet, the
transmitter requires sometime before it can send valid data.
The receiving delay accounts for the time it takes a radio to
respondto a good signal. Most squelch circuits have some delay,
and then mostaudio chains have some delay even after the squelch
has decided thesignal is good.  So, TXDelay needs to account for
both. Setting it to zero soundssuspect; I'd guess the TNC uses a
non-precise granule, so you getsome short delay, which means
that sometimes packets will work andsometimes they
won't.>However, this DCD state machine creates a problem.
Intermod, accidental>carriers and non-fullquieting packets are
ignored. One can not receive packets>if one is experiencing
Intermod or accidental carriers, so why transmit? The>weak
signals ARE the hidden transmitters, so please do not transmit
over them.>And, we have found some people have set the AUDELAY
setting, so a dead>carrier is transmitted for the first part of
the packet making life somewhat>difficult. These people are
using relay driven boat anchors and require it>to not have spurs
triggering the various repeaters in our area. We `may'>end up
transmiting over that as well since it is perceived to be `not
a>packet'.  The weak signals may be exposed transmitters; i.e.,
too far awayfor you to jam, but strong enough to interfere with
you. Anyway, theTAPR State Machine asserts DCD on dead carriers
(really). So, accidentalcarriers and many kinds of intermod will
assert DCD, so that problem isnot as pronounced.>Thus, we come
full circle back to requiring the squelch signal.>Now, if we
could all use the DCD mod to get back some bandwidth
(TXDELAY=0)>AND use the squelch to prevent transmission over
Intermod/Weak packets>then we will be almost home. This is what,
as a minimum, all stations>should implement in hardware. What a
fight.  Which is why the TAPR State Machine has an input which
can be used tosignify "channel busy" from the squelch line.--  *
Dana H. Myers KK6JQ         | Views expressed here are    * * (213)
337-5136         | mine and do not necessarily    * * [e-mail]        |
reflect those of my
employer    *------------------------------Date: 1 Nov 91 09:35:59
GMTFrom: ub!dsinc!wells![e-mail]: Digital Packet
Repeater Info WantedTo:
[e-mail]@qualcom.qualcomm.com (Phil Karn)
writes:....> Yes and no. Again, the throughput must be
normalized to the amount of> spectrum being used, and the
possibility that multiple non-interfering> transmissions may
occur simultaneously in different parts of the> network can
greatly increase the total carrying capacity of the> network.
Of course, for this to occur you need a) automatic> transmitter
power control, and b) a routing algorithm that minimizes> NOT
the number of hops taken to reach the destination, but the
total> number of receivers that have to be "captured" along the
way. This> means choosing a relatively long series of closely
spaced, low power> transmitters (each having a very small
geographic coverage area) over> a few high power transmitters
(that blanket much more geographical> area).....  It sounds that
the cellular telephone approach may be a way to start to
approach the packet problem.  Unless absolutely needed, apower
level ought to be restricted to some small set amount (let'ssay
5 watts).  As far as an algorithm goes, why not start something
where the networknodes and user nodes can convey their Lat/Long.
position.  This mayallow the network some smarts about best
possible routing as a firstlevel 'guess' for
connections/thruput.--
=================================================================
========Edward E. Wells Jr., N3IAS, President            Voice:
(215)-943-6061Wells Computer Systems Corp., Box 343, Levittown,
Pa.
19058{dsinc,francis,hotps,houxl,lgnp1,mdi386,pebco}!wells!edw----
--------------------------Date: 1 Nov 91 20:04:56 GMTFrom:
[e-mail]: Packet-Radio Digest V91
#281To: [e-mail] ALL!  Can anyone help in
obtaining a copy of the W0RLI Packet BBS Software for amateur
use in Russia. I am making this request on behalf of Ed Kritsky,
NT2X. See his article on the Coup de Etat in the Soviet Union &
the activities of Amateur Radio Station R3A in the December
Issue of QST.                Thanx & 73,                        Walt Kornienko -
K2WK.------------------------------Date: 31 Oct 91 20:14:55
GMTFrom:
caen!deccrl!bloom-beacon!eru!hagbard!sunic!liuida!isy!lysator.liu
.se![e-mail]: WANTED: TheNet 1.16 or laterTo:
[e-mail]'m looking for the latest versions of
thenet. In all the archivesi've been looking around in I have
only found version 1.0, 1.01 ormaybe 1.10. I want at least 1.16
or newer. Could someone pleasegive me pointer where I can
look?SM5KWO Bo Jansson, Linkoeping,
Sweden------------------------------Date: 1 Nov 91 18:24:08
GMTFrom:
ucselx!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!
swrinde!cs.utexas.edu!tamsun!cs.tamu.edu![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital
Packet Repeater Info WantedIn article
<[e-mail]>, [e-mail]
(Phil Karn) writes:[stuff deleted]|> Talking to the CDMA
architects here at Qualcomm (and seeing it in|> actual
operation) has made me a BIG believer in transmitter power|>
control. The result is a system that is 10-30x as spectrally
efficient|> as ordinary, non-power-controlled FM. It really
works!As Robert Heinlein once said, "There ain't no such thing
as a free lunch."You've stated (or implied) that maximizing
spectral efficiency is yourdesign goal.  Well, transmitting data
via the USmail is spectrallyefficient -- but there are certain
performance limitations.  Before I'dsign up for a more
spectrally efficient method, I'd like to see youdiscuss the
trade-offs in terms of protocol performance,
equipmentcomplexity, required dynamic range, etc.Cheers, Willis
n5szf------------------------------Date: 1 Nov 91 15:33:58
GMTFrom:
ubc-cs!alberta!aunro!ve6mgs![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>markSubject : Re: Digital
Packet Repeater Info WantedDana Myers sez:>pressing the repeater
split button on your radio. A full duplex linear>translator
would have the advantage of passing all data modes, but
would>not provide data regeneration which would lead to less
consistent>performance for different users. In either case, full
duplex repeater>or linear translator, the users need only do
what they all do now to>use a voice repeater.Ok, so we have
Digipeaters, Nodes, Full duplex linear translators
andregenerative repeaters. Please do NOT forget that the latter
two represent alinking problem. It is NOT an easy job to link
repeaters, but it is simple tolink Nodes and Digipeaters on the
same frequency. The only use for the fullduplex systems are for
point to point LAN situations, and they represent aproblem once
you start trying to set up a backbone ...A regenerative repeater
could be linked to another regenerative repeater,I am not
debating that that is not possible, just that the costs of sucha
link far outstrip the costs of the system in place right now.
Our clubis making efforts to link Edmonton to Saskatoon, about 8
LONG UNRELIABLEhops as it stands ... we are having troubles
getting money/equipment/timefor half the trip, try setting up a
set of regenerative repeaters with theincreased cost of all the
Cans, linking hardware and such and it soonbecomes an impossible
dream (Waaaahhhhh).Ciao, 73 de VE6MGS/Mark
-sk-------------------------------Date: 1 Nov 91 13:07:21
GMTFrom:
netnews.upenn.edu!uofs!vulture.cs.uofs.edu![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedIn article
<[e-mail]>, [e-mail] (Dana H.
Myers) writes:|> (keep in mind many packeteers have trouble
building the cable from the|> radio to the TNC, how can they
modify a modern FM radio for powerI hate to rain on your parade,
but how many of these hams who "have trouble building the cable
from the radio to the TNC" are going to be able to set upa full
duplex packet station??  How many "out of the box" full duplex
systemshave you seen??  For better or worse, the digipeater is
here to stay for sometime to come.  And it is still the most
practical to set up if you intend tomaintain compatability with
the installed user base.I personally would like to try using
packet thru a linear translator in orderto have full duplex
operation.  It works fine for Real Broadband LANS, and I would
like to see how it works over the air.  But if there are no
users withequipment to take advantage of this type of operation,
there is not much chanceof ever seeing it in operation.All the
best.bill     KB3YV--      Bill Gunshannon          |        If
this statement wasn't here,     [e-mail]   |  This
space would be left intentionally blank
[e-mail]    |         #include <std.disclaimer.h>
------------------------------End of Packet-Radio Digest V91
#282******************************Date: Sun,  3 Nov 91 04:30:03
PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #283To: packet-radioPacket-Radio Digest         Sun,
3 Nov 91       Volume 91 : Issue 283Today's Topics:
          Baycom - English docs?                       DCD Mod
and Squelch busy             Digital Packet Repeater Info Wanted
(2 msgs)                  pacsat broadcast protocol (2 msgs)Send
Replies or notes for publication to: <[e-mail]>Send
subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 2 Nov 91 11:04:50 GMTFrom:
[e-mail]: Baycom - English docs?To:
[e-mail] is becoming quite popular in the
United States. I don't run ithere  but I do help others out and
I tell people about the program allthe time.       I have both
versions 1.2 and 1.4 and in 1.2 there are some Englishdocs.  Was
wondering what differences there are between 1.2 and 1.4 and are
there any English docs available for 1.4 or at least the info
forthe upgrade.     Also what exactly is the latest
version?------------------------------Date: 2 Nov 91 16:13:10
GMTFrom: sun-barr!lll-winken!aunro!ve6mgs![e-mail]:
DCD Mod and Squelch busyTo: [e-mail]@locus.com
(Dana H. Myers) sez:>  Hurrah for everyone who uses State
Machine DCD! However, you probably>can not all run TXDELAY 0.
Why? Because the TXDelay actually is two different>delays. One
is the *receiver active delay*, the other is the
*transmitter>active delay*.Correct, I have my parameter AXDELAY
set to 5 (50ms) since my transmitter usesrelays for the TX/RX,
the crystals are running all the time (my mod) forthe receiver
so that is a non-issue. My point was that the TXDELAY need
notaccount for the receiver delay anymore. I found that when I
had TXDELAYset rather than AXDELAY that I tripped various voice
repeaters in the area.Your mileage will vary, AXDELAY should NOT
be used unless required.My statement of 0 was for Dramatic
effect (and wishfull thinking), A shortlie `sometimes' saves a
load of explanation ...>  The weak signals may be exposed
transmitters; i.e., too far away>for you to jam, but strong
enough to interfere with you. Anyway, the>TAPR State Machine
asserts DCD on dead carriers (really). So, accidentalA dead
carrier exhibits NO packet behavior. However, the DCD state
machine,may be on or off depending on what state it was in just
before the deadcarrier occurs. This is a BUG not a FEATURE and
should not be relied upon.I found this out when I played with
disconnecting the mic signal, and laterconfirmed this when a
local's transmitter locked up because his stationsupply (a set
of 6 Volt Truck Batteries) dropped down while he was outof
town.>  Which is why the TAPR State Machine has an input which
can be used to>signify "channel busy" from the squelch line.Do
not forget, that ALL TNCs have a squelch busy line on their
radioconnector. It is labelled RF-DCD on the MFJ-1270, MFJ-1274
and otherTNC-2 versions and SQ on the PK232. I do not know about
the naming onother TNCs, but it should be intuitive. Connecting
directly to the StateMachine mod would be a waste of a good
connector :-)Anyways, the point of the post is all this
discussion of power control,avante-garde repeaters and such
seemed a waste since the user base isoften reluctant to make
their TNCs spectrally efficient, little lonebandwidth friendly
(I could p*k* :-). The usual solution is to use thebrute force
approach (9600 - 56KBaud).Ciao, 73 de VE6MGS/Mark
-sk-------------------------------Date: 1 Nov 91 22:50:36
GMTFrom: ogicse!emory!wa4mei!ke4zv![e-mail]: Digital
Packet Repeater Info WantedTo: [e-mail] article
<[e-mail]> [e-mail] (Ed Wells) writes:>>  As far as
an algorithm goes, why not start something where the
network>nodes and user nodes can convey their Lat/Long.
position.  This may>allow the network some smarts about best
possible routing as a first>level 'guess' for
connections/thruput.This subject has been well debated in the
past. Primarily the problemwith this approach is that network
topology and geography aren't closely coupled. Due to
propagation and terrain, the best, sometimesthe only path
between two stations may not be along the geodesicconnecting
those stations. Having to first go North in order to routeSouth
is a very common situation in packet radio.Gary
KE4ZV------------------------------Date: 3 Nov 91 06:23:23
GMTFrom:
qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]:
Digital Packet Repeater Info WantedTo: [e-mail]
article <[e-mail]> [e-mail] (Ed Wells) writes:>  It
sounds that the cellular telephone approach may be a way to
>start to approach the packet problem.  Unless absolutely
needed, a>power level ought to be restricted to some small set
amount (let's>say 5 watts).There's no fundamental reason to set
an arbitrary limit on thetransmitter power, as long as only the
actual amount of power requiredis used for any given
transmission. Of course, economics (and the 1KwFCC rule) will
dicate SOME limit in any actual radio.>  As far as an algorithm
goes, why not start something where the network>nodes and user
nodes can convey their Lat/Long. position.  This may>allow the
network some smarts about best possible routing as a first>level
'guess' for connections/thruput.This has been discussed in the
past. For many real-world topologies,latitude/longitude figures
bear only an extremely approximate relationto optimal routing.
It seems to me that a fully dynamic scheme thatmakes decisions
on what can actually be heard is needed anyway, andthat will
pretty much supersede the lat/long
info.Phil------------------------------Date: 1 Nov 91 22:41:37
GMTFrom:
pacbell.com!mips!sdd.hp.com!uakari.primate.wisc.edu!caen!uvaarpa!
cube![e-mail]: pacsat broadcast protocolTo:
[e-mail] article
<[e-mail]> [e-mail] (Gary Sanders)
 writes:> In article
<[e-mail]>
[e-mail] (Tim Hayes) writes:> >> >Does anyone
know where to find programs to use the new pacsat> >broadcast
protocol? Software for the Mac would be most useful but>
>anyting for PC compatibles would do as well. Anonymous FTP
sources> >favored, but at this point any source would be
helpful.> > Tim,>     I have several programs for the MAC to use
the packsat> broadcast protocal as well as other mac programs
for amateur use.> The BBS can be reached at 614-895-2553.> > --
> Gary W. Sanders (gws@n8emr or ...!osu-cis!n8emr!gws),
72277,1325> N8EMR @ N8JVY (ip addr) 44.70.0.1 [Ohio AMPR address
coordinator]> HAM BBS 614-895-2553 (1200/2400/V.32/PEP)> Voice:
614-895-2552 (eves/weekends)Any chance of posting them somewhere
on Internet? UCSD.edu or  Tomcat.gsfc.nasa.gov would be good!Jim
WA4ONG--Jim De Arras            | The opinions expressed herein
areHand Held Products, Inc.| not necessarily those of
Hand804.784.3090 voice      | Held Products, Inc., and may
not804.784.3147 FAX        | even be mine. Use at your own
risk------------------------------Date: 2 Nov 91 14:45:47
GMTFrom:
sdd.hp.com!zaphod.mps.ohio-state.edu!n8emr![e-mail]:
pacsat broadcast protocolTo: [e-mail] article
<[e-mail]> [e-mail]
(Jim De Arras) writes:>In article
<[e-mail]> [e-mail] (Gary Sanders)
 >writes:>> In article
<[e-mail]>
>[e-mail] (Tim Hayes) writes:>> >>> >Does anyone
know where to find programs to use the new pacsat>> >broadcast
protocol? Software for the Mac would be most useful but>>
>anyting for PC compatibles would do as well. Anonymous FTP
sources....>Any chance of posting them somewhere on Internet?
UCSD.edu or  >Tomcat.gsfc.nasa.gov would be good!>>Jim
WA4ONG    You can get a number of ham related mac files
fromapple.com, Also ucsd and tomcat has a number of files as
well.-- Gary W. Sanders (gws@n8emr or ...!osu-cis!n8emr!gws),
72277,1325N8EMR @ N8JVY (ip addr) 44.70.0.1 [Ohio AMPR address
coordinator]HAM BBS 614-895-2553 (1200/2400/V.32/PEP)Voice:
614-895-2552 (eves/weekends)------------------------------Date:
1 Nov 91 22:42:24 GMTFrom:
ogicse!emory!wa4mei!ke4zv![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To : [e-mail]
(Gary Coffman)Subject : Re: Digital Packet Repeater Info
WantedIn article <[e-mail]>
[e-mail] writes:>In article
<[e-mail]>, [e-mail] (Gary
Coffman) writes:>|> While many of the problems caused by single
frequency store and forward>|> can be *mitigated* by clever
protocols and careful physical network>|> layout, practical
limitations make the "bent pipe" superior in many>|> cases.>>It
depends on your definition of "superior". I must admit that
my>personal definition is strongly biased towards maximizing
spectral>efficiency, i.e., designing a network that maximizes
the total number>of bits that can be moved per second across a
given distance, using a>given amount of spectrum in a given
geographical area. The "bent pipe">has the problem that
everyone's packets blanket the entire>geographical area covered
by the repeater, even if they are going to>the station next
door.  They also use twice as much spectrum.That's true, but
thruput between individual stations beyond line ofsight is
significantly better with bent pipes than with
multi-hoptechniques that halve the effective baudrate at each
step. Trafficanalysis around here indicates that the majority of
station to stationcommunications occurs beyond the line of sight
rather than neighborto neighbor. We must consider the actual
desired traffic flows ina system when deciding which technique
best suits maximizing networkusability. Designing to solve the
wrong problem can lead to a suboptimalsolution to user
needs.Amateur networks are unlike government networks in that
the fundingand direction of the network comes from many
competing individualseach trying to maximize his success in
communicating with a desiredtarget station. There is little
central control or authority, theuser base is sparse and poorly
connected, and resources are limited. Techniques used in
implementing the network must be responsive to this or the
system will fail to gain enough support from the user community
to be established and maintained.Exponential backoff as
originally implemented in your Net code is a good technical
solution to the problem of congestive channel collapse, but has
not been well received by many because it unacceptably reduces
the thruputof individual stations in a mixed competitive network
that is not nearingcongestive collapse.I applaud your research
into solutions for densely populated, congestive collapse
threatened networking systems, but that's not the major
percievedproblem facing amateur data communications. Simple
connectivity and lowindividual thruput are the major perceived
problems. Bent pipes immediatelyaddress both of these problems.
Your solution requires a packing densityseldom reached in
amateur data networks.Conceptually I like your proposals becuase
they address the problem ofsystem redundancy in the event of
single node failure. The reality,however, is that single nodes
are often the only link between groupsof stations. The amateur
network is sparse and resources to add multiplecell sites to
close that gap are missing.For the near term, concentrating on
systems that address today's problemsis more likely to be well
received and implemented. Please continue yourresearch, amateur
networks may one day need them, but don't expect themto be
widely implemented in today's networks or today's hardware.
Meanwhile others will continue to attempt to address today's
problems with solutions geared to meeting today's basic user
population needs.Gary KE4ZV------------------------------Date: 3
Nov 91 06:50:49 GMTFrom:
qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedIn article
<[e-mail]> [e-mail] (Mark G.
Salyzyn VE6MGS) writes:>regenerative repeaters. Please do NOT
forget that the latter two represent a>linking problem. It is
NOT an easy job to link repeaters, but it is simple to>link
Nodes and Digipeaters on the same frequency.I don't see any
problem here; you can link two regenerating,full-duplex
repeaters quite easily by just setting up co-located
userstations for the two repeaters and connecting the two user
stationsthrough a packet switch that routes between them. It's
just likeplacing an IP router (or a bridge, for that matter)
between twoEthernets.Phil------------------------------Date: 2
Nov 91 22:55:05 GMTFrom:
usc!elroy.jpl.nasa.gov!orchard.la.locus.com!devnet.la.locus.com!d
[e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedIn article
<[e-mail]> [e-mail] (Mark G.
Salyzyn VE6MGS) writes:>Dana Myers sez:>>pressing the repeater
split button on your radio. A full duplex linear>>translator
would have the advantage of passing all data modes, but
would>>not provide data regeneration which would lead to less
consistent>>performance for different users. In either case,
full duplex repeater>>or linear translator, the users need only
do what they all do now to>>use a voice repeater.>>Ok, so we
have Digipeaters, Nodes, Full duplex linear translators
and>regenerative repeaters. Please do NOT forget that the latter
two represent a>linking problem. It is NOT an easy job to link
repeaters, but it is simple to>link Nodes and Digipeaters on the
same frequency. The only use for the full>duplex systems are for
point to point LAN situations, and they represent a>problem once
you start trying to set up a backbone ...  What is so difficult
about linking duplex data repeaters? You havea station somwhere
(anywhere) in the coverage area that links to a backbone.
Couldn't be easier. I'll reiterate the model I keep thinkingof;
duplex repeaters which cover user areas and are linked usinghigh
speed trunking. What is so difficult about that? It has
theadvantage of linking off-frequency, which can spread the load
aroundbetter and, once again, eliminate hidden transmitter
syndrome.--  * Dana H. Myers KK6JQ         | Views expressed here
are    * * [phone]         | mine and do not necessarily    * *
[e-mail]        | reflect those of my
employer    *------------------------------Date: 3 Nov 91 06:47:46
GMTFrom:
qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet Repeater Info
WantedIn article <[e-mail]> [e-mail]
(Willis Marti) writes:>Before I'd>sign up for a more spectrally
efficient method, I'd like to see you>discuss the trade-offs in
terms of protocol performance, equipment>complexity, required
dynamic range, etc.These are valid points. If it were easy to
do, we'd be doing it already.So there's no question that a
power-controlled system would be more complexthan what we have
now. But I don't think that's necessarily a
disadvantage,especially if much of the complexity can be placed
in the software (which iseasy to replicate once it's written).So
the main issue is the cost/difficulty of the required
hardwaresupport for power control (all else is in the protocol,
which issoftware). The receiver is easy; just put an A/D
converter on the AGClead and use a lookup table to convert that
to received power in dBm.A quick back-of-the-envelope worst-case
calculation says that youmight need as much as 128 dB of dynamic
range in the transmitter; thistakes you from 100 watts (a fairly
hefty transmitter on VHF/UHF) downto a tenth of a nanowatt
(about what's required to talk to yournext-door neighbor 30 feet
away.)  Now you may not need all thisdynamic range in any
particular station -- you may not need 100 wattsto reach the
furthest station in your network, and you only need toreduce
power to the level required to reach your nearest neighbor,
whomay be much farther away than next door.Getting this much
dynamic range in a power-controlled transmitter willprobably
take some work, but I don't think it should beinsurmountable.
You can probably get 20-30 dB of range by controllingthe gain of
the common PA "bricks", so you'll probably need to switchout
entire stages, starting with the final, to get more
attenuationthan that.  PIN diodes can probably do the trick. For
example, youjust shut off the power to the final and bypass it
with PIN diodes. Ifyou need more isolation, switch in some
attenuator stages.  You dohave to make sure that the PIN diodes
provide enough isolation to keepthe final stage from feeding
back when it is switched in and runningat full gain.Again, I
don't expect the average ham to hack this into his radio, butI
don't think that this should be beyond the abilities of a good
radiodesigner either. No, the hardest part is going to be to
convince theaverage ham that it really *IS* in his best interest
to not always runthe maximum power that his transmitter is
capable of...Phil------------------------------Date: 3 Nov 91
06:11:28 GMTFrom:
qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: DCD Mod and
Squelch busyThis discussion of DCD problems just underscores
something I've been sayingfor the past several years: :-)CSMA on
simplex radio doesn't work!The whole problem with any carrier
detect circuit, EVEN ONE THAT ISINSTANTANEOUS AND 100% RELIABLE
at distinguishing real data fromnoise, is that it doesn't really
tell you what you want to know: wouldI interfere with somebody
if I were to transmit now? Not hearinganother signal on the
channel doesn't guarantee that you won'tinterfere with somebody
if you transmit, and conversely hearinganother signal doesn't
mean that you would necessarily interfere withit if you DID
transmit.I think the secret to making simplex packet radio work
is to use areceiver-directed contention scheme. That is, you
shouldn't care ifyou hear a given transmitter; you want to know
if you'll interferewith that transmitter's intended receivers.
That means you need aprotocol where the receiver, not the
transmitter, holds off contendingtransmitters. E.g., my "MACA"
scheme, or the simplified version.And the nice thing about such
a scheme is that its all software; you canget rid of your
carrier detect circuits
altogether.Phil------------------------------Date: 3 Nov 91
08:39:12 GMTFrom:
qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedIn article
<[e-mail]> [e-mail] (Gary
Coffman) writes:>That's true, but thruput between individual
stations beyond line of>sight is significantly better with bent
pipes than with multi-hop>techniques that halve the effective
baudrate at each step.I don't think this is true, especially if
you normalize for the amountof spectrum that's being used. If
the stations aren't inline-of-sight, then chances are they're
fairly far apartgeographically, and that calls for a repeater
that blankets a fairlylarge metropolitan area. A series of
relatively smallstore-and-forward repeaters could cover the
distance between thestations without having to blanket the
entire area covered by the bigrepeater. Traffic>analysis around
here indicates that the majority of station to
station>communications occurs beyond the line of sight rather
than neighbor>to neighbor. We must consider the actual desired
traffic flows in>a system when deciding which technique best
suits maximizing network>usability. Designing to solve the wrong
problem can lead to a suboptimal>solution to user needs.It would
be interesting to look at your traffic statistics from abroader
perspective. Is all the traffic to or from a single node,(e.g.,
a BBS or DX cluster?) If so, then a change in
applicationarchitecture is called for - users should send
person-to-personmessages to each other directly, not through
BBSes, and DX calloutsand BBS bulletin traffic should be relayed
either through high levelrelay stations running an efficient
broadcast protocol - the one placewhere large, high-level
transmitters make sense - or with an efficientstore-and-forward
neighbor-to-neighbor "flooding" scheme a la USENET.In this day
and age, I have to admit that I have little sympathy
forsquandering spectrum to support "dumb terminal" users who
can't bebothered to get the necessary local computing power and
storage to dothe job right.>Amateur networks are unlike
government networks in that the funding>and direction of the
network comes from many competing individuals>each trying to
maximize his success in communicating with a desired>target
station. There is little central control or authority, the>user
base is sparse and poorly connected, and resources are limited.
>Techniques used in implementing the network must be responsive
to this >or the system will fail to gain enough support from the
user community >to be established and maintained.Exactly! That's
why I'm such a fan of decentralized, self-organizingnetworks
that avoid depending on specialized shared resources likehilltop
repeaters.  It's much easier to convince a user to buysomething
for himself than to contribute his fair share to a jointproject.
 (AMSAT has had to deal with this fact for years.)  Thatthere
are as many centralized service nodes on the air as there
arespeaks more to the dedication, generosity and egos (not
necessarilymeant pejoratively) of a few hams who are more
willing than they oughtto be to compensate for the laziness of
the average ham.>Exponential backoff as originally implemented
in your Net code is a good >technical solution to the problem of
congestive channel collapse, but has >not been well received by
many because it unacceptably reduces the thruput>of individual
stations in a mixed competitive network that is not
nearing>congestive collapse.There is a good solution to this
problem, at least at the AX.25 level -the "blimit" (backoff
limit) parameter. You set it to the maximum numberof stations
that can contend for the channel simultaneously. It thenlimits
the exponential backoff to that degree. That prevents
congestioncollapse, and it also keeps the backoff from getting
out of hand."Competitive" is the key word in what you said.
There's enoughcompetition already in ham radio, especially of
the destructive kindthat results in less for everybody. I'm not
proud to be in a servicewhere the lucky few who get through to
the space shuttle on 2mFM haveto run megawatts of EIRP to do it.
I'm not proud to be an amateurpacketeer when I listen to a
packet channel running far below itscapacity because of power
levels that are 40-50 dB above where theyneed to be.Somebody (I
can't remember who) said that a civilization can be ratedby the
extent to which its members are willing to maximize the
commongood as opposed to maximizing their own individual good.
By thismeasure, ham radio isn't very civilized. Human nature
being what itis, you can't expect much better given the
primitive, manual nature ofour technology and its requirement
that users go out of their way togive the other guy a break. If
you want things to get better, you haveto automate them. And
that's what I'm trying to do. I try to design myalgorithms to
produce GLOBAL optimums in network performance, and ifsomebody
else doesn't like it, well, they have the source code and
canhack it to their own liking.>I applaud your research into
solutions for densely populated, congestive >collapse threatened
networking systems, but that's not the major percieved>problem
facing amateur data communications. Simple connectivity and
low>individual thruput are the major perceived problems. Bent
pipes immediately>address both of these problems. Your solution
requires a packing density>seldom reached in amateur data
networks.Try visiting Southern California...>Conceptually I like
your proposals becuase they address the problem of>system
redundancy in the event of single node failure. The
reality,>however, is that single nodes are often the only link
between groups>of stations. The amateur network is sparse and
resources to add multiple>cell sites to close that gap are
missing.Again, visit here sometime. Actually, my goal is to
devise an architecturethat will work for ANY concentration of
nodes. That's the nice thing aboutit - if your network is
sparse, then stations will, on average, run morepower and talk
farther between hops because that maximizes the networkcapacity
for that set of circumstances. But as you add nodes and
theaverage internodal distance decreases, the average transmit
power decreases,and the total network capacity in a given
geographic area actually INCREASESdue to the increased frequency
reuse factor.>For the near term, concentrating on systems that
address today's problems>is more likely to be well received and
implemented. Please continue your>research, amateur networks may
one day need them, but don't expect them>to be widely
implemented in today's networks or today's hardware. Meanwhile
>others will continue to attempt to address today's problems
with solutions >geared to meeting today's basic user population
needs.Once again, I see our approaches as being more
complementary thancompetitive.  I think the more approaches that
are pursued inparallel, the better; the greater the chance that
one will fit a givennetwork's needs. It is partly because I saw
others working on the fullduplex repeater (but no one working on
fundamental changes to simplexrelaying) that I decided to give
the lowly digipeater another
seriouslook.Phil------------------------------End of
Packet-Radio Digest V91 #283******************************Date:
Mon,  4 Nov 91 04:30:05 PSTFrom: Packet-Radio Mailing List and
Newsgroup </dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #284To: packet-radioPacket-Radio Digest         Mon,
4 Nov 91       Volume 91 : Issue 284Today's Topics:     DCD Mod
and Squelch busy (Was Re: Info on packet repeaters)
   Digital Packet Repeater Info Wanted            Wanted Rose
Networking Code v901111 FTP site??Send Replies or notes for
publication to: <[e-mail]>Send subscription
requests to: <[e-mail]>Problems you can't
solve otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 3 Nov 91 17:46:21 GMTFrom:
mcsun!news.funet.fi!cc.tut.fi![e-mail]: DCD
Mod and Squelch busy (Was Re: Info on packet repeaters)To:
[e-mail] article
<[e-mail]> [e-mail] (Mark G.
Salyzyn VE6MGS) writes:>have a mixed base (DCD State machine is
implemented in every TNC except AEA>and KAM) then you have
problems. You can ask any MFJ-1270 owner to run withoutKAM
versions 4.00 onwards do have a possibility of software DCD. I
have had4.00 since thursday and it seems to work remarkably
better than the squelch'DCD'.German TNC2 clones by DK9SJ have an
Exar 2211 DCD circuit. It works ratherwell but it cannot
distinguish audio bleeps from real data.We have modified all our
network TNCs to have the state machine and try toencourage all
users to make the modification, too.73 de Benjamin
OH3BK------------------------------Date: 3 Nov 91 16:07:02
GMTFrom:
sdd.hp.com!spool.mu.edu!cs.umn.edu!kksys!edgar!brainiac!moron!chr
[e-mail]: Digital Packet Repeater Info WantedTo:
[e-mail]> In article
<[e-mail]>, [e-mail] (Dana H.
Myer> |> (keep in mind many packeteers have trouble building the
cable from the> |> radio to the TNC, how can they modify a
modern FM radio for power> If these "hams" have problems
figuring out _how_ to build a cable, rather than being unable to
build able because of some physical condition, I for one would
like to know how they managed to obtain their license ;-)  OR,
is that the meaning of th term, "store-bought ham"?  Answers
please on a postcard to:  "Blue Peter, BBC, Bush House....."
73's     Chris Cox  W0/G4JEC     EMail [e-mail]
        AMPRNet  [e-mail]

  ------------------------------Date: 4 Nov 91 02:20:09 GMTFrom:
sdd.hp.com!spool.mu.edu!munnari.oz.au!yoyo.aarnet.edu.au!sirius.u
cs.adelaide.edu.au![e-mail]:
Wanted Rose Networking Code v901111 FTP site??To:
[e-mail]!Can anyone tell me where I might be
able to FTP a copy of the 901111 versionof the Rose X.25
Networking software? I have 900703 but am looking for901111 as I
believe it has password protection on the node
configurationaccess.Also I am interested in finding out more
about a PC version of Rose.A bulletin floated across my local
BBS network a few weeks ago from Franceregarding a version of
Rose that had been ported to a IBM-PC platformand I would be
most interested to hear more about this, whats requiredas far as
TNC's or Plug in cards etc, whether the software is
availableyet, where can it be obtained from etcAny help would be
great.Thanks and Cheers de Grant VK5ZWI--Grant Willis (VK5ZWI),
Electronic Engineering Student. | Adelaide
UniversityAARNet/Internet1: [e-mail]
| South AUSTRALIAAARNet/Internet2:
[e-mail] | My views are my
own,AmPRNET: VK5ZWI@VK5TTY.#SA.AUS.OC  [44.136.171.11]     | not
the Uni's!------------------------------Date: 4 Nov 91 02:26:43
GMTFrom:
usc!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!van-bc!u
bc-cs!alberta!aunro!ve6mgs![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>>Subject : Linking
Regenerative Repeaters (Was Re: Digital Packet Repeater Info
Wanted)[e-mail] (Dana H. Myers) sez:>  What is so
difficult about linking duplex data repeaters? You haveCost ...
:-}No, we are thinking of linking regenerative repeaters here
(if we get anyup that is) using Raw IP backbone links. Some of
these may even linkdirectly into Internet sites, providing some
form of security filtering.But, this all involves costs, and we
have enough troubles convincing thelocals to fork over for AX.25
nodes. But, corporate donations are now beingsought to solve
this problem ...Ciao, 73 de VE6MGS/Mark
-sk-------------------------------Date: 4 Nov 91 02:36:14
GMTFrom:
swrinde!elroy.jpl.nasa.gov!news.larc.nasa.gov!lll-winken!aunro!ve
6mgs![e-mail]: [e-mail]
<[e-mail]>, <[e-mail]>,
<[e-mail]>Subject : Output Power
Control (Was Re: Digital Packet Repeater Info
Wanted)[e-mail] (Phil Karn) sez:>Getting this
much dynamic range in a power-controlled transmitter
will>probably take some work, but I don't think it should
be>insurmountable.  You can probably get 20-30 dB of range by
controllingYour standard SWR portection circuit should be able
to handle this, astandard feedback loop input.>Again, I don't
expect the average ham to hack this into his radio, but>I don't
think that this should be beyond the abilities of a good
radio>designer either. No, the hardest part is going to be to
convince theThe ALC input (the other name of the feedback point
itemized above) is whatshould be added if not already available
... Some way of measuring theACTUAL RF output is all that needs
to be added ...Ciao, 73 de VE6MGS/Mark
-sk-------------------------------Date: 4 Nov 91 02:34:35
GMTFrom:
sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!emory!wa4mei!ke4zv!g
[e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>*Reply-To : [e-mail]
(Gary Coffman)Subject : Re: DCD Mod and Squelch busyIn article
<[e-mail]> [e-mail] (Mark G.
Salyzyn VE6MGS) writes:>>Anyways, the point of the post is all
this discussion of power control,>avante-garde repeaters and
such seemed a waste since the user base is>often reluctant to
make their TNCs spectrally efficient, little lone>bandwidth
friendly (I could p*k* :-). The usual solution is to use
the>brute force approach (9600 - 56KBaud).I don't consider our
56 kb system brute force. We only occupy 1.2 hzper baud. That's
much better than the 20 hz per baud of other schemeslike the
current AFSK modems that try to operate through voice radios.Our
TR time is under 5 ms and doesn't require a TXD of 50, which
equatesto 500 ms in TAPR clones. In that half a second of crud,
our system wouldhave sent 25 kb of data. I prefer the term
elegant to describe our 56 kbmodems. Using voice squelch systems
on a data radio is an abomination thatwastes valuable channel
time for weak noise bursts and stations so faraway that our
transmission won't interfere anyway. That's what FM captureis
for. Not to mention the abominable squelch opening delays that
causeother stations to extend their TXD in order to communicate
with the slowestradio on the channel. Use of AF squelch is the
wrong solution to a mostlynon-existant problem.Gary
KE4ZV------------------------------Date: 4 Nov 91 02:12:19
GMTFrom:
usc!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!samsung!emory!wa4mei
!ke4zv![e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To : [e-mail]
(Gary Coffman)Subject : Re: Digital Packet Repeater Info
WantedIn article <[e-mail]>
[e-mail] (Phil Karn) writes:>In article
<[e-mail]> [e-mail] (Gary
Coffman) writes:>>That's true, but thruput between individual
stations beyond line of>>sight is significantly better with bent
pipes than with multi-hop>>techniques that halve the effective
baudrate at each step.>>I don't think this is true, especially
if you normalize for the amount>of spectrum that's being used.
If the stations aren't in>line-of-sight, then chances are
they're fairly far apart>geographically, and that calls for a
repeater that blankets a fairly>large metropolitan area. A
series of relatively small>store-and-forward repeaters could
cover the distance between the>stations without having to
blanket the entire area covered by the big>repeater.I think this
is the basic sticking point. It's barely possible to get *one*
repeater funded, sited, and maintained in most areas. Torequire
numerous cell sites becomes financially and
organizationallyimpossible. Most of our c ommun

ications is terrain limited rather thanpower limited so power
control doesn't enter in to the equation verymuch at all. To
require many little relay sites linking the foldsin the terrain
is more complex and expensive than maintaining onevery high site
that looks down into all the valleys. I understandthat this is a
local problem and that in flat areas power controlwould be
helpful, as would directional antennas. In Atlanta we arelooking
at 500 sometime users in 1800 square miles. At any given time
less than a hundred of those stations are powered up and
lessthan 30 are in use. They all want to be able to communicate
witheach other in real time at some point.>It would be
interesting to look at your traffic statistics from a>broader
perspective. Is all the traffic to or from a single node,>(e.g.,
a BBS or DX cluster?) If so, then a change in
application>architecture is called for - users should send
person-to-person>messages to each other directly, not through
BBSes, and DX callouts>and BBS bulletin traffic should be
relayed either through high level>relay stations running an
efficient broadcast protocol - the one place>where large,
high-level transmitters make sense - or with an
efficient>store-and-forward neighbor-to-neighbor "flooding"
scheme a la USENET.>In this day and age, I have to admit that I
have little sympathy for>squandering spectrum to support "dumb
terminal" users who can't be>bothered to get the necessary local
computing power and storage to do>the job right.I agree with
this 100%. We badly need to implement a broadcast protocol*and*
a flooding scheme. Both would ease the burden on the
networkcaused by users reading the same bulletins one after the
other. Thatprobably is an accurate representation of traffic on
our low speedlinks. On the high speed links the majority of the
traffic is stationto station mail and file transfers. There is a
major difference betweenthe users on the two systems, however.
Our high speed users tend to be24 hour a day stations while our
low speed users only appear at randomtimes and use their
equipment for other things when not actively onpacket. This
makes a broadcast protocol hard to sell.>Exactly! That's why I'm
such a fan of decentralized, self-organizing>networks that avoid
depending on specialized shared resources like>hilltop
repeaters.  It's much easier to convince a user to buy>something
for himself than to contribute his fair share to a
joint>project.  (AMSAT has had to deal with this fact for
years.)  That>there are as many centralized service nodes on the
air as there are>speaks more to the dedication, generosity and
egos (not necessarily>meant pejoratively) of a few hams who are
more willing than they ought>to be to compensate for the
laziness of the average ham.While I don't disagree with the
spirit of what you say, I must repeatthat many of our users are
terrain limited (and apartment bound).That means they have no
connectivity at all without outside aid.It's easier to sell
*one* community resource than many, and infinitelyeasier for a
very small group of dedicated volunteers to *maintain*one site
than many. Our most scarce resource is people.>There is a good
solution to this problem, at least at the AX.25 level ->the
"blimit" (backoff limit) parameter. You set it to the maximum
number>of stations that can contend for the channel
simultaneously. It then>limits the exponential backoff to that
degree. That prevents congestion>collapse, and it also keeps the
backoff from getting out of hand.Yes, I know, and I appreciate
it. What I was referring to was the necessity to *add* that
parameter to the original scheme. Sometimesreal world
constraints break otherwise brilliant solutions to problems.If
level one were ethernet grade instead of being lossey and
mixedwith stations who don't back off, the fix wouldn't have
been necessary.But they are and it was because some things were
beyond our limitedcontrol. Designing for the real world I call
it.>"Competitive" is the key word in what you said. There's
enough>competition already in ham radio, especially of the
destructive kind>that results in less for everybody. I'm not
proud to be in a service>where the lucky few who get through to
the space shuttle on 2mFM have>to run megawatts of EIRP to do
it. I'm not proud to be an amateur>packeteer when I listen to a
packet channel running far below its>capacity because of power
levels that are 40-50 dB above where they>need to be.I
understand. I appreciate why you are working to add spatial
diversityto time diversity in packet radio. Bent pipes are an
attempt to maximizethe effectiveness of time diversity, which is
poorly done on simplexstore and forward because of hidden and
exposed terminals. By not halvingthe effective baudrate, it
makes up for it's use of two channels. Inyour proposal, spatial
diversity through power control minimizes thehidden and exposed
terminal problems. But every additional hop halvesthe effective
baudrate, and power control doesn't address the problemof
terrain blocking, thus making any connectivity at all a problem
for many stations.>Once again, I see our approaches as being
more complementary than>competitive.  I think the more
approaches that are pursued in>parallel, the better; the greater
the chance that one will fit a given>network's needs. It is
partly because I saw others working on the full>duplex repeater
(but no one working on fundamental changes to simplex>relaying)
that I decided to give the lowly digipeater another
serious>look.I agree, and don't let my comments act as a damper
on your approach. Ihope that you do consider that a cellular
approach *does* require more24 hour stations positioned at
strategic locations to adequately provideservice for all. And
that somebody has to *maintain* those stations andpay the power
bills and site rental. There never seems to be a ham livingwhere
you desperately need a relay.Gary
KE4ZV------------------------------End of Packet-Radio Digest
V91 #284******************************Date: Tue,  5 Nov 91
04:30:09 PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #285To: packet-radioPacket-Radio Digest         Tue,
5 Nov 91       Volume 91 : Issue 285Today's Topics:
         DCD Mod and Squelch busy     DCD Mod and Squelch busy
(Was Re: Info on packet repeaters)
Packet-Radio Digest V91 #280                     Packet-Radio
Digest V91 #281                              Rose on PCSend
Replies or notes for publication to: <[e-mail]>Send
subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 4 Nov 91 14:10:02 GMTFrom:
usc!sdd.hp.com!cs.utexas.edu!asuvax!anasaz!qip![e-mail]
ct: DCD Mod and Squelch busyTo: [e-mail]:
In article <[e-mail]> [e-mail]
(Gary Coffman) writes:]I don't consider our 56 kb system brute
force. We only occupy 1.2 hz]per baud. That's much better than
the 20 hz per baud of other schemes]like the current AFSK modems
that try to operate through voice radios.Gary, could you give me
a phone number or whatever that will allow meto get data on
those 56kb modems?-- John Moore NJ7E, 7525 Clearwater Pkwy,
Scottsdale, AZ 85253  (602-951-9326)ncar!noao!asuvax!anasaz!john
[e-mail] anasaz![e-mail]"It would be
thought a hard government that should tax its people one tenth
part..." B. Franklin   - Standard Disclaimer Applies - - -
Support ALL of the bill of rights, INCLUDING the 2nd amendment!
- -------------------------------Date: 4 Nov 91 18:46:11
GMTFrom: intran![e-mail]: DCD Mod and Squelch
busy (Was Re: Info on packet repeaters)To:
[e-mail] know there is a line in PLL chips that
signals when the PLL is locked.Couldn't this line be wired into
the TNC, and replace TXDelay=RaNdOm#?I know most people want to
have the option of removing the packetradio and not have lotsa
wires, but when was the last time your radioleft the TNC.Right
solution for wrong problem.This Saturday there is a meeting of
twinsLAN (minneapolis areapacket radio group).  It is at the
Paveck Radio museum in St. LouisPark.  Hopefully it won't snow
(at least as much as last weekend), andsome folks with good
ideas will show up.What is the idea for the optimum solution?
What I would like tosee are multiple freq's.  the 1200 baud
folks can stay on 145.0X,the 9600 baud folks can go to 4XX.YY,
and the 56KB can be organizedon {900, 1.2G, ...}.  Some
separation for backbones of traffic, butmost 56KB stuff would
probably end up like the internet (hopefullyonly the good
stuff), with telnet connections, and some FTP, and someSMTP,
this an X session thrown in for keeping things busy.Yes anything
at or above 9600 should be full duplex (actually the 1200 should
be also, but who's gonna listen?)  This leads to weird
repeatersituations, and might be real hard to keep organized.
Probably better solutions would be spread spectrum, or
'cellular' typesolutions.  Using the FDDI type protocols, with a
specific frequencydesignated for organizing the FDDI stuff.  How
about the 1200baud modemcommunicating to a clearing house,
asking for a slot in the protocol,the clearinghouse grants, the
56KB modem listens for the slot, and handles the transactions.
When done the 1200 baud modem tells the clearinghouse everything
is done and the connection is closed.Thoughts while typeing,
maybe none of this makes total sense.Tommy B.wd0eib @
wbogdbuunet!intran![tommyb!]tom------------------------------Date
: 4 Nov 91 12:52:12 GMTFrom: [e-mail]:
Packet-Radio Digest V91 #280To: [e-mail] some
kind soul point me to a mail server that can send me RFC's
ondemand?  I need to snatch a number of RFC's, but alas, have
lost my FTPcapability.    Mucho Gracias in advance, etc..,--
John McCluskeyPostal Mail : John McCluskey, 808 de Bienville,
Montreal P.Q. H2J 1V1,  CANADATelephone   : [phone]
Call Sign: KB6PZFEMail (home):
[e-mail]--------------------------
----Date: 4 Nov 91 17:13:55 GMTFrom:
timbuk.cray.com!shamash!duke![e-mail]:
Packet-Radio Digest V91 #281To: [e-mail] article
<[e-mail]> [e-mail]
(Walter Kornienko, GC-HSI) writes:>>Hey ALL!  >>Can anyone help
in obtaining a copy of the W0RLI Packet BBS Software for
>amateur use in Russia. I am making this request on behalf of Ed
Kritsky, >NT2X. See his article on the Coup de Etat in the
Soviet Union & the activities >of Amateur Radio Station R3A in
the December Issue of QST.>>                Thanx & 73,>                        Walt Kornienko
- K2WK.I'll follow Walt's request with one for the Ukraine. If
anyonehas a source or can provide a copy to me I'll forward it
on toUB5WE in Lvov for their use there.N0ISL
John*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--** John
Douglas       * Everything nailed down is   *     * Arden Hills,
MN    * coming loose: Angel Gabriel ** Control Data Corp. * Marc
Connelly: Green Acres  ** . . . . . . . . . . . . . . . . . . .
. . . . . .** Disclaimer: Nothing stated above may be reprod-  *
* in any form other than stone tablets. Copyright  *  * pending
. No warrenty is extended or implied.:^) *
*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-------------
-----------------Date: 4 Nov 91 16:19:42 GMTFrom:
[e-mail]: Rose on PCTo:
[e-mail]:    HUTIN@ASL@PSI%ASLVX6@MRGATE@SNDRTRTo:
"[e-mail]"@M_INTERNET@MRGATE@SNDRTRThe french
packet association (ATEPRA) and F6FBB have implemented ROSEon PC
based on the sources released by W2VY. This version is
fullyoperational today and will be released. I 'll get a version
and put itsomewhere for ftp access. The present version uses
serial ports but8530 will be supported in the future. I'll
contact people in France later this week to get advanced details
and schedules.73s Remi W5/FE6CNB Atepra
member------------------------------Date: 4 Nov 91 17:36:07
GMTFrom: [e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info [e-mail] (Bill Gunshannon)
writes:>In order for this system to work, not only the
digi-peater, but all the>users have to be running true full
duplex.  They have to be able to hear>themselves transmit so
that they know they have captured the repeater.>If they have
not, then they must shut down the transmitter in order to>not
interfere with the station who has captured it.  That would be
full>duplex.  Anything less offers nothing and uses twice as
much spectrum.This is simply wrong: it is NOT necessary for the
users to run fullduplex for the digital repeater to represent a
significant gain inchannel throughput.  The repeater will
eliminate the hidden-terminalproblem, greatly reducing the
collision rate.  The use of p-persistanceaccess methods will
again reduce the collision rate.While it is true that having
each user be full-duplex and able to tellwhether the signal
being repeated is his own or someone else's wouldagain reduce
the collision rate, the additional complexity of therequired
user station might well outweigh the advantages of it.  Itwould
certainly be worth a try.  Note that for this to work, it is
notenough to be fully able to receive whilst you transmit; you
must ALSOhave some way to tell that the signal coming back from
the repeater isyours - which means that you have to decode the
header on the packet tosee if it's yours.  You can't simply X-OR
the bits coming back, sincethere are variable propagation
delays.  Nor can you examine the voltagelevel on the cable
(which is how Ethernet collisions are detected),since there
isn't any relationship between received signal strength
andtransmitted signals and collisions.Let's look at a few of
these points in a little greater detail.If you have hidden
terminals (i.e., there are stations B and C that cancommunicate
with station A, but not with each other), in the absence
ofslotting methods, there is a virtual certainty that you will
havecollisions when B and C both transmit at the same time.
CSMA/CA willnot be able to avoid these, since B and C can't hear
each other toavoid colliding.If you replace A with a duplex
(i.e., two-frequency) busy-tone system,then B won't transmit
when C is already on the air, since A will beemitting a busy
tone to notify all stations that A's input channel isin use.
True, if user stations are all running DWAIT=0 channelaccess,
then as soon as the busy tone stops, they'll all jump on theair
and collide.But if the user stations are running p-persistance
and the slottime isset long enough for a station to acquire the
busy tone, then when thefirst transmission ends, each station
will "toss a die" to see if itshould transmit in that slot.  If
the station doesn't transmit at thattime, then it waits one slot
and checks for channel busy again.  Thusyou have reduced the
probability that stations will collide.[A necessary condition
for this is that slottime has to be set largeenough to allow
stations to determine that the channel IS busy, whichmeans that
it must take into account the squelch open time and thedetector
lock-on time of the typical receiver.  For a 1200 bps AFSKsystem
{gack}, probably 250 ms is a reasonable time.  Also,
theprobability value needs to be set to a number slightly less
than thenumber of stations likely to want to transmit at one
time - for atypical metro area, this may be four to eight
stations, so you'd set itto 1/4 to 1/8, or 64/256 or
32/256.]Since having a single station running busy-tone access
is unfair andimpractical, you instead use a repeater.  The
repeater is full-duplex,but the user stations don't have to be.
Any station using the repeaterwill be heard by all stations
using the repeater, and you automaticallyget all the advantages
of busy-tone channel access and collisionavoidance, plus you
extend the range of the stations using it.It is not necessary
for the repeaters to be running 25 watts at 2kmaltitude and
covering 10,000 square km; the concept is JUST AS VALID ifthe
repeater runs less than 1 watt and covers just part of a
city.This latter cellular approach would allow for geographical
re-use ofchannel pairs, and assuming the repeaters can be linked
on some otherfrequency to provide common network access, all
users will benefit fromsuch an arrangement.However, such a
scheme requires quite a bit of cooperation anddedication, as
well as what might be an impractical amount of money andsites,
so I don't hold out much hope of seeing a truely cellular
hampacket radio system any time soon.  Would be nice, though.In
the meantime, let's see what we can do to make what we have
better.Just because we can't do it all isn't a good reason why
we can't do someof it.    -
Brian------------------------------Date: 4 Nov 91 20:22:14
GMTFrom: ulowell!tegra![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedIn article <[e-mail]>
[e-mail] (Bill Gunshannon) writes:   In article
<[e-mail]>, [e-mail] (Dana H.
Myers) writes:   |>    |>   What poor logic. *Using* a full
duplex data repeater is as easy as   |> pressing the repeater
split button on your radio. A full duplex linear   I'm afraid I
don't see the poor logic in this.  Of course, I also don't   see
the logic in "as easy as pressing the repeater split button on
your   radio".  I don't know about your radio, but that doesn't
make mine full    duplex.  I may transmit on a different
frequency than I receive on, but The repeater is full duplex.
The users are half duplex.   I still can only do one or the
other at any given time.  If that is all   the users are doing,
then there is absolutely no advantage to the full   duplex
digi-peater because you still have the hidden transmitter
problem.No, the full duplex repeater has eliminated the hidden
transmitterproblem.  *All* users of the repeater can hear all
the other usersthrough the repeater.  Another advantage is the
lack of store andforward time.   In order for this system to
work, not only the digi-peater, but all the   users have to be
running true full duplex.  They have to be able to hear
themselves transmit so that they know they have captured the
repeater.This is not necessary.  The users running full duplex
will sensecollisions but that is a minimal gain compared to
eliminating the hiddentransmitter problem, which half duplex
users of a full duplex repeatercan do.   If they have not, then
they must shut down the transmitter in order to   not interfere
with the station who has captured it.  That would be full
duplex.  Anything less offers nothing and uses twice as much
spectrum.No, this is wrong.  To summarize:              The repeater
is full duplex              The users are half duplex        This is the
same situation as voice repeaters       All stations can now hear
all the other stations            No hidden transmitters            No collision
detectionjv"Somebody needs to do something--it's just incredibly
pathetic that       it has to be *us*."  -- Jerry Garcia _____|
   | Johnathan Vail | [e-mail]|Tegra|  Member: LPF   |
N1DXG@448.625-(WorldNet) -----  [phone] |
[e-mail]------------------------------Date: 4 Nov 91
14:54:14 GMTFrom:
sdd.hp.com!elroy.jpl.nasa.gov!orchard.la.locus.com!devnet.la.locu
s.com![e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: DCD Mod and
Squelch busyIn article <[e-mail]>
[e-mail] (Mark G. Salyzyn VE6MGS) writes:>[e-mail]
(Dana H. Myers) sez:>>  The weak signals may be exposed
transmitters; i.e., too far away>>for you to jam, but strong
enough to interfere with you. Anyway, the>>TAPR State Machine
asserts DCD on dead carriers (really). So, accidental>>A dead
carrier exhibits NO packet behavior. However, the DCD state
machine,>may be on or off depending on what state it was in just
before the dead>carrier occurs. This is a BUG not a FEATURE and
should not be relied upon.  I agree this is a bug. However, it
appears to be a reliable behaviorthe the TAPR State Machine as
installed in my PK-88.>Anyways, the point of the post is all
this discussion of power control,>avante-garde repeaters and
such seemed a waste since the user base is>often reluctant to
make their TNCs spectrally efficient, little lone>bandwidth
friendly (I could p*k* :-). The usual solution is to use
the>brute force approach (9600 - 56KBaud).   Duplex repeaters
are *not* avant-garde. They've been around forever,at least 25
years in the amateur radio context. Everyone seems to knowhow to
use one.--  * Dana H. Myers KK6JQ         | Views expressed here are    *
* [phone]         | mine and do not necessarily    * *
[e-mail]        | reflect those of my
employer    *------------------------------Date: 4 Nov 91 19:31:55
GMTFrom:
sdd.hp.com!elroy.jpl.nasa.gov!orchard.la.locus.com!devnet.la.locu
s.com![e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedIn article <[e-mail]>
[e-mail] (Bill Gunshannon) writes:>In article
<[e-mail]>, [e-mail] (Dana H.
Myers) writes:>|> >|>   What poor logic. *Using* a full duplex
data repeater is as easy as>|> pressing the repeater split
button on your radio. A full duplex linear>|> translator would
have the advantage of passing all data modes, but would>|> not
provide data regeneration which would lead to less consistent>|>
performance for different users. In either case, full duplex
repeater>|> or linear translator, the users need only do what
they all do now to>|> use a voice repeater.>|> >>I'm afraid I
don't see the poor logic in this.  Of course, I also don't>see
the logic in "as easy as pressing the repeater split button on
your>radio".  I don't know about your radio, but that doesn't
make mine full >duplex.  While I apologize for saying "What poor
logic", I must reiterate that Iam talking about *using* a
full-duplex repeater. Pressing the repeatersplit button on your
radio does indeed allow you to use a full-duplexrepeater. No, it
does not make your radio into a full-duplex radio, butyou don't
need that.>I may transmit on a different frequency than I
receive on, but >I still can only do one or the other at any
given time.  If that is all>the users are doing, then there is
absolutely no advantage to the full>duplex digi-peater because
you still have the hidden transmitter problem.  Please explain
why we still have the hidden transmitter problem. Bymaking the
entire user area audible to all users, no transmitter ishidden.
Sure, most radios run half-duplex, but the hidden
transmitterproblem is (in theory) solved using Carrier Sense
Multiple Access,which checks for a channel busy before starting
to transmit.>In order for this system to work, not only the
digi-peater, but all the>users have to be running true full
duplex.  They have to be able to hear>themselves transmit so
that they know they have captured the repeater.>If they have
not, then they must shut down the transmitter in order to>not
interfere with the station who has captured it.  That would be
full>duplex.  Anything less offers nothing and uses twice as
much spectrum.  What you are describing is Carrier Sense
Multiple Access/CollisionDetection, which is certainly an
improvement over the plain old CSMAwe currently use in packet.
Of course, to actually use CSMA/CD everypacket user would
require special hardware and software, which makesit rather
unattractive....   I must dispute your claim that a duplex
repeater provides no advantage.You are incorrect in stating that
the hidden transmitter problem persistswith a duplex repeater. A
properly designed duplex repeater makes allusers of the machine
equally audible to all other users. There are nohidden
transmitters. However, there is still a window where CSMA
breaksdown and collisions may occur; this is due to the finite
delay fromthe instant a station detects the channel is clear and
the point in timewhen that station can make the channel busy.
This finite delay is thetransmitter keyup delay and any delay in
the signal path in the repeater.   However, it is illustrative
to understand how big the collisionwindows are for the
digipeater and duplex repeater situations. We'llassume a 128
byte packet with only one address pair, which results ina packet
approximately 150 bytes long. At 1200 baud, this packet
willrequire about 1 second to send. Since most packeteers seem
to usesynthesized radios with fairly long TX Delays (150 - 200
mS),#! rnews 1328 spool.mu.eduPath:
spool.mu.edu!samsung!uunet!boulder!parrikarFrom:
[e-mail] (Rajan Parrikar)Newsgroups:
soc.culture.indianSubject: Re: STORY ON DEEPAVALIMessage-ID:
<[e-mail]>Date: 4 Nov 91 22:48:50
GMTArticle-I.D.: colorado.1991Nov4.224850.15784Posted: Mon Nov
4 16:48:50 1991References: <[e-mail]>Sender:
[e-mail] (The Daily Planet)Distribution:
usaOrganization: University of Colorado, BoulderLines:
23Nntp-Posting-Host: toreador.colorado.eduIn article
<[e-mail]> [e-mail] (Madhavan
Narayanan) writes:>Hai>>I plan to invite some of my American
friends on Deepavali,>and I need to tell them convincingly the
story of Deepavali,>can some one out there mail in a simple form
so that>i would not have much tough time in explaining them all
thatis>too difficult to understand.>>thanks in
advance>>Madhavan>[e-mail] are
different versions. The one followed in Goa celebratesKrishna's
victory over the demon Narakasura. Accordingly, onthe Diwali
eve, effigies of Narakasura are put on display inmany
neighbourhoods and all sorts of variety entertainment programmes
are organised. At dawn, the Narakasuras are consignedto the
flames. Wonder if this practice is limited to Goa
only.Rajan=====------------------------------End of Packet-Radio
Digest V91 #285******************************Date: Wed,  6 Nov
91 04:30:04 PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #286To: packet-radioPacket-Radio Digest         Wed,
6 Nov 91       Volume 91 : Issue 286Today's Topics:
  Digital fullduplex repeaters. (2 msgs)                    How
to get the W0RLI BBS code.                     Packet-Radio
Digest V91 #285              W0RLI BBS Code - Incorrect Mailing
AddressSend Replies or notes for publication to:
<[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 4 Nov 91 17:14:31 GMTFrom:
[e-mail]: Digital fullduplex
repeaters.To: [e-mail] idea of bit-level
repeaters surely breaks down inthe case of amateur style
less-than-100%-reliable paths, and when thesystem is not
fully-connected (hidden transmitter problem).Only by receiving
the *whole* of a frame (assuming we are usingHDLC and AX25) and
performing the usual CRC, can we be sure thatthe frame is
'clean' and therefore worth repeating.This implies
store-and-forward at level 2, in other words a frame-level(as
opposed to a bit-level) repeater.I suspect the FCC may take
offence at any repeating of incomplete frames,or those where the
'callsign' octets have been accidentally modified....If you just
regeneratively repeat at the bit level, without checking
thevalidity of the bits in their level-2 context, there is a
strong possibilitythat you will spend some significant time
repeating garbage.For example, your DCD or Statemachine may be
triggered, so you startrepeating on the output frequency, then
you get hit either by aburst of intermod, or a 'hidden station'
stamps on your repeater inputfrequency. The smart repeater
should detect this, and stop repeating; butit has already sent
part of a frame (which it was repeating before
thenoise/intermod. appeared) on the output frequency; others see
therepeater as having repeated an incomplete, junk frame.The
extent to which this is harmful depends on several factors,
someof which are:- (1) Synchronisation time of the modems. (2)
TX/RX changeover time (turnround time) of the radios (3) Typical
duration of a single frame. (4) Ratio of (1+2) to (3)The only
case where i can see a legitimate use for bit-levelrepeaters is
where there is nobody else using the frequencies, boththe
repeater and the stations it links are using highly-directional
beamantennas, and the link shows a very low error rate..An
example would be to link two adjacent valleys, on a
dedicatedfrequency.In other cases, it seems to me that
frame-level repeaters are the preferredsolution. Pete Lucas
[e-mail]    PJML%IA.NWL.AC.UK@UKACRL
G6WBJ.ampr.org------------------------------Date: 6 Nov 91
03:06:39 GMTFrom: [e-mail]: Digital fullduplex
repeaters.To:
[e-mail]@ibma.nerc-wallingford.ac.UK (Pete
Lucas, NERC Computer Services, Swindon) writes:>I suspect the
FCC may take offence at any repeating of incomplete frames,>or
those where the 'callsign' octets have been accidentally
modified....No, since the repeater identifies itself adequately,
its transmitter isidentified within legal requirements.  The
transmitting station hasidentified its transmissions.  There is
no requirement that a voicestation's voice ID has to be repeated
in order to be legal; it need onlyhave been made properly on the
signal emanating from the originatingstation.  The repeater is
responsible for identifying itself.>a strong possibility>that
you will spend some significant time repeating
garbage.Certainly.  However, voice repeaters often repeat
undecipherable weaksignals too.  Since it's to no one's
advantage for it to continue to doso, either the originating
station fixes his problems or he goes away.>The only case where
i can see a legitimate use for bit-level>repeaters is where
there is nobody else using the frequencies, both>the repeater
and the stations it links are using highly-directional
beam>antennas, and the link shows a very low error rate..I
suspect most people using the repeater will be able to present
it withsignals that have a low error rate, even when repeated.
At least, theyhave so far in our tests.>In other cases, it seems
to me that frame-level repeaters are the preferred>solution.If
you have a frame-level repeater and uncontrolled access, you
must transmita busy-tone whenever a candidate frame is being
received (unless you'realready transmitting a
previously-received frame), or else you've justearned back the
hidden-station problem.  And having the repeater be aframe-level
device is the same as adding one digipeater delay into
everyconnection.  I don't think frame-level repeating is much of
a win.    - Brian------------------------------Date: 5 Nov 91
00:11:43 GMTFrom:
news.mentorg.com!mntgfx![e-mail]: How to get
the W0RLI BBS code.To: [e-mail] ... you can
e-mail me here for instructions, or e-mail me via the bbs
network, or call at my homephone (it's listed) or my work
phone.You can download the latest version from the wa6rdhLL BBS
- 916/678-1535 1200-9600 baud, or you can senda formatted
diskette / self-addressed mailer to n6iya:John Smith, 1061 Pine
Drive, Felton, CA 97007.Suspect the folks asking for it are not
on packet, sinceall the above information passed through the bbs
netas bulletins during the past week.   ...  Hank-- Hank Oredson
@ Mentor GraphicsInternet     : [e-mail]
Radio: [e-mail]------------------------------Date:
5 Nov 91 15:22:14 GMTFrom: [e-mail]:
Packet-Radio Digest V91 #285To: [e-mail] JOHN
DOUGLAS:To help out the countrymen/women of my ancestors
(UB5-land) here is what Igot from AA4RE in the way of BBS info.
Now, this is what I call service!*From: Roy Engehausen
<[e-mail]>**Version 2.11 of the AA4RE BB program is
now available.**The primary advantage of BB over the
MBL/RLI/BQE/CBBS....  systems is*the ability to handle multiple
connects per port.  The program uses it*own multitasker and no
DesqView, DoubleDos, etc is required.  On the*down side, BB has
been optimized for speed and requires at least 512K*(and usually
640K) to be used productively.  Only an 8088 based*machine is
required**BB uses a "host-mode" interface so the only TNCs
supported are the TNC-1*and TNC-2 (or clones) with the WA8DED
(or clone) EPROMS installed, the*AEA PK-87, PK-88, PK-232, and
the DRSI PC*PA TNC card.  It also runs*with any KISS TNC using
the G8BPQ PC Node switch.**You can get these programs by sending
a $5 US (or equivalent) to:**  Dave Larton, N6JQJ*  766 El
Cerrito Way, #D*  Gilroy, CA  95020-4149*  [phone]**
John Anderson, N7IJI*  2729 Park Road*  Charlotte, NC  28209*
(704)-333-3249**Canadians can send 5.00 CDN to:**  A.R.E.S.
Group*  Att: REBBS Update*  P.O. Box 35*  St-Jean Chrysostome,*
Quebec,  Canada    G6Z 2L3**For source code, include $2 more
(needs multiple diskettes).  We can*handle all formats of 5 1/4
and 3 1/2 inch diskettes**The software can also be obtained by
downloading from the following BBS:**   WA6RDH BBS --
916-678-1535 -- 300/1200/2400/4800/9600 N81 V.32*   WB3FFV BBS
-- 410-625-0817 -- 1200&2400 (Non-MNP)*              --
410-625-9482 -- 1200&2400 (MNP5), 4800&9600 V.32 (V.42/MNP5)*
          -- 410-625-9663 -- 1200&2400 (MNP5), 9600 & 19200
(PEP)**The software is also loaded onto the W3IWI TOMCAT FTP
server*(tomcat.gsfc.nasa.gov) accessible via both SLIP and thru
the Internet.*It is also at ucsd.edu**The software can also be
delivered via BITNET.  Send a note to ENGE at*ALAMDEN for
deliver over BITNET.BTW, I have started downloading from TOMCAT.
Already sent NT2X the latest copyof W0RLI. Thanx to Roy's info
it looks like the Sov-Hams will have a potpourriof BBS software
to chose from. Now if only governments could share infothis
openly  8^)=      73, Walt (Wolodja) Kornienko -
K2WK------------------------------Date: 5 Nov 91 13:39:58
GMTFrom: fernwood!glenbrook.com![e-mail]: W0RLI
BBS Code - Incorrect Mailing AddressTo:
[e-mail]'s a correction (from HamNet on
CompuServe) to the address that Hank posted for N6IYA:Message:
#85088, S/9  Packet RadioDate:    Mon, Nov 4, 1991 11:17:16
PMSubject: #85053-W0RLI Packet BBSFrom:    Russ  NW6U
74017,1577To:      HamNet SysOp Scott W3VS 76703,407 (private)
(deletable)Saw message on obtaining latest RLI code.
Unfortunately, the address for John Smith N6IYA is incorrect as
listed. Correct is: 1060 Pine Drive, Felton, CA 95018 ---Hope
you can correct it before all those requests get lost. Russ NW6U
@
KI6EH.#NOCAL.CA..................................................
....................    Scott Loftesness, 515 Buena Vista Ave.,
Redwood City, CA 94061    Fax: [phone]
Internet: [e-mail]                 Others:
[e-mail]   -or-
[e-mail]:::::::::::::::::::::::::::::::::::::::::
:::::::::::::::::::::::::::::
------------------------------Date: 4 Nov 91 19:49:02 GMTFrom:
elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!qt.cs.utexas.edu!yale.ed
u!spool.mu.edu!cs.umn.edu!uc.msc.edu!apctrc!voyager![e-mail]
a.eduTo: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>olReply-To :
[e-mail] : Re: Amateurs on USENET List
[CORRECTION]I would just e-mail this to the author, but since
this incorrect info hasgone out again, I'd just assume people
who might otherwise try to contact mevia this bad info see the
correction now, instead of in (hopefully) the nextposting of
this.In article <[e-mail]>
[e-mail](Mark G. Salyzyn VE6MGS)
writes:>[e-mail]                n5ial    Jim D.
Graham>[e-mail]            n5ial    Jim D.
Graham>[e-mail]                n5ial    Jim D. GrahamAll of the
addresses above are incorrect, and will get you nothing
butbounced mail.  Even though you see me post from these
addresses, they arestrictly News --- NO E-MAIL.  Please update
the list to show the followingcorrect
information:[e-mail]                n5ial    James D.
[e-mail]                n5ial    James D.
[e-mail]                n5ial    James D.
Grahamj.graham.ieee.org currently points to
[e-mail], but is listedfirst, since if my email
address changes, this will remain constant.Mark, please QSL your
receipt of this to any of the above addresses (in thecorrected
list....  :-)  ).  Thanks.   --jimStandard disclaimer....Ever
since my cat learned to type, there's no tellingwhose thoughts
these really are....         73 DE N5IAL
(/9)-------------------------------------------------------------
-----------------"Oh dear, I think you'll find reality's on the
blink again."                                          -- Marvin
The Paranoid AndroidINTERNET:  [e-mail]
____________________________________________
[e-mail] || AMATEUR RADIO (Packet):
[e-mail]     || TCP/IP: [e-mail]
(44.72.47.193)COMPMAIL:  j.graham              || AX.25:
n5ial@wb9yae
(Chicago.IL.US.Earth)--------------------------------------------
----------------------------------------------------------------D
ate: 5 Nov 91 16:44:35 GMTFrom: [e-mail]:
[e-mail]
<[e-mail]>, <[e-mail]>,
<[e-mail]>Subject : Re: Beginner packet
help needed.For a really fast switch, you might care to look at
the GracilisPackeTen product.  Although there are currently some
rough edges tosmooth out, it has the promise of being the
premier packet switch forseveral years to come.It comes in two
flavours: one is a PC-based card, the other standalone.Each
handles 5 ports, three of which are megabit rated and the other
twonot quite so fast.  You can even plug them together to get 10
ports ina pc-based architecture.It runs a modified version of
Phil Karn's NOS, including a nice net/romimplementation for
backwards compatability with obsolete networks.We're installing
one here in San Diego sometime in the next few months,with 56kb,
9600 and 1200 bps full-duplex repeater user access, 9600
bpsmetropolitan trunking, and it will participate in the
CaliforniaIntercity network.  I think it will give us a really
nice network hubfor some advanced packeting.  We may even put up
a second one someday.This is the sort of community resource that
people CAN get together tofinance and support, and all the
packeteers in the area benefit thereby.    -
Brian------------------------------Date: 5 Nov 91 06:59:57
GMTFrom:
swrinde!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!alberta!adec23!au
nro!ve6mgs![e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: DCD mod and
Squelch busyI said:>>may be on or off depending on what state it
was in just before the dead>>carrier occurs. This is a BUG not a
FEATURE and should not be relied upon.Dana H. Myers
([e-mail]) replies:>  I agree this is a bug. However, it
appears to be a reliable behavior>the the TAPR State Machine as
installed in my PK-88.I have it in my HK-232 and it is `stock'
in the MFJ-1270 and I can flip acoin on it's behavior on dead
carriers :-(>   Duplex repeaters are *not* avant-garde. They've
been around forever,>at least 25 years in the amateur radio
context. Everyone seems to know>how to use one.It is avant-garde
if YOU need a duplexer or set of cans at EVERY sitejust to use
the advantages of a regenerative repeater. You do NOT get
anyadvantages (except wasting two frequencies rather than one)
unless you canhear the output of the repeater while transmitting
to see if you collided withsomeone. I use avant-garde as a dirty
word here (like user friendly) since Isee no advantages ... The
cost of a duplexer or cans for each user as well asthe repeater
makes my skin crawl.Don't tell me that you can hear when you are
doubling with someone on thevoice repeater. The solution is to
go cross band (bent pipe was it?) tomake life easier. Again, a
cost, since a dual bander DIGITAL radio is NOTavailable
commercially (I think, correct me and I will be converted).Wow,
I havn't held a train of thought this long since I tried to
tunea set of dual webbers :-).Ciao, 73 de VE6MGS/Mark
-sk-------------------------------Date: 5 Nov 91 14:53:55
GMTFrom:
swrinde!cs.utexas.edu!wupost!emory!wa4mei!ke4zv![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To : [e-mail] (Gary
Coffman)Subject : Re: Digital Packet Repeater Info WantedIn
article <[e-mail]> [e-mail]
(Bill Gunshannon) writes:>>I'm afraid I don't see the poor logic
in this.  Of course, I also don't>see the logic in "as easy as
pressing the repeater split button on your>radio".  I don't know
about your radio, but that doesn't make mine full >duplex.  I
may transmit on a different frequency than I receive on, but >I
still can only do one or the other at any given time.  If that
is all>the users are doing, then there is absolutely no
advantage to the full>duplex digi-peater because you still have
the hidden transmitter problem.>In order for this system to
work, not only the digi-peater, but all the>users have to be
running true full duplex.  They have to be able to
hear>themselves transmit so that they know they have captured
the repeater.>If they have not, then they must shut down the
transmitter in order to>not interfere with the station who has
captured it.  That would be full>duplex.  Anything less offers
nothing and uses twice as much spectrum.Bill, it's the
*repeater* that is full duplex, the users continue tooperate
half duplex. This gives you reliable CSMA, but as you notedoes
not give true CD, so collisions can occur undetected if two
users start transmitting at *exactly* the same time. This isn't
toolikely for two reasons, the window of vulnerability is small,
andp-persistence randomizes the dwait value. What it does do is
totallyeliminate hidden transmitters. This eliminates 99% of the
collisionsthat occur on a simplex store and forward digipeater.
Since everyone is listening to the repeater output, and the
repeater keys up immediately when a packet appears on it's
input, there's no store and forward delay, most collisions are
avoided. In a simplex digipeater network,many stations cannot
hear each other while all can hear the digi.  When a station
keys up to send a packet to the digi, he may clobber another
station that is already transmitting to the digi. With a duplex
repeater, that is avoided. Therefore the only opportunity for
collisions is the small key up delay of the repeater rather than
the entire duration of a packet. Adding full duplex at the user
end only closes that small few millisecond window of
vulnerability and gains little in collision avoidance while
increasinguser station cost markedly by requiring a duplexer at
every station.If you detect a collision while running full
duplex, both stations,you and the collidee still will have to
retry the trashed packets, sounkeying immediately upon CD
doesn't help thruput.Gary
KE4ZV------------------------------Date: 6 Nov 91 02:57:01
GMTFrom: [e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: DCD mod and
Squelch [e-mail] (Mark G. Salyzyn VE6MGS) shows his
ignorance:>Don't tell me that you can hear when you are doubling
with someone on the>voice repeater.Of course I can.  I'm running
a Motorola Micor in my car, and itsimultaneously receives the
repeater's output while I'm transmitting onthe repeater's input.
 It runs 50 watts out, was built 15 years ago,and I paid $150
for it.  Lots of them at the swapmeets for $50 thesedays.Oh,
you've got one of those Japanese ham-grade radios?  Well, you
haveonly yourself to blame for buying sub-standard
equipment.Wasn't it Rush that had a song about how all the trees
were kept equalby axe and chainsaw?Anyway, that's all
irrelevant.  In another message, I explained why a"bent pipe"
repeater was a big win for packet operation even when theusers
aren't duplex.  Please take a moment to read and understand
it.    - Brian------------------------------Date: 5 Nov 91 06:46:20
GMTFrom:
swrinde!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!
van-bc!ubc-cs!alberta!adec23!aunro!ve6mgs![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: DCD mod and
Squelch [e-mail] (Gary Coffman) writes:>I don't
consider our 56 kb system brute force. We only occupy 1.2 hz>per
baud. That's much better than the 20 hz per baud of other
schemesOk, I concede the point. Except (no experience here yet
:-( ) I believe manyfeel that is the solution to the problem of
poorly set up 1200 Baud systems.I have tripled my throughput by
improving my system WITHOUT UNDUELY TAKINGCHANNEL FROM OTHER
STATION. Sure, I could set ppersist to 256 and slottimeto 0 ..
but I don't. I have a 50ms keyup time (poor relays batman) that
Iendeavor to improve. I (and others) have pushed for the DCD mod
to allowshorter TXDELAY/AUDELAY. I have pushed (unsuccessfully)
the use of RFCARRIER DETECT to keep unruly transmissions. I am a
saint and my father isbigger than your father ...>Using voice
squelch systems on a data radio is an abomination that>wastes
valuable channel time for weak noise bursts and stations so
far>away that our transmission won't interfere anyway. That's
what FM capture>...>is for. Not to mention the abominable
squelch opening delays that cause>other stations to extend their
TXD in order to communicate with the slowest>radio on the
channel. Use of AF squelch is the wrong solution to a mostlyTHAT
is what I am saying. However, keep in mind that a signal 20dB
downwill disrupt FM capture enough to make the packet unreadable
(out of fullquieting) so you may be surprised how weak of a
station can hurt you. And,keep in mind that weak station is
trying to hit the node, and YOU may bewasting his channel access
by being so unfriendly. Classic Hidden Transmitterproblem.I
proport that an unsquelched high quality audio (usually from the
topof the volumn control pot) AND the squelch busy signal
combined provideyour best system for the single frequency
compromise. I had to providea little bit of audio amplification
(6dB) on one of my rigs, but theother two work fine as is. The
squelch busy signal usually needed aswitching transistor or two
to get the signal just right. The squelch busy,backing off your
access to the channel, may in fact be improving thegeneral
throughput of your area of influence (for a lack of a better
name)by not allowing you to stomp on `some' of the hidden
transmitters.The advantage, is that you can listen in on the
packet channel (to debugproblems and set the squelch regularily
if not automatically done) withoutaffecting the TNCs audio.Ciao,
73 de VE6MGS/Mark -sk-------------------------------Date: 5 Nov
91 17:08:26 GMTFrom:
pacbell.com!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-
state.edu!sol.ctr.columbia.edu!emory!wa4mei!ke4zv![e-mail]
: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>olumbReply-To : [e-mail] (Gary
Coffman)Subject : Re: DCD Mod and Squelch busy (Was Re: Info on
packet repeaters)In article <[e-mail]> [e-mail]
(Tom B.) writes:>>I know there is a line in PLL chips that
signals when the PLL is locked.>Couldn't this line be wired into
the TNC, and replace TXDelay=RaNdOm#?No, because it doesn't
answer the fundamental problem. PLL lockup isnot the only cause
of transmitter delay. Many rigs still use relaysfor TR. Most
switch voltages on and off in the transmit and recievechains
during TR. All this requires settling time. Often the
greatestdelay in the system is the recharging of capacitors in
the audio chain.Txdelay compensates for both transmitter and
receiver response delays.You must set it so that your
transmitter has time to get to full power,and so that the
*slowest* receiver in the system has time to recoverand
unsquelch. This is the real killer, the slowest receiver in
the*system* determines Txdelay for everyone else. That's why
using audiosquelch is very very bad. DCD state machines and open
squelch speedsup the entire *system*. P-persistence, the random
number that determineswhen Txdelay *starts* is an important
*contention* management feature in newer TNC firmware. It is in
fact a randomizer for Dwait. It prevents a pair of stations from
repeatedly retrying on top of each other and timing out.>I know
most people want to have the option of removing the packet>radio
and not have lotsa wires, but when was the last time your
radio>left the TNC.Most of the radio *improvements* that could
reduce Txdelay are internalmodifications to the TR system and
require no external wires. Theywon't affect voice operation.
Dedicated RF modems are a better answerto packet radio since
they can be optomized from the start for shortturnaround.>What
is the idea for the optimum solution?  What I would like to>see
are multiple freq's.  the 1200 baud folks can stay on
145.0X,>the 9600 baud folks can go to 4XX.YY, and the 56KB can
be organized>on {900, 1.2G, ...}.  Some separation for backbones
of traffic, but>most 56KB stuff would probably end up like the
internet (hopefully>only the good stuff), with telnet
connections, and some FTP, and some>SMTP, this an X session
thrown in for keeping things busy.This is basically what we
already do in Georgia, though many of our56 kb trunks use 223
Mhz because they have to span relatively longdistances, our
longest hop is currently 57 miles. We use 433 Mhz56 kb trunks
too and try to use a frequency inversion scheme sothat adjacent
nodes aren't talking on the same frequency. This requires two RF
modems at each switch site, but reduces contentionto nil. Our
9600 baud work centers on a 440 Mhz full duplex repeaterand a
440 Mhz simplex frequency. Our 1200 baud work is divided
amongLANs on the various 145.0x Mhz frequencies and on a 146 Mhz
duplexrepeater. Everyone is linked together via the 56 kb
trunks.>Yes anything at or above 9600 should be full duplex
(actually the 1200 >should be also, but who's gonna listen?)
This leads to weird repeater>situations, and might be real hard
to keep organized.  Full duplex at each user station is not very
helpful at the lower speeds,and not really important at the
higher speeds until you start to dointeractive work with short
packets. The requirement for a duplexer orcrossband equipment at
each user site is too expensive for a largeuser base to support.
Full duplex at a central repeater site is importanthowever. It
eliminates hidden transmitters for an entire LAN at the costof
only one duplexer.>Probably better solutions would be spread
spectrum, or 'cellular' type>solutions.  Using the FDDI type
protocols, with a specific frequency>designated for organizing
the FDDI stuff.  How about the 1200baud modem>communicating to a
clearing house, asking for a slot in the protocol,>the
clearinghouse grants, the 56KB modem listens for the slot, and
>handles the transactions.  When done the 1200 baud modem tells
the >clearinghouse everything is done and the connection is
closed.This is only useful when many users have line of sight
with each other.That is very rare in our area. When high cell
sites are required togive connectivity, cost and complexity of
the *system* rise rapidly.Gary
KE4ZV------------------------------End of Packet-Radio Digest
V91 #286******************************Date: Thu,  7 Nov 91
04:30:05 PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #287To: packet-radioPacket-Radio Digest         Thu,
7 Nov 91       Volume 91 : Issue 287Today's Topics:
         DCD mod and Squelch busy                Digital
fullduplex repeaters. (2 msgs)                    How to get the
W0RLI BBS code.Send Replies or notes for publication to:
<[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 6 Nov 91 01:39:11 GMTFrom:
gatech!ncar!asuvax!anasaz!qip![e-mail]: DCD mod and
Squelch busyTo: [e-mail]: In article
<[e-mail]> [e-mail] (Mark G.
Salyzyn VE6MGS) writes:]It is avant-garde if YOU need a duplexer
or set of cans at EVERY site]just to use the advantages of a
regenerative repeater. You do NOT get any]advantages (except
wasting two frequencies rather than one) unless you can]hear the
output of the repeater while transmitting to see if you collided
with]someone. I use avant-garde as a dirty word here (like user
friendly) since I]see no advantages ... The cost of a duplexer
or cans for each user as well as]the repeater makes my skin
crawl.This is just plain nonsense. You don't need full dux in
CSMA. Onlyin CSMA/CD is it required.You get significant
advantage because your carrier detect signal hearsstations that
start before you transmit, reducing collisions.
Also,regeneration will reduce the error (and hence
retransmission) ratebecause people who might be on the channel
with weak signals simplex willhave better signals through the
repeater in most cases.-- John Moore NJ7E, 7525 Clearwater Pkwy,
Scottsdale, AZ 85253  (602-951-9326)ncar!noao!asuvax!anasaz!john
[e-mail] anasaz![e-mail]"It would be
thought a hard government that should tax its people one tenth
part..." B. Franklin   - Standard Disclaimer Applies - - -
Support ALL of the bill of rights, INCLUDING the 2nd amendment!
- -------------------------------Date: 6 Nov 91 15:27:20
GMTFrom:
sdd.hp.com!news.cs.indiana.edu!mips!swrinde!elroy.jpl.nasa.gov!or
chard.la.locus.com!devnet.la.locus.com![e-mail]:
Digital fullduplex repeaters.To: [e-mail] article
<04.Nov.91.17:24:54.GMT.#[e-mail]>
[e-mail] (Pete Lucas, NERC Computer
Services, Swindon) writes:>>The idea of bit-level repeaters
surely breaks down in>the case of amateur style
less-than-100%-reliable paths, and when the>system is not
fully-connected (hidden transmitter problem).  Surely breaks
down? We're talking about duplex data repeaters.They work just
like voice repeaters. There's really no difference.They
eliminate the hidden transmitter problem, dramatically
reducingthe chance of collision between stations.>Only by
receiving the *whole* of a frame (assuming we are using>HDLC and
AX25) and performing the usual CRC, can we be sure that>the
frame is 'clean' and therefore worth repeating.  Repeat 'em all
and let God sort 'em out.>I suspect the FCC may take offence at
any repeating of incomplete frames,>or those where the
'callsign' octets have been accidentally modified....>If you
just regeneratively repeat at the bit level, without checking
the>validity of the bits in their level-2 context, there is a
strong possibility>that you will spend some significant time
repeating garbage.    The FCC has never had a problem with
people that are only 10%readable on a voice repeater; why should
they start worrying aboutdata frames which are noisy on
packet?>For example, your DCD or Statemachine may be triggered,
so you start>repeating on the output frequency, then you get hit
either by a>burst of intermod, or a 'hidden station' stamps on
your repeater input>frequency.   For all practical purposes, you
won't ever have hidden stationson a duplex data repeater.
Certainly it is possible, but not likely.> The smart repeater
should detect this, and stop repeating; but>it has already sent
part of a frame (which it was repeating before
the>noise/intermod. appeared) on the output frequency; others
see the>repeater as having repeated an incomplete, junk frame.
Why is this a problem?>The extent to which this is harmful
depends on several factors, some>of which are:->> (1)
Synchronisation time of the modems.> (2) TX/RX changeover time
(turnround time) of the radios> (3) Typical duration of a single
frame.> (4) Ratio of (1+2) to (3)  Why are any of these
considerations with respect to corrupt dataframes? I don't see
your point.  Brush up on how duplex data repeaters work. Send me
a SASE andI'll send you copies of the ARRL Computer Networking
Conferencepapers on this subject (This offer is open to all).
You'll seethat your concerns are moot.--  * Dana H. Myers KK6JQ
        | Views expressed here are    * * [phone]         | mine and do
not necessarily    * * [e-mail]        | reflect those of my
employer    * * "Dammit Bones, spare me the lecture and give me the
shot!"   *------------------------------Date: 6 Nov 91 15:32:38
GMTFrom: ulowell!tegra![e-mail]: Digital
fullduplex repeaters.To: [e-mail] article
<04.Nov.91.17:24:54.GMT.#[e-mail]>
[e-mail] (Pete Lucas, NERC Computer
Services, Swindon) writes:   The idea of bit-level repeaters
surely breaks down in   the case of amateur style
less-than-100%-reliable paths, and when the   system is not
fully-connected (hidden transmitter problem).   Only by
receiving the *whole* of a frame (assuming we are using   HDLC
and AX25) and performing the usual CRC, can we be sure that
the frame is 'clean' and therefore worth repeating.   This
implies store-and-forward at level 2, in other words a
frame-level   (as opposed to a bit-level) repeater.   I suspect
the FCC may take offence at any repeating of incomplete frames,
 or those where the 'callsign' octets have been accidentally
modified....IMHO, repeating garbage packets with incomplete
callsigns is not alegal problem as long as the repeater IDs
*itself*.  The individualrepeated packets are not IDing the
repeater, they presumably wereIDing the original station.   If
you just regeneratively repeat at the bit level, without
checking the   validity of the bits in their level-2 context,
there is a strong possibility   that you will spend some
significant time repeating garbage.This could be true but what
else would you be doing with that time?Your reciever is busy
recieving the garbage and not doing useful workanyway.   If this
becomes a problems then it is a problem that theoriginating
station needs to work out and is a network managementproblem and
not anything wrong with the use of a repeater.   For example,
your DCD or Statemachine may be triggered, so you start
repeating on the output frequency, then you get hit either by a
 burst of intermod, or a 'hidden station' stamps on your
repeater input   frequency. The smart repeater should detect
this, and stop repeating; butAs I believe, there is not legal
reason to stop repeating and notechnical reason either since the
transmitting station will continueto send.  Unless it is also
full duplex and includes collisiondetection.  In that case it
stops itself and no "smarts" are needed bythe repeater.   The
only case where i can see a legitimate use for bit-level
repeaters is where there is nobody else using the frequencies,
both   the repeater and the stations it links are using
highly-directional beam   antennas, and the link shows a very
low error rate..The legitimate use I see is to eliminate hidden
transmitters andprovide a little better turnaround time over
store and forwarddigipeaters.  Since the repeater is a fixed
location and all the usersare presumably fixed, beam antennas
are a very good idea to boost linkmargins and promote re-use of
the repeater pair.jv"Gravity pulls the trousers down
Morality pulls the trousers up" -- Bedful of Metaphysicians
_____|     | Johnathan Vail     [e-mail]     (508)
663-7435|Tegra|      MEMBER: League for Programming Freedom
-----   [e-mail]
N1DXG@448.625-(WorldNet)------------------------------Date: 6
Nov 91 15:34:44 GMTFrom:
pacbell.com!mips!swrinde!cs.utexas.edu!tamsun!cs.tamu.edu!willis@
ucsd.eduSubject: How to get the W0RLI BBS code.To:
[e-mail] article
<[e-mail]>, [e-mail]
writes:[skip]|> Suspect the folks asking for it are not on
packet, since|> all the above information passed through the bbs
net|> as bulletins during the past week.|> What makes you think
that the bbs net can get all messages distributedto all the bbs
nodes within a week (or so) ?WillisInternet:
[e-mail]:
n5szf@w5ac.#wtx.tx.usa.noam------------------------------Date: 6
Nov 91 21:43:51 GMTFrom:
uakari.primate.wisc.edu!sdd.hp.com!cs.utexas.edu!tamsun!cs.tamu.e
du![e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedIn article
<[e-mail]>, [e-mail] (Dana H.
Myers)writes:[skip]"The hidden transmitter problem is
eliminated. Completely. 100%. Everyreceiver on the duplex
machine can hear every other transmitter. 100%."While I agree
wholeheartedly with the arguments for duplex repeaters, theabove
statement is a bit optimistic.  What (I think) you mean is
that:"Every receiver on the duplex machine {i.e. those that can
hear therepeater} can hear every other transmitter THAT THE
REPEATER CAN HEAR."There will still be cases of systems the
repeater cannot hear but that can& will be heard by stations in
the repeater's area.  Packet frequency usageand siting would
have to coordinated a whole lot more than it is now tocompletely
eliminate the possibility.On a side issue, can anyone tell me if
the Ramsey 2m kits can readily beset up for duplex
operation?Cheers, Willis
n5szf------------------------------Date: 6 Nov 91 12:47:23
GMTFrom:
netnews.upenn.edu!uofs!vulture.cs.uofs.edu![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedOK.  Now I think we all agree.  What I think
caused some of the confusion isthe concept of "full duplex" as
oppoesd to "half duplex".  I will agree thatthe hidden
transmitter problem is reduced but definitely not eliminated.
Afterall, I am sure we have all heard a double on a voice
repeater. And in that case we are not talking about 200 msec
response times. :-)I personally would like to see CSMA/CD
implemented, but it probably isn't comingsoon. So, lets get
practical.  I have a couple of DR-200s friom PACCOMM.  What is
thelikelyhood that I could throw together the necessary software
to make one of thesereceive on one channel and immediately
retransmit the bits on the other channelthus providing a cheap,
regenerating, full-duplex repeater??I'm probably going to give
it a try one way or the other as the only other choicefor these
boxes is ROSE and I don't see a lot of interest in doing
that.Basicly, I plan to look at making it take the bits exactly
as it receives them stuff them out the other port.Any c omme

nts??All the best.bill    KB3YV--      Bill Gunshannon
|        If this statement wasn't here,
[e-mail]   |  This space would be left
intentionally blank     [e-mail]    |
#include <std.disclaimer.h>
------------------------------Date: 6 Nov 91 16:36:17 GMTFrom:
mcsun!fuug!nntp.hut.fi!vipunen.hut.fi![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>, <[e-mail]>fiReply-To
: [e-mail] (Kaj Wiik)Subject : Re: Beginner packet
help needed.In article <[e-mail]> [e-mail] (Brian
Kantor) writes:>For a really fast switch, you might care to look
at the Gracilis>PackeTen product.  Although there are currently
some rough edges to>smooth out, it has the promise of being the
premier packet switch for>several years to come.>>It comes in
two flavours: one is a PC-based card, the other standalone.>Each
handles 5 ports, three of which are megabit rated and the other
twoWhat is the approximate price class the PackeTen cards will
fall?Kaj OH6EH/2--
-----------------------------------------------------------------
--------------Helsinki University of Technology,       |
[e-mail]              |Metsahovi Radio Research Station         |
!EID RO EVOM                   |Otakaari 5A, SF-02150 Espoo, Finland     |
oh6eh@oh2rba                  |------------------------------Date: 5 Nov
91 18:57:40 GMTFrom:
usc!elroy.jpl.nasa.gov!orchard.la.locus.com!devnet.la.locus.com!d
[e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>7Subject : Re: DCD mod and
Squelch busyI firmly stated:   Duplex repeaters are *not*
avant-garde. They've been around forever,  at least 25 years in
the amateur radio context. Everyone seems to know  how to use
one.And Mark G. Salyzyn (VE6MGS) replied:  It is avant-garde if
YOU need a duplexer or set of cans at EVERY site  just to use
the advantages of a regenerative repeater. You do NOT get any
advantages (except wasting two frequencies rather than one)
unless you can  hear the output of the repeater while
transmitting to see if you collided with  someone. I use
avant-garde as a dirty word here (like user friendly) since I
see no advantages ... The cost of a duplexer or cans for each
user as well as  the repeater makes my skin crawl.Now,
patiently, I state:  Elimination of the hidden transmitter
syndrome is a major win. Even a  half-duplex user of a full
duplex machine enjoys this. I have always  thought that it is
intuitively obvious that making all of the transmitters  visible
to all the receivers eliminates the hidden transmitter problem.
I don't know how to make it any clearer. You don't need to run
full-duplex  and detect collisions at the user site; it is only
an incremental  improvement, which is made less useful by the
fact that collisions are  less likely.  Don't make things more
complicated than they need to be.--  * Dana H. Myers KK6JQ         |
Views expressed here are    * * [phone]         | mine and do not
necessarily    * * [e-mail]        | reflect those of my employer    *
* "Dammit Bones, spare me the lecture and give me the shot!"
*------------------------------Date: 6 Nov 91 17:29:43 GMTFrom:
pacbell.com!mips!swrinde!elroy.jpl.nasa.gov!orchard.la.locus.com!
devnet.la.locus.com![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedIn article <[e-mail]>
[e-mail] (Bill Gunshannon) writes:>OK.  Now I
think we all agree.  What I think caused some of the confusion
is>the concept of "full duplex" as oppoesd to "half duplex".  I
will agree that>the hidden transmitter problem is reduced but
definitely not eliminated.  After>all, I am sure we have all
heard a double on a voice repeater.> And in that case >we are
not talking about 200 msec response times. :-)  The hidden
transmitter problem is eliminated. Completely. 100%.
Everyreceiver on the duplex machine can hear every other
transmitter. 100%.However, you are right that there will still
be collisions. The collisionswill *not* be due to hidden
transmitter syndrome, though. The collisionsare due to the delay
from the time a station starts transmitting tothe time another
station starts receiving. This delay is the combinationof
transmitter keyup delay, propagation delay to and from the
repeater,and receiver DCD response time. The propagation delays
are short, supposethe repeater is 40 miles away, the delay due
to propagation is around200 uS. The receiver DCD response, if
using a good circuit like a statemachine, will be less than,
say, 16 bit times, or 13 mS at 1200 baud.The transmitter keyup
delay is the most important. Most synthesizedradios require 150+
mS to start transmitting from the time PTT isactivated.  On a
voice repeater, the 150+ mS delay is enough to lead to
voicecollisions. On a data repeater, the same is true.  How is
the likelihood of a collision reduced on a duplex machine?  A
couple of ways. First of all, *stop using slow PLL radios for
packet*.Use a crystal controlled radio for packet. They switch
much, much faster,and introduce much less phase induced noise in
your signal. They'recheaper, too. Crystal controlled radios are
plentiful and cheap atswap meets. It simply doesn't make sense
to take an 800+ channel PLLsynthesized radio and dedicate it to
one packet channel. Take a crystalradio and buy one pair of
crystals and be done with it. The fasterTX Delay reduces the
chance of collision and increases your throughput.  The next way
to reduce collisions is to introduce a randomdelay after the
channel clear before transmitting. This delay shouldbe long
enough to allow a transmitter to become audible. Persistanceis a
little better; every transmitter rolls a die and decides
whetherto wait or to transmit right away. Ideally, the
probability ofeach transmitter deciding to transmit should be
about 1/n, wheren is the number of transmitters competing for
the channel at once.> So, lets get practical.  I have a couple
of DR-200s friom PACCOMM.> What is the likelyhood that I could
throw together the necessary software> to make one of these
receive on one channel and immediately retransmit> the bits on
the other channel thus providing a cheap, regenerating,>
full-duplex repeater?? I'm probably going to give it a try one
way or> the other as the only other choice for these boxes is
ROSE and I don't> see a lot of interest in doing that.  If you
are going to run the transmitter and receiver at the sametime,
you need to make certain to provide sufficient isolationbetween
them. You can either use separate antennas a good distanceapart,
separate frequencies a good distance apart (like a factor of2 or
more), or a single antenna with a duplexer. Look in the
ARRLHandbook in the section on FM repeaters for more information
onsetting up a duplex repeater.--  * Dana H. Myers KK6JQ         |
Views expressed here are    * * [phone]         | mine and do not
necessarily    * * [e-mail]        | reflect those of my employer    *
* "Dammit Bones, spare me the lecture and give me the shot!"
*------------------------------End of Packet-Radio Digest V91
#287******************************Date: Fri,  8 Nov 91 04:30:04
PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #288To: packet-radioPacket-Radio Digest         Fri,
8 Nov 91       Volume 91 : Issue 288Today's Topics:
   Connecting my W2A to a PK88 (3 msgs)
CSMA/CD vs. CSMA/CA (2 msgs)                  DCD mod and
Squelch busy (2 msgs)                    Digital fullduplex
repeaters.                        getting W0RLI BBS Code
                  PRMBS and CDROM?Send Replies or notes for
publication to: <[e-mail]>Send subscription
requests to: <[e-mail]>Problems you can't
solve otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 6 Nov 91 18:33:00 GMTFrom:
pacbell.com!mips!zaphod.mps.ohio-state.edu!uakari.primate.wisc.ed
u!aplcen!wb3ffv!ka3ovk!irscscm!sunstone!sunstone![e-mail]
ubject: Connecting my W2A to a PK88To: [e-mail]
recently bought a PK88 and am trying to decide the best way to
wireit to my Icom W2A.  I would like to be able to
receive/transmit packet on oneband, with the option of listening
to my favorite voice repeater on theother.  Has anyone done
this?  (that's a silly question, there always is at leastsomeone
on here that has done EVERYTHING!)Any help would be appreciated.
 I can't seem to find anyone in my area witha W2A.Thanks!--
INTERNET:[e-mail]:...uunet!media!ka3ovk!irscscm
!sunstone!georgeISA:SM:AUR   IRS/AUR - Standard disclaimer
applies         (FTS)586-6882
[phone]------------------------------Date: 7 Nov 91
05:25:28 GMTFrom:
ub!dsinc!wells!beyonet![e-mail]: Connecting my
W2A to a PK88To: [e-mail]@sunstone.uucp
(George Vogel) writes:>I recently bought a PK88 and am trying to
decide the best way to wire>it to my Icom W2A.  I would like to
be able to receive/transmit packet on one>band, with the option
of listening to my favorite voice repeater on the>other.      <*> I
would like to know if this can be done to most or all
dual-band mobile radios?Steve
Urich            WB3FTP            [e-mail]------------------------------D
ate: 7 Nov 91 17:05:07 GMTFrom:
pa.dec.com!nntpd.lkg.dec.com!regent.enet.dec.com![e-mail]
c.comSubject: Connecting my W2A to a PK88To:
[e-mail] article
<[e-mail]>, [e-mail]
(George Vogel) writes:|>I recently bought a PK88 and am trying
to decide the best way to wire|>it to my Icom W2A.  I would like
to be able to receive/transmit packet on one|>band, with the
option of listening to my favorite voice repeater on the|>other.
 |>Has anyone done this?  (that's a silly question, there always
is at least|>someone on here that has done EVERYTHING!)|>|>Any
help would be appreciated.  I can't seem to find anyone in my
area with|>a W2A.|>|>Thanks!|>|>--
|>INTERNET:[e-mail]|>UUCP:...uunet!media!ka3ovk!irs
cscm!sunstone!george|>ISA:SM:AUR   IRS/AUR - Standard disclaimer
applies|>         (FTS)586-6882   [phone]|>    This should be
fairly easy to do. The interface for the speaker and microphone
is the same electricaly as the older Icom walkies. When you plug
into the mic/sp1 connector, you have ground on the shell,
speaker on the tip and mic on the ring. Use the hookup that the
PK88 lists for the Icom walkies but make the connector for the
W2 - you still have all three leads that the other walkies
had.    To listen to the other band at the same time you will need
to plug either an earphone or another speaker into the sp2
connector. Without this, the audio fo rthe second band will go
to the PK88!    /s/    Bob Gettys
N1BRM------------------------------Date: 7 Nov 91 06:13:20
GMTFrom:
sdd.hp.com!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!alberta!adec23
!ve6mgs![e-mail]: CSMA/CD vs. CSMA/CATo:
[e-mail] Moore NJ7E sez:>This is just plain
nonsense. You don't need full dux in CSMA. Only>in CSMA/CD is it
required.That is what I am arguing for. Dana and I have had a
little e-mail discussion(or was it an argument :-) going about
this (Dana:/CA or Me:/CD). I feel thatif we design /CD into the
system (Full duplex repeaters and Full duplex usersites) that
the system will cost the same if done properly.IF we go for the
CSMA/CA model now, we have to trash it to get the /CDmodel, thus
it will NEVER be done. However, the same considerations fora
full duplex user site are made for a Half Duplex CSMA/CD site,
savingon (what I feel to be) useless technology associated with
CSMA/CA channels.Now, you can all correct me if I am wrong, but
if we press for thedevelopment of a dual band data radio (ie, 2W
TC on 440, 220MHz RX)we solve the costs of the cans (duplexers)
and I am sure it will costthe same as any single band data radio
AND supplies us with FULL DUPLEXoperation if we need it to boot.
For the 56Kbps modem, a dual bandtransverter would be in order,
this, unfortuneatly, would be moreexpensive than the simplex
version (A chink in the armour :-{ ).Now, if you use a dual band
(ie 220MHx TX and 440MHz Rx) regenerativerepeater, cheaper,
since we do not need cans for it. The the single bandrepeater
would require cans. We could run CSMA/CD with the dual band
dataradio with, I am sure, a simple mod to the KISS EPROM
firmware.Or, we could use these (dual band, user site, and
repeater site) as the basisfor a FULL DUPLEX site to site link.
And, my imagination goes wild on whatwe could do if the Repeater
was smart (rather than simply just regenerative)and run Half or
Full duplex operation to the repeater (if it was a
gateway)depending on what you need at that instant. My bwain
hurst just thinkingabout all the `fun' things we could do with
the channel.Or, do you all want to buy single band split data
radios and pay more inthe long run. The choice is up to you (not
me anymore, I bought a singleband data radio already :-{ ) to do
it right and stop thinking thatCSMA/CD is not possible, or too
expensive to set up. By buying singleband data radios, you are
all chipping this (useless CSMA/CA) technology instone.I know
that the improvements going from Aloha to CSMA/CA are great,
butgoing to CSMA/CD and FULL Duplex at a drop of a hat must be
even a greaterimprovement at what I feel at this juncture to be
the same cost if we couldjust get our collective minds together
and `make the market'.May the REAL DISCUSSION begin ... and
thanks Dana for helping me thinkthis problem through.Ciao, 73 de
VE6MGS/Mark -sk-------------------------------Date: 7 Nov 91
13:18:51 GMTFrom:
theory.TC.Cornell.EDU![e-mail]:
CSMA/CD vs. CSMA/CATo: [e-mail] article
<[e-mail]> [e-mail] (Mark G.
Salyzyn VE6MGS) writes:>>This is just plain nonsense. You don't
need full dux in CSMA. Only>>in CSMA/CD is it required.>>That is
what I am arguing for. Dana and I have had a little e-mail
discussion>(or was it an argument :-) going about this (Dana:/CA
or Me:/CD). I feel that>if we design /CD into the system (Full
duplex repeaters and Full duplex user>sites) that the system
will cost the same if done properly.The problem is doing
collision detection cheaply (or at all) at high datarates (I
think this discussion has come up before).Collision detection is
an *analog* process, done at the physical layer.  Sofor a system
with CD, you not only need full duplex equipment, but you
needsome CD circuitry.  How complex is this circuitry?Consider
Ethernet:  an Ethernet transceiver listens while transmitting
withthe receive and transmit points at the same spot at the
cable.  To peformCD, the transceiver just compares the transmit
and receive data (ignoringthe insignificant time skew between
the two signals).However with the system you describe, the
receiver hears what is transmittedtwo link delays ago (the path
out and the path back).  For a 10km path, thislink delay is on
the order of 70 uSec.  At 1200 baud, this delay is is
about1/12th of a bit time.  However, at 56kb the link delay is
about 4 bit times.So at 56kb, a CD system must compare what is
being received now with whatwas sent "about" 4 bits ago (where
"about" depends on the total delayof the system).  As the speeds
and link lengths increase, the problem gets worse.  With high
enough data rates, long links, and short packets, itis possible
to have an entire packet in flight on the link and not be ableto
do collision detection at all.My point is that doing collision
detection on a full duplex repeater/fullduplex user system is
complex and costly.  It doesn't sound worth the effort.-- =  =
=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
 =  =  =Andrew C. Payne, N8KEI        UUCP:
...!cornell!batcomputer!payne                          INTERNET:
 [e-mail]------------------------------Date:
7 Nov 91 23:04:04 GMTFrom:
pa.dec.com!jrdzzz.jrd.dec.com!jrdzzz![e-mail]
ct: DCD mod and Squelch busyTo: [e-mail] article
<[e-mail]> [e-mail] (Steve Urich) writes:>
<*> Speaking about dual bander radios. I would like to throw
my>           2 cents in and ask if dual banders are a better
choice in>           packet then single banders and what the
advandages are vs>           the disadvandages? I am looking for
input on what would be>           the best suitable radio for
packet so I'll know when Its time>           to buy my TNC and
radio(s).Usually dual banders have slow PTT switch response
because of its PLLcomplexity. And you can't transmit
simultaneously on two (or more)bands. I do not recommend dual
(or more) banders for a permanentpacket radio operation.>
Steve Urich             WB3FTP            [e-mail]-- Kenji, JJ1BDX--Kenji
Rikitake // VMS/Japanese Development, DEC Japan R&D
Center------------------------------Date: 7 Nov 91 02:34:09
GMTFrom: gatech!emory!wa4mei!ke4zv![e-mail]: DCD mod
and Squelch busyTo: [e-mail] article
<1991Nov6.013911.1898@anasaz> john@anasaz (John Moore)
writes:>>You get significant advantage because your carrier
detect signal hears>stations that start before you transmit,
reducing collisions. Also,>regeneration will reduce the error
(and hence retransmission) rate>because people who might be on
the channel with weak signals simplex will>have better signals
through the repeater in most cases.We've tried with and without
bit regeneration on our full duplex repeater.There doesn't
appear to be any advantage to using the regenerator exceptto
keep voice users off. If the signal is good enough to be decoded
atthe repeater, it's good enough to be decoded after being
repeated, ifyour repeater is any good. We're using regeneration
now, but strictlyas a anti-voice measure. Theoretically it
should help, but in practicewe haven't seen it.BTW we probably
have a claim as the first full time dedicated fullduplex data
repeater. The KD4NC-1 146.13/73 machine has been fulltime packet
since the mid-80s. We've run AX25MON extensively on itand on the
other LAN in town which is simplex store and forward on145.03.
The duplex system consistently has better than double thethruput
of the simplex system. During peak activity it is *much*better
than double the capacity of the simplex system. All GrapesLANs
are linked by 56 kb trunks, or are in the process of
beinglinked. Users on 145.03 report better performance when
connectingthrough the switches to a user on the 146.13/73 system
than when they connect to another station directly on 145.03
using the switch as a digi.The trunks are so lightly loaded that
they are virtually contentionfree. They have 49 times the
capacity of a 1200 baud channel.Gary
KE4ZV------------------------------Date: 7 Nov 91 02:51:17
GMTFrom: ogicse!emory!wa4mei!ke4zv![e-mail]: Digital
fullduplex repeaters.To: [e-mail] article
<04.Nov.91.17:24:54.GMT.#[e-mail]>
[e-mail] (Pete Lucas, NERC Computer
Services, Swindon) writes:>>The idea of bit-level repeaters
surely breaks down in>the case of amateur style
less-than-100%-reliable paths, and when the>system is not
fully-connected (hidden transmitter problem).There are no hidden
transmitters in a full duplex repeater system. Eitheryou are in
range and can use the system, in which case you hear
everybodycourtsey of the repeater, or you are out of range and
can't use the system.Our LANs are laid out based on the 100%
coverage curves of our repeaters.If you aren't in the coverage,
you're supposed to be on another LAN.>Only by receiving the
*whole* of a frame (assuming we are using>HDLC and AX25) and
performing the usual CRC, can we be sure that>the frame is
'clean' and therefore worth repeating.>This implies
store-and-forward at level 2, in other words a frame-level>(as
opposed to a bit-level) repeater.The repeater repeats *in real
time* everything it hears on it's input,just like a voice
machine. Even if the frame winds up as garbage, itserves as a
busy tone to keep anyone else from wasting time by attemptingto
transmit over it.>I suspect the FCC may take offence at any
repeating of incomplete frames,>or those where the 'callsign'
octets have been accidentally modified....The FCC cares as
little about this as it does about a mobile voice userwho is
chopping in and out of a voice repeater. The responsibility
ofidentification lies with each individual transmitter. The
repeater IDsevery 10 minutes. It's up to other stations to ID
themselves on thefrequency on which they are transmitting.>If
you just regeneratively repeat at the bit level, without
checking the>validity of the bits in their level-2 context,
there is a strong possibility>that you will spend some
significant time repeating garbage.Since the garbage is being
repeated *in real time*, no usable channel timeis lost. The
garbage merely acts as a busy tone to notify other channelusers
not to waste their time transmitting until the input frequency
ofthe repeater is clear.>For example, your DCD or Statemachine
may be triggered, so you start>repeating on the output
frequency, then you get hit either by a>burst of intermod, or a
'hidden station' stamps on your repeater input>frequency. The
smart repeater should detect this, and stop repeating; but>it
has already sent part of a frame (which it was repeating before
the>noise/intermod. appeared) on the output frequency; others
see the>repeater as having repeated an incomplete, junk
frame.See above, the "junk" acts as a busy tone preventing
another user fromattempting a packet that will be trashed by the
"hidden" transmitterthat would exist if you aborted repeating
the bad frame. Without thismechanism you are no better off than
with a simplex system replete withit's hidden transmitters.>The
extent to which this is harmful depends on several factors,
some>of which are:->> (1) Synchronisation time of the modems.>
(2) TX/RX changeover time (turnround time) of the radios> (3)
Typical duration of a single frame.> (4) Ratio of (1+2) to
(3)>>The only case where i can see a legitimate use for
bit-level>repeaters is where there is nobody else using the
frequencies, both>the repeater and the stations it links are
using highly-directional beam>antennas, and the link shows a
very low error rate..>An example would be to link two adjacent
valleys, on a dedicated>frequency.>In other cases, it seems to
me that frame-level repeaters are the preferred>solution.No.
Frame level store and forward halves the effective baudrate of
thechannel. *And* it offers no protection from hidden
transmitters. It is a clear loser when compared to direct
repeating.Gary KE4ZV------------------------------Date: 7 Nov 91
23:58:46 GMTFrom: [e-mail]: getting
W0RLI BBS CodeTo: [e-mail] response to
[e-mail], who was responding to Hank
Oredson'sposting:Willis - you must be living in a very broken
part of the network.I was the one who sent out the bulletin - it
went to KD5SL within 1 hr.and he feeds via VHF and 30m into
Texas ...I would check your in-state paths Willis ... you should
have a bulletinlike that within 24-48 hours ...Dave
VE3GYQINTERNET: [e-mail]:
ria.ccs.uwo.ca!toth!daveBBS world: VE3GYQ @
VE3GYQ.ON.CAN------------------------------Date: 7 Nov 91
13:01:29 GMTFrom:
pacbell.com!att!cbnewsj![e-mail]: PRMBS and
CDROM?To: [e-mail] there anybody out there that
is running PRMBS and has the HamCallCDrom online? Do you support
callsign lookups? If so how???Thanks in advance for any replies.
73, Tom KB2GLO.-- Tom Kenny, KB2GLOUUCP: ...!att!mtuxo!tek
       Internet: [e-mail] Radio:
kb2glo@n2kzh..nj.usa   AMPR: [e-mail]
[44.64.0.10]------------------------------Date: 7 Nov 91
01:53:56 GMTFrom:
pacbell.com!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-
state.edu!ub!dsinc!wells!beyonet![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>wellsSubject : Re: DCD mod and Squelch
[e-mail] (Brian Kantor) writes:>Of course I can.  I'm
running a Motorola Micor in my car, and it>simultaneously
receives the repeater's output while I'm transmitting on>the
repeater's input.  It runs 50 watts out, was built 15 years
ago,    <*> Was this the stock configuration or did you have to
mod. the        reciever section so it would always be on? Also you
would have        to have some sort of a duplexer on the micor??? I
used and        maintained a few of these commercial radios and
never knew        they had the ability to do that :-).        They
must be one hell of a packet radio.Steve
Urich            WB3FTP            [e-mail]------------------------------D
ate: 7 Nov 91 00:27:08 GMTFrom:
ub!dsinc!wells!beyonet![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>, <[e-mail]>Subject :
Re: Beginner packet help [e-mail] (Brian Kantor)
writes:>For a really fast switch, you might care to look at the
Gracilis>PackeTen product.  Although there are currently some
rough edges to    <*> This is a new named product for me. Is this a
TNC type        box? Where does one find info on all of these
"wonderful        toys" :-) It seems there are more packet produced
stuff        out there then a Newbie can handle.>It comes in two
flavours: one is a PC-based card, the other standalone.>Each
handles 5 ports, three of which are megabit rated and the other
two>not quite so fast.  You can even plug them together to get
10 ports in>a pc-based architecture.    <*> This is where I start
looking at the standalones only because        I would like to use
a UNIX based computer for my packet        cravings :-).>It runs a
modified version of Phil Karn's NOS, including a nice
net/rom>implementation for backwards compatability with obsolete
networks.    <*> This is what I would probably use also even though
I am very        Openminded and would love to hear everyones
opinions on that        subject. I will probably have to use the
old hit and miss         routine and use what would best be
suitable for me.>We're installing one here in San Diego sometime
in the next few months,>with 56kb, 9600 and 1200 bps full-duplex
repeater user access, 9600 bps>metropolitan trunking, and it
will participate in the California>Intercity network.  I think
it will give us a really nice network hub    <*> This must be all
in the 1296mhz range where CA is one of the        only areas that
use that portion of the ham bands thank god.        Here is Philly
there are 2 1296mhz rptrs. Voice. I think there        might be
some 1296mhz backbone packet but I'm not sure since        I am
typing hear say. >This is the sort of community resource that
people CAN get together to>finance and support, and all the
packeteers in the area benefit thereby.>    - Brian    <*> Once again
this resource is the best way to go if you want to        keep
costs down and let everyone enjoy the fruits of packet
without having to do it all by only 1 supporter. I guess you
could start a public HUB club and ask for yearly donations
like PBS television :-).Steve
Urich            WB3FTP            [e-mail]------------------------------D
ate: 7 Nov 91 00:31:12 GMTFrom: mdisea![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet Repeater Info
WantedIn article <[e-mail]> [e-mail]
(Willis Marti) writes:>In article
<[e-mail]>, [e-mail] (Dana H.
Myers)>writes:>[skip]>"The hidden transmitter problem is
eliminated. Completely. 100%. Every>receiver on the duplex
machine can hear every other transmitter. 100%.">>While I agree
wholeheartedly with the arguments for duplex repeaters,
the>above statement is a bit optimistic.  What (I think) you
mean is that:>"Every receiver on the duplex machine {i.e. those
that can hear the>repeater} can hear every other transmitter
THAT THE REPEATER CAN HEAR.">>There will still be cases of
systems the repeater cannot hear but that can>& will be heard by
stations in the repeater's area.  Packet frequency usage>and
siting would have to coordinated a whole lot more than it is now
to>completely eliminate the possibility.Gee, it's not very nice
to operate simplex on the input to a repeater,whether that
repeater be voice or packet. Even inverse duplex on arepeater's
frequencies tends to tick people off. This is basically theonly
way that interference of this kind would occur. Unless, of
coursethe local coordinating body allocated the same repeater
pair to twopacket repeaters that are too close to each other...
But then, thesame rules that are used to coordinate voice duplex
repeaters shouldbe used to coordinate packet duplex repeaters.
Especially since theytend to share the same frequency bands.Jack
Brindle, wa4fibinternet:
[e-mail]------------------------------Date: 6 Nov
91 22:54:38 GMTFrom:
theory.TC.Cornell.EDU![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>theoSubject : Re: Digital Packet Repeater
Info WantedIn article <[e-mail]> [e-mail]
(Willis Marti) writes:>"The hidden transmitter problem is
eliminated. Completely. 100%. Every>receiver on the duplex
machine can hear every other transmitter. 100%.">While I agree
wholeheartedly with the arguments for duplex repeaters,
the>above statement is a bit optimistic.  What (I think) you
mean is that:>"Every receiver on the duplex machine {i.e. those
that can hear the>repeater} can hear every other transmitter
THAT THE REPEATER CAN HEAR."    Sure, but the clarification doesn't
really apply (see below).>There will still be cases of systems
the repeater cannot hear but that can>& will be heard by
stations in the repeater's area.  Packet frequency usage>and
siting would have to coordinated a whole lot more than it is now
to>completely eliminate the possibility.    But the user's of the
system aren't listening on the repeater'sinput:  they are
listening on the output.  Therefore, the system's userswill
*never* hear any station directly.    Coordination is a problem.
However, it is not an insurmountableone:  it has been done for
voice repeaters, why can't it be done for datarepeaters?-- =  =
=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
 =  =  =Andrew C. Payne, N8KEI        UUCP:
...!cornell!batcomputer!payne                          INTERNET:
 [e-mail]------------------------------Date:
6 Nov 91 12:47:23 GMTFrom:
sdd.hp.com!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!alberta!adec23
!ve6mgs![e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info [e-mail] (Bill Gunshannon)
sez:>OK.  Now I think we all agree.  What I think caused some of
the confusion is>the concept of "full duplex" as oppoesd to
"half duplex".  I will agree that>the hidden transmitter problem
is reduced but definitely not eliminated.  Afterreduced quite a
bit from the Aloha like system we have now ...>I personally
would like to see CSMA/CD implemented, but it probably
isn't>coming soon. It can, and I recommend that you do NOT buy a
radio until a manufactureror home brew'er starts building Full
Duplex Radios NOW.>So, lets get practical.  I have a couple of
DR-200s friom PACCOMM.  What is>the likelyhood that I could
throw together the necessary software to make one>of these
receive on one channel and immediately retransmit the bits on
the>other channel thus providing a cheap, regenerating,
full-duplex repeater??Sorry, no software required AT ALL.Make
sure you talk to the local frequency co-ordinator to get a
repeater pair.Take your data radio and connect it appropriately
to the Full Duplex 9600(or 19.2K) modem (The K9?? modem is NOT
Full Duplex). Wire the TXD to theRXD on the modem. Use the CD to
trigger the transmitter.Get/build/beg/borrow/steal a set of Cans
(Duplexers) for the data radio andvoila'.There, a regenerative
repeater. Ahhh, but you were talking node, that isNOT a
regenerative repeater and it creates the hidden transmitter
problemand requires software and maintenance costs.A node could
be formed using the NETROM/TheNet/ROSE software on regularTNC
feeding the Modem and Data Radio. No special bits, except
`maybe' somecareful zipping up of the Z80 processor (Z-80H at
12MHZ? may be necessary).But, I doubt it if the code is written
carefully since there are KISS56KEPROMs for the TNC-2s
anyways.Hope this helps ...Ciao, 73 de VE6MGS/Mark
-sk-------------------------------Date: 7 Nov 91 16:47:20
GMTFrom: [e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedIn article <[e-mail]>
[e-mail] (Bill Gunshannon) writes:>So, lets get
practical.  I have a couple of DR-200s friom PACCOMM.>What is
the likelyhood that I could throw together the
necessary>software to make one of these receive on one channel
and immediately>retransmit the bits on the other channel thus
providing a cheap,>regenerating, full-duplex repeater??Well,1)
You could cut the trace going into the modulator and hook up
theoutput from the demodulator if you wanted, but that would
give you onlyFSK regeneration - the bits wouldn't be retimed.2)
You could run them through basically a D-type flip-flop and
clock itat the derived baud rate, and that would regenerate the
bit widths, butnot the timing.3) You could clock the FF circuit
from a baud rate generator and hopethat no one in your area has
a baud clock that's far enough off tocause problems, or add a
bit FIFO and clock the bits in with the derivedreceived clock
and out with the timed clock.I use scheme (1) with a K9NG modem,
which regenerates both 1200 and9600.  For $35 it's not bad; when
the K9NG kit came without all theuseless parts and was $10
cheaper it was an even better deal.    -
Brian------------------------------Date: 7 Nov 91 04:14:10
GMTFrom:
ogicse!uwm.edu!linac!att!cbfsb!cbnewsb.cb.att.com![e-mail]
To: [e-mail]
<[e-mail]>, <[e-mail]>,
<[e-mail]>)Subject : Re: Digital
Packet Repeater Info WantedIn article
<[e-mail]> [e-mail]
(Jack Brindle) writes:>same rules that are used to coordinate
voice duplex repeaters should>be used to coordinate packet
duplex repeaters. Especially since they>tend to share the same
frequency bands.Couldn't one just take an existing underused
voice repeater and convert itto a data repeater?  Coordination
is already done (unless the requirementsof a data machine are
much different than voice).  Would a data machine anda voice
machine in the next county live with each other on the same
frequency?I could see it happen that we would get a random
distribution of voice and data machines in the repeater
subbands, the data machines being convertedvoice machines.
(people have mentioned that there is an overabundanceof voice
machines around)  73 de wiskey alpha two, india serria
echo------------------------------Date: 7 Nov 91 01:47:40
GMTFrom:
mvb.saic.com!unogate!orion.oac.uci.edu!usc!zaphod.mps.ohio-state.
edu!ub!dsinc!wells!beyonet![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: DCD mod and
Squelch [e-mail] (Mark G. Salyzyn VE6MGS)
writes:>Don't tell me that you can hear when you are doubling
with someone on the>voice repeater. The solution is to go cross
band (bent pipe was it?) to>make life easier. Again, a cost,
since a dual bander DIGITAL radio is NOT>available commercially
(I think, correct me and I will be converted).    <*> Speaking
about dual bander radios. I would like to throw my        2 cents
in and ask if dual banders are a better choice in        packet
then single banders and what the advandages are vs        the
disadvandages? I am looking for input on what would be        the
best suitable radio for packet so I'll know when Its time        to
buy my TNC and radio(s).>Ciao, 73 de VE6MGS/Mark -sk-Steve Urich
            WB3FTP            [e-mail]------------------------------Date:
7 Nov 91 15:33:21 GMTFrom:
sdd.hp.com!cs.utexas.edu!tamsun!cs.tamu.edu![e-mail]:
[e-mail] <1991Nov6.013911.1898@anasaz>,
<[e-mail]>,
<[e-mail]>Subject : Collision Detect
Was Re: CSMA/CD vs. CSMA/CAIn article
<[e-mail]>,
[e-mail] (Andrew Payne) writes:[skip]|>
Consider Ethernet:  an Ethernet transceiver listens while
transmitting with|> the receive and transmit points at the same
spot at the cable.  To peform|> CD, the transceiver just
compares the transmit and receive data (ignoring|> the
insignificant time skew between the two signals).A
clarification.  *Baseband* ethernet systems {the 'traditional'
ethernet}detect collisions by a purely analog method --> the
voltage level present(dc averaged) is greater than 1
transmitter.  No bit comparison is used.Couldn't be used, since
IEEE 802.3 requires collision detection even whilenot
transmitting.[skip]|> was sent "about" 4 bits ago (where "about"
depends on the total delay|> of the system).  As the speeds and
link lengths increase, the problem |> gets worse.  With high
enough data rates, long links, and short packets, it|> is
possible to have an entire packet in flight on the link and not
be able|> to do collision detection at all.The broadband (CATV)
systems are more like packet thru a repeater.In broadband
systems, the collision detection can be done by the
headend,which recieves enough information to detect a collision
and starts sendingan "extra" collision detection signal, or you
can have individual stationsdo bit by bit (easier is byte by
byte) comparisons.|> |> My point is that doing collision
detection on a full duplex repeater/full|> duplex user system is
complex and costly.  It doesn't sound worth the effort.It is
more complex than not doing it; simulations and experience ( on
nonpacket LANs) say you get a lot of bang for the buck.|> -- |>
=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
 =  =  =  =  =|> Andrew C. Payne, N8KEI        UUCP:
...!cornell!batcomputer!payne|>
INTERNET:
[e-mail]------------------------------Date: 7
Nov 91 17:55:56 GMTFrom:
sdd.hp.com!mips!wyse![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet Repeater Info
WantedIn article <[e-mail]> [e-mail]
(Willis Marti) writes:>There will still be cases of systems the
repeater cannot hear but that can>& will be heard by stations in
the repeater's area.  Don't think so.  This whole idea works
because it is EXPECTED that theonly guy on the Repeater's output
is the repeater!  Consequently anyoneusing the repeater will
only hear the repeater. >Packet frequency usage>and siting would
have to coordinated a whole lot more than it is now
to>completely eliminate the possibility.Yep, coordination is
absolutely mandatory...but the statement thatwe would be doing
it a whole lot more than we already are doesn'tseem to hold
up...just ask AA4RE.... Roy serves as the Packet Freq
coordinator for Northern CA.  NCPA(Northern Cal Packet Assoc)has
been doing coordination for a few years now, and seems to
bedoing a very solid job of it.  Steve KA6S
------------------------------Date: 7 Nov 91 16:39:38 GMTFrom:
[e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet Repeater Info
WantedIn article <[e-mail]> [e-mail]
(Willis Marti) writes:>There will still be cases of systems the
repeater cannot hear but that can>& will be heard by stations in
the repeater's area.  Packet frequency usage>and siting would
have to coordinated a whole lot more than it is now
to>completely eliminate the possibility.No, all you have to do
is keep hitting the idiot over the head until hestops operating
on the repeater's output frequency, and switches histransmitter
over to the input.  Or run the repeater's delayed dropouttime up
to half an hour or something so he'll notice.Duh.    -
Brian------------------------------End of Packet-Radio Digest
V91 #288******************************Date: Sat,  9 Nov 91
04:30:05 PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #289To: packet-radioPacket-Radio Digest         Sat,
9 Nov 91       Volume 91 : Issue 289Today's Topics:
       Connecting my W2A to a PK88
CSMA/CD vs. CSMA/CA                  DCD Mod and Squelch busy (2
msgs)     DCD Mod and Squelch busy (Was Re: Info on packet
repeaters)                    Digital fullduplex repeaters.
       Digital Packet Repeater Info Wanted (2 msgs)
       DSP,DOVE, PHASE IIID, AND ME                       HP
48sx running packet?                           Recommend a
TNC?Send Replies or notes for publication to:
<[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 8 Nov 91 01:47:18 GMTFrom:
uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!swrinde!elroy.j
pl.nasa.gov!orchard.la.locus.com!devnet.la.locus.com![e-mail]
paSubject: Connecting my W2A to a PK88To:
[e-mail] article <[e-mail]>
[e-mail] (Bob Gettys) writes:>>In article
<[e-mail]>, [e-mail]
(George Vogel) writes:>|>Has anyone done this?  (that's a silly
question, there always is at least>|>someone on here that has
done EVERYTHING!)>|>  Yeah, and some people on here have done
everything TWICE! Like,Kantor, for instance.--  * Dana H. Myers
KK6JQ         | Views expressed here are    * * [phone]         | mine
and do not necessarily    * * [e-mail]        | reflect those of my
employer    * * "Dammit Bones, spare me the lecture and give me the
shot!"   *------------------------------Date: 8 Nov 91 03:02:49
GMTFrom: ogicse!emory!wa4mei!ke4zv![e-mail]: CSMA/CD
vs. CSMA/CATo: [e-mail] article
<[e-mail]> [e-mail] (Mark G.
Salyzyn VE6MGS) writes:>John Moore NJ7E sez:>>This is just plain
nonsense. You don't need full dux in CSMA. Only>>in CSMA/CD is
it required.>>That is what I am arguing for. Dana and I have had
a little e-mail discussion>(or was it an argument :-) going
about this (Dana:/CA or Me:/CD). I feel that>if we design /CD
into the system (Full duplex repeaters and Full duplex
user>sites) that the system will cost the same if done
properly.>>IF we go for the CSMA/CA model now, we have to trash
it to get the /CD>model, thus it will NEVER be done. However,
the same considerations for>a full duplex user site are made for
a Half Duplex CSMA/CD site, saving>on (what I feel to be)
useless technology associated with CSMA/CA channels.We've
already gone for the CSMA/CA model. It's already a success
andall the users already have radios and antennas to use it. In
fact thesame radios they have been using for years for voice.
Both the new andused markets are full of these dual use radios.
Requiring users tobuy new dualbanders to play presents a large
obstacle to entry intopacket.>Now, you can all correct me if I
am wrong, but if we press for the>development of a dual band
data radio (ie, 2W TC on 440, 220MHz RX)>we solve the costs of
the cans (duplexers) and I am sure it will cost>the same as any
single band data radio AND supplies us with FULL
DUPLEX>operation if we need it to boot. For the 56Kbps modem, a
dual band>transverter would be in order, this, unfortuneatly,
would be more>expensive than the simplex version (A chink in the
armour :-{ ).Such dual band radios aren't likely to be cheap,
the demand will berelatively small and they can't be used for
anything else like voiceor simplex or conventional repeated
packet on a single band. This meansthat if the repeater goes
down, everybody is dead in the water. Theycan't go back to
simplex because their radios transmit on a differentband. This
could be a disaster in emergency communications. Therewon't be
any on the used market for a while where $50 radios suitablefor
packet are now common. All this to partially close a 120 ms
windowof vulnerability to collisions. And it doesn't really even
do that.All you get is the ability to abort a frame in progress
rather thanwaiting until it is over to do the retry. You still
have to do theretry.>Now, if you use a dual band (ie 220MHx TX
and 440MHz Rx) regenerative>repeater, cheaper, since we do not
need cans for it. The the single band>repeater would require
cans. We could run CSMA/CD with the dual band data>radio with, I
am sure, a simple mod to the KISS EPROM firmware.Notice now that
you are asking for a different radio, inverted fromthe user
radios at the repeater site. This will be really low volumeand
really expensive, but what else is new at a repeater site.
Inaddition to being backwards from all the users, you still need
a stackof cans equivalent to a duplexer in order to live in the
RF environmentof a high site with it's commercial repeaters and
pagers. You can'tcut corners at a repeater site. Forget the
transmit circulator andyou'll be kicked off the site so quick
you'll see yourself going upthe mountain as you come back
down.>Or, we could use these (dual band, user site, and repeater
site) as the basis>for a FULL DUPLEX site to site link. And, my
imagination goes wild on what>we could do if the Repeater was
smart (rather than simply just regenerative)>and run Half or
Full duplex operation to the repeater (if it was a
gateway)>depending on what you need at that instant. My bwain
hurst just thinking>about all the `fun' things we could do with
the channel.Running a true full duplex trunk link is another
matter entirely. There,in a non-contention environment, you can
fully use the back channel whiletransmitting on the forward
channel. Not only does this immediately doubleyour channel
capacity, but you don't have to stop and wait for acks anda
sliding window protocol really works. Now this is a nailed up
bidirectionallink that no user on a LAN could achieve. A totally
different situation.And it doesn't matter as much that it isn't
cheap because there are fewertrunk links than users and all can
chip in to pay.Packet can't grow in a vacuum, there are
practical reasons why CSMA/CAwas the choice made for user LANs.
Crossband repeating solves a smallproblem while creating others,
such as the inability to form ad hocemergency networks, that are
much worse.Gary KE4ZV------------------------------Date: 5 Nov
91 22:32:42 GMTFrom:
elroy.jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]
.eduSubject: DCD Mod and Squelch busyTo: [e-mail]
message <[e-mail]> you write:> I know there is a line in
PLL chips that signals when the PLL is locked.> Couldn't this
line be wired into the TNC, and replace TXDelay=RaNdOm#?> > I
know most people want to have the option of removing the packet>
radio and not have lotsa wires, but when was the last time your
radio> left the TNC.This is only part of the reason for txdelay
- it also compensates forthe other guys T/R switching.  TXDelay
rather elegantly takes care ofthese.  How do you know if it
works?  Simple - you set it empirically,so it works with all the
stations you want to work - and you'll hearabout it in rather
short order if it is set too short :-)Another drawback - most
hams have a PbSn (that's solder to younon-chemistry-types :-)
phobia, and you'd never get most of 'em tosolder in the extra
wire.  Look at the federal project we have withthe 2 stinkin'
wires needed for 9600 FSK!  Yes - folks would ratherBUILD an
expensive and inefficient fax-chip based modem than solder
2wires into their sacred 2 meter rig. > What is the idea for the
optimum solution?  What I would like to > see are multiple
freq's.  the 1200 baud folks can stay on 145.0X, > the 9600 baud
folks can go to 4XX.YY, and the 56KB can be organized > on {900,
1.2G, ...}.  Some separation for backbones of traffic, but >
most 56KB stuff would probably end up like the internet
(hopefully> only the good stuff), with telnet connections, and
some FTP, and some> SMTP, this an X session thrown in for
keeping things busy. I'd much rather see 9600 on 2 meters.  Why?
 It's top speed there, andneeds only 12 KHz - actually a little
LESS than wasteful 1200 baud! I can see some wanting 9600 on 222
(I HATE calling it that!) or 440,as a second 9600 port for home,
but in general, I feel we should usethe higher bands for higher
speeds. > Yes anything at or above 9600 should be full duplex
(actually the 1200 > should be also, but who's gonna listen?)
This leads to weird repeater > situations, and might be real
hard to keep organized.  I'd much rather see duplex repeaters
(not full duplex).  We have 2 duplex packet repeaters here in
L.A. (one 1200/9600 dual speed), and they work extremely
well.Full duplex would require crossbanding, a definite turn-off
for all but the most rabid amongst us.> Probably better
solutions would be spread spectrum, or 'cellular'> type
solutions.  Using the FDDI type protocols, with a specific>
frequency > designated for organizing the FDDI stuff.  How about
the> 1200baud modem communicating to a clearing house, asking
for a slot> in the protocol, the clearinghouse grants, the 56KB
modem listens> for the slot, and handles the transactions.  When
done the 1200 baud> modem tells the clearinghouse everything is
done and the connection> is closed. Work these options out and
let us know your results.                -o-Don't take this as a negative
lecture - it's not intended as such.A fan of Ernest Hemingway
approached him with a "great idea for anovel".  After listening
to it, Hemingway asked "well, how does itbegin?  What are the
characters like?  What about the setting?  Howwill the plot
develop?", and a lot more questions.  The fan said,"well - I
don't know...".  Hemingway then pointed out that it was aLONG
way from being a great novel. Same way with other ideas.  There
are gadzillions of 'em - but most never progress past the "idea"
stage.  Why?  Just like the fan, we all assume that someone ELSE
will develop our idea.There are several very wealthy companies
who will develop other peoples' ideas - for a fee!I don't mean
this to be a lecture, or anything at all negative; ratheran
encouragement to _research_ and _develop_ your ideas
yourself.After all, it would be a shame if you had the answer to
all ofpacket's problems, but it never got developed because you
left it upto others. As Edison once said, "Genius is 2%
inspiration and 98% perspiration".I suppose that's why some need
deodorant more than others :-) Yours,  _ _ _             __ ' )
) )   /       /  )        _/_  / / / o /_  _   /    . . __  /  o
_ / ' (_<_/ <_(/_ (__/ (_/_/ (_<__<_/_)_  Packet:
wd6ehr@n6yn.#soca.ca.usa    [e-mail] [44.16.0.21]
wd6ehr.ampr.org![e-mail] or [e-mail]   CI$
73240,3523 wd6ehr-3 netrom switch   wd6ehr-6 conference bridge
wd6ehr-8 mbox/info 146.745 @ 1200 baud <----> 439.025 @ 9600
baud <----> 28.103 @ 300 baud 7921 Wilkinson Avenue; North
Hollywood CA USA 91605-2210 (818)
765-2857------------------------------Date: 8 Nov 91 19:16:08
GMTFrom:
qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]:
DCD Mod and Squelch busyTo: [e-mail] article
<[e-mail]> [e-mail] (Gary
Coffman) writes:]I don't consider our 56 kb system brute force.
We only occupy 1.2 hz]per baud. That's much better than the 20
hz per baud of other schemes]like the current AFSK modems that
try to operate through voice radios.Actually, from what I've
been learning about cellular radio (andfrequency reuse in
spectrally efficient, i.e., interference-limitedsystems), it's
not so much the 1.2 Hz/bit/sec figure of the WA4DSYmodem that
makes it more efficient, but the fact that it uses much
lessenergy to send each bit than does AFSK/FM. This affects how
closely youcan space co-channel transmitters without mutual
interference, which isthe single most important factor in
overall spectral
efficiency.Phil------------------------------Date: 4 Nov 91
21:38:22 GMTFrom:
elroy.jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]
.eduSubject: DCD Mod and Squelch busy (Was Re: Info on packet
repeaters)To: [e-mail] message
<[e-mail]> you write:> > > In article
<[e-mail]> [e-mail] (Mark G.
Salyzyn> VE6MGS) writes:> > >have a mixed base (DCD State
machine is implemented in every TNC except AEA> >and KAM) then
you have problems. You can ask any MFJ-1270 owner to run > > KAM
versions 4.00 onwards do have a possibility of software DCD. I
have had> 4.00 since thursday and it seems to work remarkably
better than the squelch> 'DCD'.yup - except it doesn't work (at
least on version 3.00).  Somestations are eliminated when using
software CD.  I'm back to using myold faithful DCD state
machine. > German TNC2 clones by DK9SJ have an Exar 2211 DCD
circuit. It works rather> well but it cannot distinguish audio
bleeps from real data.The MFJ line uses EXAR 2211's, too - and
seem to be the best 1200modems around.  In addition, the 1278
has a true DCD state machine,and works the best of any 1200 TNC
I've ever seen! > We have modified all our network TNCs to have
the state machine and try to> encourage all users to make the
modification, too.Good move!  I too am convinced that ALL
networks (AND all end users!)would be well advised to use true
DCD.  It doesn't just minimizeTXDelay - it actually improves
_Y_O_U_R_ throughput!  How?  Simple:less collisions, less
txdelay (ergo more time for data), less problemswith others
using short TXDelays, less chance of being collided with(because
you listen that much closer to your keyup!), and a
couplegiggly-zillion other reasons.  I think it's the best $17
that can bespent on 1200 baud packet.  Yours,  _ _ _
__ ' ) ) )   /       /  )        _/_  / / / o /_  _   /    . .
__  /  o _ / ' (_<_/ <_(/_ (__/ (_/_/ (_<__<_/_)_  Packet:
wd6ehr@n6yn.#soca.ca.usa    [e-mail] [44.16.0.21]
wd6ehr.ampr.org![e-mail] or [e-mail]   CI$
73240,3523 wd6ehr-3 netrom switch   wd6ehr-6 conference bridge
wd6ehr-8 mbox/info 146.745 @ 1200 baud <----> 439.025 @ 9600
baud <----> 28.103 @ 300 baud 7921 Wilkinson Avenue; North
Hollywood CA USA 91605-2210 (818)
765-2857------------------------------Date: 8 Nov 91 11:31:18
GMTFrom: [e-mail]: Digital fullduplex
repeaters.To: [e-mail] do not see how a
full-duplex repeater can cure the 'hidden station'problem. While
this may work in a fully-connected system,topography and
propagation make it a false assumption for the realworld, where
re-use of frequencies in adjacent areas is essential.The analogy
of voice repeaters is flawed, since voice repeaters *do*
providefiltering, on the basis of PL or CTCSS tone. They do not
repeat everything(though at times it sure sounds like
it!).Dana's idea of repeating everything is spectrally
inefficient and seems tobe contrary to basic logic; IMHO you
should establish a principle of onlyrepeating that which is
necessary. In other words, the repeater shouldbe seen as a
'regenerative bridge/router'.  We should be using the model
oftwo or more LANs linked via a brouter rather than  a
'super-line-driver'repeater that simply passes everything.Think
like 'linking spatially-separated sub-nets' rather than
'extending asingle network'. Pete Lucas   [e-mail]
PJML%IA.NWL.AC.UK@UKACRL
G6WBJ.ampr.org------------------------------Date: 4 Nov 91
21:58:20 GMTFrom:
elroy.jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]
.eduSubject: Digital Packet Repeater Info WantedTo:
[e-mail] message
<[e-mail]> you write:> > In article
<[e-mail]> [e-mail]
(Phil> Karn) writes:> >In article
<[e-mail]> [e-mail] (Gary
Coffman)> writes:> >>That's true, but thruput between individual
stations beyond line of> >>sight is significantly better with
bent pipes than with multi-hop> >>techniques that halve the
effective baudrate at each step.> >> >I don't think this is
true, especially if you normalize for the amount> >of spectrum
that's being used. If the stations aren't in> >line-of-sight,
then chances are they're fairly far apart> >geographically, and
that calls for a repeater that blankets a fairly> >large
metropolitan area. A series of relatively small>
>store-and-forward repeaters could cover the distance between
the> >stations without having to blanket the entire area covered
by the big> >repeater.> > I think this is the basic sticking
point. It's barely possible to > get *one* repeater funded,
sited, and maintained in most areas. To> require numerous cell
sites becomes financially and organizationally> impossible. Most
of our communications is terrain limited rather than> power
limited so power control doesn't enter in to the equation very>
much at all. To require many little relay sites linking the
folds> in the terrain is more complex and expensive than
maintaining one> very high site that looks down into all the
valleys. I understand> that this is a local problem and that in
flat areas power control> would be helpful, as would directional
antennas. In Atlanta we are> looking at 500 sometime users in
1800 square miles. At any given > time less than a hundred of
those stations are powered up and less> than 30 are in use. They
all want to be able to communicate with> each other in real time
at some point.I think you're missing Phil's point, Gary - these
aren't "sites" -they're end user stations.  Instead of having
dumb, wasteful digi's,or netwrong that doesn't work much better,
they're RF-power controlled"smart" store and forward - probably
at speeds more like T-1 than1200.  They minimize QRM by keeping
power to what is actually legallyrequired; the minimum to
communicate.  Who pays for them?  Anyone who wants to be part of
this particularhigh speed system.  Depending on how you view it,
it's either"democracy" or "anarchy" :-)As far as halving thruput
with each hop, a system that begins with a very high speed can
afford to do that.If the unwashed masses want to use boring
1200, they're still welcometo do so, and a bent pipe duplex
repeater will work miracles for them.We have 2 of these varmints
in L.A. (one is dual 1200/9600), and yes,they work marvelously
well - MUCH better than a pair of simplexchannels, especially
when things get busy. Nonetheless, there's room for both - and
more - in amateur packet.(Besides, I have a feeling you guys
know you are talking apples andorangutans :-) Yours,  _ _ _
       __ ' ) ) )   /       /  )        _/_  / / / o /_  _   /
 . . __  /  o _ / ' (_<_/ <_(/_ (__/ (_/_/ (_<__<_/_)_  Packet:
wd6ehr@n6yn.#soca.ca.usa    [e-mail] [44.16.0.21]
wd6ehr.ampr.org![e-mail] or [e-mail]   CI$
73240,3523 wd6ehr-3 netrom switch   wd6ehr-6 conference bridge
wd6ehr-8 mbox/info 146.745 @ 1200 baud <----> 439.025 @ 9600
baud <----> 28.103 @ 300 baud 7921 Wilkinson Avenue; North
Hollywood CA USA 91605-2210 (818)
765-2857------------------------------Date: 6 Nov 91 18:42:32
GMTFrom:
elroy.jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]
.eduSubject: Digital Packet Repeater Info WantedTo:
[e-mail] message
<[e-mail]> you write:> > In article
<[e-mail]> [e-mail] (Bill>
Gunshannon) writes:> >In article
<[e-mail]>, [e-mail] (Dana H.>
Myers) writes:> >|> > >|>   What poor logic. *Using* a full
duplex data repeater is as easy as> >|> pressing the repeater
split button on your radio. A full duplex linear> >|> translator
would have the advantage of passing all data modes, but would>
>|> not provide data regeneration which would lead to less
consistent> >|> performance for different users. In either case,
full duplex repeater> >|> or linear translator, the users need
only do what they all do now to> >|> use a voice repeater.> >|>
> >> >I'm afraid I don't see the poor logic in this.  Of course,
I also don't> >see the logic in "as easy as pressing the
repeater split button on your> >radio".  I don't know about your
radio, but that doesn't make mine full > >duplex.> >   While I
apologize for saying "What poor logic", I must reiterate that I>
am talking about *using* a full-duplex repeater. Pressing the
repeater> split button on your radio does indeed allow you to
use a full-duplex> repeater. No, it does not make your radio
into a full-duplex radio, but> you don't need that.To quote Paul
Newman, What we have here is a failure to communicate.It seems
Bill is talking about DIGIpeater, and Dana is talkingREpeater.
Apples and orangutans.A duplex packet repeater is functionally a
"bent pipe" thatretransmits IMMEDIATELY what it hears, and
REQUIRES a PAIR offrequencies.  When one speaks into a bent
pipe, he hears his voicecome out of the other end immediately.
It is not stored andforwarded. We have 2 duplex packet repeaters
in Los Angeles.  Collisions areexceedingly rare on a voice-type
repeater ( a "bent pipe") with amodem for regeneration of
packets.  Actually, our 1200/9600 repeateruses the data slicer
from a k9ng modem to simply "clean up" the 9600data. This is NOT
the same as everyone having transmit and receive running100% -
We don't run full duplex; the REPEATER does.  It's just like
your local VOICE repeater, which is technically a"duplex"
repeater, i.e. IT uses 2 freq's at once - but the USERS onlyhave
to change frequency upon transmit (or receive - however
youprefer perceiving it :-)and this _is_ "as easy as pressing
the repeater split button on yourradio". This has often proven
to be a difficult point to get across.Why do we call them
"duplex repeaters"?  Simple - because with packet, we have
"simplex repeaters" - digipeaters, ka-nodes, netwrong/TheNET,
ROSE, ad nauseum.> >I may transmit on a different frequency than
I receive on, but > >I still can only do one or the other at any
given time.  If that is all> >the users are doing, then there is
absolutely no advantage to the full> >duplex digi-peater because
you still have the hidden transmitter problem.
^^^^^^^^^^^digipeater - yes.  Bent pipe REpeater - no!!>
Please explain why we still have the hidden transmitter problem.
By> making the entire user area audible to all users, no
transmitter is> hidden. Sure, most radios run half-duplex, but
the hidden transmitter> problem is (in theory) solved using
Carrier Sense Multiple Access,> which checks for a channel busy
before starting to transmit.> > >In order for this system to
work, not only the digi-peater, but all the> >users have to be
running true full duplex.  They have to be able to hear>
>themselves transmit so that they know they have captured the
repeater.> >If they have not, then they must shut down the
transmitter in order to> >not interfere with the station who has
captured it.  That would be full> >duplex.  Anything less offers
nothing and uses twice as much spectrum.> >   What you are
describing is Carrier Sense Multiple Access/Collision>
Detection, which is certainly an improvement over the plain old
CSMA> we currently use in packet. Of course, to actually  use

 CSMA/CD every> packet user would require special hardware and
software, which makes> it rather unattractive....> >    I must
dispute your claim that a duplex repeater provides no advantage.
                                            ^^^^^^^^apples and
orangutans.> You are incorrect in stating that the hidden
transmitter problem persists> with a duplex repeater. A properly
designed duplex repeater makes all> users of the machine equally
audible to all other users. There are no> hidden transmitters.
However, there is still a window where CSMA breaks> down and
collisions may occur; this is due to the finite delay from> the
instant a station detects the channel is clear and the point in
time> when that station can make the channel busy. This finite
delay is the> transmitter keyup delay and any delay in the
signal path in the repeater.> >    However, it is illustrative
to understand how big the collision> windows are for the
digipeater and duplex repeater situations. We'll> assume a 128
byte packet with only one address pair, which results in> a
packet approximately 150 bytes long. At 1200 baud, this packet
will> require about 1 second to send. Since most packeteers seem
to use> synthesized radios with fairly long TX Delays (150 - 200
mS), the total> window for collision is 1 second plus the 200
mS, or 1.2 seconds on a> digipeater where there are hidden
transmitters. On a duplex machine, the> only time when a
collision can occur is the 200 mS keyup window. The> window for
collisions on a duplex machine is 17% of what it is on a>
simplex digi.  In the case one is using a fast crystal
controlled radio,> the TX delay could be, say, 70 mS. Then, the
windows are 1.07 S versus> .07 S, or the collision window on the
duplex machine is 6% of the size> it is on a simplex digi. Of
course, the collision window is really> determined by the
slowest station on the channel.I have synthesized rigs that work
down to TXD 3 (30 mS), i.e. Icom290H, etc.  I have never been
able to get any rig working at less than3 with the local
stations I use for testing.  On 2 meter 1200, I find TXD 50 to
be necessary.  Some stations need it.These, of course, are not
running DCD state machines.Also, not all rockbound rigs are that
fast, due to poor designrelating to T/R switchover and receiver
recovery.  This is not animportant design criteria for voice
rigs. >   While p-persistance is not a panacea, it can largely
mitigate the> remaining collision window on a duplex repeater.
Overall, under heavy> loading, a duplex repeater can provide a
more graceful erosion of> throughput than a simplex digi. This
is certainly an advantage. In> fact, it could be the case that a
heavily loaded duplex repeater> can provide better coverage and
efficiency to more users than two simplex> digis.> >    The
ability to detect collisions once transmitting helps maintain>
channel efficiency when the loading goes up. Since this is
starting to> discuss a less common topic, I'll suggest that
interested parties brush> up on the advantages of CSMA/CD versus
CSMA. A good reference would> be Tannenbaum's _Computer
Networks_.> -- >  * Dana H. Myers KK6JQ         | Views expressed here
are    *>  * [phone]         | mine and do not necessarily    *>  *
[e-mail]        | reflect those of my employer    *> > >  Yours,  _
_ _             __ ' ) ) )   /       /  )        _/_  / / / o /_
 _   /    . . __  /  o _ / ' (_<_/ <_(/_ (__/ (_/_/ (_<__<_/_)_
Packet: wd6ehr@n6yn.#soca.ca.usa    [e-mail]
[44.16.0.21] wd6ehr.ampr.org![e-mail] or
[e-mail]   CI$ 73240,3523 wd6ehr-3 netrom switch
wd6ehr-6 conference bridge  wd6ehr-8 mbox/info 146.745 @ 1200
baud <----> 439.025 @ 9600 baud <----> 28.103 @ 300 baud 7921
Wilkinson Avenue; North Hollywood CA USA 91605-2210 (818)
765-2857/ex------------------------------Date: 6 Nov 91 18:33:29
GMTFrom: idacrd![e-mail]: DSP,DOVE, PHASE IIID,
AND METo: [e-mail]:I am returning to life
after a long hibernation (not self
imposed).------------------------------Date: 9 Nov 91 04:36:53
GMTFrom: sdd.hp.com!mips!quack![e-mail]:
HP 48sx running packet?To: [e-mail] own an Icom
W2A and a HP 48SX calculator. The 48SX is hp'snewest top of the
line calculator that just came out about a year ago. What makes
is interesting is that it has a serialport, and a full a-z
character set. I only use the serialport to interface the hp to
my computer to transfer programsand such, I was wondering if
anyone has ever written packetsoftware the the 48sx? It would be
just about the smallestportable packet station you could get,
when combined witha HT.  73's-- Brian
[e-mail]6CFA@N0ARY.#NOCAL.CA.USA.NA408-996
-3342------------------------------Date: 4 Nov 91 13:47:43
GMTFrom:
mcsun!uknet!warwick!nott-cs!lut.ac.uk!@uunet.uu.netSubject:
Recommend a TNC?To: [e-mail],I am new to
amateur radio and would like to get invloved in packet. I havean
Alinco 2m transiever and a old Z88 portable computer. Can anyone
suggesta suitable, portable, TNC? What features should I be
looking for?Thanks,Sean Clark,Loughborough
University------------------------------Date: 8 Nov 91 19:03:32
GMTFrom:
qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>, <[e-mail]>Subject : Re:
Digital Packet Repeater Info WantedIn article <[e-mail]>
[e-mail] (Brian Kantor) writes:>This is simply wrong: it
is NOT necessary for the users to run full>duplex for the
digital repeater to represent a significant gain in>channel
throughput.  The repeater will eliminate the
hidden-terminal>problem, greatly reducing the collision rate.
The use of p-persistance>access methods will again reduce the
collision rate.True, but extra care will have to be taken to
keep the network stableunder overload. Much of Ethernet's
incredible robustness topathological overload comes from its
collision detection feature.Instead of avoiding collisions
completely (which is impossible), theircost is greatly reduced
by cutting transmissions short as soon as acollision is
detected. If you don't abort collisions, then it's easyfor the
network to collapse under load; as the load increases,
thepercentage of collisions which waste network bandwidth
increases, andthe network capacity goes down. There *are* other
ways besidescollision detection to keep the channel stable, but
they involve morecomplex protocols (like MACA).>>If you have
hidden terminals (i.e., there are stations B and C that
can>communicate with station A, but not with each other), in the
absence of>slotting methods, there is a virtual certainty that
you will have>collisions when B and C both transmit at the same
time.  CSMA/CA will>not be able to avoid these, since B and C
can't hear each other to>avoid colliding.Which specific CSMA/CA
are you referring to here? My MACA protocol(both the explicit
and implicit versions) are designed to handle thissituation -
stations B and C will hear packets from A that inform themthat A
is listening to stations they cannot hear directly, and theywill
defer. In a sense, it is a single-frequency version of
busy-tonemultiple access.------------------------------Date: 8
Nov 91 02:16:53 GMTFrom:
pacbell.com!att!emory!wa4mei!ke4zv![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>, <[e-mail]>Reply-To
: [e-mail] (Gary Coffman)Subject : Re: DCD mod and
Squelch busyIn article <[e-mail]> [e-mail]
(Steve Urich) writes:>[e-mail] (Mark G. Salyzyn VE6MGS)
writes:>>>Don't tell me that you can hear when you are doubling
with someone on the>>voice repeater. The solution is to go cross
band (bent pipe was it?) to>>make life easier. Again, a cost,
since a dual bander DIGITAL radio is NOT>>available commercially
(I think, correct me and I will be converted).>>    <*> Speaking
about dual bander radios. I would like to throw my>        2 cents
in and ask if dual banders are a better choice in>        packet
then single banders and what the advandages are vs>        the
disadvandages? I am looking for input on what would be>        the
best suitable radio for packet so I'll know when Its time>
to buy my TNC and radio(s).As somebody else noted, the best
radio for low speed packet is a singlechannel crystal controlled
rig with fast TR switching and open squelch.Words to live by,
STAY ON YOUR LAN FREQUENCY. Don't go hopping all overthe bands
or you'll confuse the routing software. Suitable radios canbe
found for $50 to $100 at any hamfest.Gary
KE4ZV------------------------------Date: 8 Nov 91 02:07:11
GMTFrom: pacbell.com!att!emory!wa4mei!ke4zv![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To : [e-mail]
(Gary Coffman)Subject : Re: Digital Packet Repeater Info
WantedIn article <[e-mail]>
[e-mail] (robert.f.casey) writes:>In article
<[e-mail]> [e-mail]
(Jack Brindle) writes:>>same rules that are used to coordinate
voice duplex repeaters should>>be used to coordinate packet
duplex repeaters. Especially since they>>tend to share the same
frequency bands.>>Couldn't one just take an existing underused
voice repeater and convert it>to a data repeater?  Coordination
is already done (unless the requirements>of a data machine are
much different than voice).  Would a data machine and>a voice
machine in the next county live with each other on the same
frequency?>I could see it happen that we would get a random
distribution of voice and >data machines in the repeater
subbands, the data machines being converted>voice machines.
(people have mentioned that there is an overabundance>of voice
machines around)  >73 de wiskey alpha two, india serria echoIt's
been done. Our repeater coordinating body, the SERA, doesn't
carewhether a repeater is to be used for voice or data. They
just mark itin their records as voice, data, or mixed. The only
issue that concernsthem is co-channel interference. As long as
the machine meets the inferference contours, they'll coordinate
it. They use a computer systemsimilar to the one the FCC uses
for broadcast coordination.Gary
KE4ZV------------------------------Date: 8 Nov 91 01:59:10
GMTFrom: ogicse!emory!wa4mei!ke4zv![e-mail]:
[e-mail]
<[e-mail]>, <[e-mail]>,
<[e-mail]>Reply-To : [e-mail] (Gary
Coffman)Subject : Re: Beginner packet help needed.In article
<[e-mail]> [e-mail] (Steve Urich)
writes:>[e-mail] (Brian Kantor) writes:>>>We're installing
one here in San Diego sometime in the next few months,>>with
56kb, 9600 and 1200 bps full-duplex repeater user access, 9600
bps>>metropolitan trunking, and it will participate in the
California>>Intercity network.  I think it will give us a really
nice network hub>>>This is the sort of community resource that
people CAN get together to>>finance and support, and all the
packeteers in the area benefit thereby.>>    - Brian>>    <*> Once
again this resource is the best way to go if you want to>
keep costs down and let everyone enjoy the fruits of packet>
without having to do it all by only 1 supporter. I guess you>
 could start a public HUB club and ask for yearly donations >
 like PBS television :-).We do it the old fashioned way with
packet radio clubs supporting thepacket equivalent of repeaters
just like old line clubs support voicerepeaters. Packet is no
longer the province of the lone wolf. To doany worthwhile
networking requires organizations that can coordinateand finance
packet trunks and LAN services. Here in Georgia the LANs are
organized as local clubs who are members of the
statewidenetworking organization Grapes. Note that Grapes is not
a membershiporganization, it's members are the local clubs that
make up theLANs. It acts as a coordinating and implementing body
for statewidenetworking activity. All network switches are owned
and financed byGrapes while LAN services are the responsibility
of the local clubs.Gary KE4ZV------------------------------Date:
8 Nov 91 01:32:31 GMTFrom:
ogicse!emory!wa4mei!ke4zv![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To : [e-mail] (Gary
Coffman)Subject : Re: Digital Packet Repeater Info WantedIn
article <[e-mail]> [e-mail]
(Bill Gunshannon) writes:>So, lets get practical.  I have a
couple of DR-200s friom PACCOMM.  What is the>likelyhood that I
could throw together the necessary software to make one of
these>receive on one channel and immediately retransmit the bits
on the other channel>thus providing a cheap, regenerating,
full-duplex repeater??>I'm probably going to give it a try one
way or the other as the only other choice>for these boxes is
ROSE and I don't see a lot of interest in doing that.>>Basicly,
I plan to look at making it take the bits exactly as it receives
them >stuff them out the other port.>Any comments??Ok, I'll tell
you how we do it in hardware. We take the output of thereceive
modem and pass it through a multiplexer chip to the
transmitmodem. The other side of the multiplexer goes to the
TNC's SIO so thebackbone link, handled by one of our switches,
can access the LAN.We OR the CTSA of the SIO with the CD line of
the receive modem to generate PTT. So either an incoming packet
or the trunk switch can key the repeater, and the proper data
stream is switched to the transmit modem by a selector derived
from either CD or CTSA feeding the multiplexer chip. Two gates
and a multiplexer do it all and they plug onto the
modemdisconnect header of the TNC. Neat and simple. No software
changesrequired. We run ordinary KISS in the TNC. The switch
sees everypacket on the LAN, but only acts on those addressed to
it. Notethat you don't use a via to connect to somebody else on
the LAN,but you do use a via to connect to somebody outside the
LAN bymultiport digipeating. You can also connect to the switch
and use it's NETROM emulator to get out of the LAN, and, of
course, TCP/IPworks correctly. We run a local version of Phil's
NOS code on theswitches.For a standalone repeater, all you need
is to wire CD to PTT andloop data from the receive modem to the
transmit modem.Gary KE4ZV------------------------------Date: 8
Nov 91 01:48:04 GMTFrom:
pacbell.com!att!emory!wa4mei!ke4zv![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To : [e-mail] (Gary
Coffman)Subject : Re: Digital Packet Repeater Info WantedIn
article <[e-mail]> [e-mail] (Willis Marti)
writes:>In article <[e-mail]>,
[e-mail] (Dana H. Myers)>writes:>[skip]>"The hidden
transmitter problem is eliminated. Completely. 100%.
Every>receiver on the duplex machine can hear every other
transmitter. 100%.">>While I agree wholeheartedly with the
arguments for duplex repeaters, the>above statement is a bit
optimistic.  What (I think) you mean is that:>"Every receiver on
the duplex machine {i.e. those that can hear the>repeater} can
hear every other transmitter THAT THE REPEATER CAN HEAR.">>There
will still be cases of systems the repeater cannot hear but that
can>& will be heard by stations in the repeater's area.  Packet
frequency usage>and siting would have to coordinated a whole lot
more than it is now to>completely eliminate the possibility.At
least in the SERA's area of authority, duplex repeaters are
duplexrepeaters whether they carry packet data or voice. The
same coordinationprocess applies to both, and both use the same
set of repeater channels.Therefore problems of interference are
exactly the same for voice anddata repeaters. SERA does a great
job and most repeaters never experienceco-channel interference
unless there is a grandaddy of a band opening.Operating simplex
on a repeater input is bad amateur practice and wewill T-hunt
you down and file a complaint with the FCC.>On a side issue, can
anyone tell me if the Ramsey 2m kits can readily be>set up for
duplex operation?No. There isn't enough shielding between
transmitter and receiver, in fact,there is none. To operate
duplex you need repeater grade radio equipmentlike Motorola or
GE that offer superb isolation between transmitter andreceiver.
On the other hand, the Ramsey is a superb data radio for useto
*access* a duplex repeater, I'm using one now in place of tying
up aIC-28H. They switch fast and have adequate power and
sensitivity to beused with a repeater.Gary
KE4ZV------------------------------Date: (null)From: (null)I
have news on several fronts: DSP, DOVE, Phase III-D.DSP:  At
long last, the AEA box is right as rain.  I cannot tell you
howpainful this has been personally.  Over a year ago, Brooks
Van Pelt,KB2CST, went off on his own, with all he learned from
Pat (KA2MOV) andI, while funded by AEA and started the DSP-12
(the LL Grace box).  Ikept telling AEA that we had to hold off
until the hardware was right.They kept insisting that I fix the
software first.  I could never seemto get it through their thick
heads that the egg comes before the chicken.What they wanted to
do was to sell the hardware, as is, with the best jobI could do
with the software.  I refused.  The result of this was
thatBrooks was able to finally get to the point WHERE THE AEA
BOX WAS ONE YEARAGO, and he started marketing the box.  Unless
something has recentlychanged, the DSP-12 is NOT LEGAL FOR SALE
OR OWNERSHIP IN THE UNITED STATES.This is because as of the last
time I investigated (three weeks ago) it had NOTbeen through the
FCC Certification process.When Brooks started shipping his box
about 3 months ago, AEA absolutelypanicked.  They went
absolutely nonlinear.  Brooks is a small operation,and unless he
licenses the technology to another firm, which I wouldresist
mightily, he is a pimple on the butt of the world.  He cannot
domore than 10 a month production for the amateur market.  I
have done all inmy power to resist the move by AEA to force
Brook's former partners fromsuing him.  In my opinion, Pat and
I, and AEA have nothing to gain bygiving him a David versus
Goliath martyrdom to live under.  It is clearto me that he has
no assets that I could collect to pay attorney's feesand AEA
insists that Pat and I eat those costs.  FORGET IT.  I believe
Brooksis teetering on the brink of financial disaster and I for
one just want toleave him alone and let him sink under the
weight of the pile he has madefor himself.  On a positive note,
after refusing to move forward at alluntil the analog front end
of this box was made right, we have succeededdue to a brilliant
piece of retrofit engineering by Al Chandler, K6RFK,the VP
Engineering at AEA.  It is a great piece of work and fixes all
theproblems I have encountered.  I RECEIVED THIS FIX LAST
SUNDAY, thus the reasonwe have gone substantially nowhere in
months.  The problems were all due tothe AGC implementation that
Pat, Brooks, and I chose for the AEA DSP box andit caused poor
performance in places that I refused to tolerate. Brooks
haschosen to give up on those modes where this is a problem. I
refused.  The box,as originally designed, and essentially copied
by Brooks for the DSP-12 in theDSP section, did an absolutely
horrible job on Morse, AMTOR, APT-WEFAX, andother amplitude
modulated modes, including some slow QAM stuff I have
beenworking on for HF work.  I have now done an implementation
of EVERY MODEMPROMISED TO AEA IN THE BEGINNING, and all that
remains is a bit of tweaking,and adding of frills that makes the
things easier to use.  N0JCF, W3IWI,KA2MOV, N6IA, K6RFK, and
myself will all be testing these things as they gettweaked
starting next week.  It's a short timer at long long last and I
willthink long and hard about tackling such a project again as a
basement wizard.DOVE:  As I've already mentioned, I got sent
away from home several weeks agofor the job.  Unfortunately, as
far as doing DOVE's initial code load,I AM IT.  It requires a
special procedure, using S band equipment, which Iwill describe
in detail in an upcoming article, and this procedure takeslonger
than two days, and that is MUCH longer than the six hours at a
whack Ihave had to do the job in the past few weeks.  Harold
Price, NK6K, has done agreat job on getting the software ready
for his end, I have all the voicesoftware running and tested at
home, I have several voice files ready to load,I just need time
at home to use the station to load the bird.  I hope that canbe
done next week.One more interruption, albeit a pleasant one,
occurred last weekend.  SeveralAMSAT engineers and other
volunteers met in Orlando, Fla (no sight seeingwas accomplished,
we worked the entire time even down to the attitudeadjustment
times, on Phase III-D).  As many of you know, we are starting
anew major satellite project in AMSAT, to be launched on an
Ariane 5.We are one of the payloads selected for the test
launches of the new Ariane5, being developed now.  This was made
official last July.  So good is ourreputation with ESA and
Ariane, our bird is THE load bearing structurefor ALL the other
payloads in our particular launch (CLUSTER is the ensembleof
other payloads).  Our bird is a massive brute.  In its
currentconfiguration it is 500-600 Kg and 3+ meters in diameter
with extendable solarpanels that make it 10+ meters cross make
this by far the most ambitioussatellite project.  In the openly
expressed opinion of many participantsin these engineering
meetings, it is one of the most ambitious volunteertechnical
EVER attempted.  It is exciting to be a part of it.  Launch
isscheduled for 1995 though many of us believe it will slip to
1986 at theearliest.  We need this bird for sure since AO-13 has
been the recipientof some unusually chaotic dynamics in it
nonlinear dynamical system.  Itwill reenter the earth's
atmosphere and burn up in 1986 due to a completelyunknown to us
perturbation produced by the unfortunate choice by us
forinclination and the RAAN given to us by the launcher and
effects of theirrelationship to the orbit of the moon and forces
from the sun's gravity.Tom Clark, W3IWI, at Goddard Space Flight
Center has worked with colleaguesthere on a study he
commissioned and has found just how both lucky andunlucky we
are.  AMSAT engineers from Finland, Germany, and the US werein
attendance.  If you include UOSAT amateur radio payloads (even
if youdon't but I just wanted to include them) we are by far the
mostfrequent flyer on Ariane, and more to come.That is enough
for now, I will hope to see many of you in Los Angelesat the La
Cienega Holiday Inn for the AMSAT annual meeting.  There willbe
a FULL SCALE mockup of Phase IIID there for your
amusement.Bob------------------------------Date: 7 Nov 91
20:05:13 GMTFrom: ulowell!tegra![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedIn article
<[e-mail]> [e-mail]
(robert.f.casey) writes:   In article
<[e-mail]> [e-mail]
(Jack Brindle) writes:   >same rules that are used to coordinate
voice duplex repeaters should   >be used to coordinate packet
duplex repeaters. Especially since they   >tend to share the
same frequency bands.   Couldn't one just take an existing
underused voice repeater and convert it   to a data repeater?
Coordination is already done (unless the requirements   of a
data machine are much different than voice). This is what
happened in this area.  At first the coordinators hadtrouble
with it being packet on repeater frequencies.  Now thesituation
seems more reasonable with the distinction being simplex
vsrepeater pair coordination.  The requirements of a data
machine canactually be less if you assume that only fixed
stations with beams areaccessing it.  Re-use of the pair should
be easier than with highpower omni-mobiles roaming around as
with voice repeaters.        Would a data machine and   a voice
machine in the next county live with each other on the same
frequency?   I could see it happen that we would get a random
distribution of voice and    data machines in the repeater
subbands, the data machines being converted   voice machines.
(people have mentioned that there is an overabundance   of voice
machines around)  I don't see any real problem with coexistence.
 Even though there isan overabundance of voice machines the
spectrum in most areas isallocated.  Taking away allocation is a
very touchy subject if it isyour allocation that is
taken.(Example, supposedly there is someone in Boston with three
UHF allocations.  three repeaters linked together at someone's
house. silly but thats the way it is.)jv.   .  The end of the
world doesn't come suddenly and without warning. To 9 3
imagine it does is to be fooled by popular misconception and
thus  .    fail to recognize the larger picture.  The end of the
world is an       ongoing process.  It starts slowly,
imperceptably then blossoms       unnoticed in our very midst
until it has engulfed all that there is       and none is free
from its spell. _____|     | Johnathan Vail     [e-mail]
  [phone]|Tegra|      MEMBER: League for Programming
Freedom -----   [e-mail]
N1DXG@448.625-(WorldNet)------------------------------Date: 8
Nov 91 03:59:11 GMTFrom:
pacbell.com!iggy.GW.Vitalink.COM!widener!ukma!aunro!ve6mgs!mark@u
csd.eduTo: [e-mail]
<1991Nov6.013911.1898@anasaz>,
<[e-mail]>,
<[e-mail]>Subject : Re: CSMA/CD vs.
CSMA/CAFrom: [e-mail] (Andrew Payne)>The
problem is doing collision detection cheaply (or at all) at high
data>rates (I think this discussion has come up
before).>>Collision detection is an *analog* process, done at
the physical layer.  So>for a system with CD, you not only need
full duplex equipment, but you need>some CD circuitry.  How
complex is this circuitry?No, collision detect, due to the
delays, will have to be a *digital*process. I expect the packet
to start sending and if a similar packet doesn'tshow up on the
repeater output in set (parameterized) time I will unkey.The
protocol may have to be changed to allow for a `destroyable'
headerdue to doubling. I do NOT expect any problems even
handling 56KBaud sincethe TNC could be sped up by using a Z80H
or whatever if necessary.>My point is that doing collision
detection on a full duplex repeater/full>duplex user system is
complex and costly.  It doesn't sound worth the effort.Afraid to
write software? and you are on a computer network? Wow ...
Thecomplexity `may' come in on making full duplex radios, but I
am sure thata Full Duplex KISS TNC can handle the vulgarities of
collision detection.Ciao, 73 de VE6MGS/Mark
-sk-------------------------------Date: 8 Nov 91 04:32:51
GMTFrom:
pacbell.com!iggy.GW.Vitalink.COM!widener!ukma!aunro!ve6mgs!mark@u
csd.eduTo: [e-mail] <04.Nov.91.17:,
24:54.GMT.#[e-mail]>,
<[e-mail]>pSubject : Re: Digital
fullduplex repeaters.From: [e-mail] (Gary Coffman)
sez:>There are no hidden transmitters in a full duplex repeater
system. Either>you are in range and can use the system, in which
case you hear everybody>courtsey of the repeater, or you are out
of range and can't use the system.>Our LANs are laid out based
on the 100% coverage curves of our repeaters.>If you aren't in
the coverage, you're supposed to be on another LAN.Are you not
being a bit optimistic? In our considerably more
sparcelypopulated area (about a million people) we could NEVER
force this. The areathat the population covers is `just' a bit
larger than an acceptable footprintfor a regenerative repeater.
There WILL be weak stations that `may' trip therepeater `some'
of the times that will be strong enough to break up otherpackets
(A hidden transmitter problem) by taking the signal out of
fullquieting into the repeater.If the system were CSMA/CD this
wouldn't happen tho' ... :-} cause the errantsystem will be wise
to it's ways :-).Ciao, 73 de VE6MGS/Mark
-sk-------------------------------Date: 8 Nov 91 19:08:43
GMTFrom:
qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>, <[e-mail]>Subject :
Re: Digital Packet Repeater Info WantedIn article
<[e-mail]> [e-mail] (Johnathan Vail) writes:>
 In order for this system to work, not only the digi-peater, but
all the>   users have to be running true full duplex.  They have
to be able to hear>   themselves transmit so that they know they
have captured the repeater.>>This is not necessary.  The users
running full duplex will sense>collisions but that is a minimal
gain compared to eliminating the hidden>transmitter problem,
which half duplex users of a full duplex repeater>can do.I still
hear lots of doubles on FM voice repeaters, especially in
N-wayrandom
roundtables...Phil------------------------------Date: 8 Nov 91
19:19:10 GMTFrom:
qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedIn article
<[e-mail]> [e-mail] (Dana H.
Myers) writes:>  What you are describing is Carrier Sense
Multiple Access/Collision>Detection, which is certainly an
improvement over the plain old CSMA>we currently use in packet.
Of course, to actually use CSMA/CD every>packet user would
require special hardware and software, which makes>it rather
unattractive....The "special hardware" required for full duplex
CSMA/CD could be assimple as a second radio (on a different
band, to eliminate the needfor a duplexer).  OSCAR users have
been doing this for years. Yes, youdo need special software, but
once this has been written it can bemuch more easily duplicated
than special hardware.Phil------------------------------End of
Packet-Radio Digest V91 #289******************************Date:
Sun, 10 Nov 91 04:30:08 PSTFrom: Packet-Radio Mailing List and
Newsgroup </dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #290To: packet-radioPacket-Radio Digest         Sun,
10 Nov 91       Volume 91 : Issue 290Today's Topics:
  9600/19.2k modem interfacing info wanted               Atari
Mega 4 + 50 MB HD + Laser for sale                Digital
fullduplex repeaters. (2 msgs)             Digital Packet
Repeater Info Wanted (2 msgs)                           Help for
the New                   HP 48sx running packet? (2 msgs)
        Spectral Efficiency of Duplex RepeatersSend Replies or
notes for publication to: <[e-mail]>Send
subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 8 Nov 91 17:04:19 GMTFrom:
cs.utexas.edu!hermes.chpc.utexas.edu!corvette.utdallas.edu!tamsun
!cs.tamu.edu![e-mail]: 9600/19.2k modem
interfacing info wantedTo: [e-mail]'d like to
gather the information as to how the various modems are
interfaced with radios.  Obviously, folks have accomplished
this, but theredoesn't seem to be a compendium of details for a
person that has modem X andradio Y and doesn't know where he
should stick the wires in.  If people will send their details, I
will archive them and have them available on an anonymous FTP
site, probably csseq.cs.tamu.edu.  If this already exists,
please hit me with a rubber chicken and correct myignorance.73,
Kurt-- Kurt Freiberger, wb5bbw      [e-mail]   409/847-8607
 fax:[phone]Dept. of Computer Science, Texas A&M University
     DoD #264: BMW R80/7 pilot"We preserve our freedom using
three boxes: ballot, jury, and cartridge."      *** Not an
official document of Texas A&M University
***------------------------------Date: 9 Nov 91 15:13:31
GMTFrom:
sdd.hp.com!cs.utexas.edu!utgpu!news-server.ecf!epas!meggin@ucsd.e
duSubject: Atari Mega 4 + 50 MB HD + Laser for saleTo:
[e-mail] might be willing to sell one of our Mega
4's, depending on whatkind of offer we receive. Here is the
complete system: Atari Mega 4: M68000 Chip, 4MB RAM, 720K DSDD
Floppy built-in,               detached keyboard Atari SM124
Monochrome monitor Bytesize systems 50 MB hard drive Atari
SLM804 laser printer (300 dpi, 8 pages/sec) + controller Cables,
etc. Misc softwareThis is an ideal system for Minix 68K (if you
have a legal copy ofMinix, I will supply you with an updated
kernel, etc) or for DTPwith Calamus under TOS. If you're
interested, drop me a line.For a decent offer with a certified
check, we will deliver within3 hours (or so) of
Toronto.David------------------------------Date: 8 Nov 91
09:03:06 GMTFrom:
pacbell.com!att!linac!uwm.edu!wupost!cs.utexas.edu!swrinde!elroy.
jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]:
 Digital fullduplex repeaters.To: [e-mail]
message <04.Nov.91.17:24:54.GMT.#[e-mail]> you write:>
The idea of bit-level repeaters surely breaks down in> the case
of amateur style less-than-100%-reliable paths, and when the>
system is not fully-connected (hidden transmitter problem).>
Only by receiving the *whole* of a frame (assuming we are using>
HDLC and AX25) and performing the usual CRC, can we be sure
that> the frame is 'clean' and therefore worth repeating.But we
don't _have_ to be sure - only "reasonably sure".> This implies
store-and-forward at level 2, in other words a frame-level> (as
opposed to a bit-level) repeater.You've never used a digital
DUPLEX repeater, have you?It's EXACTLY like a _V_O_I_C_E_
repeater!  It's NOT a DIGIpeater, tcp/ip gateway, netWRONG,
TheNet, ROSE, or any of this other store and forward
electro-junk.You send a packet on channel A, and it sends it
right back out on channel B, where everyone else is
listening.IMMEDIATELY!You could use it for VOICE.That's why some
will add a modem to decode, then immediately regenerate, the
packets.  (Of course, this "cleans" them up, too.)            -o-We have
2 of them here in Los Angeles, and the problems you imagine are
not significant realities.What you'd gain in the way of the tiny
percentage of corrupt packets not retransmitted, you'd lose many
times over in collisions and wasted time.> I suspect the FCC may
take offence at any repeating of incomplete frames,> or those
where the 'callsign' octets have been accidentally modified....I
suspect they don't, any more so than voice repeater sysops could
be found fault with because a user is in a grungy area and can't
properly identify.  None of our repeaters have been cited thus
far, and I'm not anticipating any.The FCC is not some hideous
monster waiting for the opportune time to strike at our
collective jugulars.  They realize that some packets will be
corrupt.> If you just regeneratively repeat at the bit level,
without checking the> validity of the bits in their level-2
context, there is a strong possibility> that you will spend some
significant time repeating garbage.This is rare in the real
world of duplex packet repeaters.> For example, your DCD or
Statemachine may be triggered, so you start> repeating on the
output frequency, then you get hit either by a> burst of
intermod, or a 'hidden station' stamps on your repeater input>
frequency.nope - the DUPLEX repeater is transmitting, so all
other stations on the repeater pair HEAR it and DON'T
transmit.Let me reiterate for the giggly-zillionth time:On a
DUPLEX PACKET REPEATER (it's like a VOICE REPEATER), there are
*****************************************************************
************_ N _ O _   _ H _ I _ D _ D _ E _ N _   _ S _ T _ A
_ T _ I _ O _ N _ S _ ! _
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^*****************************************************
************************A "double" is a rare occurrence,
especially if all are using sensible p-persist settings.Intermod
is not a significant problem at decent sites with properly
designed repeaters.> The smart repeater should detect this, and
stop repeating; but> it has already sent part of a frame (which
it was repeating before the> noise/intermod. appeared) on the
output frequency; others see the> repeater as having repeated an
incomplete, junk frame.> The extent to which this is harmful
depends on several factors, some> of which are:-> >  (1)
Synchronisation time of the modems.>  (2) TX/RX changeover time
(turnround time) of the radios>  (3) Typical duration of a
single frame.>  (4) Ratio of (1+2) to (3)> > The only case where
i can see a legitimate use for bit-level> repeaters is where
there is nobody else using the frequencies, both> the repeater
and the stations it links are using highly-directional beam>
antennas, and the link shows a very low error rate..You're
needlessly complicating things, and the potential return is so
small as to be insignificant.The pair would have to be a
coordinated repeater pair, of course.Directional antennas are
nice, but not nearly as mandatory as you imply.They work
marvelously over wide areas - at 1200 baud, 9600 baud, and even
higher baud rates.> An example would be to link two adjacent
valleys, on a dedicated> frequency.This would be a PAIR of
frequencies - just like a VOICE repeater!!!> In other cases, it
seems to me that frame-level repeaters are the preferred>
solution.You're still left with hidden terminals with frame
level repeaters,because of the non-immediate capture of the
frequency.Duplex packet repeaters DO work - orders of magnitude
better than ANY store and forward system I've ever seen.>  Pete
Lucas   [e-mail]    PJML%IA.NWL.AC.UK@UKACRL
G6WBJ.ampr.org Yours,  _ _ _             __ ' ) ) )   /       /
)        _/_  / / / o /_  _   /    . . __  /  o _ / ' (_<_/
<_(/_ (__/ (_/_/ (_<__<_/_)_  Packet: wd6ehr@n6yn.#soca.ca.usa
 [e-mail] [44.16.0.21]
wd6ehr.ampr.org![e-mail] or [e-mail]   CI$
73240,3523 wd6ehr-3 netrom switch   wd6ehr-6 conference bridge
wd6ehr-8 mbox/info 146.745 @ 1200 baud <----> 439.025 @ 9600
baud <----> 28.103 @ 300 baud 7921 Wilkinson Avenue; North
Hollywood CA USA 91605-2210 (818)
765-2857------------------------------Date: 9 Nov 91 01:50:18
GMTFrom:
usc!elroy.jpl.nasa.gov!orchard.la.locus.com!devnet.la.locus.com!d
[e-mail]: Digital fullduplex repeaters.To:
[e-mail] article
<08.Nov.91.11:34:31.GMT.#[e-mail]>
[e-mail] (Pete Lucas, NERC Computer
Services, Swindon) writes:>>>I do not see how a full-duplex
repeater can cure the 'hidden station'>problem. While this may
work in a fully-connected system,>topography and propagation
make it a false assumption for the real>world, where re-use of
frequencies in adjacent areas is essential.   Let me try this
just one more time... by making all transmittersvisible *in real
time* to all other stations *using the repeater*,there are no
hidden transmitters.  This statement sort of explainsitself. By
making it so all stations can see all transmitters, thereare no
hidden transmitters. I do not know how to make it any
simpler.>The analogy of voice repeaters is flawed, since voice
repeaters *do* provide>filtering, on the basis of PL or CTCSS
tone. They do not repeat everything>(though at times it sure
sounds like it!).  Your understanding of the analogy of voice
repeaters is flawed.Until recently, most voice repeaters in
Northern California hadno CTCSS. They repeated everything that
achieved enough quietingto break the receiver squelch. As a
result, you sometimes heardpeople that were too far away to hear
the repeater. However, thesestations were always quite weak and
easily captured, and it isnot illegal to capture them since you
are not jamming theirtwo-way non-broadcast operation. However,
this is not a caseof hidden transmitter syndrome. It is a case
of exposed transmittersyndrome.>Dana's idea of repeating
everything is spectrally inefficient and seems to>be contrary to
basic logic; IMHO you should establish a principle of
only>repeating that which is necessary.  Gary KE4ZV recently
posted empirical observations that indicated aLAN running on a
duplex repeater provides generally twice the throughput(much
more under heavy loading) than a simplex digipeater based
LAN,which refutes your statement of spectral inefficiency.  I
didn't invent duplex repeaters. They were invented before I
wasborn. I didn't invent duplex data repeaters; they were
invented whileI was not paying attention to packet. However,
when I discovered them,I studied up on them and discovered they
did indeed solve many ofthe problems of providing useful LAN
service without requiring anychanges (other than frequency) of
the users.  Since you obviously don't understand how duplex
repeaters workyet, I suggest you stop criticizing them and
actually learnhow they work. Refer to the Proceedings of the
Sixth and SeventhARRL Computer Networking Conferences as a
start.--  * Dana H. Myers KK6JQ         | Views expressed here are    * *
[phone]         | mine and do not necessarily    * *
[e-mail]        | reflect those of my employer    * * "Dammit
Bones, spare me the lecture and give me the shot!"
*------------------------------Date: 8 Nov 91 09:54:56 GMTFrom:
uakari.primate.wisc.edu!samsung!sdd.hp.com!elroy.jpl.nasa.gov!gri
an!puffin!wd6ehr.ampr.org![e-mail]: Digital
Packet Repeater Info WantedTo: [e-mail] message
<[e-mail]> you write:> So, lets get
practical.  I have a couple of DR-200s friom PACCOMM.  What is
the> likelihood that I could throw together the necessary
software to make one of> these> receive on one channel and
immediately retransmit the bits on the other channel> thus
providing a cheap, regenerating, full-duplex repeater??>>
Basically, I plan to look at making it take the bits exactly as
it receives > them and stuff them out the other port.> Any
comments??Assuming 1200 baud AFSK, a simple Bell 202-type modem
would do this just fine.  I doubt you'd obtain any significant
advantage from further bit-bashing. Yours,  _ _ _             __
' ) ) )   /       /  )        _/_  / / / o /_  _   /    . . __
/  o _ / ' (_<_/ <_(/_ (__/ (_/_/ (_<__<_/_)_  Packet:
wd6ehr@n6yn.#soca.ca.usa    [e-mail] [44.16.0.21]
wd6ehr.ampr.org![e-mail] or [e-mail]   CI$
73240,3523 wd6ehr-3 netrom switch   wd6ehr-6 conference bridge
wd6ehr-8 mbox/info 146.745 @ 1200 baud <----> 439.025 @ 9600
baud <----> 28.103 @ 300 baud 7921 Wilkinson Avenue; North
Hollywood CA USA 91605-2210 (818)
765-2857------------------------------Date: 8 Nov 91 19:36:33
GMTFrom:
pacbell.com!att!emory!wa4mei!ke4zv![e-mail]: Digital
Packet Repeater Info WantedTo: [e-mail] article
<[e-mail]> wd6ehr.ampr.org![e-mail]
writes:>In message <[e-mail]> you
write:>> >> In article <[e-mail]>
[e-mail] (Phil>> Karn) writes:>> >In article
<[e-mail]> [e-mail] (Gary
Coffman)>> writes:>> >> I think this is the basic sticking
point. It's barely possible to >> get *one* repeater funded,
sited, and maintained in most areas. To>> require numerous cell
sites becomes financially and organizationally>> impossible.
Most of our communications is terrain limited rather than>>
power limited so power control doesn't enter in to the equation
very>> much at all. To require many little relay sites linking
the folds>> in the terrain is more complex and expensive than
maintaining one>> very high site that looks down into all the
valleys. I understand>> that this is a local problem and that in
flat areas power control>> would be helpful, as would
directional antennas. In Atlanta we are>> looking at 500
sometime users in 1800 square miles. At any given >> time less
than a hundred of those stations are powered up and less>> than
30 are in use. They all want to be able to communicate with>>
each other in real time at some point.>>I think you're missing
Phil's point, Gary - these aren't "sites" ->they're end user
stations.  Instead of having dumb, wasteful digi's,>or netwrong
that doesn't work much better, they're RF-power
controlled>"smart" store and forward - probably at speeds more
like T-1 than>1200.  They minimize QRM by keeping power to what
is actually legally>required; the minimum to communicate.  And I
think you are missing my point, most users don't leave
theirstations turned on 24 hrs a day and there's no reasonable
way toforce them to do so. That leaves lots of people with *no*
connectivitymost of the time. That's simply unacceptable. Power
control is nota viable option when you are separated from the
nearest active userby solid granite.>Who pays for them?  Anyone
who wants to be part of this particular>high speed system.
Depending on how you view it, it's either>"democracy" or
"anarchy" :-)He who pays calls the tune and when he decides to
go on vacation orotherwise shut down his *personal* station,
numerous users are *cutoff*from network access until he decides
to come back on. We've been downthat road, it doesn't work.>As
far as halving thruput with each hop, a system that begins with
a >very high speed can afford to do that.*If* we get T1 it will
be on fixed links so dynamic power controldoesn't enter in to
the equation here either. On lower speed channelsevery bps is
precious.>If the unwashed masses want to use boring 1200,
they're still welcome>to do so, and a bent pipe duplex repeater
will work miracles for them.>We have 2 of these varmints in L.A.
(one is dual 1200/9600), and yes,>they work marvelously well -
MUCH better than a pair of simplex>channels, especially when
things get busy. Actually 9600 baud is usable, though I agree
that 1200 is worthlessfor interactive use.>Nonetheless, there's
room for both - and more - in amateur packet.Sure.>(Besides, I
have a feeling you guys know you are talking apples
and>orangutans :-)Yes, I'm interested in solving today's
problems while keeping an eyeon tommorrow. I think Phil is
looking at next century's problem forportable users of X server
palmtops. :-)Gary KE4ZV------------------------------Date: 9 Nov
91 01:35:40 GMTFrom:
usc!elroy.jpl.nasa.gov!jato!burns!spc9![e-mail]:
Help for the NewTo: [e-mail],I need some
guidance.First of all, let me say that I am just now studying to
take the Technicianslicense exam.  I became interested in doing
packet radio work as a consequenceof doing some research for a
graduate course that I am currently taking.I am an ultra novice
yet would like to become involved in packet comm.In reading
several documents included with some s/w (ka9q stuff) and in
readingthe newsgroups, It was suggested that anyone new and
interested in doingpacket radio should seek out the more
experienced hams in the area for advice.Well, here you are.I
currently live in the Duarte, CA area and would like to know if
there area plentitude of packeteers in the area (L.A./So
Cal)?Who should I contact for further info?  Is there/are there
any local groupswho administer packeteering in the area?  What
about an administrator forInternet addresses?As a beginner,
should I stay down in the lower data rate group or should Istart
right into 9600+ comm.?  Is there an emerging standard as far as
datarates for packet comm.?What kind of equipment should I get?
Already have the computer.  Anysuggestions as far as TNCs,
transceivers, etc?  (HELP!!! what do I get?!)Is it only to be
determined based upon money?Is there a standard power
transceiver necessary for packet work?Would greatly appreciate
the
help.Kolin+======================================================
=====================++  "Guilt Trip:  The nuclear weapon of
relationships."                      ++
       -- K. Hand
++---------------------------------------------------------------
------------++  Kolin E. Hand
[e-mail]        ++  Jet Propulsion Laboratory
            [e-mail]
++===============================================================
============+------------------------------Date: 9 Nov 91
15:37:17 GMTFrom: mips!quack![e-mail]: HP
48sx running packet?To:
[e-mail][e-mail] (Joel Montgomery)
writes:>I own a W2A and in the process of getting a 48sx.  I
believe that it has kermit>built into the internal software and
that an interface kit for it only costs>50 bucks or so.  I'm
expecting to have mine up and running on packet as >soon as I
finish the TNC I'm building for a school project.  Ought to work
>just fine! You are correct. The 48sx does have kermit built in.
That is what I use to communicate with my PC. I bought the
interface cable. It can be picked up for $30.00 if you know
where to buy it, and dont bother to buy the software with it.
Kermit can be found almost anywhere. But, is kermit what youd
want to use to communicate to a tnc? The 48sx is fully
programmable, and I think you can program the serial port to do
whatever you want. I would just think you'd want to open it and
have it act like a dumb terminal or something, not run kermit.
Kermit is good, but do Tnc's support it?           -- Brian
[e-mail]6CFA@N0ARY.#NOCAL.CA.USA.NA408-996
-3342------------------------------Date: 9 Nov 91 04:16:49
GMTFrom:
usc!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.iasta
te.edu![e-mail]: HP 48sx running
packet?To: [e-mail] article
<[e-mail]>, [e-mail] (Brian
Weaver) writes:> > I own an Icom W2A and a HP 48SX calculator.
The 48SX is hp's> newest top of the line calculator that just
came out about a > year ago. What makes is interesting is that
it has a serial> port, and a full a-z character set. I only use
the serial> port to interface the hp to my computer to transfer
programs> and such, I was wondering if anyone has ever written
packet> software the the 48sx? It would be just about the
smallest> portable packet station you could get, when combined
with> a HT.>  >  73's> > > -- > Brian Weaver>
[e-mail]> KD6CFA@N0ARY.#NOCAL.CA.USA.NA>
408-996-3342I own a W2A and in the process of getting a 48sx.  I
believe that it has kermitbuilt into the internal software and
that an interface kit for it only costs50 bucks or so.  I'm
expecting to have mine up and running on packet as soon as I
finish the TNC I'm building for a school project.  Ought to work
just
fine![e-mail]------------------------------Da
te: 9 Nov 91 16:31:44 GMTFrom:
elroy.jpl.nasa.gov!orchard.la.locus.com!devnet.la.locus.com!dana@
decwrl.dec.comSubject: Spectral Efficiency of Duplex
RepeatersTo: [e-mail]'ve decided that the claims
that duplex repeaters are spectrallyinefficient ignore the
following facts:    Duplex repeaters use two frequencies for X
amount of time.    Simplex digipeaters use one frequency for 2*X
amount of time.    The "time-bandwidth" product is the same.
The duplex repeater reduces the chance of collisions at    least
80%.    The real time elapsed to send one packet to another
station is    half as much.--  * Dana H. Myers KK6JQ         | Views
expressed here are    * * [phone]         | mine and do not
necessarily    * * [e-mail]        | reflect those of my employer    *
* "Dammit Bones, spare me the lecture and give me the shot!"
*------------------------------Date: 9 Nov 91 09:52:47 GMTFrom:
sun-barr!lll-winken!aunro!ve6mgs![e-mail]:
[e-mail] <1991Nov6.013911.1898@anasaz>,
<[e-mail]>,
<[e-mail]>l-wSubject : Re: CSMA/CD vs.
CSMA/CAFrom: [e-mail] (Gary Coffman)>Such dual band
radios aren't likely to be cheap, the demand will be>relatively
small and they can't be used for anything else like voice>or
simplex or conventional repeated packet on a single band. This
meansWe have to get something straight first, I was thinking of
a system of9600/19.2K repeaters requiring the data radios. There
are no used radiosthat work adequately on 9600 unless they are
hacked carefully. The costof hacking a radio is VERY close to
the price of a cheap data radio. TheData radio uses separate
transmit and receive sections so there should beno difference in
the cost between a single or dual band data radio. TheGracilis
data radio goes for about $169, I see that is CHEAP ...>that if
the repeater goes down, everybody is dead in the water.
TheyAgreed ... but our experience has been that we are dead in
the waterwhen we loose the node (on 1200 Baud packet) anyways
unless there isa backup node.>All you get is the ability to
abort a frame in progress rather than>waiting until it is over
to do the retry. You still have to do the>retry.I proposed a
junkable header to look after this, The offending stationwould
get off to let other stations use the channel instead of tying
upthe channel for however long the packet is. The junkable
header (lengthshould be configurable) would be unique, and easy
to check and wouldallow the `first' station perhaps some ability
to use the repeater afterall contenders have gotten off. This
adds some (software) complexity byrequiring a station to `know'
that it was the first one because thefirst part of it's header
was not corrupted, and may be an unreasonabledesign parameter
anyways. Just think of two ftp sessions going on, largepackets,
and a collision occurs, I would guess the channel is unusablefor
5 seconds in CSMA/CA, but could be reclamed immediately with
CSMA/CD.>>Now, if you use a dual band (ie 220MHx TX and 440MHz
Rx) regenerative>>repeater, cheaper, since we do not need cans
for it. The the single band>>repeater would require cans. We
could run CSMA/CD with the dual band data>>radio with, I am
sure, a simple mod to the KISS EPROM firmware.>Notice now that
you are asking for a different radio, inverted from>the user
radios at the repeater site. This will be really low volume>and
really expensive, but what else is new at a repeater site.
In>addition to being backwards from all the users, you still
need a stack>of cans equivalent to a duplexer in order to live
in the RF environment>of a high site with it's commercial
repeaters and pagers. You can'tTouche' (perhaps, we are talking
about a network of 2W repeaters, high placesmay not be as
necessary, RF cells is the design consideration here), I guessmy
point for a cheaper repeater are for naught, but the price
should be aboutthe same as the simplex anyways.>Packet can't
grow in a vacuum, there are practical reasons why CSMA/CA>was
the choice made for user LANs. Crossband repeating solves a
small>Problem while creating others, such as the inability to
form ad hoc>emergency networks, that are much worse.The 1200
Baud system is the BACKUP emergency network, I do not expect
itto go away as I still see people checking into Landline BBS'
at 300 Baud ...However, I am arguing for the fastest network we
can get for the same costas the CSMA/CA systems that are
starting to pop up. The power users are goingto expect SPEED out
of the ether, and I for one am dismayed at the CSMA/CAcompromise
on higher speed packet.Sure, it would be nice to get CSMA/CD at
1200, I guess, but lets leave 1200as the `cheap' system makeing
protocol improvements to get rid of it'sdisadvantages to make it
a viable backup network.Ciao, 73 de VE6MGS/Mark
-sk-------------------------------Date: 8 Nov 91 19:19:34
GMTFrom: pacbell.com!att!emory!wa4mei!ke4zv![e-mail]:
[e-mail] 54.GMT.#[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To : [e-mail]
(Gary Coffman)Subject : Re: Digital fullduplex repeaters.In
article <[e-mail]> [e-mail] (Mark
G. Salyzyn VE6MGS) writes:>From: [e-mail] (Gary Coffman)
sez:>>>There are no hidden transmitters in a full duplex
repeater system. Either>>you are in range and can use the
system, in which case you hear everybody>>courtsey of the
repeater, or you are out of range and can't use the system.>>Our
LANs are laid out based on the 100% coverage curves of our
repeaters.>>If you aren't in the coverage, you're supposed to be
on another LAN.>>Are you not being a bit optimistic? In our
considerably more sparcely>populated area (about a million
people) we could NEVER force this. The area>that the population
covers is `just' a bit larger than an acceptable footprint>for a
regenerative repeater. There WILL be weak stations that `may'
trip the>repeater `some' of the times that will be strong enough
to break up other>packets (A hidden transmitter problem) by
taking the signal out of full>quieting into the repeater.>>If
the system were CSMA/CD this wouldn't happen tho' ... :-} cause
the errant>system will be wise to it's ways :-).The errant user
wises up anyway when he finds he has no thruput. He thengoes
elsewhere and stays there. We have two LANs serving metro and
peopledo stay where they belong. Because that's the only place
where theirsystems work.Gary
KE4ZV------------------------------Date: (null)From: (null)If
you can't do collision detection for most of the packet time,
you mightwant to consider simplifying the collision detection
scheme a bit.Instead of a character by character comparision, do
a packet by packet comparison.  After you send a packet, it
should be sitting in your inputqueue.  If it is not, you assume
that it collided and queue it for retransmission.  This method
works well with the fancier chips that dobuffering, but might
have problems if your link to the repeater is weak(lots of
unnecessary retries by the sending station because it can't
hitor hear the repeater well).>Afraid to write software? and you
are on a computer network? Wow ... The>complexity `may' come in
on making full duplex radios, but I am sure that>a Full Duplex
KISS TNC can handle the vulgarities of collision detection.Nope,
not afraid of software.  In fact, my design style leans toward
doingas much as possible in software with minimal hardware.
For an extremeexample, look at Poor Man's Packet (PMP).In
summary, I'm still not convinced that collision detection as you
proposeis worth the trouble.  The "complexity" may be minimal:
just a little bitof extra code.  But you pay the price in
performance:  you are now doing a full-duplex link on a
character-by-character basis--this puts a limit on thelink
rate.Also, I don't see any big performance improvements for
collision detection scheme you propose.  I believe the question
was asked before, and I'll ask itagain here:  can you quantify
the performace gains from adding collisiondetection?-- =  =  =
=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
 =  =Andrew C. Payne, N8KEI        UUCP:
...!cornell!batcomputer!payne                          INTERNET:
 [e-mail]------------------------------Date:
8 Nov 91 19:16:58 GMTFrom:
theory.TC.Cornell.EDU![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>ry.TSubject : Re: CSMA/CD vs.
CSMA/CAIn article <[e-mail]>
[e-mail] (Mark G. Salyzyn VE6MGS) writes:>No, collision
detect, due to the delays, will have to be a *digital*>process.
I expect the packet to start sending and if a similar packet
doesn't>show up on the repeater output in set (parameterized)
time I will unkey.>The protocol may have to be changed to allow
for a `destroyable' header>due to doubling. I do NOT expect any
problems even handling 56KBaud since>the TNC could be sped up by
using a Z80H or whatever if necessary.Ok, so I assume that you
are talking of doing a character-by-charactercomaprison (taking
into account the link delay, of course) of the outgoingdata with
the incoming data.  As soon as you get a mismatch, you assume
that you had a collision and immediately stop sending.One
problem with this scheme is that it assumes that a character
stream ofthe incoming data is available.  This is fine on a
Zilog SIO or SCC but won't work on any chip that buffers
incoming packets (like most Ethernetchips) where you don't have
easy access to characters as they come in.Buffering becomes
necessary as data rates increase--you can't affort to touch each
character as it comes in our goes out.The scheme may work just
fine at low data rates with a Z80 based TNC.  It might even work
at 56kb with a souped up TNC.  I wouldn't bet on much more.It is
a shame to have the TNC as the limiting factor on the maximum
linkdata rate.However, a more serious problem is that you can
only detect collisions inthe data portions of the frames (where
characters are being sent that you cancompare).  If the
keyup/synchronization time is long, you won't gain much fromthis
scheme because you won't be able to detect collisions until well
intothe packet.  For a pathalogical example, let's consider a
56kb system.------------------------------Date: 8 Nov 91
19:15:52 GMTFrom:
pacbell.com!att!emory!wa4mei!ke4zv![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To : [e-mail]
(Gary Coffman)Subject : Re: CSMA/CD vs. CSMA/CAIn article
<[e-mail]> [e-mail] (Mark G.
Salyzyn VE6MGS) writes:>From: [e-mail]
(Andrew Payne)>>>The problem is doing collision detection
cheaply (or at all) at high data>>rates (I think this discussion
has come up before).>>>>Collision detection is an *analog*
process, done at the physical layer.  So>>for a system with CD,
you not only need full duplex equipment, but you need>>some CD
circuitry.  How complex is this circuitry?>No, collision detect,
due to the delays, will have to be a *digital*>process. I expect
the packet to start sending and if a similar packet doesn't>show
up on the repeater output in set (parameterized) time I will
unkey.>The protocol may have to be changed to allow for a
`destroyable' header>due to doubling. I do NOT expect any
problems even handling 56KBaud since>the TNC could be sped up by
using a Z80H or whatever if necessary.We have tried to make a
TNC2 with fast parts do 56 kb duplex. *We*, Grapes,can't do it.
Good luck. We've moved on to other methods such as the PI card
and the Gracilis cards. You can't get around the time of
flightproblem. In most cases the packet is just starting to come
out of therepeater as we finish sending it. Adding a long
"destroyable" headerjust wastes channel time. Even the TCP/IP
header causes an annoyingloss of thruput.>>My point is that
doing collision detection on a full duplex repeater/full>>duplex
user system is complex and costly.  It doesn't sound worth the
effort.>Afraid to write software? and you are on a computer
network? Wow ... The>complexity `may' come in on making full
duplex radios, but I am sure that>a Full Duplex KISS TNC can
handle the vulgarities of collision detection.This is not a
software problem. Primarily it is a physical problem thatneeds
physical remedies that the speed of light prohibit in
reasonableLAN sizes.Gary
KE4ZV------------------------------Date: 8 Nov 91 19:15:52
GMTFrom: sun-barr!lll-winken!aunro!ve6mgs![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>SSubject : Re: CSMA/CD vs.
CSMA/CAFrom: [e-mail] (Gary Coffman)>I said:>>The
protocol may have to be changed to allow for a `destroyable'
header>>due to doubling. I do NOT expect any problems even
handling 56KBaud since>>the TNC could be sped up by using a Z80H
or whatever if necessary.>>We have tried to make a TNC2 with
fast parts do 56 kb duplex. *We*, Grapes,>can't do it. Good
luck. We've moved on to other methods such as the I based my
statement on the fact that KISS56 runs on a 5MHz Z80, I am surea
CSMA/CD system can run on a up to 16MHz Z80 (available and
cheap, the Z80Habove is only a 8MHz part). The conversation
between the host and the TNC is aproblem, but as we make the
software smar te

r, we could add filtration to keepthe packets that we have no
interest in from hitting the KISS link. I know thatKISS is not
to understand protocols on the air, but the destroyable
headerthat I ask for is for the link layer protocol, not for the
host, and it wouldprovide this kind of control (expanding KISS
to add power control, `some'acquisition for S unit reading and a
packet transmitted status message alongwith this `budlist' kind
of control).I have seen a 33MHz 386 NOT handle 4800 Baud just
because the network cardinterrupted the processor on EVERY
network transaction, hardly an acceptablesolution on the
hardwire networks, why should it be acceptable on
packet.Methinks GRAPES took the easy way out and assumed the PC
would be hereforever, but I can not use this system since I own
a NON ?86 Unix Box.You guys locked me out !!! (How were you to
know a 16MHz Z80 was coming out)>PI card and the Gracilis cards.
You can't get around the time of flight>problem. In most cases
the packet is just starting to come out of the>repeater as we
finish sending it. Adding a long "destroyable" headerThe 56K
modem has 4 bit delay, the 9600 regenerative has a 1 bit
delay,the bent pipe repeater has NO delay. There is a TX delay
that is in theorder of 5ms in the Gracilis data radio as an
example. I expect thedestroyable header to be in the order of
10ms (10 characters at 9600, 60 at56K see more below).>just
wastes channel time. Even the TCP/IP header causes an
annoying>loss of thruput.(That is what Raw IP is for).>This is
not a software problem. Primarily it is a physical problem
that>needs physical remedies that the speed of light prohibit in
reasonable>LAN
sizes.2*(30Miles/186000Miles/sec)*56000bits/sec*(1/8)chars/bit =
2 characters !!!speed of light is `there' at 56Kbps, but hardly
an issue as compared torealizable TX delays of 5ms (35 chars at
56Kbps). However, this is stillsmall with respect to the packet
sizes I expect to see (greater than 4096 at56Kbps, greater than
1024 at 9600).Next ...Ciao, 73 de VE6MGS/Mark
-sk-------------------------------Date: 9 Nov 91 11:30:24
GMTFrom:
uakari.primate.wisc.edu!news.larc.nasa.gov!elroy.jpl.nasa.gov!sdd
.hp.com!cs.utexas.edu!uwm.edu!lll-winken!aunro!ve6mgs!mark@ames.a
rpaTo: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>pSubject : Re: CSMA/CD vs
CSMA/[e-mail] (Andrew Payne) sez:>Ok, so I
assume that you are talking of doing a
character-by-character>comparison (taking into account the link
delay, of course) of the outgoing>data with the incoming data.
As soon as you get a mismatch, you assume >that you had a
collision and immediately stop sending.Yup, mainly because I am
thinking of using a TNC-2 as the controller tokeep me from being
tied down to any specific host processor platform, andbecause of
a Firm conviction on my part that the TNC-2 can be souped
upenough to handle up to 56Kbps effortlessly.>won't work on any
chip that buffers incoming packets (like most Ethernet>chips)
where you don't have easy access to characters as they come
in.>Buffering becomes necessary as data rates increase--you
can't affort to >touch each character as it comes in our goes
out.As the complexity of buffering is added, a small
microcontroller, I wouldsee no problem with adding additional
hardware to make the collisiondetection work at higher speeds.
Higher speed LAN cards are smart enoughto only interrupt the
host processor when a packet that is associated withthe host
processor is being processed, sounds pretty smart to me, a
delayedcollision detect would be a trivial problem to implement
in hardware. Abucket brigade that matches the destroyable header
to the shifting value ofthe received packet would be simpler
than the buffer control hardware.>The scheme may work just fine
at low data rates with a Z80 based TNC.  It >might even work at
56kb with a souped up TNC.  I wouldn't bet on much more.>It is a
shame to have the TNC as the limiting factor on the maximum
link>data rate.For now, true, but I expect that at higher rates
than 56Kbps, 1Mbps forexample, hardware will be honed quit
adequately for the purpose. Collisiondetection may not be an
issue as compared with Transmit and Propogationdelays and
bandwidth requirements. If we NEED a link that fast, I
expectthat Spread Spectrum technology or single dedicated users
(backbones) we forgoANY collision detection.>From the paper in
the 6th CNC, WA4DSY's modem takes 10 to 13 ms to>stabilize
before data can be sent.  Assuming that the repeater is
>regenerative, let's make the total delay 20ms. Not a problem
since I expect to keep the transmit side of a
regenerativerepeater always active, keying the transmit finals
ONLY. I expect that thecommunity will demand quick keying on the
repeater, heck, the repeater couldbe keyed up ALL the time
ignoring the power consumption and legalities ofthe situation
which would give us a 4 bit time delay at 56KBaud.I may have
missed the point here, as I have not perused the details of
thisstabilizing time. Is the stabilizing time based on transmit
(no problem),or receive locking (A BIG PROBLEM)?>If you can't do
collision detection for most of the packet time, you might>want
to consider simplifying the collision detection scheme a
bit.>Instead of a character by character comparision, do a
packet by packet >comparison.  After you send a packet, it
should be sitting in your input>queue.  If it is not, you assume
that it collided and queue it for No gain here, Collision
detection should prevent access to a channel, notgive blanket
permission to make it unusable for the entire length of
thepacket.>, but might have problems if your link to the
repeater is weak>(lots of unnecessary retries by the sending
station because it can't hit>or hear the repeater well).Well,
this reality may be the ONLY problem that I see, but a weak
station,if the collision detection is done character by
character or bit by bit, willimmediately sense it's folly and
get off the air. An annoyance to the user,but a reality of HIS
situation (I do feel pity, but hopefully HIS communitywill feel
pity and set up a linked repeater closer to his station).>Nope,
not afraid of software.  In fact, my design style leans toward
doing>as much as possible in software with minimal hardware.
For an extreme>example, look at Poor Man's Packet (PMP).Your
Hired !!!!  :-)>Also, I don't see any big performance
improvements for collision detection >scheme you propose.  I
believe the question was asked before, and I'll ask it>again
here:  can you quantify the performace gains from adding
collision>detection?No I can't on an RF LAN. CSMA/CD is a
requirement on wired networks and thereIS an improvement. On a
RF LAN, the only way we can guarantee this similarimprovement is
to keep the repeaters running at top efficiency (keyup
time).This improved efficiency `may' cost, but IMHO it is simply
good hardwarepractices (keep TX section `just' ready to key up)
and not unusual orcomplicated hardware that will provide
this.Any delays in the repeater, double it (due to my suggestion
of adestroyable header), and that is the window for collisions
to occur. Thisoverhead WILL have a major effect on the payback
of CSMA/CD and I do NOThave the tools handy to figure out where
we loose this payback as comparedto CSMA/CA (I was hoping that
the net would have a guru with the numbers).Someone out there
should have a network simulator package that can have aRX delay
automatically added back in.But, a cursory view, for average 1
second packets at 9600 Baud and a 20ms(highly conservative)
delay would only yield a 2% increase in channelefficiency over
CSMA/CA. But, if we include the ACK and other short
packets(<40ms) as well into the average, I expect that the
improvement would becloser to 10% (a guess) on the above case
because CSMA/CA would have distintproblems even knowing that a
collision occured on the short packet, causing anunnecessary
retry, in the case of the ACK packet (my guess would be
larger,but there are software schemes that will help the CSMA/CA
case due to everyoneunderstanding priority acknowledge). Idealy,
CSMA/CD ONLY has a 20ms headerwastage, the channel can be used
FULLY, while the CSMA/CA schemes oftenrequires the channel
sitting idle for extended periods of time to work (thebackoff
algorithms and random waits after collisions) easily wasting
more thanthe destroyable header and repeater delays in channel
access.Thanks, 73 de VE6MGS/Mark
-sk-------------------------------End of Packet-Radio Digest V91
#290******************************Date: Mon, 11 Nov 91 04:30:05
PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #291To: packet-radioPacket-Radio Digest         Mon,
11 Nov 91       Volume 91 : Issue 291Today's Topics:
          DCD Mod and Squelch busy                    Digital
fullduplex repeaters.                   forwarded for a friend
(2 msgs)          How can I reduce interference with an HT? (3
msgs)                            packet Virus?
           Rose on PCSend Replies or notes for publication to:
<[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 9 Nov 91 15:55:14 GMTFrom:
gatech!emory!wa4mei!ke4zv![e-mail]: DCD Mod and
Squelch busyTo: [e-mail] article
<[e-mail]> [e-mail]
(Phil Karn) writes:>In article
<[e-mail]> [e-mail] (Gary
Coffman) writes:>]I don't consider our 56 kb system brute force.
We only occupy 1.2 hz>]per baud. That's much better than the 20
hz per baud of other schemes>]like the current AFSK modems that
try to operate through voice radios.>>Actually, from what I've
been learning about cellular radio (and>frequency reuse in
spectrally efficient, i.e., interference-limited>systems), it's
not so much the 1.2 Hz/bit/sec figure of the WA4DSY>modem that
makes it more efficient, but the fact that it uses much
less>energy to send each bit than does AFSK/FM. This affects how
closely you>can space co-channel transmitters without mutual
interference, which is>the single most important factor in
overall spectral efficiency.>>PhilLet me address this in two
ways. First, the bandplan allows us 100 khzchannels of which we
only occupy 70 khz. So adjacent channels actuallyhave 30 khz
guard bands. This isn't generally necessary with the
WA4DSYmodem. Operation on 70 khz channels at the same site is
possible, thoughthe guard band helps if one of the signals being
received is weak. Thespectrum is very bandlimited. Second,
capture. One of our sites is57 air miles from it's neighbor and
another site is 20 miles from thesame neighbor. The closer site
will reliably capture the channel fromthe further site. In this
case this is a bug not a feature and we aretransposing the two
sites' links to the common neighbor to differentchannels to
avoid contention. As a side note, all our links run from 3 to 7
watts into either gain omni antennas or beams. What will killa
link, however, is narrow band interference located inside the
channelspectrum. It totally screws up the slicer bias and kills
us dead.Gary KE4ZV------------------------------Date: 9 Nov 91
15:11:00 GMTFrom:
gatech!emory!wa4mei!ke4zv![e-mail]: Digital
fullduplex repeaters.To: [e-mail] article
<08.Nov.91.11:34:31.GMT.#[e-mail]>
[e-mail] (Pete Lucas, NERC Computer
Services, Swindon) writes:>>>I do not see how a full-duplex
repeater can cure the 'hidden station'>problem. While this may
work in a fully-connected system,>topography and propagation
make it a false assumption for the real>world, where re-use of
frequencies in adjacent areas is essential.>The analogy of voice
repeaters is flawed, since voice repeaters *do*
provide>filtering, on the basis of PL or CTCSS tone. They do not
repeat everything>(though at times it sure sounds like
it!).Maybe in your part of the world repeaters all use CTCSS.
Here we usefrequency coordination. The only two machines in
Atlanta that use CTCSSdo so to keep the riffraff out and not
because they have co-channelinterference. The rule is 175 miles
separation co-channel and 75 milesfirst adjacent channel. Unless
there is a monster band opening, thereis *no* interference. For
example, the nearest co-channel machine tothe one I own is 250
miles away. We've only heard it once, and havenever heard it's
users through our machine since they are lower andrun less
power. There are no hidden stations except for a few lidswho
tried to operate simplex on the repeater input channel. We
T-huntedthem and flagged them to the FCC. Problem solved.>Dana's
idea of repeating everything is spectrally inefficient and seems
to>be contrary to basic logic; IMHO you should establish a
principle of only>repeating that which is necessary. In other
words, the repeater should>be seen as a 'regenerative
bridge/router'.  We should be using the model of>two or more
LANs linked via a brouter rather than  a
'super-line-driver'>repeater that simply passes
everything.>Think like 'linking spatially-separated sub-nets'
rather than 'extending a>single network'.Think simple
connectivity. Many of our users would not be in range of*any* 24
hour station without the repeater. Store and forward halvesthe
effective baudrate. Store and forward inevitably has hidden
terminals.A repeater has neither problem and offers 24 hour
connectivity to allusers.Gary
KE4ZV------------------------------Date: 10 Nov 91 18:53:08
GMTFrom: [e-mail]: forwarded for a
friendTo: [e-mail]>From
la8ak%la9k%pi8eae.bbs@pi8eae Thu Oct 24 08:13:16 1991Received:
from pi8eae by pi8mac.ampr.org with SMTP    id AA00023495 ; Thu, 24
Oct 91 09:11:53 METReceived: from pi8eae by pi8eae with SMTP    id
AA5593 ; Thu, 24 Oct 91 08:59:42 METReceived: from pi8eae.bbs by
pi8eae with BBSFWD    id AA5591 ; Thu, 24 Oct 91 08:54:39 METDate:
19 Oct 91 00:08 ZMessage-Id: <5591@pi8eae>From:
[e-mail]: pa2agaSubject: RE:
PacketRadio Digest 91/257X-BBS-Msg-Type: PX-BBS-Path:
la9k!oz2pac!oz7bbs!oz8box!oz8bbs!oz7box!db0hes!db0hb!db0cl        db0ob
k!db0aha!pi8daz!pi8eaeHELLOJUST SOME COMMENTS ON STANDARD PACKET
RADIO CONNECTOR, THIS CERTAINLYDOES NOT PROVIDE FOR DUPLEX
OPERATION, WHICH SEEM TO INTEREST INPARTICULARLY GERMANY73 DE
JAN-MARTINLA8AK@LA9K------------------------------Date: 10 Nov
91 18:53:45 GMTFrom: [e-mail]:
forwarded for a friendTo: [e-mail]>From
on1aot%on6ar%pi8eae.bbs@pi8eae Fri Nov 01 23:25:26 1991Received:
from pi8eae by pi8mac.ampr.org with SMTP    id AA00023900 ; Sat, 02
Nov 91 00:21:35 METReceived: from pi8eae by pi8eae with SMTP    id
AA5700 ; Sat, 02 Nov 91 00:14:38 METReceived: from pi8eae.bbs by
pi8eae with BBSFWD    id AA5698 ; Sat, 02 Nov 91 00:09:25 METDate:
01 Nov 91 22:21 ZMessage-Id: <5698@pi8eae>From:
[e-mail]: pa2agaSubject: re to
digest 91/277X-BBS-Msg-Type: PX-BBS-Path:
on6ar!pi8hwb!pi8eaeFrom: ON1AOT@ON6AR.#AN.BEL.EU.ampr.orgTo  :
PA2AGA@PI8EAEReply to Digest 91/277>From ON1AOT @ ON6ARSubject:
V29 modemchip YamahaHello,I would like to get more information
and contacts with persons of the japaneesgroup PRUG (especially
with jj1bdx & je1waz).I have seen in digest 277 that they are
using a v29 chip from yamaha,I think it is the ym-7109.I have
send 2 letters to 2 OM's in the USA who are using this
chip,connected tothe modem disconnect plug of a tnc2c,but i
never received any answer.So i would like to have some contact
with the OM's in Japan to get more infoand if possible also some
layout and schematics of the diagram.Everyone can reach me via:-
Packet Radio: ON1AOT @ ON6AR- Personal adres: ON1AOT,Crauwels
Walter,Lode Vissenaekenstraat 30,2600 Berchem,
Belgium,Europe- Fax: to ON1AOT ++/32/38873571I will pay every
costs for info and documentation.I have send a lot of dollars to
the American OM's but i lost my money !!!73
------------------------------Date: 10 Nov 91 07:05:17 GMTFrom:
dog.ee.lbl.gov!csam.lbl.gov!agate!garnet.berkeley.edu![e-mail]
uSubject: How can I reduce interference with an HT?To:
[e-mail]'ve run into a nasty problem after putting
up my new dual-banderantenna (Cushcraft AR-270).  The external
antenna, now mounted infront of my house and soon to go up on
the roof, certainly solves theoriginal trouble I had;
interference from my computer and TNC arecompletely eliminated,
and I can finally run a packet operation... ofsorts.The problem
is that the antenna seems to be too good for the front endof my
Yaesu FT-470 HT.  I get public service -- police, coast
guard,and who knows what else -- splattered randomly around 2m;
perversely,it seems to be concentrated on the packet frequency I
use most often,though that might just be my paranoia.  Anyway,
the result is that,depending I suppose on whether the police are
having a busy day ornot, packet operation ranges from slow (lots
of retries as incomingpackets are disrupted by a "MAN WITH A GUN
ON 12th ST") to impossible(so many retries that the poor TNC's
give up).  No way to be running.Does anyone have any suggestions
as to what I could do?  Preferably an>inexpensive< kind of
solution... I'm definitely low-budget nowadays.Thanks a lot for
any suggestions, and73de N2LAWAdam Jacobs
(Kuznetsov)[e-mail]@banzai.cc.columbia.edu----
--------------------------Date: 10 Nov 91 14:46:29 GMTFrom:
gatech!emory!wa4mei!ke4zv![e-mail]: How can I reduce
interference with an HT?To: [e-mail] article
<[e-mail]> [e-mail] (Adam
Jacobs N2LAW) writes:>>The problem is that the antenna seems to
be too good for the front end>of my Yaesu FT-470 HT.  I get
public service -- police, coast guard,>and who knows what else
-- splattered randomly around 2m; perversely,>it seems to be
concentrated on the packet frequency I use most often,>though
that might just be my paranoia.  Anyway, the result is
that,>depending I suppose on whether the police are having a
busy day or>not, packet operation ranges from slow (lots of
retries as incoming>packets are disrupted by a "MAN WITH A GUN
ON 12th ST") to impossible>(so many retries that the poor TNC's
give up).  No way to be running.>>Does anyone have any
suggestions as to what I could do?  Preferably an>>inexpensive<
kind of solution... I'm definitely low-budget nowadays.Sure.
Build a narrow *bandpass* filter to put between your radio
andthe external antenna. HTs are made very sensitive so they can
be usedwith rubber dummy loads, and they are very wideband for
those who wantto illegally go out of band. They are natural
intermod generators. The bandpass filter will put them back the
way they should have been manufacturedin the first place and the
junk will disappear.Gary
KE4ZV------------------------------Date: 10 Nov 91 23:17:58
GMTFrom:
milton!sumax!ole!ssc![e-mail]: How
can I reduce interference with an HT?To: [e-mail]
article <[e-mail]>,
[e-mail] (Adam Jacobs N2LAW) writes:> I've run
into a nasty problem after putting up my new dual-bander>
antenna (Cushcraft AR-270).  The external antenna, now mounted
in> front of my house and soon to go up on the roof, certainly
solves the> original trouble I had; interference from my
computer and TNC are> completely eliminated, and I can finally
run a packet operation... of> sorts.> > The problem is that the
antenna seems to be too good for the front end> of my Yaesu
FT-470 HT.  I get public service -- police, coast guard,> and
who knows what else -- splattered randomly around 2m;
perversely,> it seems to be concentrated on the packet frequency
I use most often,> though that might just be my paranoia.
Anyway, the result is that,> depending I suppose on whether the
police are having a busy day or> not, packet operation ranges
from slow (lots of retries as incoming> packets are disrupted by
a "MAN WITH A GUN ON 12th ST") to impossible> (so many retries
that the poor TNC's give up)..This is a classic problem with
HTs.  The front ends are made to workonly with the standard
rubber duckie included with the radio.  Anythingelse in a high
RF environment is going to impress so much RF voltageon the
front end that it goes crazy.  I have had the same problem inmy
car with an IC2AT.  When I went from a 1/4 wave groundplane to
oneof those LONG collinear antennas, the problem got worse.I
understand the new Radio Shack HT is supposed to avoid this
problem,possibly by restricting the coverage to ham band
only.Get a standard radio, and use the HT as an HT....just for
carryingaround and use with a rubber
duckie.----------------------------------------------------------
---------------- Tad Cook     |  Phone:  [phone]
 |   MCI Mail: 3288544    Seattle, WA  |  Packet: KT7H @
N7DUO.WA.USA.NA   |   [e-mail]               |
USENET: [e-mail]      or...uw-beaver!sumax!ssc!tad
-----------------------------------------------------------------
---------------------------------------Date: 10 Nov 91 02:05:44
GMTFrom:
ogicse!uwm.edu!linac!att!cbfsb!cbnewsb.cb.att.com![e-mail]
Subject: packet Virus?To: [e-mail] this from
packet.  I wouldn't think an ascii file could do this.Is it
possible for a file that is sent as mail, or a posting, to
causeitself to get run as a program on the BBS computer?  Didn't
think so.Date: 18 Sept 91 20:46Message- ID: <4664@W7LUS>From:
KA4OPZ@W7LUSTo: VIRUS@USASubject: VIRUS in the packet system!
!Path:
KC4EWO!WB4WOR!N4UFF!KC4KRR!n4KZL!WB8CQV!KA8DRR!WA8GUG!N8GTC!

KB6RAA!KA0WIN!KC4MCQ!N4JDA!KB4VOL!WB4TEM!KB4FOEWNLAN*>W2GKN
[I;6,0]:!W7LUS My hard drive went away last night and it appears
to have been caused by a program called "Freeall" which came
from WB%*** in Stuart, FL.... using chkdsk and diskfix, both
pointed to the above file....it ate all my system files and my
packet terminal pgm....It is a 6K file made up of all lower
subset ascii...it also did in the local
bbs...===========================================================
============.(the usual disclaimers)....
WA2ISE------------------------------Date: 5 Nov 91 18:57:16
GMTFrom:
news.hawaii.edu!mpg.phys.hawaii.edu![e-mail]: Rose
on PCTo: [e-mail] article
<[e-mail]>
[e-mail]
writes:>From:    HUTIN@ASL@PSI%ASLVX6@MRGATE@SNDRTR>To:    "packet-radi
[e-mail]"@M_INTERNET@MRGATE@SNDRTR>>>The french packet
association (ATEPRA) and F6FBB have implemented ROSE>on PC based
on the sources released by W2VY. This version is
fully>operational today and will be released. I 'll get a
version and put it>somewhere for ftp access. The present version
uses serial ports but>8530 will be supported in the future. I'll
contact people in France >later this week to get advanced
details and schedules.Does the new version remove the two-hop
digipeater limitation that was part ofearlier versions?  That
limitation prevents a ROSE network from being useablewith other
networks.-- Antonio Querubin  [e-mail] /
[e-mail] /
[e-mail]------------------------------Date: 10 Nov
91 04:04:44 GMTFrom:
dog.ee.lbl.gov!csam.lbl.gov!agate!spool.mu.edu!think.com!zaphod.m
ps.ohio-state.edu!hobbes.physics.uiowa.edu!news.iastate.edu!s1joe
[e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>besSubject : Re: HP 48sx running
packet?In article <[e-mail]>,
[e-mail] (Brian Weaver) writes:>  But, is kermit
what youd want to use to communicate to a tnc?>  The 48sx is
fully programmable, and I think you can program the serial>
port to do whatever you want. I would just think you'd want to
open>  it and have it act like a dumb terminal or something, not
run kermit.>  Kermit is good, but do Tnc's support it?
> That's a good question.  The poor man's packet TNC with the
software ported over to the 48SX would* be the ultimate in small
packeteering.  Unfortunately,I don't have my 48 yet, (sniff) and
have to wait another week I guess.  I'll begin on the project as
soon as I get it though.  If it is possible to programthe serial
port directly and not bother with the kermit program, so much
thebetter.  I do know that it will* work with kermit though.  I
know a coupleof people who have used kermit or cyterm with their
TNCs and had them
[e-mail]------------------------------Da
te: 10 Nov 91 05:27:46 GMTFrom:
usc!zaphod.mps.ohio-state.edu!mips!pacbell.com!tandem!k3mc@ucsd.e
duTo: [e-mail]
<1991Nov6.013911.1898@anasaz>,
<[e-mail]>,
<[e-mail]>Subject : Re: CSMA/CD vs.
CSMA/CAI find this discussion fascinating.  For our call on the
issue, please seethe 10th ARRL Computer Networking Conference
Proceedings (1991, San Jose,CA)for our article "A Full-Duplex
56kb/s CSMA/CD Packet Radio Repeater System",by me(Mike k3mc)
and Lars Karlsson, AA6IW.Basically, collision detection is done
by comparing the bytes being receivedwith the bytes being
transmitted, taking into account repeater delays.  Andthe
repeater runs the same code as the user station.  The user
station consists of a Hamtronics XV-4 transverter (29 MHz to 433
MHz)and an SHF electronics 900 MHz transverter, with just the
receiver partpopulated.  The digital controller is a Kantronics
Data Engine.We've got the h/w together, and expect to get the
s/w running during theChristmas vacation.73
-Mike------------------------------Date: 9 Nov 91 18:11:39
GMTFrom: gatech!dscatl!wa4mei!kd4nc!ke4zv![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To : [e-mail]
(Gary Coffman)Subject : Re: CSMA/CD vs. CSMA/CAIn article
<[e-mail]> [e-mail] (Mark G.
Salyzyn VE6MGS) writes:>From: [e-mail] (Gary Coffman)>>I
said:>>>The protocol may have to be changed to allow for a
`destroyable' header>>>due to doubling. I do NOT expect any
problems even handling 56KBaud since>>>the TNC could be sped up
by using a Z80H or whatever if necessary.>>>>We have tried to
make a TNC2 with fast parts do 56 kb duplex. *We*,
Grapes,>>can't do it. Good luck. We've moved on to other methods
such as the >>I based my statement on the fact that KISS56 runs
on a 5MHz Z80, I am sure>a CSMA/CD system can run on a up to
16MHz Z80 (available and cheap, the Z80H>above is only a 8MHz
part). The conversation between the host and the TNC is
a>problem, but as we make the software smarter, we could add
filtration to keep>the packets that we have no interest in from
hitting the KISS link. I know that>KISS is not to understand
protocols on the air, but the destroyable header>that I ask for
is for the link layer protocol, not for the host, and it
would>provide this kind of control (expanding KISS to add power
control, `some'>acquisition for S unit reading and a packet
transmitted status message along>with this `budlist' kind of
control).>>I have seen a 33MHz 386 NOT handle 4800 Baud just
because the network card>interrupted the processor on EVERY
network transaction, hardly an acceptable>solution on the
hardwire networks, why should it be acceptable on
packet.>>Methinks GRAPES took the easy way out and assumed the
PC would be here>forever, but I can not use this system since I
own a NON ?86 Unix Box.>You guys locked me out !!! (How were you
to know a 16MHz Z80 was coming out)Intercooled turbocharged Z80s
notwithstanding, we hit a limit of 19.2 kbon the serial link to
the PC using interrupt per character. With 16550sand careful
tweaking, 38.4 kb is barely possible. We realized we were
flogginga dead horse fighting an async link when we should be
using DMA and interruptper packet instead. Now, with no special
driver tuning we can handle multiple56 kb modems simultaneously.
We didn't lock you out, you're free to go yourown way. I'd
suggest you hack an 8530 on your machine and write your
owndriver. Or if your machine has a smart serial controller,
then bolt aKantronics Data Engine on and let her fly. Now that's
a super TNC thatcan fly. Actually, the best way we've found to
tie a Unix box into thesystem is to take a cheap 286 motherboard
and stuff a PI card and anethernet board in it and let it act as
the radio interface. Three ofus do this at home now.Doing
protocol and power control in the TNC2 is beyond reason at 56
kb.We had to produce a special "tweak" version of KISS just to
handle theradio channel at 56 kb and the serial link at 19.2 kb.
The Z80H's timingmargins on reads are so slim already that we
had to hand select ROMS toavoid wait states. Going to the V40
DE56 allows you freedom to do more,but it costs as much as a
clone PC and spare parts aren't on every street corner when
lightning pays a visit to the switch site. Some PIcards in a
cheap 16 Mhz 286 clone lets you fly at the same cost witheasier
availability of spare parts. We have 8 active switch sites with4
more coming on line. They all have multiple ports. We can't
afford the downtime of a low volume specialty item for our
switches. We have several of the cheap PI cards on hand and 20
minute availability of PC motherboards and power supplies.
Anybody seriously building a network has to consider the cost
and manhours required for maintenance. We don't have the time to
do component level repairs anymore. We're operating a production
network with carefully drawn LANs serviced by duplex repeaters,
simplex store and forward, and 56 kb trunks interconnectingthe
LANs. We regularly service 500 in state stations and pass thru
hordes of out of state traffic without bottlenecks and
congestive collapses. We even havea 56 kb repeater in the works
for the real speed demons, not to mention acouple of nuts
pushing ethernet baseband over a 10 Ghz link. We even still tie
in antique simplex KA-nodes, Netwrongs, and creepy ROSE stuff.
Our charter is to common carrier anything that comes our way.
That's not easy andthere are some real kludges at the fringes
and connectivity isn't alwaysperfect, but we're trying with
little manpower and small dollars to achieve a quality system
that everyone can use.We have a user using a HF rig driving a
transverter, several old GE andMotorola boat anchors, bunches of
IC22As, rubber ducky HTs in apartments,multi-hundred watt Oscar
stations, and hordes of top line ricebox users.Everything from
Silent 700s to Unix boxes generate the data. Our MacIntoshuser
left town. We've got to service them all.Gary
KE4ZV------------------------------Date: 10 Nov 91 14:13:19
GMTFrom:
cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!clarkson!logic!t
[e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info [e-mail] (Gary Coffman) writes:>I
think this is the basic sticking point. It's barely possible to
>get *one* repeater funded, sited, and maintained in most areas.
To>require numerous cell sites becomes financially and
organizationally>impossible. Most of our communications is
terrain limited rather than>power limited so power control
doesn't enter in to the equation very>much at all. To require
many little relay sites linking the folds>in the terrain is more
complex and expensive than maintaining one>very high site that
looks down into all the valleys. I understand>that this is a
local problem and that in flat areas power control>would be
helpful, as would directional antennas. In Atlanta we
are>looking at 500 sometime users in 1800 square miles. At any
given >time less than a hundred of those stations are powered up
and less>than 30 are in use. They all want to be able to
communicate with>each other in real time at some point.>While I
don't disagree with the spirit of what you say, I must
repeat>that many of our users are terrain limited (and apartment
bound).>That means they have no connectivity at all without
outside aid.>It's easier to sell *one* community resource than
many, and infinitely>easier for a very small group of dedicated
volunteers to *maintain*>one site than many. Our most scarce
resource is people.>I agree, and don't let my comments act as a
damper on your approach. I>hope that you do consider that a
cellular approach *does* require more>24 hour stations
positioned at strategic locations to adequately provide>service
for all. And that somebody has to *maintain* those stations
and>pay the power bills and site rental. There never seems to be
a ham living>where you desperately need a relay.>Gary KE4ZVGary,
and all,  My major thrust in packet involvement in the past 6 or
so years hasbeen in motivation.  I think that what you are
saying is that thetechnology isn't a limiting factor in making a
'good' network for your area.  You are limited by funds and lack
of interested hams.I think that a large portion of this
conversation/thread can beshort circuited if the problem of lack
of motivation is specificallyaddressed.    A VE6 made a comment
in this thread as well about the rediculousnessof telling all of
the Alberta packeteers that they must implement high tech or at
least relatively complex hardware instead of their
145.01digipeaters.  Indeed it is rediculous.  The trick here is
to demonstratethe value of the complex implementation and then
ride the wave ofenthusiasm.  If you can't demonstrate your
proposal well enough toget popular support then there isn't any
need to discuss the implementation plans now is there?    My
proposal of three years ago was to take multiport TheNET
nodesand set them up with dedicated point to point links.  Each
site islinked to each other site by a UHF radio pair.  That
means at minimum 3 radios per site, 2 on UHF and 1 on 2m for
user access.  Allservers (ALL of them) use dedicated links to
each other and to thenetwork nodes.   Repeaters may be used in
place of 2m user access portsand, depending on performance vs
traffic, for server access points.    In the past three years
the club that I helped form to implement thisplan (North East
Digital Association) has succeeded in promotingsome 200+ radios
to be used for networking, not to mention the serversand
etcetera.  We now have a workable network from Boston to Erie
Pa.By workable I mean that any station can get on and connect to
any otherstation along the network, 24 hours a day, without fear
of getting dumped.  The whole key is motivation, not technology.
 Start simple, keep it simple.Software is secondary, so is
hardware.  Be public.  Spread documentation toEVERYBODY, users,
server ops, node ops, disinterested parties.  Make surethat ALL
hams understand that they can play a part if the follow the
simple ground rules.  Now that we've a network all sorts of neat
stuffis showing up on it.  TCP/IP, DxCluster, DOSgate, BBS
stuff, round tables,callsign servers..   280 members and going
strong.  By the way (this is a plug) if you are interested in
this club, theypublish lots of good stuff including a Quarterly
journal which comes toabout 200 pages per year.  Membership is
$15/year and does NOT supportany hardware.  NEDA, POBox 563,
Manchester NH 03105.             Tadd  --[ KA2DEW @
KA2JXI.#NNY.NY.USA.NA                - Tadd Torborg
][ [e-mail]                   - 20 Clinton St
           ][ NEDA (North East Digital Association) Editor  -
Potsdam, NY 13676        ] [ Clarkson University
          - 315-268-6288
]------------------------------Date: 9 Nov 91 16:40:10 GMTFrom:
gatech!emory!wa4mei!ke4zv![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To : [e-mail]
(Gary Coffman)Subject : Re: Digital Packet Repeater Info
WantedIn article <[e-mail]>
[e-mail] (Phil Karn) writes:>>I still hear lots
of doubles on FM voice repeaters, especially in N-way>random
roundtables...People aren't as good as machines at implementing
an optimum random backoffprotocol. We added a double beep to one
of our repeaters that helped a lot.Somebody wanting to interject
a thought keys between the beeps and normalflow waits for both
beeps. That simple little change made a world of differencein
reducing doubles. If somebody is consistently too quick on the
trigger,we follow him around at the next club social and chant
"Wait for the beep!"Very effective.Gary
KE4ZV------------------------------Date: 10 Nov 91 14:30:29
GMTFrom:
ogicse!uwm.edu!zaphod.mps.ohio-state.edu!rpi!clarkson!logic!torbo
[e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info [e-mail] (Dana H. Myers) writes:>
However, it is illustrative to understand how big the
collision>windows are for the digipeater and duplex repeater
situations. We'll>assume a 128 byte packet with only one address
pair, which results in>a packet approximately 150 bytes long. At
1200 baud, this packet will>require about 1 second to send.
Since most packeteers seem to use>synthesized radios with fairly
long TX Delays (150 - 200 mS), the total>window for collision is
1 second plus the 200 mS, or 1.2 seconds on a>digipeater where
there are hidden transmitters. On a duplex machine, the>only
time when a collision can occur is the 200 mS keyup window.
The>window for collisions on a duplex machine is 17% of what it
is on a>simplex digi.  In the case one is using a fast crystal
controlled radio,>the TX delay could be, say, 70 mS. Then, the
windows are 1.07 S versus>.07 S, or the collision window on the
duplex machine is 6% of the size>it is on a simplex digi. Of
course, the collision window is really>determined by the slowest
station on the channel.>  While p-persistance is not a panacea,
it can largely mitigate the>remaining collision window on a
duplex repeater.  Overall, under heavy>loading, a duplex
repeater can provide a more graceful erosion of>throughput than
a simplex digi. This is certainly an advantage. In>fact, it
could be the case that a heavily loaded duplex repeater>can
provide better coverage and efficiency to more users than two
simplex>digis.Your comparison here says that a repeater is
better than two simplex digis.This is VERY true.  However, a
repeater might not be at all as good asseparate dedicated links
to each station.  In some cases dedicated linksmay be justified.
 Some times taking heavy users off the repeater andgiving them
dedicated links can save the day.  This is the case currentlyat
the WA1TPP repeater in Springfield Mass.  The repeater is being
usedas a routing point for 2 VHF user access points, two NOS
nodes and three   bulletin boards.  This is too much.  At 1200
baud across the repeater there just isn't enough bandwidth.
With dedicated links to each of theusers the throughput would be
much higher.  (Best case 7x better).  Replacing the repeater
with seven half duplex radios wouldn't even bethat expensive.
The repeater has duplexers and has Tx and Rx that mustsupport a
link to the weakest user.  Most of the users can access thesite
with 1 watt.  So, the site's repeater could be replaced by 5
dipoleswith 5 1watt handie talkies, two yagis and a pair of 20
watt xtal mobiles.Seven modems/ network ports would also need to
be added to provideswitching.  However, considering the
improvement in throughput and thefact that the repeater's omni
is being replaced by a pair of yagis tothe worse case stations
the actually emitted RF at the site goes DOWN!This is a savings
of spectrum!  The 1 watt signals wouldn't be heardanywhere near
as far away as the repeater and it's omni was.    Interesting
conclusion eh?This is--[ KA2DEW @ KA2JXI.#NNY.NY.USA.NA
      - Tadd Torborg             ][ [e-mail]
                 - 20 Clinton St            ][ NEDA (North East
Digital Association) Editor  - Potsdam, NY 13676        ] [
Clarkson University                           - 315-268-6288
        ]------------------------------Date: 11 Nov 91 04:28:00
GMTFrom: mdisea![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>-Subject : Re: CSMA/CD vs.
CSMA/CAIn article <[e-mail]>
[e-mail] (Mark G. Salyzyn VE6MGS) writes:>From:
[e-mail] (Gary Coffman)>>I said:>>>The protocol may have
to be changed to allow for a `destroyable' header>>>due to
doubling. I do NOT expect any problems even handling 56KBaud
since>>>the TNC could be sped up by using a Z80H or whatever if
necessary.>>>>We have tried to make a TNC2 with fast parts do 56
kb duplex. *We*, Grapes,>>can't do it. Good luck. We've moved on
to other methods such as the >>I based my statement on the fact
that KISS56 runs on a 5MHz Z80, I am sure>a CSMA/CD system can
run on a up to 16MHz Z80 (available and cheap, the Z80HWith
extremely expensive support and memory chips......>>Methinks
GRAPES took the easy way out and assumed the PC would be
here>forever, but I can not use this system since I own a NON
?86 Unix Box.>You guys locked me out !!! (How were you to know a
16MHz Z80 was coming out)Give me a break. As one of the members
of the GRAPES board for several years,I am here to tell you that
GRAPES was NOT focused on ?86 machines only. Iactually do have
an 8088 box. That should come as a surprise to many people,since
I also have seven Macintoshes of various flavors, including
several512K boards that I use as servers. I was the first to
test a hi-speed TNCwith a host link faster than 19.2KB. I have
pushed for a KISS TNC that couldhandle faster rates. I really
believe the Z80 technology is way out of dataand needs to be
replaced with something better. 68302s are now
relativelyinexpensive. Interesting that Gracilis is the only
folks to release one...To paraphrase WA4DSY, the high-speed RF
is here. Where is the digital? And,in this case in particular,
where is the high speed digital that can providesynchronization
between sent and received bits, with delays, in real time?>>>PI
card and the Gracilis cards. You can't get around the time of
flight>>problem. In most cases the packet is just starting to
come out of the>>repeater as we finish sending it. Adding a long
"destroyable" header>The 56K modem has 4 bit delay, the 9600
regenerative has a 1 bit delay,>the bent pipe repeater has NO
delay. There is a TX delay that is in the
^^^^^^^^^^^^Not even for keyup? Do you leave the TX on all the
time, or simply trashthe first part of a packet as the TX comes
up to power? Or, do you send the"destroyable" header at the
beginning of each packet on the channel, thuslowering the
effective throughput of the channel? I really suspect that
fullduplex techniques with CSMA/CA will do far more to resolve
any problem ofthis sort than providing the necessary
hardware/software for CSMA/CD. But,of course then we have to put
our computers to the task of solving thepacket equivalent of the
four color map problem...>order of 5ms in the Gracilis data
radio as an example. I expect the>destroyable header to be in
the order of 10ms (10 characters at 9600, 60 at>56K see more
below).>>>just wastes channel time. Even the TCP/IP header
causes an annoying>>loss of thruput.>(That is what Raw IP is
for).>>>This is not a software problem. Primarily it is a
physical problem that>>needs physical remedies that the speed of
light prohibit in reasonable>>LAN
sizes.>2*(30Miles/186000Miles/sec)*56000bits/sec*(1/8)chars/bit
= 2 characters !!!>speed of light is `there' at 56Kbps, but
hardly an issue as compared to>realizable TX delays of 5ms (35
chars at 56Kbps). However, this is still>small with respect to
the packet sizes I expect to see (greater than 4096 at>56Kbps,
greater than 1024 at 9600).>>Next ...Actually, it sounds like
it's time for you to build the hardware and writethe paper to
prove your point.>>Ciao, 73 de VE6MGS/Mark -sk-Jack Brindle,
wa4fibinternet: [e-mail]:  Bothell,
WA------------------------------End of Packet-Radio Digest V91
#291******************************Date: Tue, 12 Nov 91 04:30:05
PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #292To: packet-radioPacket-Radio Digest         Tue,
12 Nov 91       Volume 91 : Issue 292Today's Topics:
    Digital Packet Repeater Info Wanted                     For
Sale: Apple CD-ROM drive                          G8BPQ and
220KISS                       HP 48sx running packet?
               Recommend a TNC?                    SUBSCRIBE
k.hand Kolin E. Hand                           V29 9600
modemsSend Replies or notes for publication to:
<[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 11 Nov 91 22:22:50 GMTFrom:
qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]:
Digital Packet Repeater Info WantedTo:
[e-mail]4ZV:> I think this is the basic sticking
point. It's barely possible to > get *one* repeater funded,
sited, and maintained in most areas. To> require numerous cell
sites becomes financially and organizationally>
impossible.WD6EHR:>I think you're missing Phil's point, Gary -
these aren't "sites" ->they're end user stations.  Instead of
having dumb, wasteful digi's,>or netwrong that doesn't work much
better, they're RF-power controlled>"smart" store and forward -
probably at speeds more like T-1 than>1200.  They minimize QRM
by keeping power to what is actually legally>required; the
minimum to communicate.  Thank you, Bert, I had meant to make
exactly this point myself when Ifirst saw Gary's posting, but I
procrastinated until after the systemhad expired his
article...KE4ZV:> And I think you are missing my point, most
users don't leave their> stations turned on 24 hrs a day and
there's no reasonable way to> force them to do so. That leaves
lots of people with *no* connectivity> most of the time. That's
simply unacceptable. Power control is not> a viable option when
you are separated from the nearest active user> by solid
granite.This doesn't follow. First of all, the reason many users
don't leavetheir stations on 24 hours per day is because they
share their voiceradios with their packet stations. If we could
mass produce cheap,dedicated data radios that weren't useful for
FM voice, then moreusers might be willing to leave them on all
the time. Especially ifthere was a good reason to do so, like
contributing their share to thelocal network infrastructure.But
even if you have users going on and off the air, the network
isdesigned to adapt. If A and C had been communicating through
B, and Bgoes off the air, then A and C will attempt to
communicate directlywith higher power (or find another
intermediate relay) before givingup. Only if it is impossible to
find another path will the network bepartitioned.Of course,
depending on the circumstances you may still want toestablish
fixed "utility" nodes.  These would be functionallyidentical to
ordinary user nodes, except that they would be morelikely to be
in good locations (e.g., hilltops) and would be supportedby a
group rather than an individual. But because these nodes
wouldlikely blanket large geographic areas, it is important that
they notbe used simply because they are there if an alternate,
more efficientroute is available. They're there just to
guarantee connectivity whenroutes through intermediate user
nodes are not available.WD6EHR:>As far as halving thruput with
each hop, a system that begins with a >very high speed can
afford to do that.No, throughput will NOT DECREASE with
additional hops! Because powercontrol keeps you from blanketing
the entire network with yourtransmissions, you can "pipeline"
your packets down a chain of simplexrepeaters. Once one of your
packets has propagated out of (relativelyshort) range, you can
launch another before the first one has reachedits destination
without interfering with it. And since the averagetransmit power
will decrease with an increasing density of nodes, theoverall
network capacity automatically INCREASES as you put more nodeson
the channel. Try doing that with either conventional digipeaters
orfull duplex repeaters.Phil------------------------------Date:
11 Nov 91 20:16:18 GMTFrom:
ogicse!usenet.coe.montana.edu!milton!cs.washington![e-mail]
bject: For Sale: Apple CD-ROM driveTo: [e-mail]
              Apple CD-ROM drive     o  One brand new Apple
CD-ROM drive.     o  Connects to Apple II, all Macintosh
computers and        other machines with SCSI interfaces.     o
In unopened package.     o  Under warranty/completly legal with
paperwork.     o  Will ship if necessary.     o  $550 (list is
$799)Call 206-525-6149 (evenings or msg) or E-Mail:
[e-mail]--                Dan
Kerns    [e-mail]                Univ. of Washington, Computer
Science------------------------------Date: 11 Nov 91 12:54:16
GMTFrom:
netnews.upenn.edu!uofs!vulture.cs.uofs.edu![e-mail]
t: G8BPQ and 220KISSTo: [e-mail] anyone used the
KISS EPROM code for the PACCOMM TNC-220 provided byG8BPQ??  I
tried it over the weekend and although it receives OK, it
seemsto be unable to transmit anything.  When data comes from
the PC to the TNCthe LED lights (but not very bright) and the
TNC never keys the radio orsends the data.Anybody have a
suggestion to offer??  Is there anyone with contact with G8BPQ
who could see if he will make his 220KISS Source available??  I
wouldlove to put my old TNC-220 to use, but all I run is
TCPIP.Thanks in advance.bill    KB3YV--      Bill Gunshannon
     |        If this statement wasn't here,
[e-mail]   |  This space would be left
intentionally blank     [e-mail]    |
#include <std.disclaimer.h>
------------------------------Date: 11 Nov 91 22:05:51 GMTFrom:
ogicse!uwm.edu!cs.utexas.edu!bcm!lib!oac.hsc.uth.tmc.edu!jmaynard
@ucsd.eduSubject: HP 48sx running packet?To:
[e-mail] article <[e-mail]>
[e-mail] (Brian Weaver) writes:>I was wondering
if anyone has ever written packet>software the the 48sx? It
would be just about the smallest>portable packet station you
could get, when combined with>a HT.There are a few tterminal
emulators out there for the 48; you can find them inthe archives
at seq.uncwil.edu. There's an associated mail server,
andinstructions on using it are posted regularly to
comp.sys.hp48.Personally, for small packeting, I'd use an
HP95LX, a PacComm HandiPacket, andan IC2SAT or similar. Both the
TNC and the radio come with belt clips, and the95 has a nicer
keyboard and much larger screen (16x64 instead of 7x22). I
maytry packeting with my 48 one of these days, but it'd be
purely an item ofcuriosity.-- Jay Maynard, EMT-P, K5ZC, PP-ASEL
| Never ascribe to malice that which
[e-mail]      | adequately be explained
by stupidity."I'd lend you a clue, but I already did that and it
hasn't come back yet." --                            Peter da
Silva------------------------------Date: 11 Nov 91 14:05:09
GMTFrom:
mcsun!fuug!nntp.hut.fi!vipunen.hut.fi![e-mail]
: Recommend a TNC?To: [e-mail] article
<[e-mail]> [e-mail] (Sean
Clark) writes:>Hello,>>I am new to amateur radio and would like
to get invloved in packet. I have>an Alinco 2m transiever and a
old Z88 portable computer. Can anyone suggest>a suitable,
portable, TNC? What features should I be looking for?Maybe
Baycom would be the right answer? It is a software based TNC.
The Modemolnly is hardware, I ahve been working with it for abt
6 months and am verysatisfied. The software is
PD.>>Thanks,>>Sean Clark,>Loughborough UniversityTimo
OH2LVZ------------------------------Date: 11 Nov 91 23:14:37
GMTFrom: [e-mail]: SUBSCRIBE k.hand
Kolin E. HandTo: [e-mail] k.hand Kolin E.
HandI hope this works.  Followed instruction in FAQ list.Kolin--
+================================================================
===========++  "Guilt Trip:  The nuclear weapon of
relationships."                      ++
       -- K. Hand
++---------------------------------------------------------------
------------++  Kolin E. Hand
[e-mail]        ++  Jet Propulsion Laboratory
            [e-mail]
++===============================================================
============+------------------------------Date: 10 Nov 91
23:48:36 GMTFrom: [e-mail]: V29 9600
modemsTo: [e-mail]1AOT asks for people who are
using the Yamaha YM7109 for 9600 packet.     I currently have a
couple of these modems here along with a few otherpeople in the
Detroit, Michigan area.  We have been very busy working onother
things with packet and every now and then we mess with the
modems.When we finally kick ourselves (or someone else kicks us)
to actually finish these things, then we will be posting the
results in packet-radioand tcp-group. We do have a printed
circuit board made that plugs intothe modem disconnect header of
a TAPR2 type tnc (like the MFJ-1270/1271,Paccomm TNC200, AEA
PK-80, etc...) and Jeff, WB8WKA has a couple of TEKKradios that
will probably be used. I have a few boards here and the
otherones are at other peoples houses.       The modems do work
at 9600 baud and you can just plug it into themicrophone jack on
the radio. An Icom HT with the common slow squelch evenworks
fine at 9600.  Now for those of you that will argue about V29
and thetraining time, READ THE LATEST CHANGES IN THE CHIP!!!
Take everything youknow bad about V29 and throw it away, Yamaha
has changed things in the chipand you can run without training
time.      Let's NOT start any debates about V29, G3RUH, K9NG
and whatever elsemight be out there.  When we have these done
and we pass out the informationfor other people to run it, then
we can discuss it the differences. Pleaseno arguements on
something that you havn't tried or don't have the knowledgefor a
discussion about.  The info WILL be posted for
all.-------------------------------------------------------------
-----------------|      Michigan's  TCP/IP LAN       | AX25 BBS
: N8FOW@WB8H.#SEMI.MI.USA.NA ||          147.56 MHz
 | AMPRnet   : [e-mail]     ||         Ron
Atkinson              | Internet  : [e-mail]
||            N8FOW                  | BITNET    :
au351%po.cwru.edu@cunyvm
|----------------------------------------------------------------
--------------------------------------------Date: 11 Nov 91
14:36:04 GMTFrom:
sun-barr!cs.utexas.edu!samsung!emory!wa4mei!ke4zv![e-mail]
o: [e-mail]
<[e-mail]>,
<[e-mail]>, <.689782399@logic>Reply-To
: [e-mail] (Gary Coffman)Subject : Re: Digital Packet
Repeater Info WantedIn article <.689782399@logic>
[e-mail] (Tadd Torborg)
writes:>>Gary, and all,>  My major thrust in packet involvement
in the past 6 or so years has>been in motivation.  I think that
what you are saying is that the>technology isn't a limiting
factor in making a 'good' network for >your area.  You are
limited by funds and lack of interested hams.>I think that a
large portion of this conversation/thread can be>short circuited
if the problem of lack of motivation is specifically>addressed.
You are certainly correct. There's an old story about a ham and
eggsbreakfast. The chicken was *involved* in producing the
breakfast, butthe pig was *committed*. We have a lot of involved
amateurs, around 500, who get on packet 3 or 4 times a week and
attend meetings and pay dues. Then we have about 30 *committed*
amateurs. These guys operate 24 hourstations, install and
maintain high sites, run forwarding BBSs, andthe like. To last,
a network design must satisfy the communicationsneeds of the
involved, and not burn out the committed. Our networkinggroup
has about $15,000 a year in operating budget. That has to
build,maintain, and pay utilities and rent for the network.
Money hasn'tbeen the limiting factor, lack of worker manhours
has. Looking atmost clubs, I think our experience is typical.
Gary KE4ZV------------------------------Date: 11 Nov 91 20:45:07
GMTFrom: timbuk.cray.com!shamash!duke![e-mail]:
[e-mail] thread, (I, think)asReply-To :
[e-mail] (john r douglas  x6668)Subject : PACTORI have the
QEX articles on PACTOR and wonder if anyone herehas experience
with PACTOR. Is it an expermential mode? Has anyoneseen or used
the PTC described? Are they available in the US?Thanks es
73:John*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--**
John Douglas       * Everything nailed down is   *     * Arden
Hills, MN    * coming loose: Angel Gabriel ** Control Data Corp.
* Marc Connelly: Green Acres  ** . . . . . . . . . . . . . . . .
. . . . . . . . .** Disclaimer: Nothing stated above may be
reprod-  * * in any form other than stone tablets. Copyright  *
* pending . No warrenty is extended or implied.:^) *
*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-------------
-----------------Date: 11 Nov 91 22:53:02 GMTFrom:
qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]:
[e-mail] <1991Nov6.013911.1898@anasaz>,
<[e-mail]>,
<[e-mail]>Reply-To :
[e-mail] : Re: CSMA/CD vs. CSMA/CAIn
article <[e-mail]>, [e-mail]
(Gary Coffman) writes:|> We've already gone for the CSMA/CA
model. It's already a success and|> all the users already have
radios and antennas to use it.Um, could I get you guys to modify
your terminology a bit? As far as Iknow, NO ONE in amateur
packet radio is currently using a CSMA/CA(Carrier Sense Multiple
Access with Collision Avoidance) channelaccess algorithm.  I
have *proposed* two flavors of such a protocol(MACA and implicit
MACA) but neither is in actual use yet (ah, if Ionly had the
time...) CSMA/CA *is* in production use on at least onewired
network, Apple's Localtalk. Localtalk and MACA both use
usespecial RTS/CTS messages to enable data transmissions when
they areleast likely to cause collisions. Implicit MACA works by
monitoringtraffic sent to other users, avoiding the overhead of
special RTS/CTSmessages, albeit with an incrased risk of
collision. None of theseschemes guarantee no collisions, they
just try to reduce theirfrequency, particularly on large data
packets.Contemporary simplex packet radio is just CSMA - there
is *no*"collision avoidance" component above and beyond carrier
sensing. Soplease do not use "CSMA/CA" to refer to it.
Thanks!Phil------------------------------Date: 11 Nov 91
22:07:11 GMTFrom:
qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To :
[e-mail] : Re: Digital Packet Repeater
Info WantedIn article <[e-mail]>,
[e-mail] (Gary Coffman) writes:|> In article
<[e-mail]> [e-mail]
(Phil Karn) writes:|> >|> >I still hear lots of doubles on FM
voice repeaters, especially in N-way|> >random roundtables...|>
|> People aren't as good as machines at implementing an optimum
random backoff|> protocol. [...]Granted. Although my comment was
a little flip, I still thought itmade a valid point, which is
that collisions can still easily occur ina fully connected CSMA
network when several stations are allcontending for the channel
when the active one goes clear. Having usedthe full duplex voice
FM system Brian described recently is veryinstructive; you can
avoid a lot of wasted time in doubles. And youcan hear all the
rude remarks made about you by the other repeaterusers.
:-)Phil------------------------------Date: 11 Nov 91 18:17:00
GMTFrom: hayes![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: CSMA/CD vs.
CSMA/CAOrganization: Hayes Microcomputer Products, Norcross,
GALines: 22In article <[e-mail]>,
[e-mail] (Gary Coffman) writes:> > [ Tons of informative
posting deleted ]>> Our MacIntosh> user left town. We've got to
service them all.> > Gary KE4ZVUh, you have a new Macintosh user
on the block. <grin>   Bill-- Bill Coleman, AA4LR
! CIS: 76067,2327    AppleLink: D1958Principal Software Engineer
       ! Packet Radio: AA4LR @ W4QOHayes Microcomputer Products,
Inc. ! UUCP: uunet!hayes!bcolemanPOB 105203 Atlanta, GA 30348
USA   ! Internet: [e-mail]: "My
employer doesn't pay me to have opinions."Quote: "If you think a
serious business computer must be painfully difficult        to
use, Macintosh isn't it."------------------------------End of
Packet-Radio Digest V91 #292******************************Date:
Wed, 13 Nov 91 04:30:03 PSTFrom: Packet-Radio Mailing List and
Newsgroup </dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #293To: packet-radioPacket-Radio Digest         Wed,
13 Nov 91       Volume 91 : Issue 293Today's Topics:
  Censorship of packet bulletins (3 msgs)
 CSMA/CD vs. CSMA/CA                       digest getting larger
?                     For Sale: Apple CD-ROM drive
      Packet-Radio Digest V91 #291
subscription requestSend Replies or notes for publication to:
<[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 12 Nov 91 15:42:42 GMTFrom:
sun-barr!cronkite.Central.Sun.COM!newstop!eastapps!hienergy!jimv@
ames.arpaSubject: Censorship of packet bulletinsTo:
[e-mail] was wondering if other parts of the
country are having the same problemswith sysops censoring packet
bulletins as we are in the east. It seemssysops out here think
nothing of "xxx"ing out whatever they deem as"inappropriate"
material. This usually consists of prices on forsale itemsand
home bbs info (apparently they figure if you reply to a forsale
bulletinto ask questions, your doing business over packet
radio). I contend thata sysop has NO right to censor another
hams message. If they feel it wouldbe illegal to pass it on,
they have EVERY right to kill it and inform thesender of the
fact (and the reason why), but NO right to edit it. I'd liketo
know what others think, do you care if your messages are
edited?Jim Vienneau, Sun Microsystems Inc - Billerica, MAEmail:
[e-mail]   Amateur Radio: WB1BGood old Ma Bell
(well old anyway):
[phone]------------------------------Date: 12 Nov 91
16:32:50 GMTFrom:
charon.amdahl.com!amdahl![e-mail]: Censorship of
packet bulletinsTo: [e-mail] article
<[e-mail]> [e-mail] ( J

im Vienneau  - Sun Microsystems) writes:>I was wondering if
other parts of the country are having the same problems>with
sysops censoring packet bulletins as we are in the east. It
seems>sysops out here think nothing of "xxx"ing out whatever
they deem as>"inappropriate" material. This usually consists of
prices on forsale items>and home bbs info (apparently they
figure if you reply to a forsale bulletin>to ask questions, your
doing business over packet radio). I contend that>a sysop has NO
right to censor another hams message.On the contrary. The FCC
has made it painfully clear that sysops areto be held
responsible for what passes over their BBS systems. If youdon't
like that, your dispute is with the FCC, not with the sysop.
Eachsysop is the one to decide how he or she is going to comply
with the law.Each sysop is the one to decide how close to the
great undefined "edge"he or she will operate.And, on the
contrary. I believe that sysops think far more than "nothing"of
chopping up messages. But, they believe that it's what they must
doin order to avoid losing their privileges. I don't know of too
manysysops who enjoy reviewing every single message that passes
throughtheir system.>
        If they feel it would>be illegal to pass it on, they
have EVERY right to kill it and inform the>sender of the fact
(and the reason why), but NO right to edit it.There is a great
gulf between "editing" and replacing information withstrings of
"X." If it is clear that the information was deleted, and
whodeleted it, then there is no issue (except that you may
disagree with itsremoval).I suspect that most of these
activities don't alter the meaning of theoriginal bulletin
substantially. It's the sysop's call as to whetherthey can
remove the offending material without destroying the meaningof
the message. If they can, perhaps it's better that they do that,
sothat at least some of the information can be passed.>
                                                       I'd
like>to know what others think, do you care if your messages are
edited?This sort of rhetoric is really counter-productive. Of
course people"care" if their messages are edited. That doesn't
mean that they haveto react to it as if the paycheck had been
altered.You are free to attach to your message "To SYSOPS: if
you believe thatthis message cannot be forwarded in its
entirety, please do not forward itat all, and notify the
originator." I'd absolutely expect any sysopto comply with that
request. Probably the sysops who delete informationare doing so
under the assumption that 90% of the message is better
thannone.However, I suspect that if we have a bunch of folks
whining about"censorship" on one side, and the FCC on the other,
a number ofsysops are going to decide that the stress isn't
worth it, and simplyshut down their systems. Then what are you
going to do? I suggestthat you consider carefully the
consequences before using loadedterms like
"censorship."Greg------------------------------Date: 12 Nov 91
19:10:30 GMTFrom:
sun-barr!cronkite.Central.Sun.COM!newstop!eastapps!hienergy!jimv@
ames.arpaSubject: Censorship of packet bulletinsTo:
[e-mail]>>In article <[e-mail]>
[e-mail] (Jim Vienneau  - >>Sun Microsystems)
writes:>>I was wondering if other parts of the country are
having the same problems>>with sysops censoring packet bulletins
as we are in the east. It seems>>sysops out here think nothing
of "xxx"ing out whatever they deem as>>"inappropriate" material.
This usually consists of prices on forsale items>>and home bbs
info (apparently they figure if you reply to a forsale
bulletin>>to ask questions, your doing business over packet
radio). I contend that>>a sysop has NO right to censor another
hams [e-mail] (Greg Bullough) writes:>On the
contrary. The FCC has made it painfully clear that sysops are>to
be held responsible for what passes over their BBS systems. If
youI didn't say the sysops had to let illegal traffic pass, just
that theyhad no right to edit the traffic. They can certainly
kill anything that'struely illegal.>And, on the contrary. I
believe that sysops think far more than "nothing">of chopping up
messages. But, they believe that it's what they must do>in order
to avoid losing their privileges. I don't know of too
many>sysops who enjoy reviewing every single message that passes
through>their system.Do you REALLY read very single message that
passes through your system?>
               If they feel it would>>be illegal to pass it on,
they have EVERY right to kill it and inform the>>sender of the
fact (and the reason why), but NO right to edit it.>There is a
great gulf between "editing" and replacing information
with>strings of "X." If it is clear that the information was
deleted, and who>deleted it, then there is no issue (except that
you may disagree with its>removal).I'm sorry, but I do not see
this as a "great gulf". If I send a message I expect it to get
to the other end in the same form as it left in unless I'm told
otherwise (much like this message). It's also not clear to ME
who deleted it. To me it's no different than receiving a letter
with a bunch of holes cut in it where the post office decided
that those parts were not acceptable to send through the postal
service. They have no right to make that distinction,and neither
do you.>I suspect that most of these activities don't alter the
meaning of the>original bulletin substantially. It's the sysop's
call as to whether>they can remove the offending material
without destroying the meaning>of the message. If they can,
perhaps it's better that they do that, so>that at least some of
the information can be passed.I'm sorry, but it's not the sysops
call whether removing text changes thethe meaning of another
ham's message.>>
                I'd like>>to know what others think, do you care
if your messages are edited?>This sort of rhetoric is really
counter-productive. Of course people>"care" if their messages
are edited. That doesn't mean that they have>to react to it as
if the paycheck had been altered.>You are free to attach to your
message "To SYSOPS: if you believe that>this message cannot be
forwarded in its entirety, please do not forward it>at all, andI
should not have to attach this to every bulletin I send to keep
sysopsfrom hacking my messages.>However, I suspect that if we
have a bunch of folks whining about>"censorship" on one side,
and the FCC on the other, a number of>sysops are going to decide
that the stress isn't worth it, and simply>shut down their
systems. Then what are you going to do? I suggest>that you
consider carefully the consequences before using loaded>terms
like "censorship."If you want to pull the plug rather than work
with the amateur community todo the "right" thing, then I
suspect we'll all be better off. After all, it'sno magic trick
to put a packet BBS on the air. I'm not asking for sysops to do
anything they believe is illegal, only thatthey not edit user's
messages without their knowledge. I took a packet pollof about
10 sysops here on the east coast last week. They were all
niceenough to respond, most in detail. Of the 10, only one
stated that heedited messages. The other 9 all said that it was
not their place or intent(nor did they have the time to read
them all anyway) to edit messages. Isuspect the FCC will need to
make some adjustments in their policies asour fledgling network
grows. In the meantime, let's do what makes sense.-jim>GregJim
Vienneau, Sun Microsystems Inc - Billerica, MAEmail:
[e-mail]   Amateur Radio: WB1BGood old Ma Bell
(well old anyway):
[phone]------------------------------Date: 12 Nov 91
16:01:34 GMTFrom: [e-mail]: CSMA/CD vs.
CSMA/CATo: [e-mail]'ve been following this
discussion with great interest.  Since I just readhis paper on
CSMA/CD in the 10th CNC proceedings that came last week, I
washoping K3MC would jump in.  Mike sez:>I find this discussion
fascinating.  For our call on the issue, please see>the 10th
ARRL Computer Networking Conference Proceedings (1991, San
Jose,CA)>for our article "A Full-Duplex 56kb/s CSMA/CD Packet
Radio Repeater System",>by me(Mike k3mc) and Lars Karlsson,
AA6IW.>>Basically, collision detection is done by comparing the
bytes being received>with the bytes being transmitted, taking
into account repeater delays.  And
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^Some details on how this
will be done would be appreciated!>the repeater runs the same
code as the user station.  The figure showing the repeater
configuration has the received data gateddirectly to the
transmit data line.  I presume this is an oversimplificationto
keep the diagram simple - or have you really found a way to do
thiswithout a FIFO buffer?  I'm just about to lash up another
FIFO circuit forour next 56kb/s repeater (actually, >56k is
planned), and if it ain'tnecessary, I want to know! :-)>The user
station consists of a Hamtronics XV-4 transverter (29 MHz to 433
MHz)>and an SHF electronics 900 MHz transverter, with just the
receiver part>populated.  The digital controller is a Kantronics
Data Engine.>>We've got the h/w together, and expect to get the
s/w running during the>Christmas vacation.Barry
VE3JF------------------------------Date: 12 Nov 91 13:39:27
GMTFrom: [e-mail]: digest getting
larger ?To: [e-mail] see that this digest is
getting larger each issue..... Why ?why do we have to quote the
entire mail sent by another person and addour own comments...
and then yet another person to requote the allreadyquoted
message for the 2nd or 3rd time... and so it goes on. We have
archivesof past digests... We can refer to a past subject cant
we ?? This is seeas the continued re-quoteing of past
mail/messages as a Wast of Bandwidth!!the last 3 or so
packet-radio-digests have been larger than 45 kb some havebeen
larger than 56-61kb long!! this practice has only seemed to
haveappeared in the last 2-3 months   so please think of gateway
operatorslike me... that have to split the last N'th digests
into 5 or 6 partsbefore re mailing out on a slower ax25 radio
network.... So can you pleasethink before you include the quote
of an entire packet-radio-digest,Just to say YES I AGREE to some
single one line topic !!Thanks you  DC0HK.ampr.org
[e-mail]
[digest.mail.gate]------------------------------Date: 12 Nov 91
02:23:42 GMTFrom:
pacbell.com!att!linac!mp.cs.niu.edu!ux1.cso.uiuc.edu!roma!wmagro@
ucsd.eduSubject: For Sale: Apple CD-ROM driveTo:
[e-mail] article
<[e-mail]>,
[e-mail] (Daniel Kerns) writes:|> |>
    Apple CD-ROM drive|> |>      o  $550 (list is $799)Does
everyone know that atari is selling the chinon SCSI CD-ROM unit
for $385 LIST?!  Identical functionality to the Apple
drive.------------------------------Date: 12 Nov 91 04:57:45
GMTFrom: [e-mail]: Packet-Radio Digest
V91 #291To: [e-mail] anyone have any comments
on the Kantronics DVR 2-2 ?Is it good, bad, whatever?
               Lee------------------------------Date: 12 Nov 91
17:18:22 GMTFrom: [e-mail]:
subscription requestTo: [e-mail]
packet-radio Andre' ThomasHELPAndre' ThomasComputer &
Information ServicesUniversity of Minnesota   (612) 625 -
1300------------------------------Date: 12 Nov 91 07:15:59
GMTFrom: atha!aunro!ve6mgs![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: CSMA/CD
vs. CSMA/CAI shoot my mouth off again and say:>I based my
statement on the fact that KISS56 runs on a 5MHz Z80, I am
sure>a CSMA/CD system can run on a up to 16MHz Z80 (available
and cheap, the Z80HFrom: [e-mail] (Jack
Brindle)>With extremely expensive support and memory chips...I
figure we do not need to go as far as 16MHz on a Z80, I am just
indicatingthat a TNC can be made responsible for 9600-19.2Kbps
packet. However, thereis not a computer alive (to exagerate the
point) that could take KISS on theserial ports at that rate. My
point was to use an appropriately souped up TNC(regardless of
CSMA/CA or CSMA/CD or whatever) to handle the vulgarities
ofCSMA/CD on the high speed systems. I also stated that
something be set up inthe KISS protocol similar to the Budlist
to keep the PC to TNC traffic downso that a cheapy XT could even
be used to handle high speed packet (ie, readonly packets that
are destined for me or are broadcasts for everyone to see,these
packets would be filtered at the destroyable header level).>in
this case in particular, where is the high speed digital that
can provide>synchronization between sent and received bits, with
delays, in real time?I was out of line about a 16MHz Z80, but my
guess is that a slower Z80 can doit. I won't put my money where
my mouth is 'cause I havn't got any money.Your point about using
a newer processor (68302) is great, but if I want aquick
implementation on a readily available (and cheap) TNC ...Here I
go, opening my trap without putting bwain in gear:>>the bent
pipe repeater has NO delay. There is a TX delay that is in the>
                      ^^^^^^^^^^^^>Not even for keyup? Do you
leave the TX on all the time, or simply trashI should stop using
NO delay, 0 delay and other attrocities, and replace itwith
neglegible ...>Or, do you send the "destroyable" header at the
beginning of each packet>on the channel, thus lowering the
effective throughput of the channel?I `figure' the destroyable
header would be 10ms long ... negligible (:-O)with respect to
the packet sizes I expect at higher (>9600) speeds.The problem
with CSMA/CA, with the current state of the technology,is I
expect it to crumble when the load gets high on the channel.
Morethan two stations are BOUND to key up at the same time right
after thechannel clears. CSMA/CD was the solution on the hard
wired networks toget rid of the problems of scale when CSMA/CA
stopped working on a busynetwork. Sure, some improvements have
been made in /CA protocols, but keepingwith it, when we can
implement /CD is like my arguments to keep using TNC-2susing
Z-80s at 56KBaud and beyond ...A self-centered egotistical quip
from me:>>Next ...>Actually, it sounds like it's time for you to
build the hardware and write>the paper to prove your point.Yup,
it does, I do not have any research and development funds right
now. Thecentral planning commitee (my wife) has vetoed every
request for suitablefunding.  My noise was to prompt someone
else to build it before I did. Asfar as writing the papers, it
has been done already and we have been passedby ...        < Pep Talk
>The demand for simplex data radios is there, thus the
manufacturers makethem. The equivalently priced data radios with
separate receive and transmitbands used for implementing Full
Duplex and CSMA/CD has no demand, and thusnegligable
availability. Please request these dual band radios from ANY
sourcethat could possibly make them and maybe we can get on to
doing bigger andbetter things. It wouldn't be to hard for them
to come out with the productsince all they need do is slice up
the TX and RX sections on to separateboards and mix and match as
the orders require.I am sure that many have put this subject in
the kill list now ...Ciao, 73 de VE6MGS/Mark
-sk-------------------------------End of Packet-Radio Digest V91
#293******************************Date: Thu, 14 Nov 91 04:30:04
PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #294To: packet-radioPacket-Radio Digest         Thu,
14 Nov 91       Volume 91 : Issue 294Today's Topics:
       Censorship of packet bulletins
CSMA/CD vs. CSMA/CA                         repeaters, kiss, axh
                             Rose on PC
Sorry for the mixupSend Replies or notes for publication to:
<[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 13 Nov 91 16:42:13 GMTFrom:
[e-mail]: Censorship of packet
bulletinsTo: [e-mail] Vienneau:
[e-mail] writes:>I was wondering if other parts of
the country are having the same problems>with sysops censoring
packet bulletins as we are in the east. It seems>sysops out here
think nothing of "xxx"ing out whatever they deem
as>"inappropriate" material. This usually consists of prices on
forsale items>and home bbs info (apparently they figure if you
reply to a forsale bulletin>to ask questions, your doing
business over packet radio). I contend that>a sysop has NO right
to censor another hams message. If they feel it would>be illegal
to pass it on, they have EVERY right to kill it and inform
the>sender of the fact (and the reason why), but NO right to
edit it. I'd like>to know what others think, do you care if your
messages are edited?Personally I think that:1. He who owns the
hardware... owns the hardware and all that implies.2. That
probably too many sysops are overreacting to another
overreaction   that the FCC Field Office in Norfolk made
concerning "business messages".   a. That an overreaction from
the sysops is understandable due to the      FCC's lack of clear
guidelines and nebulous and inconsistent      enforcement
policies concerning a LOT of the regulations.3. That there is
not a heck of a lot a ham can do in North Carolina   concerning
the activities of a sysop in Washington State.   a.  Thus, local
problems have to be solved locally (if they can be at
all), and there is not too much others can do about it, other
than       make the sysop aware of their opinions.In reply to
[e-mail] (Greg Bullough) Jim writes:>I didn't say the
sysops had to let illegal traffic pass, just that they>had no
right to edit the traffic. They can certainly kill anything
that's>truely illegal.There will always be a difference in
opinion between two people in whatis termed "illegal".   If the
whole message was to be deleted and a responsesent to the sender
as to why... there would be a hate mail battle startedin a large
percentage of cases as it is obvious that he who sent it feltit
was legal to begin with, and as such... he is going to be upset
that itwas killed.   Thus sending a message back to the
originator will START morebattles (IMHO) than "X"ing out parts
of it and letting the rest go.Possibly a better way to address
this Jim, would be to get the FCC to comeout and say that only
the originator will be held responsible for a messageon packet
and not the BBS's.  If they came out with that statement, I
wouldagree with your points 100%, but since just the opposite is
what happened,my support is with the people who have already
been slammed once for tryingto be an active part in packet
development.Greg writes:>You are free to attach to your message
"To SYSOPS: if you believe that>this message cannot be forwarded
in its entirety, please do not forward it>at all, andJim
replies:>I should not have to attach this to every bulletin I
send to keep sysops>from hacking my messages.Maybe not.  But BBS
ops should not really have to worry about being slammedfor
passing on a message either (again IMHO), but they have been,
thus theyreacted.  So now we have a situation.  Granted it's sad
that it has come tothis point... but the only thing you can do
about it is have personaldiscussions with the people that you
know to be doing it, but the bottom lineis that it's their
call.Greg writes:>However, I suspect that if we have a bunch of
folks whining about>"censorship" on one side, and the FCC on the
other, a number of>sysops are going to decide that the stress
isn't worth it, and simply>shut down their systems. Then what
are you going to do? I suggest>that you consider carefully the
consequences before using loaded>terms like "censorship."Jim
replies:>If you want to pull the plug rather than work with the
amateur community to>do the "right" thing, then I suspect we'll
all be better off.>After all, it's no magic trick to put a
packet BBS on the
air.^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^No... and it's no "magic trick" to put up 56 kbs backbones, or
T-1 links forthat matter... in fact not too much in Amateur
Radio is a "magic trick".However it does take money, dedication,
time, effort, and a certain attitudethe combination of which is
a pretty rare quality.  I also note yourstatement about "working
with the amateur community to do the right thing".I must point
out that while I personally respect your views (and really
dounderstand them) you do not represent "the amateur community"
nor do youropinions necessarily represent "the right thing".So
while I support the fact that all Amateurs should work towards
thecommon good by doing the "right thing", I think it is
premature to makethe innuendo that these sysops are not.>I'm not
asking for sysops to do anything they believe is illegal, only
that>they not edit user's messages without their knowledge. I
took a packet poll>of about 10 sysops here on the east coast
last week. They were all nice>enough to respond, most in detail.
Of the 10, only one stated that he>edited messages. The other 9
all said that it was not their place or intent>(nor did they
have the time to read them all anyway) to edit messages.
I>suspect the FCC will need to make some adjustments in their
policies as>our fledgling network grows. In the meantime, let's
do what makes sense.If only one of out of 10 is editing the
messages, then it's probably nottoo severe of a problem (if your
poll is representative of the communitythat you were trying to
poll).  There is no doubt that the FCC needs tomake some
adjustments in their policies!  In fact.. I personally
believethat this should be our major thrust and not railing on
sysops for reactingthe way some of them did to a really stupid
FCC interpretation and resultantaction.Those that are editing
messages will in time relent from their activitiesif the FCC
relents from the type of activity that led to it.  Attacking
thesysop is counter-productive, especially if done publicly.  It
has to be alocal action, and if you can't come to terms, then it
has to be a local GROUPaction that agrees to not support his
BBS.  Anything else will just lead toa flame battle with common
sense going out the window in favor of hate andretribution.Mark
[e-mail]------------------------------D
ate: 13 Nov 91 16:49:40 GMTFrom:
pacbell.com!tandem![e-mail]: CSMA/CD vs. CSMA/CATo:
[e-mail], indeed a FIFO is needed.  The
diagram was simplified to emphasizewhat we are doing; we intend
to borrow heavily on the work you guys have done!The
byte-by-byte comparison works like this:  You start sending your
bytes,and keep them in memory.  You then keep comparing the byte
you receive tothe first byte you transmit.  If no match, you
wait till you get the nextbyte, etc. (note in the repeater's
case, you get your echo almost immediately).After you've waited
the FIFO length + prop delays + scrambler delays, and youhaven't
begun to sync to the received bytestream, then a collision must
behappening, so you abort transmitting.Incidentally, Barry, you
seem to be using a pretty deep FIFO; is there anyparticular
reason this can't be just a 2-byte or 3-byte FIFO?The advantage,
besides detecting collisions, is that we expect to send
BIGpackets without adversely affecting total channel throughput,
because we knowthat the receiving station hears us, and we won't
have to retransmit.  Thelargest packet size can be dynamically
determined by making the lengthinversely proportional to the
number of stations using the repeater.Best
-Mike------------------------------Date: 13 Nov 91 17:05:00
GMTFrom: [e-mail]: repeaters, kiss,
axhTo: [e-mail] repeater fans,  HELP !There has
already been considerable discussion on the merits(perceived or
otherwise) of using full duplex 'voice style'repeaters for
packet. In general, it seems fairly clear from anintuitive
sense, that the repeater concept reduces the 'late
hit'collisions that result from hidden transmitters, thereby
negatingthe need for critically organized local networks or
cell-groupsystems. Collisions can and do still occur, however
'window ofsusceptibility' is reduced from infinite to a few
hundred ms outof each 3 to 7 secs transmission. (at least at
1200 baud, withmoderate frame limits). If you've ever worked a
mountain topdigi/netnode/simplex switch, common sense will tell
you, whilethis may not be the most efficient to increase
thru-put, there isat least some measure of improvement.That
being said. Here in Connecticut I operate a repeater on146.415 /
147.415, intended primarily for packet. The machine isan older
G.E. master-pro, using a wired 'ored' combination of therepeater
receiver squelch output and the DCD output from a TNC1to key the
transmitter. (Actually the dcd contribution is totallyredundant
in this setup and as near as i can tell is not reallynecessary.)
The hang-time for the machine is set for about 8 secsto
accommodate 'reasonable' (empirically derived value, subjectto
opinion and/or religious beliefs) ack or next-frame times at1200
baud. The machine passes regenerated 1200 tones, with noability
to stop or do any 'real time' evaluate any incomingframes.The
choice of the noise/squelch-detect transmitter control wasbased
on minimizing the repeater key-up delay time, and the factthat i
have yet to see a data carrier detection scheme that is
asfool-proof. In addition, higher baud rates are
eventuallyanticipated making the squelch circuit the reliable
commontrigger for multi-baud operation.Most of the activity on
this machine centers around Karn's tcp/ipapplication, and the
machine is cross-band linked (via NOS) toseveral other machines
in the area.Here is my problem: Most users of 'voice style'
repeaters for packet, have no doubtbeen using the "ol' reliable"
TAPR command set parameters forTXD, AXD, and AXHANG to
minimumize unnecessarily long TXDsettings. Has anyone
implemented the use of these parameters forKISS mode??  While
some may argue that sacrificing one packet atthe beginning of
each transaction is not substantial, (altho at1200 baud it seems
pretty significant!!) missing one frame maycause nos/net
application to drop to the first level of backoffand if for some
reason a long irtt value has been stored, theconnection may
*never* ('never' on an interactive level appearsto be about 90
secs in my area) be established.I realize complicating the KISS
implementation may well be theproverbial 'can-o-worms', but this
seems fairly consistent withthe KISS tnc philosophy.Comments? or
solutions?Brian Ellswort ( [e-mail]
)------------------------------Date: 13 Nov 91 03:45:04 GMTFrom:
usc!hela.iti.org!ox.com!caen!spool.mu.edu!munnari.oz.au!manuel!cs
c.canberra.edu.au!echo![e-mail]: Rose on PCTo:
[e-mail] <[e-mail]>
[e-mail] (Antonio Querubin) writes:>>The french
packet association (ATEPRA) and F6FBB have implemented ROSE>>on
PC based on the sources released by W2VY. This version is
fully>Does the new version remove the two-hop digipeater
limitation that was part of>earlier versions?  That limitation
prevents a ROSE network from being useable>with other
networks.Does it also carry the PID unmodified?Carl.--
-----------------------------------------------------------------
--------Carl Makin  VK1KCM  Canberra Australia  | <Disclaimer> I
know NOTHING!Internet:      [e-mail] |Packet
Radio:  [e-mail] | "There is no substitute
forFidonet:       3:620/243.14             |  incomprehensible
good luck!"Telecom:    (+61 6) W289-8443 H296-2423
|----------------------------------------------------------------
---------------------------------------Date: 12 Nov 91 20:58:41
GMTFrom:
elroy.jpl.nasa.gov!jato!burns!spc9![e-mail]: Sorry
for the mixupTo: [e-mail] all,Sorry for that
weird message about subscription.  Had the newsgroup CC'ed whenI
sent the subscription request to UCSD's
list-server.Apologies.Kolin------------------------------Date:
13 Nov 91 18:50:59 GMTFrom: [e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Censorship of packet
bulletinsIf you post a message to a ham packet radio BBS and a
subsequentforwarding BBS operator alters that message without
your permissionand redistributes it, he has quite possibly
violated your inherentcopyright on that message.  Sue him.I
believe that a sysop has the right not to forward a message, but
hasNO right to alter its contents.Are that that desperate for
BBSs that we'll put up with this kind ofnonsense?        -
Brian------------------------------Date: 13 Nov 91 00:40:07
GMTFrom:
elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!asuvax!ukma!aunro!aupair
.cs.athabascau.ca![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>donSubject : Re: Censorship of
packet bulletinsI just LOVE it when American hams get up and
start screaming aboutRights, Censorship, Communism, Me, Mee,
Meeeee!!!  It's the samewarm fuzzy feeling I get listening to 20
metres.I am now going to exercise MY right to put this thread in
my killfile, and I sincerely hope the rest of you do, too,
before thisgroup once again starts to resemble a large mass of
muck in searchof a rake.--
atha!cs.athabascau.ca!lyndon || [e-mail]
          Packet: [e-mail]        As a math
atheist, I should be excused from this.
--Calvin------------------------------Date: 12 Nov 91 20:28:56
GMTFrom: charon.amdahl.com!amdahl![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To :
[e-mail] (Greg Bullough)Subject : Re:
Censorship of packet bulletinsIn article
<[e-mail]> [e-mail] (Jim Vienneau  -
Sun Microsystems) writes:>>Do you REALLY read very single
message that passes through your system?Some sysops apparently
do. I know the sysop on my home system releasesNOTHING until one
of the control operators read it. He says that rightup
front.>>There is a great gulf between "editing" and replacing
information with>>strings of "X." If it is clear that the
information was deleted, and who>>deleted it, then there is no
issue (except that you may disagree with its>>removal).>>I'm
sorry, but I do not see this as a "great gulf". If I send a
message I >expect it to get to the other end in the same form as
it left in unless I'm>told  otherwise (much like this message).
It's also not clear to ME who deleted >it. To me it's no
different than receiving a letter with a bunch of holes cut >in
it where the post office decided that those parts were not
acceptable to >send through the postal service. They have no
right to make that distinction,>and neither do you.On the
contrary. They have both a right and obligation, under the
FCC'scurrent interpretation of the law, to do so. USENET is not
comparableto packet networks: it isn't carried over the amateur
radio service (forprecisely the reason which you raise). Again:
if you can't live with thelimitations of the Amateur Radio
Service, and with the sysops doingwhat is necessary to protect
their operator privileges, then eitherdon't use the service or
don't use the particular BBSs.>>I suspect that most of these
activities don't alter the meaning of the>>original bulletin
substantially. It's the sysop's call as to whether>>they can
remove the offending material without destroying the meaning>>of
the message. If they can, perhaps it's better that they do that,
so>>that at least some of the information can be passed.>>I'm
sorry, but it's not the sysops call whether removing text
changes the>the meaning of another ham's message.If you are
unwilling to allow a sysop to make that judgement, then
youshould so state in your message. Considering the things being
removedare fairly well-defined (as opposed to nuances of meaning
in metaphysicaldiscussions), it isn't that difficult.>I should
not have to attach this to every bulletin I send to keep
sysops>from hacking my messages.Let me see: you're willing to
whine about how you're being "censored"but you're not willing to
ask that you not be? You have every abilityto state your
preference, but it appears that you'd rather that thewhole world
adjust itself, instead of your asking for what you wantas an
individual.>>However, I suspect that if we have a bunch of folks
whining about>>"censorship" on one side, and the FCC on the
other, a number of>>sysops are going to decide that the stress
isn't worth it, and simply>>shut down their systems. Then what
are you going to do? I suggest>>that you consider carefully the
consequences before using loaded>>terms like "censorship.">>If
you want to pull the plug rather than work with the amateur
community to>do the "right" thing, then I suspect we'll all be
better off. After all, it's>no magic trick to put a packet BBS
on the air. Sigh. That's the problem with trying to provide a
service. Even if it'sfree, there's always some self-righteous
sort who'll stand up and complainabout what they get, while on
the other hand being quite willing to takeeverything you have to
give. Get it straight: sysops can do as they will.It's THEIR
system. You are a user. You can't tell them what to do. Youcan
ask. Your alternative is not to use their system. That's
prettysimple, isn't it?>I'm not asking for sysops to do anything
they believe is illegal, only that>they not edit user's messages
without their knowledge. I took a packet poll>of about 10 sysops
here on the east coast last week. They were all nice>enough to
respond, most in detail. Of the 10, only one stated that
he>edited messages. The other 9 all said that it was not their
place or intent>(nor did they have the time to read them all
anyway) to edit messages. I>suspect the FCC will need to make
some adjustments in their policies as>our fledgling network
grows. In the meantime, let's do what makes sense.I think it
would be more correct to say "let's do what makes sense to
ME,even though it's not MY license on the line, or MY service
that's caughtbetween a rock and a hard place." Yes, the FCC
needs to make someadjustments. However, getting into some sort
of philosphical quasi-civil-liberties debate with BBS sysops
isn't going to make that happen anyquicker.So, 1 in 10 chooses
the editing route. Doesn't sound like a verypervasive so-called
"problem." On the other hand, since the freedom ofthe press
belongs to him what owns one, I'm willing to grant that onesysop
the autonomy to make his own choices. Obviously, those
choiceswill affect what users sign on and what other BBSs choose
to get"feeds" from him.  But as long as it's his callsign and
his equipment,it's his
choice.Greg------------------------------End of Packet-Radio
Digest V91 #294******************************Date: Fri, 15 Nov
91 04:30:04 PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #295To: packet-radioPacket-Radio Digest         Fri,
15 Nov 91       Volume 91 : Issue 295Today's Topics:
       Digital fullduplex repeaters.
   ELM30                         G8BPQ Node Software
               GRAPES 56k ??              Hardware flow control
and Kantronics TNC's                  What ever happened to DRSI
Inc???Send Replies or notes for publication to:
<[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 13 Nov 91 10:14:35 GMTFrom:
[e-mail]: Digital fullduplex
repeaters.To: [e-mail] do us hams persistently
refer to contacts as 'simplex' as opposed to'half duplex'?  We
are *WRONG* to do this.The internationally accepted definitions
(as used by IEEE, CCITT, ISO etc)are quite definite. A 'Simplex'
circuit works in one direction only!You are engaged in a Simplex
contact when listening to WWV.When you are working through a
normal voice repeater or a normal digipeateror working someone
on SSB voice, then you are having a 'half duplex' contactbecause
it only makes sense if one end transmits at once.You need some
protocol to manage the link to stop both parties deciding tokey
up at the same time.Full-duplex implies that both ends can
transmit concurrently with no mutualinterference or interaction,
like a telephone.What is being described as a 'full duplex
digital repeater' is beingmis-described. What it really is, is a
half-duplex repeater with collisionmanagement to make it work.
Pete Lucas   [e-mail]    PJML%IA.NWL.AC.UK@UKACRL
G6WBJ.ampr.org------------------------------Date: 15 Nov 91
07:31:25 GMTFrom: [e-mail]: ELM30To:
[e-mail] have trouble with the PCELM3.0 getting up
and running.In fact I have got it up but not running.All is does
is a short flicker on the display if a key is entered.Does
anyone have seen this ?   What is the
cure?Wim------------------------------Date: 13 Nov 91 16:01:32
GMTFrom: mcsun!uknet!glasgow!bru-cc![e-mail]:
G8BPQ Node SoftwareTo: [e-mail]'ve being looking
round ftp sites, particularly in the US, for packetsoftware and
have noticed that most of the versions of G8BPQ's nodesoftware
are very old (at least 8 months or more).The current version of
John's software is v4.04. Does anyone know of anyftp sites which
have the current version? If not, I can supply it (in ZIPformat)
to anyone who's interested in a copy.73 Nick,
G7ENS************************************************************
********************     Nick  Swift          *  JANET        :
cs90nrs @ cs.brunel.ac.uk        **                          *
Packet Radio : g7ens @ gb7ens.#38.gbr.eu
*****************************************************************
****************      "To err is human--and to blame it on a
computer is even more so."      **      --Orben's Current Comedy

*****************************************************************
***************------------------------------Date: 5 Nov 91
23:47:50 GMTFrom: [e-mail]: GRAPES 56k
??To: [e-mail] can i come in contact with GRAPES
or any member of them ?I am also interesting also to here
opinions of active 56k modem users.Please replay directly to me
as i am not subscribed to this list now.George SV1BDS Athens
[e-mail][e-mail]-------
-----------------------Date: 13 Nov 91 22:35:12 GMTFrom:
swrinde!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!moe.ks
u.ksu.edu!ux1.cso.uiuc.edu![e-mail]: Hardware
flow control and Kantronics TNC'sTo: [e-mail], I
am trying to run the OS/2 version of NOS and it requires
hardware flowcontrol. I've had my tnc's (a KAM nad a KPC-2) set
up for hw flow for quitesome time and have been running them
that way with the DOS version for abouta year and a half with no
problems. BUt the OS/2 version doesn't work. I gotout my
break-out box to see what for. I found that the tnc's (neither
one)actually pull CTS high in response to RTS from the computer.
I guess DOSdoesn't care so that version just chugs right along.
I've checked and double-checked every flow contro parameter but
still no luck. The manual says the tncwill use RTS/CTS, but that
doesn't seem to be the case. Has anyone else experienced this?
IS there a fix? I'd hate to have to junk 2 perfectly goodtnc's
because of this. Any help would be appreciated. Thanks, Jay--
*****************************************************************
********* 73 de Jay, WT9S     Internet: [e-mail]
               **                     Packet:
[e-mail]
*****************************************************************
*********------------------------------Date: 14 Nov 91 00:23:52
GMTFrom:
sdd.hp.com!elroy.jpl.nasa.gov!kilroy![e-mail]
: What ever happened to DRSI Inc???To: [e-mail]
day, All -It seems that DRSI (Digital Radio SYstems Inc) of
Florida is outof business.  Is this true?  Is there anyone who
builds a dual-channelradio modem card for the PC anymore?  I
would like one of the two channelsto be an HF modem.  Or must I
go back to serial ports and external modems?- jon
NW6H------------------------------Date: 13 Nov 91 14:57:18
GMTFrom:
elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.colu
mbia.edu!emory!wa4mei!n4rsy!ke4zv![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>ohio-Reply-To :
[e-mail] (Gary Coffman)Subject : Re: Digital Packet
Repeater Info WantedIn article
<[e-mail]> [e-mail]
writes:>KE4ZV:>> I think this is the basic sticking point. It's
barely possible to >> get *one* repeater funded, sited, and
maintained in most areas. To>> require numerous cell sites
becomes financially and organizationally>>
impossible.>>WD6EHR:>>I think you're missing Phil's point, Gary
- these aren't "sites" ->>they're end user stations.  Instead of
having dumb, wasteful digi's,>>or netwrong that doesn't work
much better, they're RF-power controlled>>"smart" store and
forward - probably at speeds more like T-1 than>>1200.  They
minimize QRM by keeping power to what is actually
legally>>required; the minimum to communicate.  >>Thank you,
Bert, I had meant to make exactly this point myself when I>first
saw Gary's posting, but I procrastinated until after the
system>had expired his article...>>KE4ZV:>> And I think you are
missing my point, most users don't leave their>> stations turned
on 24 hrs a day and there's no reasonable way to>> force them to
do so. That leaves lots of people with *no* connectivity>> most
of the time. That's simply unacceptable. Power control is not>>
a viable option when you are separated from the nearest active
user>> by solid granite.>>This doesn't follow. First of all, the
reason many users don't leave>their stations on 24 hours per day
is because they share their voice>radios with their packet
stations. If we could mass produce cheap,>dedicated data radios
that weren't useful for FM voice, then more>users might be
willing to leave them on all the time. Especially if>there was a
good reason to do so, like contributing their share to the>local
network infrastructure.>>But even if you have users going on and
off the air, the network is>designed to adapt. If A and C had
been communicating through B, and B>goes off the air, then A and
C will attempt to communicate directly>with higher power (or
find another intermediate relay) before giving>up. Only if it is
impossible to find another path will the network
be>partitioned.>>Of course, depending on the circumstances you
may still want to>establish fixed "utility" nodes.  These would
be functionally>identical to ordinary user nodes, except that
they would be more>likely to be in good locations (e.g.,
hilltops) and would be supported>by a group rather than an
individual. But because these nodes would>likely blanket large
geographic areas, it is important that they not>be used simply
because they are there if an alternate, more efficient>route is
available. They're there just to guarantee connectivity
when>routes through intermediate user nodes are not
available.But now they are exposed terminals to everyone within
range and forthose users who *must* use them, either temporarily
or permanently,they represent a loss of thruput to that user and
all others onthe frequency due to the classic exposed/hidden
terminal problem.Since you have to have them in the real world
to maintain connectivity,everybody loses.>WD6EHR:>>>As far as
halving thruput with each hop, a system that begins with a
>>very high speed can afford to do that.>>No, throughput will
NOT DECREASE with additional hops! Because power>control keeps
you from blanketing the entire network with your>transmissions,
you can "pipeline" your packets down a chain of
simplex>repeaters. Once one of your packets has propagated out
of (relatively>short) range, you can launch another before the
first one has reached>its destination without interfering with
it. And since the average>transmit power will decrease with an
increasing density of nodes, the>overall network capacity
automatically INCREASES as you put more nodes>on the channel.
Try doing that with either conventional digipeaters or>full
duplex repeaters.Phil, you can't pipeline the next packet until
the *first* repeaterretransmits it, so you *do* halve the
effective baudrate. It's truethat with careful power control you
might not halve it *again* ateach hop, but the basic halving
does occur. The only way around thisis for the repeater to
retransmit on a *different* frequency. That'swhat a duplex
repeater does with the additional benefit of no storeand forward
delay. At 56 kb halving the effective baudrate is not too bad,
but at 9600 and 1200, halving the baudrate is painful. It
basicallymakes interactive work impractical.Gary
KE4ZV------------------------------Date: 13 Nov 91 15:06:15
GMTFrom:
elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.colu
mbia.edu!emory!wa4mei!n4rsy!ke4zv![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To : [e-mail]
(Gary Coffman)Subject : Re: Digital Packet Repeater Info
WantedIn article <[e-mail]>
[e-mail] writes:>In article
<[e-mail]>, [e-mail] (Gary
Coffman) writes:>|> People aren't as good as machines at
implementing an optimum random backoff>|> protocol.
[...]>>Granted. Although my comment was a little flip, I still
thought it>made a valid point, which is that collisions can
still easily occur in>a fully connected CSMA network when
several stations are all>contending for the channel when the
active one goes clear. Having used>the full duplex voice FM
system Brian described recently is very>instructive; you can
avoid a lot of wasted time in doubles. And you>can hear all the
rude remarks made about you by the other repeater>users.
:-)Sure, but the additional expense to *each* user of full
duplex mustbe traded against the chance of collision. Those
duplexers cost likeblazes and cross band implies either a lack
of capability to formad hoc simplex networks or implies doubling
of basic radio cost toallow simplex operation on each band. It's
an ideal, but an expensiveone.Gary
KE4ZV------------------------------Date: 13 Nov 91 15:01:14
GMTFrom:
elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.colu
mbia.edu!emory!wa4mei!n4rsy!ke4zv![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>|Reply-To : [e-mail]
(Gary Coffman)Subject : Re: CSMA/CD vs. CSMA/CAIn article
<[e-mail]> [e-mail]
writes:>>Contemporary simplex packet radio is just CSMA - there
is *no*>"collision avoidance" component above and beyond carrier
sensing. So>please do not use "CSMA/CA" to refer to it.
Thanks!>>PhilIs not the P persistence protocol an attempt at
implicit CA? Especiallywhen used through a duplex repeater where
there are no hidden terminals.Gary
KE4ZV------------------------------End of Packet-Radio Digest
V91 #295******************************Date: Sat, 16 Nov 91
04:30:05 PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #296To: packet-radioPacket-Radio Digest         Sat,
16 Nov 91       Volume 91 : Issue 296Today's Topics:
  Censorship of packet bulletins (2 msgs)
Digital fullduplex repeaters.
help              How can I reduce interference with an HT?Send
Replies or notes for publication to: <[e-mail]>Send
subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 15 Nov 91 18:06:54 GMTFrom:
[e-mail]: Censorship of packet
bulletinsTo: [e-mail]
<[e-mail]>,<[e-mail]
m>, <[e-mail]>Subject : Re: Censorship of
packet bulletinsBrian Kantor ([e-mail]) responds:>If you
post a message to a ham packet radio BBS and a
subsequent>forwarding BBS operator alters that message without
your permission>and redistributes it, he has quite possibly
violated your inherent>copyright on that message.  Sue him.I was
not aware that you were also a lawyer Brian.  However I
thinkthat your advice is a inappropriate, over-reactive, and
counterproductiveapproach to a problem, and demonstrates exactly
why I told Jim that itmight be inadvisable to notify the
originator of any message that it hadbeen killed and for what
reason.  While you personally may agree that aSYSOP has the
right not to forward, another may not... and if he sharesyour
views on how to handle something that he personally happens not
toagree with, then the sysop is asking to be sued.  Isn't ham
radio great?Just think... a hobby that can lead to a person
being sued... yeah, that'sthe ticket!>I believe that a sysop has
the right not to forward a message, but has>NO right to alter
its contents.It is interesting to know that this is your
opinion.  It is my opinionthat a ham has the right to take any
action that he feels necessary toprotect the privileges of his
Amateur operating license.  If anotherham disagrees with his
method(s) then it would seem that a friendlydiscussion might be
a rational approach.>Are that that desperate for BBSs that we'll
put up with this kind of>nonsense?Simple solutions Brian:1.
Personally fund and replace any BBS/Node/whatever that operates
in a    fashion that does not agree with your viewpoints.2. Do
not use BBS/Nodes/whatever that operate in a fashion not meeting
  your approval.3. Threaten to sue fellow hams for not agreeing
with your viewpoints.A story comes to mind.  A person is
standing on a bridge admiring abeautiful river.  Suddenly he
looks down and notices that a dog isrelieving himself into said
river.  Is it rational then for theobserver to conclude that the
whole river is polluted and thusdistasteful?Consider that when
you are ready to sue a man who has made a prettybig commitment
towards the betterment of packet radio, just becauseyou don't
happen to agree with one of his methods.Mark
[e-mail]------------------------------D
ate: 15 Nov 91 20:10:51 GMTFrom: [e-mail]:
Censorship of packet bulletinsTo: [e-mail] be
specific: I would not maintain that a BBS system operator
mustcarry my traffic.  It is his equipment, and his station, and
he can runas he likes.  That is his right.  I think it would be
courteous of himto inform people whether he is exercising
(exorcising??) that option,and to allow messages to route around
him, however, that's a degree offair-mindedness that I don't
really expect many sysops to maintain.But a message I have
written is MINE, not his, and he may not make anyalteration to
it without my permission.  That is not only common courtesy,but
it is (as I understand it) USA and international law.To be more
general, I am more and more convinced that the FCC'sregulation
of the content of transmissions by amateur radio stationsis
inappropriate and should be removed.  Legislation to this
purpose(or if necessary, action through the courts) needs to
happen.But as I see it, we, as hams, have a better track record
of giving into the whims of government bureaucrats than nearly
any other hobby orprofession I've ever been associated with.My
use of hyperbole, overstatement, and taking of extreme positions
isin reaction to the incredible number of "don't argue with
them, they'lljust screw all of us" attitudes I see on the net
and hear on the air.If this controversy stirs a few more
hotheads to get involved in makingamateur radio better, we will
ALL benefit.Remember, it's a sheep's destiny to be butchered.
The question to askyourself is whether, at the end of your life,
you'll be able to lookback and say that the world became just a
little bit better because youhad lived in it.    - Brian(No, Mark,
I'm not a lawyer (yet).  Perhaps when I have more time, I'lltake
that degree too.  It is something I've often
considered.)------------------------------Date: 14 Nov 91
21:31:29 GMTFrom:
news.hawaii.edu!mpg.phys.hawaii.edu![e-mail]:
Digital fullduplex repeaters.To: [e-mail] article
<13.Nov.91.10:17:18.GMT.#[e-mail]>
[e-mail] (Pete Lucas, NERC Computer
Services, Swindon) writes:>Full-duplex implies that both ends
can transmit concurrently with no mutual>interference or
interaction, like a telephone.>What is being described as a
'full duplex digital repeater' is being>mis-described. What it
really is, is a half-duplex repeater with collision>management
to make it work.Nope, it is full-duplex because the repeater
transmits and receives at thesame time on it's given 'channel'.
The half-duplex confusion comes in becausethe end-users
equipment usually can't listen while it's transmitting.  But
thatis a problem at the end-user equipment, not at the repeater.
 If you as anend-user had enough isolation between your receiver
and transmitter (and theycould operate independently) then you
would be using the digital repeaterin full-duplex mode.  This is
not unheard of and no longer uncommon.The definition of
full-duplex makes no requirement that the transmitted and
received packets at one end of the link are different.  Just
because that happens in the SIMPLEST case of a digital repeater
makes no difference.  Inthe more general case, how do you define
the duplex mode of a repeater thatis multiplexed on different
channels?  Consider the following example that most everyone
should be familiar with.  You have a repeater system with a
phonepatch on it.  You as an end-user have a simple radio and
bring up the phonepatch.  You dial a number and start
conversing.  Suppose the person you'vedialed to starts speaking
at the same time?  As far as you're concerned you'reoperating in
a half-duplex mode.  But anyone else who can listen on both
thetransmit and receive freqs of the repeater understands this
as full-duplex operation.  The repeater and the medium (in this
case a split channel) is -- Antonio Querubin
[e-mail] / [e-mail] /
[e-mail]------------------------------Date: 15 Nov
91 19:28:28 GMTFrom: [e-mail]: helpTo:
[e-mail]------------------------------Date: 14
Nov 91 19:50:30 GMTFrom:
cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!spool.mu.e
du!agate!linus!linus![e-mail]: How can I
reduce interference with an HT?To: [e-mail]
response to N2LAW's problems with an overly sensitive Yaesu
FT-470 dualband HT, so bad that he couldn't receive packet ...
there is a known problemwith the FT-470 front end (really just
the 2m portion) where (apparently) thechoice of IF frequencies
allow all kinds of intermod to take place.Yaesu knows about this
problem and they will fix your radio for free (callYaesu for
details).  However, others have told me that Yaesu has already
madethose mods on the newer HTs, and that Yaesu will use the
serial numbers tocheck to see which group you're in.I haven't
had the mods done to my FT-470, but I regularly talk to another
guywho has.  His opinion is that the sensitivity as been
decreased slightly, someof the intermods have gone away, but
he's still plagued by other intermods ashe drives into the city
(WashDC).--james (WB3LFB)#include <disclaimers.std>--Return
email paths:    from outside MITRE:    [e-mail]    from within
MITRE:    jlf@achilles                              - Don't have a
cow, man.    _ _                      /    (   )
  /     (   )      _(_      ^^^^   _^-^_      (   )    (   )
/   /   \   /  _^^_       ( @@)    00 M    @ @/    <@@ >  >oo<
     (_^>   (^)/    ( ^ )     o /    @       Marge   Homer
Bart    Lisa  Maggie------------------------------Date: 14 Nov
91 19:52:41 GMTFrom:
qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>, <[e-mail]>Reply-To :
[e-mail] : Re: Censorship of packet
bulletinsIn article <[e-mail]>, [e-mail] (Brian
Kantor) writes:|> I believe that a sysop has the right not to
forward a message, but has|> NO right to alter its
contents.Agreed. If necessary, we can implement the technology
to detect when amessage has been modified en route. You just
append a digitalsignature formed by hashing the message (e.g.,
with MD-5) and"signing" the hash with a public key cryptosystem
(e.g., RSA).Hopefully we will not have to do
this.Phil------------------------------Date: 13 Nov 91 03:24:43
GMTFrom:
bloom-beacon!micro-heart-of-gold.mit.edu!wupost!cs.utexas.edu!tam
sun![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital
Packet Repeater Info WantedIn article
<[e-mail]> [e-mail]
writes:[stuff deleted]>This doesn't follow. First of all, the
reason many users don't leave>their stations on 24 hours per day
is because they share their voice>radios with their packet
stations. If we could mass produce cheap,There are lots of other
reasons that have nothing to do with radio cost --I run NOS to a
TNC basically running in KISS mode.  Occasionally, I have totake
that computer off the air to do other work.  I am close to
dedicatinga computer, but most of them cost more than a radio.
I think it's a badassumption that enough stations will stay on
the air except in the mostdensely populated areas -- even then
it may not be correct.>But even if you have users going on and
off the air, the network is>designed to adapt. ...> Only if it
is impossible to find another path will the network
be>partitioned.There are many cases where you just can't get
from there to here, evenif you want to pump up 1500W {like to
see that in a cheap data radio 8-)}.What you'll end up with is
exactly what you allude to later in thequoted posting -- several
'reliable' nodes, probably with good areacoverage, serving for
most traffic.  Let's design for that.  After all,the cellular
phone system wasn't/isn't designed so that your car phoneacts as
a cell relay.>>As far as halving thruput with each hop, a system
that begins with a >>very high speed can afford to do that.>No,
throughput will NOT DECREASE with additional hops! Because
power>control keeps you from blanketing the entire network with
your>transmissions, you can "pipeline" your packets down a chain
of simplex>repeaters. Once one of your packets has propagated
out of (relatively>short) range, you can launch another before
the first one has reachedPower control or no power control, your
throughout WILL decreasebecause you have to run real-world
protocols -- TCP/IP does end toend acknowledgements, but most
AX25 won't let more than 7 packets at atime be "on the fly".
And applications (and users) tend to sendabout a packet's worth
of data before waiting for the other end.  Yourpipeline will
(almost) never be filled.  Even all this assumes nopacket loss
-- every transmission is at risk.  I think I could showthat in
most environments, a full-duplex repeater would win in
throughputover your chained siplex repeaters.>its destination
without interfering with it. And since the average>transmit
power will decrease with an increasing density of nodes,
the>overall network capacity automatically INCREASES as you put
more nodes>on the channel. Try doing that with either
conventional digipeaters or>full duplex repeaters.Try figuring
your probability of collision if you have a dense gridof simplex
repeaters.  Granted it may be better to use some smallernumber
of reliable sites than one big repeater, but "every node is a
variable power simplex repeater" doesn't seem to be an
automaticwinner.Cheers, Willis n5szfPS Anybody out there
familiar w/ a network simulation package called LANSF? I'm
trying to use it to model some of the packet LANarchitectures,
and I could use someone to bounce ideas off of.73,
wfm------------------------------End of Packet-Radio Digest V91
#296******************************Date: Sun, 17 Nov 91 04:30:04
PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #297To: packet-radioPacket-Radio Digest         Sun,
17 Nov 91       Volume 91 : Issue 297Today's Topics:
     Beware: :  Pager Scam!!! (2 msgs)
Censorship of packet bulletins                         CSMA/CD
vs. CSMA/CA                    Digital fullduplex repeaters.
               TAPR 1.1.7 code for the TNC-2
  TNC dc sources? (3 msgs)         When you can't discuss the
topic, discuss the wordsSend Replies or notes for publication
to: <[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 14 Nov 91 22:35:14 GMTFrom:
swrinde!zaphod.mps.ohio-state.edu!menudo.uh.edu!lobster!n5abi!gak
@ucsd.eduSubject: Beware: :  Pager Scam!!!To:
[e-mail]@borland.com (Sidney Markowitz)
writes:> >  [e-mail] (Monte Bateman)
writes:>
>----------------------------------------------------------------
------------> >It appears that there is a new telephone "scam"
being directed at users> >of pagers.  If you get a page with a
phone number 212-540-xxxx to call,> >DON'T CALL IT!!!!> > The
same notice was posted on another newsgroup, followed by a
message> from the poster with the further information that:> >
1. This incident happened several years ago, and the story has
been> making the rounds since then.> > 2. The guy was caught,
was forced to repay the money, and was put away.> > 3.
(212)-540-xxxx numbers cannot (any more?) be called from outside
of> New York City.> >  -- sidney <[e-mail]>>
KD6AVYWish it were so, but a very recent (last two weeks) news
story here says they are still operating and using numbe

rs with at least three different prefixes. It also indicated
that it is more than one srevice doing this. (But then,
newspapers have been wrong before
:-)--------------------------------------------------------------
---------          Gene Kennedy - Ham Radio Operator, N5ABI -

[e-mail]----------------------------------------------
-------------------------------------------------------Date: 14
Nov 91 22:31:00 GMTFrom:
swrinde!zaphod.mps.ohio-state.edu!menudo.uh.edu!lobster!n5abi!gak
@ucsd.eduSubject: Beware: :  Pager Scam!!!To:
[e-mail]@nsslsun.nssl.uoknor.edu (Monte
Bateman) writes:> Copied from packet radio::::> >
-----------------------------------------------------------------
------------> It appears that there is a new telephone "scam"
being directed at users> of pagers.  If you get a page with a
phone number 212-540-xxxx to call,> DON'T CALL IT!!!!>  > 212 is
the Area Code for New York City and the 540 exchange supposedly
acts> the same way as a 900 number where the phone number you
call from is billed.>  > The fee for calling these 540 numbers
is reported to be   $  5 5   ! ! >  > The people with these
numbers are reportedly calling around the country> inserting
these numbers into pagers to get the pager owners to call and>
return the page and the 540 number subscribers will
automatically get> the funds from the billing.>  > I cannot
personally confirm this situation, but forewarned is forearmed!>
 The information above is CORRECT! In certain parts of New York,
the 540 numbers are billed like 900 numbers, and in fact,
preceeded the 900 service. What's worse is that 540 is not the
only prefix being used this way. Sorry, but I can't remember the
others (there are at least two) that also use the automatic
billing and there have been several reports of them turning up
on pagers as well. If you get a page from the 212 area code that
is not a number you are familar with, be aware that you might be
in for a large bill if you call it. This scam is being
investigated by New York authorities according to the story I
saw
here.------------------------------------------------------------
-----------          Gene Kennedy - Ham Radio Operator, N5ABI -

[e-mail]----------------------------------------------
-------------------------------------------------------Date: 17
Nov 91 05:02:47 GMTFrom: [e-mail]:
Censorship of packet bulletinsTo: [e-mail]
Kantor ([e-mail]) writes:>To be specific: I would not
maintain that a BBS system operator must>carry my traffic.  It
is his equipment, and his station, and he can run>as he likes.
That is his right.  I think it would be courteous of him>to
inform people whether he is exercising (exorcising??) that
option,>and to allow messages to route around him, however,
that's a degree of>fair-mindedness that I don't really expect
many sysops to maintain.Just to say (not that it matters) that I
personally agree with youwholeheartedly Brian.  However I think
that I might have a higheropinion and regard for sysops in
general.>But a message I have written is MINE, not his, and he
may not make any>alteration to it without my permission.  That
is not only common courtesy,>but it is (as I understand it) USA
and international law.Ummm.  I don't know.  First of all
"XXX'ing" out something is not QUITE thesame as going in and
reWORDING a message.  The subject line of this stringis
"Censorship" and it may be a very fine line, but to Censure is
not quitethe same as to "ALTER".  I fully agree that no one
should ALTER, a message.If someone added some words, or in fact
added whole paragraphs, then I wouldbe quite angry and would
agree with your whole point of view.When someone REFUSES TO
FORWARD your whole message, he is CENSORING yourWHOLE message!
When someone goes in and "XXX"'s out say a phone numberlike:
1-900-332-2491, then he is censoring a PART of your message.  If
hewent in and CHANGED the phone number to "1-215-688-0997" then
he isALTERING a message.   So your real bottom line is that you
are saying thatit is OK to censure ALL of your message, but
please do not censure PART ofit.  Ok... fine.Given that the
simple inclusion of a "900" area code number in a packetbulletin
led to a whole string of BBS's being cited by the FCC, then Ican
see the point of view of some sysop that did not WANT to trash
awhole message from ANYONE, but sure as heck could not let it
continuewith that phone number in it!  That (at least now) is a
clear cut precaution,although it fries my shorts that simply
telling people to call a 900 numberis considered "business".   I
suppose that if I were to tell you Brian thatthe part you needed
to fix your radio was available from RF PARTS and thengave the
phone number for them and suggested you give them a call...
thatwould also be conducting business.  This whole issue stinks!
 (Not you, theFCC's interpretation of this issue.)In all
honestly... I sincerely believe that if you tell a sysop that
youwould rather he trash a whole message other than XXX'ing out
anything atall, that more than likely he will gladly comply.
It's easier.>To be more general, I am more and more convinced
that the FCC's>regulation of the content of transmissions by
amateur radio stations>is inappropriate and should be removed.
Legislation to this purpose>(or if necessary, action through the
courts) needs to happen.Brian... that sounds good on paper.  It
sounds good in public.  But itdoes not sound good when
implemented in a group that includes a certainfringe faction
that takes great pleasure out of abusing any and allpersonal
freedoms allowed to them.  Given Carte Blanche on subject
matter,you can be dead certain that THEIR freedom would very
soon interfere withMY freedoms.  What is considered as
"acceptable" PUBLIC subject matter atany given time is something
decided by society at large.  I agree that itis probably
impossible for the FCC to keep up with this... but to ascribeto
the alternative.. no regulation at all, is to invite abuse that
is NOTapproved by society as a whole or even a majority.And
please don't give me the answer of: "If you don't like it you
canalways turn the dial".  WRONG!  When I have to turn the dial
once in arare while... I can live with that.  However when I
have to keep turningand turning and turning that dial... I will
NOT put up with that, and mostespecially so when the majority
agrees.  Lack of any regulation, means lackof ANY control.  Lack
of ANY control is usually described as chaos.  I thinkyour idea
is great, but I do not believe that the world is yet
perfectenough that it should be implemented.>But as I see it,
we, as hams, have a better track record of giving in>to the
whims of government bureaucrats than nearly any other hobby
or>profession I've ever been associated with.That is (IMHO)
mainly because a lot of people see this hobby as aprivilege and
not as a Constitutional Right, and as such we can lobbyfor
changes in regulations, but we still are bound to abide by
them.If your meaning is that we don't lobby effectively enough
for better(more in line with reality) regulations... then I
agree... totally.And more specifically... fight for uniformity,
common sense, andcooperation in the ENFORCEMENT of the
regulations that we alreadyhave, instead of the sporadic, catch
as catch can, "depends on whoyou know", type of action that
presently seems to be the case whendealing with the bureaucracy
called the "FCC".>My use of hyperbole, overstatement, and taking
of extreme positions is>in reaction to the incredible number of
"don't argue with them, they'll>just screw all of us" attitudes
I see on the net and hear on the air.Ok... but I don't think
that it is necessary.   I would rather listen toyour calm side.
You make a lot of sense when you seriously discuss things...>If
this controversy stirs a few more hotheads to get involved in
making>amateur radio better, we will ALL benefit.Hotheads very
rarely benefit anyone... including themselves.>Remember, it's a
sheep's destiny to be butchered.  The question to ask>yourself
is whether, at the end of your life, you'll be able to look>back
and say that the world became just a little bit better because
you>had lived in it.A man that digs a ditch to the best of his
abilities, is honest/friendly,and helps his neighbors is the
type of guy that in my mind makes the worlda better place.  He
might never think so, but all those around him do.>(No, Mark,
I'm not a lawyer (yet).  Perhaps when I have more time,
I'll>take that degree too.  It is something I've often
considered.)Gee... me too.Mark
[e-mail]------------------------------D
ate: 16 Nov 91 15:27:38 GMTFrom:
[e-mail]: CSMA/CD vs. CSMA/CATo:
[e-mail] K3MC:>Barry, indeed a FIFO is needed.
 The diagram was simplified to emphasize>what we are doing; we
intend to borrow heavily on the work you guys have done!>The
byte-by-byte comparison works like this:  You start sending your
bytes,>and keep them in memory.  You then keep comparing the
byte you receive to>the first byte you transmit.  If no match,
you wait till you get the next>byte, etc. (note in the
repeater's case, you get your echo almost immediately).>After
you've waited the FIFO length + prop delays + scrambler delays,
and you>haven't begun to sync to the received bytestream, then a
collision must be>happening, so you abort
transmitting.>Incidentally, Barry, you seem to be using a pretty
deep FIFO; is there any>particular reason this can't be just a
2-byte or 3-byte FIFO?Probably not, although I wouldn't want to
stake my life on it.  The choice ofa 32-bit FIFO was based upon
a back-of-the-envelope calculation (I no longerhave the envelope
:-) ).  It assumed that the cheapie 3.579 MHz crystals usedin
the DSY modem's baud rate generator could have a fair amount of
variancein nominal value, plus the fact that we might want to
experiment withhumungous packet lengths or digital voice.  Since
the FIFO starts offhalf-full, the actual delay is 16 bits, or
about 0.29 ms.  In terms ofoverall delay, this isn't much
compared to the preamble of 12 ms or so whichis needed for the
scramblers plus DCD/clock recovery.What you could do if you
wanted to use a very short FIFO is install a trimmerin the 3.579
MHz oscillator.  Then everyone could "net" their modems to
theone at the repeater by looping back through the repeater and
tweaking thetrimmer until the rx and tx clocks were in phase.I
hope you'll be able to collect some 'before and after' stats -
it would begreat to have some real world results on the merits
of CSMA/CD versusstandard
CSMA.Barry------------------------------Date: 15 Nov 91 16:43:49
GMTFrom:
swrinde!cs.utexas.edu!tamsun!cs.tamu.edu![e-mail]:
Digital fullduplex repeaters.To: [e-mail] article
<13.Nov.91.10:17:18.GMT.#[e-mail]>,
[e-mail] (Pete Lucas, NERC Computer
Services, Swindon) writes:|> |> Why do us hams persistently
refer to contacts as 'simplex' as opposed to|> 'half duplex'?
We are *WRONG* to do this.For the same reason as why people say
they have a 2400 baud modem at home.There are many other
inaccuracies in (at least) the American dialect ofEnglish.  It
may be technically wrong, but the concept is right.  Or, at
leastthe concept is understood in the framework of the person's
understanding.There was a story where a tourist was lost and
asked a distinguished-lookingman, "Excuse me, but do you speak
English?"  The man replied, "Certainly.And I understand
American."What can I say?73,     Kurt "genuwine third-generation
Amurrican"-- Kurt Freiberger, wb5bbw      [e-mail]
409/847-8607  fax:[phone]Dept. of Computer Science, Texas
A&M University      DoD #264: BMW R80/7 pilot"We preserve our
freedom using three boxes: ballot, jury, and cartridge."
*** Not an official document of Texas A&M University
***------------------------------Date: 15 Nov 91 14:47:22
GMTFrom:
pacbell.com!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-
state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!uofs!vulture.
cs.uofs.edu![e-mail]: TAPR 1.1.7 code for the
TNC-2To: [e-mail] anyone used this code?  I just
made EPROMs of 1.1.7 and 1.1.7b and triedthem in a PACCOMM
TNC-200 (a claimed true TNC-2 Clone.)  Neither of them
doanything at all.  Is there something I am missing here?? Is
there more involvedthan just making and installing the EPROM??
It originally had 1.1.3 in and thatstill works.  I want 1.1.7b
because of the supposed, improved KISS mode.  I havebeen using a
KISS only EPROM, but it is a rather old version and I am
havingsome problems with it now.Can anyone offer any insight
into what it takes to make 1.1.7b actually work??Thanks in
advance.bill    KB3YV--      Bill Gunshannon          |
If this statement wasn't here,     [e-mail]   |
This space would be left intentionally blank
[e-mail]    |         #include <std.disclaimer.h>
------------------------------Date: 15 Nov 91 13:55:00 GMTFrom:
ub!acsu.buffalo.edu!ubvmsb.cc.buffalo.edu![e-mail]
ject: TNC dc sources?To: [e-mail] are quite a
few TNC's run on dc sources?  I can't imagine mosthams not using
them at a home base, and if that is the case why notuse AC
voltages?  I also heard that all you need is RS232 cableand
software.  Any comments?------------------------------Date: 16
Nov 91 18:04:25 GMTFrom: [e-mail]: TNC dc
sources?To: [e-mail] lot of ham stations run
entirely off one large 12v supply, which canbe a battery for
operation even when the lights go out.Besides, it's CHEAPER to
manufacture something that runs off 12 volts,even if that means
you have sell it with a power cube.  The power cubesare already
UL accepted, so you don't have to spend thousands of
dollarsgetting the TNC UL accepted.    -
Brian------------------------------Date: 15 Nov 91 18:28:14
GMTFrom:
ogicse!uwm.edu!cs.utexas.edu!utgpu!cunews!software.mitel.com!perr
[e-mail]: TNC dc sources?To: [e-mail]
article <[e-mail]>
[e-mail] (DANNY) writes:>Why are quite a
few TNC's run on dc sources?  I can't imagine most>hams not
using them at a home base, and if that is the case why not>use
AC voltages?  I also heard that all you need is RS232 cable>and
software.  Any comments?Many manufacturers choose to use the
small DC power packs because theyalready have UL (and CSA)
approval.  This way they can avoid the considerableexpense of
gaining approvals on each device they make.  I believe mostTNC
manufacturers ship the DC adapter anyway, so it's not really an
issue.-- Dave Perry
VE3IFB@[e-mail]----------------------------
--Date: 15 Nov 91 22:30:38 GMTFrom:
bloom-beacon!snorkelwacker.mit.edu!spool.mu.edu!sdd.hp.com!elroy.
jpl.nasa.gov!orchard.la.locus.com!devnet.la.locus.com!dana@ucbvax
.berkeley.eduSubject: When you can't discuss the topic, discuss
the wordsTo: [e-mail] an article some
unidentified person exclaims:    Why do us hams persistently
refer to contacts as 'simplex' as opposed to   'half duplex'?
We are *WRONG* to do this.My opinion is that people have a
tedency to start arguing about wordsand semantics when they do
not understand the topic originally underdiscussion. Sometimes
people use the wrong words to refer to somethingin such a manner
to confuse the issue; when this happens it makes senseto get in
sync on the lingo. However, when the meaning is clear, orthe
words are correct in the context of the discussion,
nit-pickingover actual words is counter-productive.--  * Dana H.
Myers KK6JQ         | Views expressed here are    * * [phone]         |
mine and do not necessarily    * * [e-mail]        | reflect those
of my employer    * * "Dammit Bones, spare me the lecture and give
me the shot!"   *------------------------------End of
Packet-Radio Digest V91 #297******************************Date:
Mon, 18 Nov 91 04:30:04 PSTFrom: Packet-Radio Mailing List and
Newsgroup </dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #298To: packet-radioPacket-Radio Digest         Mon,
18 Nov 91       Volume 91 : Issue 298Today's Topics:
                   ELM30Send Replies or notes for publication
to: <[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 15 Nov 91 23:00:54 GMTFrom:
hpl-opus!hpnmdla![e-mail]: ELM30To:
[e-mail] rec.radio.amateur.packet,
[e-mail] (Wim Nijntjes) writes:>   I have
trouble with the PCELM3.0 getting up and running.>   In fact I
have got it up but not running.>   All is does is a short
flicker on the display if a key is entered.>   Does anyone have
seen this ?   What is the cure?  I've seen it and found that
things behave much better if there is mailin the /spool/mail (or
whatever) directory.  Without mail present Ihaven't yet figured
out how to make it run.  However, this is only aftertrying for
about 15 minutes one evening.  Maybe someone else knows
thesecret of making it function when there is no mail
waiting..Glenn Elmore -N6GN-N6GN @ K3MC      amateur
IP:    [e-mail]:    [e-mail]
------------------------------Date: 17 Nov 91 07:01:53 GMTFrom:
qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: CSMA/CD vs.
CSMA/CAIn article <[e-mail]>
[e-mail] (Gary Coffman) writes:>Is not the P persistence
protocol an attempt at implicit CA? Especially>when used through
a duplex repeater where there are no hidden terminals.Not
really. There doesn't seem to be a widely accepted definition
ofwhat "collision avoidance" implies except for Apple's use of
that termto describe their Localtalk protocol. So I would tend
to limit it todescribe protocols that involve some sort of
handshake (explicit orimplicit) between sender and receiver in
which the receiver's side ofthe handshake tells other stations
to stay off the channel for awhile. p-persistence does improve
CSMA, but it doesn't add thereceiver-directed collision
avoidance feature.Phil------------------------------End of
Packet-Radio Digest V91 #298******************************Date:
Tue, 19 Nov 91 04:30:05 PSTFrom: Packet-Radio Mailing List and
Newsgroup </dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #299To: packet-radioPacket-Radio Digest         Tue,
19 Nov 91       Volume 91 : Issue 299Today's Topics:
                   ELM30             Mac's, PMP, Baycom, SoftPC
! Any idea's ??!!                    Modify MS-400 back to
standard                           TNC dc sources?Send Replies
or notes for publication to: <[e-mail]>Send
subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 18 Nov 91 18:43:06 GMTFrom:
[e-mail]: ELM30To:
[e-mail] from its reluctance to do anything if
there is no mail file to read,I've noticed a couple of other
anomalies with PCElm 3.0:The program seems to want to create its
temporary files in the currentdirectory rather than in the
directory pointed to by the HOME environmentalvariable.
Unfortunately, it has a problem when run from the root - whenyou
try and send mail, the program aborts with a message to the
effect thatit can't create "C:\\mailtext".PCElm 3.0 also seems
to have a problem handling multiple recipients in thealias file.
 It processes each entry (but I wish it could handle lineslonger
than 127 characters!) but fails to increment the message number,
soeach new message overwrites the previous one, and only the
last recipienton the list actually gets the mail.These problems
aside, I like the program, and I hope the authors continueto
support it.Barry VE3JF------------------------------Date: 18 Nov
91 15:12:00 GMTFrom:
agate!spool.mu.edu!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.ad
elaide.edu.au!levels![e-mail]: Mac's, PMP, Baycom,
SoftPC ! Any idea's ??!!To: [e-mail] query
origionated from VK5GU, but it got me thinking ....Is there any
software in existance that provides Baycom/PMP facilities onthe
mac ?? I realise that the mac serial port may not lend itself to
this sort of software as well as the pc ......Also, has ayone
played with running the above pc packages on a mac usingSoftPC
??Im am totally unfamiliar with the requirements that the Baycom
and PMP modemshave ion respect of EIA controls on the serial
interface, and can only assumethat the RS-422 on the mac may
pose problems when looking for power/controls.Any comments
_MOST_ welcome !!My addresses :[e-mail]0177  -
applelinkvk5xxx@vk5xip.#sa.aus.ocor to the origional requestor
:vk5gu@vk5wi.#sa.aus.octhanks in advance !!Rob
MayfieldAustralian Submarine Corporation Pty Ltdvk5xxx, vk5zeu
@vk5xip.#sa.aus.oc------------------------------Date: 18 Nov 91
15:16:00 GMTFrom: [e-mail]: Modify
MS-400 back to standardTo: [e-mail] recently got
an MS-400 card that had been modified to operate COMs 3-6
withIRQ 2. It had been used in a packet BBS setup with WA7MBL
amd later W0RLIsoftware. I did not receive any docs with the
card (used card) but wish tochange it to standard COM 1-4 IRQ
4,3 for COM 1 and 2 and IRQ 2 for Com 3 and4. Is there any out
there who can supply the
info?TNX---------------------------------------------------------
----------------------|Charles Layno                   Internet:
[e-mail]         ||
BITnet: [e-mail]                       ||
          CompuServe: 71441,1562
||                   Packet Mail: WB4WOR@WB4WOR.#GSO.NC.USA.NA
              ||              US Snail: P.O. Box 8252,
Greensboro, NC  27419-0252            ||          AMPRNet:
[44.75.1.32]:[e-mail]||
        "And so it goes" (Lloyd Dobbins/Linda Ellerbee)

|----------------------------------------------------------------
---------------------------------------------Date: 16 Nov 91
02:24:54 GMTFrom:
hpl-opus!hpspdla![e-mail]: TNC dc
sources?To: [e-mail] just hazard a guess that the
manufacturer's find it easier and cheaperto buy a 12 volt power
supply where the transformer hangs off the wallreceptacle than
to build an AC supply into the box.  Although powersupplies
appear simple, there are a lot of details relating to safety,UL
and other approvals.  Personally I dislike having an assortment
of bricks and blocks hangingon my outlets.  Especially the ones
which are big enough to cover theadjacent receptacle, and have a
three prong plug so you can't just turnthem around!  arrgh!
:-(------------------------------End of Packet-Radio Digest V91
#299******************************Date: Wed, 20 Nov 91 04:30:04
PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #300To: packet-radioPacket-Radio Digest         Wed,
20 Nov 91       Volume 91 : Issue 300Today's Topics:
       Censorship of packet bulletins
Getting into packet cheap                     L.L. Grace and
DSP-12 Packet                    TAPR 1.1.7 code for the TNC-2
                     WA8DED bits anywhere?Send Replies or notes
for publication to: <[e-mail]>Send subscription
requests to: <[e-mail]>Problems you can't
solve otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 19 Nov 91 04:19:52 GMTFrom:
sdd.hp.com!mips!bridge2!diasonx![e-mail]: Censorship
of packet bulletinsTo: [e-mail] the best way
to deal with naughty messages would be to replace the contents
of the offensive message with 'Censored by K0XXX.'  That way the
guys sending the bad messages will know whose machines NOT to
use.Otherwise they might figure the system is just
flakey.(Cathryn Mataga)  Not my
account...------------------------------Date: 19 Nov 91 16:17:36
GMTFrom: [e-mail]: Getting into packet
cheapTo: [e-mail]'ve decided that I want to get
into packet radio. At first I wasgoing to buy a TNC. I decided
on the PK232 because of it's largepopularity. I've since changed
my mind though. I'm going to buildthe Poor Man's Packet modem
instead. This will give me a chanceto get my feet wet and to see
if I really want to spend $300 orso on a mulitmode TNC. Here's
the question I have: How many people out there have successfully
built the Poor Man's Packet modem? I have all theparts I need
except for the 4.433619 MHz european colorburst freq.crystal.
I'm having a really hard time finding it. Does anyonehave some
suggestions as to where to find them?Internet:
[e-mail] GEnie: julie.a.s Sysop of CrossRoads BBS
[phone]------------------------------Date: 18 Nov 91
12:01:56 GMTFrom:
sdd.hp.com!wupost!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!n
ucsrl!tellab5!chinet![e-mail]: L.L. Grace and DSP-12
PacketTo: [e-mail] Ora, I can answer some of your
questions - I own L.L. Grace. The DSP-12 has a 12-bit ADC and
DAC connected to the DSP processor. Theseunits have sampling
rates of 100k samples/second. The A-to-D optionconnected to the
V40 is for telemetry and lower-quality (not toll PCM)digitized
voice work that I have some interest in. The DSP memory is fixed
at 4k words in P/X space and 4k words in Y space.These have
proven adequate for our needs so far. Sorry about thelack of
capitalization; the DSP processor does run at 24 megahertz.
Typical PCM is 64,000 bits/second. One megabyte of ram is 8
megabits.The DSP-12 can store 2.18 minutes of PCM toll quality
voice data. Inplanning the memory I assumed ADPCM at 26k
samples/second; not tollquality but certainly adequate for SSB
and mailbox work. Please let me know if I can help with further
questions. I'm more readilyavailable on CompuServe: 72677,1107.
Brooks --
-----------------------------------------------------------------
-------------Joseph Jesson
mhs!amoco![e-mail] or
[e-mail]21414 W. Honey Lane, Lake Villa, IL, 60046
Compuserve 73707,275-   Day Telephone - 312-856-3645     Eve.
Telephone - 708-356-6817
-----------------------------------------------------------------
-------------------------------------------Date: 19 Nov 91
12:32:13 GMTFrom:
netnews.upenn.edu!uofs!vulture.cs.uofs.edu![e-mail]
t: TAPR 1.1.7 code for the TNC-2To: [e-mail]
thanks to everyone who responded.  I have upgraded the RAM to
32K and1.1.7b now works great.  Of course, there is still one
problem.  Even afterre-calibration, the TNC-2 refuses to decode
signals coming from 2 different7910 based TNCs.  I am currently
using IC-2AT radios.  Could it be that theHTs are not flat
enough across the audio bandwidth??  Is there any kind
ofprocessing I could put together to make this combination
work??Thanks again.bill   KB3YV--      Bill Gunshannon
|        If this statement wasn't here,
[e-mail]   |  This space would be left
intentionally blank     [e-mail]    |
#include <std.disclaimer.h>
------------------------------Date: 19 Nov 91 00:50:30 GMTFrom:
swrinde!sdd.hp.com!hp-col!col![e-mail]: WA8DED bits
anywhere?To: [e-mail]. A friend (K0TER) is trying
to get some ARES software up which waswritten for the WA8DED
roms. Is there a network source for these bits?I scanned
ucsd.edu, but didn't see anything of DED. We're using a
TNC-1,but I bet he'd also like to try his PK-88 if there are DED
bits for it.Thanks.dave allen, wb0taq, colorado
springs------------------------------Date: 18 Nov 91 20:22:59
GMTFrom:
qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To :
[e-mail] : Re: Digital Packet Repeater
Info WantedIn article <[e-mail]>, [e-mail]
(Willis Marti) writes:|> There are lots of other reasons that
have nothing to do with radio cost --|> I run NOS to a TNC
basically running in KISS mode.  Occasionally, I have to|> take
that computer off the air to do other work.  I am close to
dedicating|> a computer, but most of them cost more than a
radio.  I think it's a bad|> assumption that enough stations
will stay on the air except in the most|> densely populated
areas -- even then it may not be correct.286 motherboards are
now down to less than $70. Or you can run NOS underDesqview (as
do many users who need to do other things while runningtheir
networks). The argument that it's too expensive to dedicate
computerequipment to running a network node is fading fast.|>
There are many cases where you just can't get from there to
here, even|> if you want to pump up 1500W {like to see that in a
cheap data radio 8-)}.|> What you'll end up with is exactly what
you allude to later in the|> quoted posting -- several
'reliable' nodes, probably with good area|> coverage, serving
for most traffic.  Let's design for that.  After all,|> the
cellular phone system wasn't/isn't designed so that your car
phone|> acts as a cell relay.There are important reasons that
relaying isn't done in cellular phonesystems. One is the fact
that cellular telephone systems are acommercial service, and
requiring customers to rely on other customerswould be hard to
sell. But the real reason is delay: all this relayingtakes time,
and voice is a delay-sensitive service. But data isdifferent. In
the data applications that consume most of the bandwidth(e.g.,
file transfer) throughput is more important than low delay,
andhere relaying makes a lot of sense.|> Power control or no
power control, your throughout WILL decrease|> because you have
to run real-world protocols -- TCP/IP does end to|> end
acknowledgements, but most AX25 won't let more than 7 packets at
a|> time be "on the fly".  And applications (and users) tend to
send|> about a packet's worth of data before waiting for the
other end.  Your|> pipeline will (almost) never be filled.  Even
all this assumes no|> packet loss -- every transmission is at
risk.  I think I could show|> that in most environments, a
full-duplex repeater would win in throughput|> over your chained
siplex repeaters.Nothing whatsoever says I have to run stock
AX.25. At the very least,I'll need to add fields to carry
"S-meter" readings to help thepower control process. In fact,
I'll probably come up with a completelynew protocol, one
specifically tailored for packet radio (unlike AX.25).It'll be
no big deal to get around the window size restrictions at
thesame time.|> Try figuring your probability of collision if
you have a dense grid|> of simplex repeaters.  Granted it may be
better to use some smaller|> number of reliable sites than one
big repeater, but "every node is a |> variable power simplex
repeater" doesn't seem to be an automatic|> winner.If you have a
dense grid, then the average spacing between nodes willbe
smaller. That means each node will use less power on the
average(since most will be routing through their closest
neighbors), thereforethe total system capacity goes
UP.Phil------------------------------Date: 18 Nov 91 17:39:45
GMTFrom:
qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To :
[e-mail] : Re: Digital Packet Repeater
Info WantedKA9Q:|> >Granted. Although my comment was a little
flip, I still thought it|> >made a valid point, which is that
collisions can still easily occur in|> >a fully connected CSMA
network when several stations are all|> >contending for the
channel when the active one goes clear. Having used|> >the full
duplex voice FM system Brian described recently is very|>
>instructive; you can avoid a lot of wasted time in doubles. And
you|> >can hear all the rude remarks made about you by the other
repeater|> >users. :-)KE4ZV:|> Sure, but the additional expense
to *each* user of full duplex must|> be traded against the
chance of collision. Those duplexers cost like|> blazes and
cross band implies either a lack of capability to form|> ad hoc
simplex networks or implies doubling of basic radio cost to|>
allow simplex operation on each band. It's an ideal, but an
expensive|> one.Good points -- that's why I think it's still
worthwhile to solve theproblems of the single-frequency,
store-and-forward relay
network!Phil------------------------------Date: 18 Nov 91
17:56:31 GMTFrom:
qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To :
[e-mail] : Re: Digital Packet Repeater
Info WantedIn article <[e-mail]>,
[e-mail] (Gary Coffman) writes:|> But now they [hilltop
relays] are exposed terminals to everyone within range and for|>
those users who *must* use them, either temporarily or
permanently,|> they represent a loss of thruput to that user and
all others on|> the frequency due to the classic exposed/hidden
terminal problem.|> Since you have to have them in the real
world to maintain connectivity,|> everybody loses.No, the way
the routing algorithm works, the hilltop sites are used onlyif a
more direct (i.e., less QRMing) path doesn't exist. In this
caseyou're not wasting anything.I should explain. Current
routing algorithms usually minimize thenumber of hops between
source and destination. Sometimes these choicescan be influenced
by manually set preferences or weights. But I arguethat in a
single-frequency relay network with power control, this isnot
the right thing to do (except perhaps for emergency traffic).
Whatyou *really* want to do is to minimize the total number of
activereceivers that have to be captured in order to send a
given packetbetween points A and B.To do this, each node first
builds a power control table: how many dbWit takes to reach each
of its neighbors. Then knowing the captureratio of the
modulation method in use, the nodes can compute how manyof those
neighbors it will have to capture in order to reach a
givenneighbor.  *That* becomes the routing metric. For example,
let'sassume a capture ratio of 10 dB (I know, a little small,
but it's justa round number for the sake of illustration). Say I
have a neighbortable like this:neighbor    powerWB6HHV        -20
dbWWB6CYT        0 dbWKA6IQA        +20 dbWN6NKF        +10 dbWKB5MU        +10
dbWTalking to WB6HHV (who is very close by) takes so little
power that Iwould be well below the other stations' noise
floors. Therefore I markhis entry with a metric of "1" (only one
receiver need be captured totalk to WB6HHV: WB6HHV itself). But
talking to WB6CYT, who is a littlefarther away, requires 20dB
more power. Talking to WB6CYT thereforerequires that I also
capture WB6HHV's receiver, but I'm still lowenough to not bother
the other three stations. So WB6CYT's metric is2.  Talking to
N6NKF or KB5MU (who are farther away still) requiresthat I
capture 4 receivers, so both have metrics of 4. And KA6IQA
isbehind a hill, so I really have to crank up the wick to reach
him. Hismetric is 5 (I have to capture ALL of my receivers to
reach him.)It is the sum of these metrics all across the network
that you wantyour routing algorithm to automatically minimize.
Strictly speaking,you are only worried about *active* stations;
capturing the receiverof an idle station causes no harm. So some
sort of activity measurementneeds to be exchanged between
neighbors so weights can be applied. It'sa complex algorithm,
but I think it's doable.KE4ZV:|> Phil, you can't pipeline the
next packet until the *first* repeater|> retransmits it, so you
*do* halve the effective baudrate. It's true|> that with careful
power control you might not halve it *again* at|> each hop, but
the basic halving does occur. The only way around this|> is for
the repeater to retransmit on a *different* frequency. That's|>
what a duplex repeater does with the additional benefit of no
store|> and forward delay. At 56 kb halving the effective
baudrate is not too |> bad, but at 9600 and 1200, halving the
baudrate is painful. It basically|> makes interactive work
impractical.Yes, you do halve the throughput, but remember
you're only using halfthe spectrum of the full duplex repeater.
Let's compare apples andapples here! Also remember that what I'm
trying to maximize is thetotal throughput of the entire network,
not the throughput of anygiven pair of users. These often are in
conflict.Phil------------------------------End of Packet-Radio
Digest V91 #300******************************Date: Thu, 21 Nov
91 04:30:05 PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #301To: packet-radioPacket-Radio Digest         Thu,
21 Nov 91       Volume 91 : Issue 301Today's Topics:
                   (none)Send Replies or notes for publication
to: <[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 20 Nov 91 13:45:00 GMTFrom:
[e-mail]: (none)To:
[e-mail] I-PACRAD
[e-mail]------------------------------End of
Packet-Radio Digest V91 #301******************************Date:
Fri, 22 Nov 91 04:30:03 PSTFrom: Packet-Radio Mailing List and
Newsgroup </dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #302To: packet-radioPacket-Radio Digest         Fri,
22 Nov 91       Volume 91 : Issue 302Today's Topics:
Mac's, PMP, Baycom, SoftPC ! Any idea's ??!!
       NOS for SysVr4Send Replies or notes for publication to:
<[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 20 Nov 91 17:45:20 GMTFrom:
intran![e-mail]: Mac's, PMP, Baycom, SoftPC ! Any
idea's ??!!To: [e-mail] article
<[e-mail]>, [e-mail]
(Rob Mayfield, vk5xxx@vk5xip.#sa.aus.oc) writes:> > Im am
totally unfamiliar with the requirements that the Baycom and PMP
modems> have ion respect of EIA controls on the serial
interface, and can only assume> that the RS-422 on the mac may
pose problems when looking for power/controls.> > Any comments
_MOST_ welcome !!PMP uses serial lines.  If there are similiar
parallel options on the mac(one interrupt, couple inputs, and
couple outputs) it ought to be a pieceof cake.  I have never
worked on the mac, but I understand how PMP works.The only
requirment for serial was optional power.  I figured my
laptopwas taxed enough, and decided to take the hit with weight,
and added a 9Vbattery to the PMP case.  The code is readable,
and works really well.If anyone has a Mac, maybe we can work on
this together.Tommy B. WD0EIB @
WB0GDB------------------------------Date: 18 Nov 91 21:10:26
GMTFrom:
prometheus!media!ka3ovk!barn!hoptoad!kumr![e-mail]
ubject: NOS for SysVr4To: [e-mail]   I am looking
for nos or net source that will work with System 5 Release4
UNIX.  I have tried the unixnet.cpio archive I found on
ucsd.edu, but whenI do an [attach asy 0 /dev/tty01...] I can't
ping the box via ether.  Anyclues?                     Thanks.
                   Tim-- Internet: [e-mail]
   FidoNet:  Tim Pozar @ 1:125/555UUCP:
...!uunet!hoptoad!kumr!pozarSnail:    Tim Pozar / KKSF / 77
Maiden Lane / San Francisco CA 94108 / USAVoice:    +1 415 788
2022------------------------------End of Packet-Radio Digest V91
#302******************************Date: Sat, 23 Nov 91 04:30:03
PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #303To: packet-radioPacket-Radio Digest         Sat,
23 Nov 91       Volume 91 : Issue 303Today's Topics:
           AX.25 queries (2 msgs)                  Getting into
packet cheap (2 msgs)             Mac's, PMP, Baycom, SoftPC !
Any idea's ??!!Send Replies or notes for publication to:
<[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 21 Nov 91 03:59:13 GMTFrom:
ucselx!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!qt.cs.utexa
s.edu!yale.edu!spool.mu.edu!munnari.oz.au!metro!ipso![e-mail]
uSubject: AX.25 queriesTo: [e-mail] to ask
some technical questions in the midst of the simplex/duplexwars,
but ... :-)A mate of mine is building his own KISS TNC, based on
a one-chip micro, andalthough having nothing to do with KISS the
following questions popped up:The "blue book" (AX.25 etc etc
version 2.0) says that the I field can beuo to 256 octets long.
Shouldn't that be 255?  A byte-count can then beused internally.
 The protocol doesn't seem to disallow zero-length I frames,and
indeed they could be useful, to signify EOF etc (a la Unix).The
Oracle also spake that the ABORT sequence is at least 15 `1'
bits, sansbit-stuffing.  I take it the receiver only has to see
7 `1' bits, to actuallyabort (I think the 8530 SCC chip does
this), so this would guarantee receptionof the sequence, no
matter when you started counting.-- Dave Horsfall (VK2KFU)
  VK2KFU @ [e-mail]
...munnari!ips.OZ.AU!dave------------------------------Date: 23
Nov 91 05:30:13 GMTFrom: [e-mail]: AX.25 queriesTo:
[e-mail] AX.25 specs are largely built on HDLC
chip specifications; it's ahack of a protocol that should have
vanished years ago but never will.As a result, it's often
necessary to bend or break the rules of theprotocol to make
things work well.One (of many) ways in which the protocol is
routinely violated is thesize of the data in an I-frame;  on
higher-speed links (56kb, etc) it'snot at all unusual to run
2048 byte packets.  It would be wise to designwith those sorts
of hacks in mind.    - Brian------------------------------Date: 20
Nov 91 16:08:40 GMTFrom:
hpl-opus!hpnmdla![e-mail]: Getting into
packet cheapTo: [e-mail]
rec.radio.amateur.packet, [e-mail] (Julie A.
Strietelmeier) writes:>    successfully built the Poor Man's
Packet modem? I have all the>    parts I need except for the
4.433619 MHz european colorburst freq.>    crystal. I'm having a
really hard time finding it. Does anyone>    have some
suggestions as to where to find them?Digikey had them a few
weeks ago for under $2 (I forget the exact pricebut I bought
5).Glenn Elmore -N6GN-N6GN @ K3MC      amateur
IP:    [e-mail]:    [e-mail]
------------------------------Date: 21 Nov 91 01:00:37 GMTFrom:
elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!magnus.acs.o
hio-state.edu![e-mail]: Getting into packet
cheapTo: [e-mail] article
<[e-mail]> [e-mail] (Glenn
Elmore) writes:>In rec.radio.amateur.packet,
[e-mail] (Julie A. Strietelmeier) writes:>>>
successfully built the Poor Man's Packet modem? I have all the>>
   parts I need except for the 4.433619 MHz european colorburst
freq.>>    crystal. I'm having a really hard time finding it.
Does anyone>>    have some suggestions as to where to find
them?>>>Digikey had them a few weeks ago for under $2 (I forget
the exact price>but I bought 5).>>Glenn Elmore -N6GN->>N6GN @
K3MC      >amateur IP:   [e-mail]>Internet:
[e-mail] I am interested in this poor man's pocket
modem.  Where can I find information. I'm currently using a KAM,
and am trying to go VERY portable with my station, i.e. a
handheld and probably an HP-95LX, and the KAM is the biggest
unit.Also, does anyone know anything about the tiny-TNC?
Apparently it was small enough to be placed in some handhelds,
although I dont know if this was actually done.  Is this the
same thing as the poor
man's?Thanks,[e-mail]----------------
--------------Date: 21 Nov 91 09:31:29 GMTFrom:
ogicse!henson!nyssa![e-mail]: Mac's, PMP, Baycom,
SoftPC ! Any idea's ??!!To: [e-mail]
<[e-mail]> [e-mail]
(Rob Mayfield, vk5xxx@vk5xip.#sa.aus.oc) writes:>Is there any
software in existance that provides Baycom/PMP facilities on>the
mac ?? I realise that the mac serial port may not lend itself to
this >sort of software as well as the pc ......Not that I know
of.  However, Macs use an 8530 for their serial ports;they do
HDLC in hardware.  No need to do 'bit banging' like PMP
orBaycom.Several years ago I hacked one of the 8530 drivers in
an old versionof Net to run on the Mac, but never got it working
reliably.>Also, has ayone played with running the above pc
packages on a mac using>SoftPC ??I suspect that this would not
work.  Baycom uses outputs that the Macdoesn't have (DTR and
RTS, but the Mac only has one output handshakingline), and PMP
uses the parallel port.>Im am totally unfamiliar with the
requirements that the Baycom and PMP modems>have ion respect of
EIA controls on the serial interface, and can only assume>that
the RS-422 on the mac may pose problems when looking for
power/controls.The PMP modem interface is TTL so you'd have to
shift levels.  ABaycom modem should work, though.Apple's MIDI
interface gets power from the differential transmit datalines by
through a fullwave diode bridge.  This might work if themodem
doesn't require too much current to run.-- --  Bob Finch
[e-mail]
[e-mail]------------------------------End of Packet-Radio
Digest V91 #303******************************Date: Sun, 24 Nov
91 04:30:04 PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #304To: packet-radioPacket-Radio Digest         Sun,
24 Nov 91       Volume 91 : Issue 304Today's Topics:
          AA4RE BBS test version.                   DCD State
machine - what is it?                   Need PacComm's address
(2 msgs)                TAPR 1.1.7b and other TNC-2 problems.
                       TNC dc sources?Send Replies or notes for
publication to: <[e-mail]>Send subscription
requests to: <[e-mail]>Problems you can't
solve otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 23 Nov 91 16:33:29 GMTFrom:
[e-mail]: AA4RE BBS test version.To:
[e-mail] latest test version (2.1T) is now
available fromtomcat.gsfc.nasa.gov and ucsd.edu.  This should be
the next-to-lasttest version.  The primary change is a
significant difference in theway the BPQ switch is handled.  For
several purposes, each radio portcan be handled
separately.Please let me know of any bugs.  It has already been
reported that theAC and AM commands are defective.Thanks in
advance for being my testers.Roy,
AA4RE------------------------------Date: 22 Nov 91 06:24:52
GMTFrom:
munnari.oz.au!metro!ipso![e-mail]: DCD
State machine - what is it?To: [e-mail] can I
find a reference as to how the State Machine actually works?I
gather it's just a suitably-programmed EPROM, coupled with a
latch, andfed with the bit-stream from the modem, to produce a
clock and/or DCD.References to it are bountiful, but little
actual information.  Is thecontent of the EPROM a (shudder!)
Trade Secret?  Or copyright?-- Dave Horsfall (VK2KFU)
VK2KFU @ [e-mail]
...munnari!ips.OZ.AU!dave------------------------------Date: 21
Nov 91 16:48:21 GMTFrom: samba!Will, [e-mail]:
Need PacComm's addressTo: [e-mail]   Can anyone out
there supply me with PacComm's address. I would liketo inquire
about their 9600 baud TNC2 modem, but I have been unableto
secure any of their advertisements.Thanks es 73,Will
Snyder/KB4LFDPacket: KB4LFD @ K4IWW.NC.USA.NOAMInternet:
[e-mail]:
[e-mail]------------------------------Date: 21 Nov
91 21:28:08 GMTFrom:
swrinde!elroy.jpl.nasa.gov!kilroy![e-mail]: Need
PacComm's addressTo: [e-mail] article
<[e-mail]>
[e-mail] (Will Snyder) writes:>>   >Can
anyone out there supply me with PacComm's address. I would
like>to inquire about their 9600 baud TNC2 modem, but I have
been unable>to secure any of their advertisements.>>Thanks es
73,>Will Snyder/KB4LFDI cannot help you right offhad with their
address, but Paccomms phonenumber is [phone].Theyre in a
suburb of Tampa, Florida.- jon
NW6H------------------------------Date: 22 Nov 91 12:28:22
GMTFrom:
usc!zaphod.mps.ohio-state.edu!wupost!darwin.sura.net!jvnc.net!net
news.upenn.edu!uofs!vulture.cs.uofs.edu![e-mail]:
TAPR 1.1.7b and other TNC-2 problems.To:
[e-mail], I got 1.1.7b working in the TNC-200
from PACCOMM.  Is it just me, oris it ridiculously slow??  RTT
using KISS mode and GRINOS went from 4 sec.to over 7 sec. with
all other things staying the same.  I watched the LEDsand it
seems to take an unreasonable amount of time from when the data
gets sent to the TNC until it decides to key-up the transmitter
and send the packet.Comments??I also have another problem.  As I
mentioned before, I am unable to decode data coming from a 7910
Modem being received by a TNC-2 with the XR Modem.I have
determined the problem to (most likely) be excessive roll-off in
the audio of the radios (IC-2AT) that I am using.  Has anyone
else seen this??Is there some simple network that I can put
together to maybe fix this up??Or is there some where deeper in
the bowels of the IC-2AT that I should be inserting the audio
from the TNC??Or maybe I should just bite the bullet and scrape
together enough free (HAHA)time to build the Ramsey radios I
bought for this purpose anyway.bill  KB3YV--      Bill
Gunshannon          |        If this statement wasn't here,
[e-mail]   |  This space would be left
intentionally blank     [e-mail]    |
#include <std.disclaimer.h>
------------------------------Date: 22 Nov 91 01:00:02 GMTFrom:
usc!zaphod.mps.ohio-state.edu!ub!galileo.cc.rochester.edu!fir.lle
.rochester.edu![e-mail]: TNC dc sources?To:
[e-mail] article
<[e-mail]>
[e-mail] (DANNY) writes:>Why are quite a
few TNC's run on dc sources?  I can't imagine most>hams not
using them at a home base, and if that is the case why not>use
AC voltages?  I also heard that all you need is RS232 cable>and
software.  Any comments?I believe that most DC, wall plug
powered electronics (TNC's included)use this power scheme to get
immediate UL listing.  Many mass marketersof wall power units
have UL listing.  DC powered devices (low voltage) don't require
UL listing. This is all basically a liability issue.73,
WB2HWI------------------------------Date: 23 Nov 91 18:09:24
GMTFrom:
agate!spool.mu.edu!think.com!yale.edu!qt.cs.utexas.edu!cs.utexas.
edu!tamsun![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedIn article
<[e-mail]> [e-mail] (Gary
Coffman) writes:>>To do this, each node first builds a power
control table: how many dbW....>>That's going to be a difficult
and very dynamic table to build with>near continous realtime
measurement and reporting required. ....> A dynamic map of the
entire>network must be kept for every possible route. Solving
n-way routing>is not simple. For any nontrivial net the
geometric complexity quickly>approaches that of a chess
game.>>Gary KE4ZVIn defense of Phil's scheme, computing routing
via power levels is not ofgeometric complexity; it does require
each station to keep track of:<destination>  <1st step to
destination> <metric>so the table size is only the size of the
"local" network.  One can cutdown on that with default routing.
Basically, one uses one of the IProuting information protocols
with the metric being # of stations that a node effects when
transmitting to the destination.  It DOES require largishtables
in dense local RF networks.  It DOES require (some) extra
bandwidth,but not much more than a bunch of netrom nodes -- and
there are 'smart' waysof exchanging info that minimize bandwidth
changes.  We do NOT have to keeptables of every possible
route.Cheers, Willis n5szf------------------------------Date: 21
Nov 91 16:04:44 GMTFrom:
elroy.jpl.nasa.gov!sdd.hp.com!mips!samsung!emory!wa4mei!ke4zv!gar
[e-mail]: [e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To : [e-mail]
(Gary Coffman)Subject : Re: Digital Packet Repeater Info
WantedIn article <[e-mail]>
[e-mail] writes:>In article
<[e-mail]>, [e-mail] (Gary
Coffman) writes:>|> But now they [hilltop relays] are exposed
terminals to everyone within range and for>|> those users who
*must* use them, either temporarily or permanently,>|> they
represent a loss of thruput to that user and all others on>|>
the frequency due to the classic exposed/hidden terminal
problem.>|> Since you have to have them in the real world to
maintain connectivity,>|> everybody loses.>>No, the way the
routing algorithm works, the hilltop sites are used only>if a
more direct (i.e., less QRMing) path doesn't exist. In this
case>you're not wasting anything.Yes I understand that, but it
takes only *one* active station needingthe services of a high
site to corrupt the entire network scheme. Iknow that around
here that would be always the case.>To do this, each node first
builds a power control table: how many dbW>it takes to reach
each of its neighbors. Then knowing the capture>ratio of the
modulation method in use, the nodes can compute how many>of
those neighbors it will have to capture in order to reach a
given>neighbor.  *That* becomes the routing metric.That's going
to be a difficult and very dynamic table to build withnear
continous realtime measurement and reporting required. Howmuch
bandwidth is going to be taken up passing capture ratio
statisticsback and forth as different stations asynchronously
become active users of the channel? A static table would be
fairly useless to a busy LAN.The calculation is going to have to
be done in depth across the entirepath. It does no good to
forward through three users who each captureonly a few receivers
when the third station must resort to a high siteto reach the
next step in the chain. A dynamic map of the entirenetwork must
be kept for every possible route. Solving n-way routingis not
simple. For any nontrivial net the geometric complexity
quicklyapproaches that of a chess game.Gary
KE4ZV------------------------------End of Packet-Radio Digest
V91 #304******************************Date: Mon, 25 Nov 91
04:30:02 PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #305To: packet-radioPacket-Radio Digest         Mon,
25 Nov 91       Volume 91 : Issue 305Today's Topics:
Mac's, PMP, Baycom, SoftPC ! Any idea's ??!! (3 msgs)
            Need PacComm's address
Source for TCM3105?                TAPR 1.1.7b and other TNC-2
problems.Send Replies or notes for publication to:
<[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 22 Nov 91 02:16:30 GMTFrom:
elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!munnari.oz.au!metro!ip
so![e-mail]: Mac's, PMP, Baycom, SoftPC ! Any
idea's ??!!To: [e-mail] article
<[e-mail]>
[e-mail] (Rob Mayfield,
vk5xxx@vk5xip.#sa.aus.oc) writes:| Im am totally unfamiliar with
the requirements that the Baycom and PMP modems| have ion
respect of EIA controls on the serial interface, and can only
assume| that the RS-422 on the mac may pose problems when
looking for power/controls.PMP doesn't use the serial port - it
bangs on the parallel (printer) port.And Baycom (as I recall)
doesn't actually use the serial port as such either -it makes
use of the RTS/CTS lines (I think).Reason: packet transmissions
are not your usual 8-bit asynchronous bytes,despite appearances
to the contrary.  It is actually HDLC with NRZImodulation.  Put
another way, serial ports won't make any sense of
thebit-stream.So, if the Mac can toggle its signals on the port
fast enough, it can do it(with appropriate software).Q: Is there
a FAQ list that answers the question of why you can't just pluga
telephone modem into your radio, to work packet?  Seems that a
number ofpeople (and I'm not including the gentleman above)
think this is the case.-- Dave Horsfall (VK2KFU)         VK2KFU
@ [e-mail]
...munnari!ips.OZ.AU!dave------------------------------Date: 22
Nov 91 15:45:19 GMTFrom: intran![e-mail]: Mac's,
PMP, Baycom, SoftPC ! Any idea's ??!!To: [e-mail]>
PMP uses serial lines.  If there are similiar parallel options
on the macOOPS!!! PMP uses parallel lines.  I blame it on low
freq EMF, causing severe brain fade (hopefully not permanent).
Tommy B.  WD0EIB @ WB0GDB  ------------------------------Date:
23 Nov 91 07:15:26 GMTFrom:
agate!spool.mu.edu!munnari.oz.au!metro!ipso![e-mail]
: Mac's, PMP, Baycom, SoftPC ! Any idea's ??!!To:
[e-mail] article <[e-mail]>
[e-mail] (Tom B.) writes:| PMP uses serial lines.  If
there are similiar parallel options on the mac| (one interrupt,
couple inputs, and couple outputs) it ought to be a piece| of
cake.You should emphasise that although it uses serial I/O, it
does not use theserial port, but rather the (parallel) printer
port.  Yes, the printer portuses a serial connector (DB-25), but
then again, the PC has got everythingelse wrong, so why stop at
the I/O connectors... :-)[ No, I'm not a Mac/Amiga/etc user -
I'm still using good ol' CP/M... ]-- Dave Horsfall (VK2KFU)
   VK2KFU @ [e-mail]
...munnari!ips.OZ.AU!dave------------------------------Date: 22
Nov 91 03:51:13 GMTFrom:
agate!spool.mu.edu!yale.edu!think.com!mips!ptimtc!chorus.mei!icsp
ub!astemgw!kuis!hugw!grape!humpty!humpty![e-mail].e
duSubject: Need PacComm's addressTo: [e-mail]
PacComm's address is:Pac-Comm Packet Radio Systems, Inc.3652 W.
Cypress StreetTampa, FL 33607-491673 de Kou,JA4MCI @
JG4IVE.JNET4.JPN.AS------------------------------Date: 22 Nov 91
18:46:41 GMTFrom: tijc02![e-mail]: Source for
TCM3105?To: [e-mail] a local club program
demonstrating PMP, we have some interest inbuilding packet
modems. Does anyone know of an inexpensive source forthe TCM3105
chip? I've seen $15.Thanks,Ed Ingraham, WX4SSiemens Industrial
Automation, Inc.        [phone] voice3000 Bill Garland
Road                     [phone] faxP. O. Box 1255
                    [e-mail] City,
Tennessee 37605-1255------------------------------Date: 22 Nov
91 19:08:01 GMTFrom:
pacbell.com!mips!zaphod.mps.ohio-state.edu!wupost!tulane!rouge!pc
.usl.edu![e-mail]: TAPR 1.1.7b and other TNC-2
problems.To: [e-mail] article
<[e-mail]> [e-mail] (Bill
Gunshannon) writes:>Well, I got 1.1.7b working in the TNC-200
from PACCOMM.  Is it just me, or>is it ridiculously slow??  RTT
using KISS mode and GRINOS went from 4 sec.>to over 7 sec. with
all other things staying the same.  I watched the LEDs>and it
seems to take an unreasonable amount of time from when the data
gets >sent to the TNC until it decides to key-up the transmitter
and send the packet.Could it be the default p-persistence and
slot times are inappropriate?I use "param tnc 2 64" and "param
tnc 3 10" for 64/255 ~= 1/4 for p-persistence, and 100 ms slot
times.73,-- -- James Dugal,    N5KNX        Internet:
[e-mail] Director        Ham packet: n5knx@k5arhComputing
Center        US Mail: PO Box 42770  Lafayette, LA  70504University of
Southwestern LA.    Tel.
318-231-6417    U.S.A.------------------------------Date: 23 Nov 91
06:58:23 GMTFrom:
news.hawaii.edu!munnari.oz.au!metro!ipso![e-mail]:
[e-mail]
<[e-mail]>, <[e-mail]>,
<[e-mail]>Subject : Re: Digital
Packet Repeater Info WantedIn article <1991Nov18.202259.21227@qu

alcomm.com>    [e-mail] writes:| If you have a
dense grid, then the average spacing between nodes will| be
smaller. That means each node will use less power on the
average| (since most will be routing through their closest
neighbors), therefore| the total system capacity goes UP.Ah, but
try selling Amateurs on the concept of using less power to be
ableto communicate more efficiently...  You get tromped on, you
simply wind upthe wick...  There, now _I'm_ tromping on _you_
:-)-- Dave Horsfall (VK2KFU)         VK2KFU @
[e-mail]
...munnari!ips.OZ.AU!dave------------------------------Date: 22
Nov 91 17:09:22 GMTFrom:
elroy.jpl.nasa.gov!sdd.hp.com!wupost!cs.utexas.edu!tamsun!cs.tamu
.edu![e-mail]: [e-mail]
<[e-mail]>, <[e-mail]>,
<[e-mail]>Subject : Simplex Chains vs
Duplex RepeatersIn article
<[e-mail]>, [e-mail]
(Phil Karn) writes:|> In article <[e-mail]>,
[e-mail] (Willis Marti) writes:[deleted]|> |> ... I
think it's a bad|> |> assumption that enough stations will stay
on the air except in the most|> |> densely populated areas --
even then it may not be correct.|> |> 286 motherboards are now
down to less than $70. Or you can run NOS under|> Desqview (as
do many users who need to do other things while running|> their
networks). The argument that it's too expensive to dedicate
computer|> equipment to running a network node is fading
fast.And a power supply is $20-$80, a case is $$, a monitor is
$$, etc.  Have you noticed how many people posting in this group
aren't willing to spend ~$120for a TNC?  Yes, computers are
(relatively) cheap.  But I don't think you'veanswered the
question about the density being there for the algorithm.{btw, I
do run NOS under Desqview -- and sometimes I still have to take
it down because of other program requirements.}[Phil explaining
why cellphones don't use the chaining scheme]|> ...But the real
reason is delay: all this relaying|> takes time, and voice is a
delay-sensitive service. But data is|> different. In the data
applications that consume most of the bandwidth|> (e.g., file
transfer) throughput is more important than low delay, and|>
here relaying makes a lot of sense.Are you advocating two
different networks, one for file transfer, one forinteractive
use?  Interactive use (not necessarily keyboard to keyboard)will
suffer the same delays as other data.  What about user access to
acallbook server?  Or just request/response to a Domain Name
Server?|> |> Power control or no power control, your throughout
WILL decrease|> |> because you have to run real-world protocols
-- TCP/IP does end to|> |> end acknowledgements, but most AX25
won't let more than 7 packets at a|> |> time be "on the fly".
And applications (and users) tend to send|> |> about a packet's
worth of data before waiting for the other end.  Your|> |>
pipeline will (almost) never be filled.  Even all this assumes
no|> |> packet loss -- every transmission is at risk.  I think I
could show|> |> that in most environments, a full-duplex
repeater would win in throughput|> |> over your chained simplex
repeaters.|> |> Nothing whatsoever says I have to run stock
AX.25. At the very least,|> I'll need to add fields to carry
"S-meter" readings to help the|> power control process. In fact,
I'll probably come up with a completely|> new protocol, one
specifically tailored for packet radio (unlike AX.25).|> It'll
be no big deal to get around the window size restrictions at
the|> same time.It isn't window size restrictions as much as it
is acknowledgements anduser/application behaviour.  The proposed
design may work well with bulkfile transfer, but not with
anything else!|> |> |> Try figuring your probability of
collision if you have a dense grid|> |> of simplex
repeaters....|> If you have a dense grid, then the average
spacing between nodes will|> be smaller. That means each node
will use less power on the average|> (since most will be routing
through their closest neighbors), therefore|> the total system
capacity goes UP.This is still rough, but decreasing the spacing
*increases* the number of hops needed, which increases the
probability of collision.  Retransmissionstake up part of
multiple small cells bandwidth.  Of course, not all trafficwill
need to traverse the maximum number of hops.  My first guess is
thatif you decrease coverage (by each single transmitter) by a
factor of 10, youwill get less than a factor of 3 thruput
increase.  Even that assumes that*every* node is on-the-air AND
*nobody* has to increase power to get to aneighbor that 'leaks'
into someone else's area...}|> PhilThanks for the response.
This is still an interesting proposal.  I thinkwe're agreed on
some things, and some left open:(a) File/mail bulk transfer
could take good advantage of this.(b) Interactive traffic would
suffer delays/loss of throughput.(c) Implementation would
(probably) mean a whole new link layer protocol   and format.(d)
There is probably a better system than 'one big duplex
repeater'.(e) It's still an open question as to whether one
would have the density   needed to make it reliable or different
from some small number of duplex   repeaters.(f) It's still open
as to how much the thruput could go up for whatever   decrease
in power/coverage, given the increase in number of hops and
chances for collision.(g) Since we haven't (yet) figured out the
measurable benefit, it's hard to   compare against the (also not
yet figured out) costs. {Yeah, I know we    all sometimes do
something 'cause it's technically elegant. 8-)}Willis
n5szf------------------------------Date: 24 Nov 91 06:14:29
GMTFrom:
qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet Repeater Info
WantedIn article <[e-mail]> [e-mail]
(Willis Marti) writes:>In defense of Phil's scheme, computing
routing via power levels is not of>geometric complexity; it does
require each station to keep track of:><destination>  <1st step
to destination> <metric>>so the table size is only the size of
the "local" network.Actually, I would probably want to use a
link-state (SPF) type ofrouting algorithm, so that each node
would have a complete list of allthe links within its network.
These algorithms tend to converge muchmore rapidly when things
change. They do tend to take more memory (tostore the link
tables) but this can be limited in practice by the useof
horizons, as in OSPF. And a well-designed SPF protocol can
reducethe network overhead below that of a conventional
(distance-vector)algorithm.Phil------------------------------End
of Packet-Radio Digest V91
#305******************************Date: Tue, 26 Nov 91 04:30:04
PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #306To: packet-radioPacket-Radio Digest         Tue,
26 Nov 91       Volume 91 : Issue 306Today's Topics:
                   (none)                    Gate way from email
to packet                        Packet with Palmtop ?Send
Replies or notes for publication to: <[e-mail]>Send
subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 26 Nov 91 06:46:00 GMTFrom:
[e-mail]: (none)To:
[e-mail] Jon
Brazelton/N4VRN------------------------------Date: 25 Nov 91
04:10:59 GMTFrom:
ogicse!uwm.edu!zaphod.mps.ohio-state.edu!caen!b-tech!ais.org!mb@u
csd.eduSubject: Gate way from email to packetTo:
[e-mail] am look for a way to send mail from
internet  to a packect radio bbs. Thebbs is called
n4uto.fl.usa.na and the station is ka8cwa. my mail forwarder is
connect to the internet.Also how would he send mail to my system
at home which ismbsun.ann-arbor.mi.us which is register with an
internet mail forward.Mike Bernson ([e-mail])
([e-mail])------------------------------Date:
25 Nov 91 20:09:56 GMTFrom: [e-mail]:
Packet with Palmtop ?To: [e-mail] would like to
know if someone here is using a palmtop computer as a
packetterminal, with what software.  Thanks in advance  F.
Rogerio F. Aragao    P T 2 T D  Department of Physics
University of Brasilia  e-mail
[e-mail]------------------------------Date: 24 Nov
91 15:24:59 GMTFrom:
pacbell.com!att!emory!kd4nc!ke4zv![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To : [e-mail] (Gary
Coffman)Subject : Re: Digital Packet Repeater Info WantedIn
article <[e-mail]> [e-mail] (Willis Marti)
writes:>In article <[e-mail]>
[e-mail] (Gary Coffman) writes:>>>To do this, each node
first builds a power control table: how many dbW>....>>>>That's
going to be a difficult and very dynamic table to build
with>>near continous realtime measurement and reporting
required. >....>> A dynamic map of the entire>>network must be
kept for every possible route. Solving n-way routing>>is not
simple. For any nontrivial net the geometric complexity
quickly>>approaches that of a chess game.>>>>Gary KE4ZV>>In
defense of Phil's scheme, computing routing via power levels is
not of>geometric complexity; it does require each station to
keep track of:><destination>  <1st step to destination>
<metric>>so the table size is only the size of the "local"
network.  One can cut>down on that with default routing.
Basically, one uses one of the IP>routing information protocols
with the metric being # of stations that a >node effects when
transmitting to the destination.  It DOES require largish>tables
in dense local RF networks.  It DOES require (some) extra
bandwidth,>but not much more than a bunch of netrom nodes -- and
there are 'smart' ways>of exchanging info that minimize
bandwidth changes.  We do NOT have to keep>tables of every
possible route.I think you missed the point. The "metric" is
going to require knowledgeof the number of stations captured by
"each" hop of a proposed path.Knowing only the cost of the first
hop is insufficient. Take for examplethe case where reaching a
certain destination can be done by two alternatepaths that both
must start with different stations. The first path requires7
hops while the second path requires 3. Now the cost to reach
either ofthe starting stations is low, but the shorter path
requires a stationdown the chain to access a high site while the
longer path does not butdoes require 3 hops that each capture 16
receivers. Now which is leastcost, and how is the originating
station going to know if it doesn'thave complete information?
Now add in that stations become active andpassive at different
times so that the metric is continously changingand it becomes a
nightmare task to pick the optimum route. A roundaboutroute
would be lower cost if all the stations captured were
currentlypassive than a short route where active stations would
be captured.The updating and metric calculations need to run in
near realtime,which requires near continous updating, which
keeps the network loadedso that there aren't any paths that
involve only passive stations.This is a lose-lose situation.Gary
KE4ZV------------------------------Date: 25 Nov 91 07:22:08
GMTFrom:
qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedIn article
<[e-mail]> [e-mail] (Dave
Horsfall) writes:>Ah, but try selling Amateurs on the concept of
using less power to be able>to communicate more efficiently...
You get tromped on, you simply wind up>the wick...  There, now
_I'm_ tromping on _you_ :-)That's why the power control must be
done *automatically*. Human naturebeing what it is, manual power
control will never amount to
much.Phil------------------------------Date: 24 Nov 91 06:08:19
GMTFrom:
qualcom.qualcomm.com!chicago.qualcomm.com![e-mail]:
[e-mail]
<[e-mail]>,
<[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedIn article
<[e-mail]> [e-mail] (Gary
Coffman) writes:>>No, the way the routing algorithm works, the
hilltop sites are used only>>if a more direct (i.e., less
QRMing) path doesn't exist. In this case>>you're not wasting
anything.>>Yes I understand that, but it takes only *one* active
station needing>the services of a high site to corrupt the
entire network scheme. I>know that around here that would be
always the case.No, it won't "corrupt the entire network
scheme". The one station whoneeds the hilltop relay may use the
network less efficiently than therest of the stations who don't,
but at least the rest of the stationswon't also be forced to
cover such a wide area with their transmissionsas would happen
if they all had to use a common hilltop repeater.Note also that
the hilltop relay need not have omnidirectionalantennas (the
actual type of antenna(s) can a local networkengineering
decision based on who needs it to get out) and thestations down
at low level need NOT defer to the hilltop relay (oranyone else,
for that matter) whenever they hear it speak -- only whenthey
determine that their transmissions might interfere with
theintended destination of the overheard transmission. This is
what ismeant by a "receiver directed" network. You don't care
about activetransmitters. You only care about active RECEIVERS
within range ofyour transmitter.>>To do this, each node first
builds a power control table: how many dbW>>it takes to reach
each of its neighbors. Then knowing the capture>>ratio of the
modulation method in use, the nodes can compute how many>>of
those neighbors it will have to capture in order to reach a
given>>neighbor.  *That* becomes the routing metric.>>That's
going to be a difficult and very dynamic table to build
with>near continous realtime measurement and reporting required.
How>much bandwidth is going to be taken up passing capture ratio
statistics>back and forth as different stations asynchronously
become active users >of the channel? A static table would be
fairly useless to a busy LAN.>The calculation is going to have
to be done in depth across the entire>path.Yes, this is going to
take work, but the DARPA SURAN project hasalready demonstrated
its feasibility. Remember this is NOT a radicallynew idea I'm
proposing -- at least not if you look beyond currentamateur
radio practice.>It does no good to forward through three users
who each capture>only a few receivers when the third station
must resort to a high site>to reach the next step in the chain.
A dynamic map of the entire>network must be kept for every
possible route. Solving n-way routing>is not simple. For any
nontrivial net the geometric complexity quickly>approaches that
of a chess game.Yes, so you wouldn't want to update the map too
often (similarproblems occur in wired networks when you try to
adapt to changingloads too quickly).  The only real penalty to
updating the map lessfrequently is that the active nodes might
spend unnecessary effortavoiding uninvolved nodes that are
actually idle and therefore don'tcare if their receivers are
captured by traffic directed to othernodes.In your specific
case, the routing algorithm would determine that thethird
station (the one that must use a high level site) is in the
pathand would probably pick a more direct route if the high
level sitecould not be avoided in some other way.  Remember that
the metricbeing minimized is the total number of receivers that
must be capturedalong the way to get a packet from point A to
point B. The number ofhops and the altitude of each relay node
is unimportant except insofaras they affect the accumulated
metric through that particular
path.Phil------------------------------End of Packet-Radio
Digest V91 #306******************************Date: Wed, 27 Nov
91 04:30:03 PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #307To: packet-radioPacket-Radio Digest         Wed,
27 Nov 91       Volume 91 : Issue 307Today's Topics:
      DCD State machine - what is it?                  Need ARRL
conference papers/RFC's                   Packet Status Register
on-line?               Packet Status Register on-line? current?
             QSL Inf 4 u5mir packet contact - request
   QSL inf 4 u5mir packet contact request.                TAPR
1.1.7b and other TNC-2 problems.                 TNC-2 1.1.7b
EPROM problem (2 msgs)Send Replies or notes for publication to:
<[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 25 Nov 91 21:43:00 GMTFrom:
deccrl!news.crl.dec.com!nntpd.lkg.dec.com!koning.enet.dec.com@dec
wrl.dec.comSubject: DCD State machine - what is it?To:
[e-mail] article
<[e-mail]>, [e-mail] (Dave
Horsfall) writes:|>Where can I find a reference as to how the
State Machine actually works?|>I gather it's just a
suitably-programmed EPROM, coupled with a latch, and|>fed with
the bit-stream from the modem, to produce a clock and/or
DCD.|>|>References to it are bountiful, but little actual
information.  Is the|>content of the EPROM a (shudder!) Trade
Secret?  Or copyright?|>|>-- |>Dave Horsfall (VK2KFU)
VK2KFU @ VK2RWI.NSW.AUS.OC|>[e-mail]
...munnari!ips.OZ.AU!dave|>I found mine in QEX, one of the
issues about the Xerox 820.  Don't rememberthe issue number.  I
can look it up, or I could post a PostScript filewith the
schematic of what I built based on that article...The ROM
contents are shown below.  The general idea is that you latchthe
ROM outputs (bits 0-6) on a 16x clock; bit 7 of the latch comes
fromthe input data.  The recovered clock is bit 3 and the NRZ
data is bit 6.One slightly strange hack: address bit 8 into the
ROM is tied high.The first half of the ROM contents corresponds
to having bit 8 low.  I guessthis allows for things to start up
cleanly during powerup.  The secondhalf does the actual work.
    paul, ni1d---------------41 42 43 44 45 46 47 48 49 4A 4B 4C 4D
4E 4F 4041 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 4041 42 43
44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 4041 42 43 44 45 46 47 48 49
4A 4B 4C 4D 4E 4F 4041 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F
4041 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 4041 42 43 44 45
46 47 48 49 4A 4B 4C 4D 4E 4F 4041 42 43 44 45 46 47 48 49 4A 4B
4C 4D 4E 4F 4041 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 4041
42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 4041 42 43 44 45 46 47
48 49 4A 4B 4C 4D 4E 4F 4041 42 43 44 45 46 47 48 49 4A 4B 4C 4D
4E 4F 4041 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 4041 42 43
44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 4041 42 43 44 45 46 47 48 49
4A 4B 4C 4D 4E 4F 4041 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F
4001 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 4003 04 05 06 06
07 08 08 09 09 0A 0B 0B 0C 0D 0E 21 22 23 24 25 26 27 28 29 2A
2B 2C 2D 2E 2F 0023 24 25 26 26 27 28 28 29 29 2A 2B 2B 2C 2D 2E
41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 40 43 44 45 46 46
47 48 48 49 49 4A 4B 4B 4C 4D 4E 61 62 63 64 65 66 67 68 69 6A
6B 6C 6D 6E 6F 0063 64 65 66 66 67 68 68 69 69 6A 6B 6B 6C 6D 6E
13 14 15 16 16 17 18 18 19 19 1A 1B 1B 1C 1D 1E 11 12 13 14 15
16 17 18 19 1A 1B 1C 1D 1E 1F 3033 34 35 36 36 37 38 38 39 39 3A
3B 3B 3C 3D 3E 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 7053
54 55 56 56 57 58 58 59 59 5A 5B 5B 5C 5D 5E 51 52 53 54 55 56
57 58 59 5A 5B 5C 5D 5E 5F 3073 74 75 76 76 77 78 78 79 79 7A 7B
7B 7C 7D 7E 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
70------------------------------Date: 25 Nov 91 16:23:02
GMTFrom:
pacbell.com!mips!think.com!zaphod.mps.ohio-state.edu!uwm.edu!ux1.
cso.uiuc.edu![e-mail]: Need ARRL conference
papers/RFC'sTo: [e-mail] all:    I'm doing a
paper for a Data Coms class in which I have to examineany
network I choose and show its relationship to the OSI model.
I've chosento write about the ampr.net. Is there any archive
available by ftp or mailserver of the ARRL computer netowrking
conference papers? Likewise for pertinent RFC's (any
recommendations on which RFC's I need?). The paper isdue Dec 10,
so please e-mail your suggestions right away :)!Still
procrastinating,Jay--
*****************************************************************
********* 73 de Jay, WT9S     Internet: [e-mail]
               **                     Packet:
[e-mail]
*****************************************************************
*********------------------------------Date: 25 Nov 91 09:12:51
GMTFrom:
news.hawaii.edu!mpg.phys.hawaii.edu![e-mail]:
Packet Status Register on-line?To: [e-mail]
anyone know if back issues of the TAPR Packet Status Register
are available on the net via anonymous FTP?-- Antonio Querubin
[e-mail] / [e-mail] /
[e-mail]------------------------------Date: 25 Nov
91 14:05:14 GMTFrom: crash!orbit!pnet51![e-mail]:
Packet Status Register on-line? current?To:
[e-mail]'m new to rec.radio.amateur.packet and no
longer very activeon packet.  Are current issues of TAPR's PSR
newsletter posted here?Is it still being published - it's been a
while since I've seen an issue.Fred Harlan Olson 1221 Russell Av
N MPLS, MN 55411  WB0YQMUUCP: {tcnet, crash,
quest}!orbit!pnet51!fholsonARPA:
crash!orbit!pnet51![e-mail]:
[e-mail]------------------------------Date: 25
Nov 91 21:41:46 GMTFrom:
munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!level
s![e-mail]: QSL Inf 4 u5mir packet contact -
requestTo: [e-mail] anyone help with the qsl
address for U5MIR, as well as his expectedmission completion
date. Are packet qsl confirmations of this type aidedby the
appropriate trace files ??73s & thanks in advance , Rob
vk5xxx------------------------------Date: 25 Nov 91 16:29:34
GMTFrom:
munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!level
s![e-mail]: QSL inf 4 u5mir packet contact
request.To: [e-mail] anyone help me with the qsl
address, personal name, and normal callsignwhen earthbound, for
U5MIR. Are accurate logs kept, or would a trace of thesession
help in confirming contact ?73's & thanks in advance ... rob
mayfield vk5xxx@vk5wi.#sa.aus.oc
         [e-mail]------------------------------Date:
25 Nov 91 18:00:16 GMTFrom:
elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!tamsun!cs.tamu.edu!kurt@
ames.arpaSubject: TAPR 1.1.7b and other TNC-2 problems.To:
[e-mail] article <[e-mail]>,
[e-mail] (Bill Gunshannon) writes:|> Well, I got
1.1.7b working in the TNC-200 from PACCOMM.  Is it just me, or|>
is it ridiculously slow??  RTT using KISS mode and GRINOS went
from 4 sec.|> to over 7 sec. with all other things staying the
same.  I watched the LEDs|> and it seems to take an unreasonable
amount of time from when the data gets |> sent to the TNC until
it decides to key-up the transmitter and send the packet.|>
Comments??I can't find the reference, but I believe they changed
the timing referencefor the values in the new KISS, so if you
use the old values the times are off.|> |> I also have another
problem.  As I mentioned before, I am unable to decode |> data
coming from a 7910 Modem being received by a TNC-2 with the XR
Modem.|> I have determined the problem to (most likely) be
excessive roll-off in the |> audio of the radios (IC-2AT) that I
am using.  Has anyone else seen this??|> Is there some simple
network that I can put together to maybe fix this up??|> Or is
there some where deeper in the bowels of the IC-2AT that I
should be |> inserting the audio from the TNC??Shame, shame!
You should be getting your audio from the discriminator, orat
least before the de-emphasis network.  Also, I just thought:
Have you yanked that filter chip and bypassed it?  It is
recommended that you do so, in the DCD mod kit instructions.  It
seems that it isn't really needed in the TNC2 modem design.I'll
put your kits together for you.....  That way Willis and I can
see ifwe want to buy them!!!!  BTW, what TxD will be needed for
those?  kf-- Kurt Freiberger, wb5bbw      [e-mail]
409/847-8607  fax:[phone]Dept. of Computer Science, Texas
A&M University      DoD #264: BMW R80/7 pilot"We preserve our
freedom using three boxes: ballot, jury, and cartridge."
*** Not an official document of Texas A&M University
***------------------------------Date: 25 Nov 91 05:46:41
GMTFrom:
news.hawaii.edu!mpg.phys.hawaii.edu![e-mail]: TNC-2
1.1.7b EPROM problemTo: [e-mail] while back, there
was some discussion of problems associated with
installingversion 1.1.7b firmware into a TNC-2.  I find myself
in the same predicamentbut don't recall what solutions if any
were posted to the net.  If anyone has saved that discussion,
could you please e-mail it to me?My specific situation:  TNC-2
clone (PK-80) with version 1.1.2 firmware and16K RAM.  Works
fine.  Put the version 1.1.7b EPROM in and the thing
doesn'trespond (at any baud rate or parity).-- Antonio Querubin
[e-mail] / [e-mail] /
[e-mail]------------------------------Date: 25 Nov
91 18:02:42 GMTFrom:
cs.utexas.edu!wupost!corvette.utdallas.edu!tamsun!cs.tamu.edu!kur
[e-mail]: TNC-2 1.1.7b EPROM problemTo:
[e-mail] article
<[e-mail]>,
[e-mail] (Antonio Querubin) writes:|> A while
back, there was some discussion of problems associated with
installing|> version 1.1.7b firmware into a TNC-2.  I find
myself in the same predicament|> but don't recall what solutions
if any were posted to the net.  If anyone has |> saved that
discussion, could you please e-mail it to me?|> |> My specific
situation:  TNC-2 clone (PK-80) with version 1.1.2 firmware
and|> 16K RAM.  Works fine.  Put the version 1.1.7b EPROM in and
the thing doesn't|> respond (at any baud rate or parity).You
must expand the memory to 32k.  this came in about 1.1.5 or so,
I believe.They used to make 2 versions, but stopped.kf-- Kurt
Freiberger, wb5bbw      [e-mail]   409/847-8607
fax:[phone]Dept. of Computer Science, Texas A&M University
    DoD #264: BMW R80/7 pilot"We preserve our freedom using
three boxes: ballot, jury, and cartridge."      *** Not an
official document of Texas A&M University
***------------------------------Date: 25 Nov 91 06:04:48
GMTFrom:
sdd.hp.com!wupost!corvette.utdallas.edu!tamsun![e-mail]:
 [e-mail]
<[e-mail]>, <[e-mail]>,
<[e-mail]>Subject : Re: Digital Packet
Repeater Info WantedIn article
<[e-mail]> [e-mail] (Gary
Coffman) writes:>In article <[e-mail]>
[e-mail] (Willis Marti) writes:>>In article
<[e-mail]> [e-mail] (Gary
Coffman) writes:>>>>To do this, each node first builds a power
control table: how many dbW>>....>>>>>>That's going to be a
difficult and very dynamic table to build with>>>near continous
realtime measurement and reporting required. >>....>>> A dynamic
map of the entire>>>network must be kept for every possible
route. Solving n-way routing>>>is not simple. For any nontrivial
net the geometric complexity quickly>>>approaches that of a
chess game.>>>>>>Gary KE4ZV>>>>In defense of Phil's scheme,
computing routing via power levels is not of>>geometric
complexity; it does require each station to keep track
of:>><destination>  <1st step to destination> <metric>....>>I
think you missed the point. The "metric" is going to require
knowledge>of the number of stations captured by "each" hop of a
proposed path.Correct.  But the way that metric is computed is
as follows: Each station computes the metric for stations it
directly contacts.  Ittells that to each of the surrounding
stations.  Each station then knowshow much it takes to get to
this '2d tier' through an adjacent station, andadds its metric
giving the metric to get to '2d tier' station.  If
multipleadjacent stations can get to the same destination, you
record the one withthe lowest total metric.  Each station will
tell the surrounding stationsof the metric for *all* the
stations it can figure out; thus, data for *all*stations on the
net gets proprogated to all stations and each station hasfigured
out the *1st step* {NOT the whole route} to every
destination.The RIP protocol sends the data in all entries every
update; more modernprotocols only send data as it changes.[rest
of Gary's comments deleted as irrelevant 8-)]>The updating and
metric calculations need to run in near realtime,>which requires
near continous updating, which keeps the network loadedOn the
order of seconds or 10s of seconds.  It does cause traffic,
butintelligent routing protocols don't eat up large percentages
of bandwidth.>so that there aren't any paths that involve only
passive stations.I'm not sure what you mean by 'passive'
stations; it really doesn't matterwhether a station does or does
not need to transmit -- it matters whethera transmission would
'reach' that node & that's part of the metric.  If thestation is
turned off, then it won't be exchanging power data & won't
becounted.>This is a lose-lose situation.Maybe.  But not because
of the routing scheme. {I personally think thethroughput gain
will not be significant in a real world environment.}>Gary
KE4ZVCheers,Willis n5szf------------------------------End of
Packet-Radio Digest V91 #307******************************Date:
Thu, 28 Nov 91 04:30:04 PSTFrom: Packet-Radio Mailing List and
Newsgroup </dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #308To: packet-radioPacket-Radio Digest         Thu,
28 Nov 91       Volume 91 : Issue 308Today's Topics:
 9600 baud and compatable radios. (2 msgs)
   BBS Authentication                   DCD State machine - what
is it?                         Digital Mobile Radio
          Packet with Palmtop ?Send Replies or notes for
publication to: <[e-mail]>Send subscription
requests to: <[e-mail]>Problems you can't
solve otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 26 Nov 91 01:08:05 GMTFrom:
ub!dsinc!wells!beyonet![e-mail]: 9600 baud and
compatable radios.To: [e-mail]    Well I just bought
the DEC. 91 "CQ" magazine because it had aninteresting article
in it from Buck Rogers K4ABT. In his article wherehe gives info
on "Which radios can be used at 9600 bauds with the G3RUHmodem,
he has a list of radios that have been used at 9600 baud.     Here
is the "G3RUH" list:    Alinco DR-1200 DataRadio        ALR series:
ALR-72, ALR 709    Kantronics DVR 2-2 Data Radio    Icom IC
series:25,38,228,271,290,471    Kenwood TR series: 7500, 7700        TM
series: 211,212,221,231,431        TS series: 700 and 770    Standard
C58, C140    Yaesu FT series: 212,221,230        He also said by the time
this column is read this list will haveincreased by ten times
:-).    Now does anyone have the latest Radio list because alot of
the radios above have been out dated and out of production. If
not well thenI guess I'll have to send US postal mail to Mr.
Miller "G3RUH" and getthe latest list. Does G3RUH or K4ABT have
an email address?     Anyone out there with success using the
Modifications on thesetrue FM pll radios and 9600? Who knows
about the modifications on theseunits and are they available
anywhere to get?    Thanks
Steve    WB3FTP------------------------------Date: 26 Nov 91
05:06:10 GMTFrom:
ucselx!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!
news.cs.indiana.edu!umn.edu!cs.umn.edu!uc.msc.edu!nachos.SSESCO.c
om![e-mail]: 9600 baud and compatable radios.To:
[e-mail] article <[e-mail]>
[e-mail] (Steve Urich) writes:>>    Here is the "G3RUH"
list:>>    Alinco DR-1200 DataRadio>        ALR series: ALR-72, ALR
709>    Kantronics DVR 2-2 Data Radio>    Icom IC
series:25,38,228,271,290,471>    Kenwood TR series: 7500, 7700>        TM
series: 211,212,221,231,431>        TS series: 700 and 770>    Standard
C58, C140>    Yaesu FT series: 212,221,230I know that the list is
bigger than this because many stations are usingYeasu FT736 and
Kenwood -711/-811 with the G3RUH on UO-14 and UO-22..I would
like to talk to anyone that is currently using either of
theKenwood -711 or -811 radios with a G3RUH, K9NG, DSP-12 or AEA
DSP-2232...I have performed the direct FSK mods on these radios
as suggested byDB2OS and ZL1TRE and am not having success.  The
modem appears to loaddown the descriminator and reliable copy is
extremely rare.I'd also like to know what the proper drive level
is to the modulator(ie, 500mVpp, 3Vpp, 2KVpp!) in either of
these radios to get +/- 3KHzdeviation.Any info greatly
appreciated.73,
[e-mail]73267,[e-mail]0JCF@WB0GDB.M
N.USA.NA(612)342-0003 @ work 8 'til 5 CST-- Chris Elmquist,
N0JCFInternet: [e-mail]   AMPRN:
[e-mail]   Telco: (612)
342-0003------------------------------Date: 28 Nov 91 03:04:23
GMTFrom: [e-mail]: BBS
AuthenticationTo: [e-mail] am experimenting with
various ways of BBS to BBS authentication.Best thing I have come
up with is that "A" sends a random number, "B"does an arithmetic
operation on the result and send the result back,"A" then
compares the distant answer with the local answer.  Thisexchange
is carried out encrypted using a key that both stations
haveagreed on.  The bad this is that this has to occur both
ways.Anyone with ideas is welcome to send them to me.Roy,
AA4REenge @ almaden.ibm.com------------------------------Date:
26 Nov 91 14:34:47 GMTFrom:
pacbell.com!att!linac!uwm.edu!spool.mu.edu!hri.com!noc.near.net!u
hasun!arrlhq![e-mail]: DCD State machine - what is
it?To: [e-mail] rec.radio.amateur.packet,
[e-mail] (Paul Koning) writes:>In article
<[e-mail]>, [e-mail] (Dave
Horsfall) writes:>|>Where can I find a reference as to how the
State Machine actually works?>|>I gather it's just a
suitably-programmed EPROM, coupled with a latch, and>|>fed with
the bit-stream from the modem, to produce a clock and/or
DCD.>|>>|>References to it are bountiful, but little actual
information.  Is the>|>content of the EPROM a (shudder!) Trade
Secret?  Or copyright?>|>>|>-- >|>Dave Horsfall (VK2KFU)
VK2KFU @ VK2RWI.NSW.AUS.OC>|>[e-mail]
...munnari!ips.OZ.AU!dave>|>>>I found mine in QEX, one of the
issues about the Xerox 820.  Don't remember>the issue number.  I
can look it up, or I could post a PostScript file>with the
schematic of what I built based on that article...>>The ROM
contents are shown below.  The general idea is that you
latch>the ROM outputs (bits 0-6) on a 16x clock; bit 7 of the
latch comes from>the input data.  The recovered clock is bit 3
and the NRZ data is bit 6.August 1986 QEX, actually.  I should
note that this design is a littledifferent from the TAPR design.
 Paul Newland, AD7I, designed the SM in theTNC2.  He included a
data-detect output (used on the K9NG modem) and,if I remember
correctly, used different bits of the output for the dataand
recovered clock.  It's been a lo-o-o-ng time, though, so my
memoryis a bit fuzzy on the details.Actually, the operation of
the SM is patterned after that of the internalDPLL in the Intel
8273, although that used a 32x clock rather than 16x.-----Jon
Bloom, KE3Z                     |
[e-mail] Radio Relay
League         |  uhasun!arrlhq!jbloom225 Main St.
         |     Usenet motto:Newington, CT  06111
|     "To serve and protest."------------------------------Date:
26 Nov 91 15:33:00 GMTFrom:
ucselx!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!wupost!darw
in.sura.net!Sirius.dfn.de!urmel![e-mail]: Digital
Mobile RadioTo: [e-mail] is an announcement for
a new mailing list about Digital Mobile Radio.The contents
should be about e.g.    - mobile communication    - digital
cellular and future phone systems      e.g. GSM, PCN, DECT,
UMTS, ... :-)    - radio channel models    - channel coding,
FEC, ARQ protocols    - speech-codec    - modulation technics
- media access protocols    - higher level protocols and
internetworking    - short message exchange applicationsIf you
want write an article, mail to:    [e-mail]
you would like to be considered, please send your address to:
[e-mail] hope there will be a hot
discussion,Peter Decker--Peter Decker  - Lehrstuhl
Kommunikationsnetze, RWTH Aachen,        Kopernikusstr. 16, D-5100
Aachen,Telefon: [phone] e-mail        -
[e-mail] ------------------------------Date: 26
Nov 91 15:47:46 GMTFrom:
ucselx!sol.ctr.columbia.edu!caen!sdd.hp.com!cs.utexas.edu!bcm!lib
!oac.hsc.uth.tmc.edu![e-mail]: Packet with
Palmtop ?To: [e-mail] article
<[e-mail]>
[e-mail](FRANCISCO ROGERIO FONTENELE
ARAGAO) writes:>I would like to know if someone here is using a
palmtop computer as a packet>terminal, with what software.Here
are a couple of messages recently posted to comp.sys.palmtops
aboutpacket on the HP95LX:--------I wrote:I just got the KA9Q
NOS TCP/IP package running on my 95. It took very littlehacking
- mainly to implement the async port fix Everett Kaser spoke of
acouple of days ago (thanks, Everett...anyone wanna vote for him
for MVP?)(...as in Most Valuable Poster.), to tell the screen
pause routine that thescreen is 16 lines long, and to compile
out such useless (on the 95) things asthe packet driver
interface and the NNTP client. I believe that the packagewould
run on a stock 95 if you disabled the ROM routines before
running it,but it would be extremely tight. A RAM card of at
least 512K is highlyrecommended. For some reason, the serial
routines won't go faster than 4800baud; I suspect that that's
because the NOS async driver is written entirelyin Turbo C,
while I think the built-in applications have had critical
parts(presumably including the driver) written in hand-tuned
assembler.I have sent Internet mail from it, and it works fine.
I used the PC sitting onmy desk as a router to the Internet,
talking SLIP to the 95 and Ethernet tothe rest of the world.Next
is a pocket packet radio (ham radio style) station; the entire
packagewill run off of batteries (lots of them, in the case of
the 95), fit into twopockets, and have all the functionality of
the average ham packet station.I'll bundle up the whole thing
and put it out for anonymous FTP in the nextfew days. Please
don't email me asking for it until I announce it here, andthen
only if you can't FTP.Outside of the slightly loose hinge at one
end (c'mon, HP, I've come to expectbetter of you), and the
built-in apps' insistence on starting off doing thingson C:,
both of which are at most minor irritants, I think HP got it
right. My95 goes nearly everywhere with me.  ---------------Greg
May, KB4OX/7, wrote:Sounds like you are having fun with the 95.
Earlier this year, I had theopportunity to play a bit and
quickly set up a HAM RADIO Packet stationusing the 95, the
built-in COMM, a two-meter rig, a PACCOM tiny batteryoperated
TNC and put it all in oneof those dandy little nylon "10 audio
cassette case holder" -- it evenhad a belt loop for the truly
faithful. All the pieces fit right in the caseincluding the 95
and cables, etc.  Talking about truly portable. (Didn't
needextra RAM or any special software -- set the TNC screen size
to 40 chrs.) And yes, we quickly built two systems and were
transfering files in no time.(By the way, the key macros are
wonderful -- you can assign the sequenceof key strokes to set up
the TNC or logging in or whatever to <char><whatever>and watch
the screen fly....)By the way, Buc Rodgers (really) has done
some work with the 95 and packet.A piece should beon the
magazine racks now..... December issue of "Amateur Radio CQ".--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that
which [e-mail]      | adequately be
explained by stupidity."I'd lend you a clue, but I already did
that and it hasn't come back yet." --
Peter da Silva------------------------------End of Packet-Radio
Digest V91 #308******************************Date: Fri, 29 Nov
91 04:30:05 PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #309To: packet-radioPacket-Radio Digest         Fri,
29 Nov 91       Volume 91 : Issue 309Today's Topics:
            Atari SSTV software                 Digital Packet
Repeater Info Wanted                      fast modems for packet
use             Highest speed TNC for Alinco DJ-F1T (2m FM)
                    ISC-Wampes on UCSD
Packet with Palmtop ?                      TAPR 1.1.7 in TNC2
Clones         Unix/Xenix KA9Q Net Derivative (WAMPES) on
UCSD.EDUSend Replies or notes for publication to:
<[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 27 Nov 91 14:39:57 GMTFrom:
pa.dec.com!decprl!decprl![e-mail]: Atari
SSTV softwareTo: [e-mail] friend of mine asked me
to post a request for him.He's looking for a Slow Scan TV
software for his Atari 520ST.If you can help, please reply to me
directly.Thanks!    Solange
Karsenty    [e-mail]------------------------------Date:
26 Nov 91 22:21:51 GMTFrom:
pa.dec.com!nntpd.lkg.dec.com!carafe.enet.dec.com!goldstein@decwrl
.dec.comSubject: Digital Packet Repeater Info WantedTo:
[e-mail] article
<[e-mail]>, [e-mail]
(Phil Karn) writes...[wrt using number of stations to be
captured as a routing metric]>Actually, I would probably want to
use a link-state (SPF) type of>routing algorithm, so that each
node would have a complete list of all>the links within its
network. These algorithms tend to converge much>more rapidly
when things change. They do tend to take more memory (to>store
the link tables) but this can be limited in practice by the
use>of horizons, as in OSPF. And a well-designed SPF protocol
can reduce>the network overhead below that of a conventional
(distance-vector)>algorithm.Care to elaborate, Phil?RSPF already
passes around link state metrics.  It has an arbitrary metric
assigned by each receiver to each subnet, as your
traditionalmetric, which it seeks to minimize on any end-to-end
path.  (For example, a 1200 bps Aloha AX.25 link might be "8"
and an Ethernet "1".)That could be changed.  Or, we could pass
around (there's a field forthis, reserved for future use) such
info as the "ERP factor".The RSPF 2.2 protocol spec is almost
ready to go out, but I'll entertain new ideas.---Fred R.
Goldstein   [e-mail]                  or
[e-mail]                    voice:  +1 508
486 7388 ------------------------------Date: 26 Nov 91 14:07:03
GMTFrom: mcsun!uknet!yorkohm!minster![e-mail]:
fast modems for packet useTo: [e-mail] am
interested in finding out about fast modems for ham radio use.I
have seen the G3RUH 9600 baud modem mentioned and also a 58.4
KBaud(have I got this correct?) device.Could someone tell me
more abotu these modems, please, or tell mewhere I can find more
information.73s de gary g6ddh------------------------------Date:
26 Nov 91 18:27:01 GMTFrom:
mnemosyne.cs.du.edu!isis.cs.du.edu![e-mail]:
Highest speed TNC for Alinco DJ-F1T (2m FM)To:
[e-mail] have been told that it is quite possible
to use my radio with astandard TNC and a dumb terminal and be up
and running with packet.That brought on a couple of questions in
my mind: can I run highspeed packet (9600 or more) on this
radio?  can I do it without major mods to the radio itself?
what are my options in terms ofTNC/modems for high speed
packet?Thanks much!73 de
KD4DAU------------------------------Date: Wed, 27 Nov 91
16:41From: [e-mail] (KA9Q Unix
Users)Subject: ISC-Wampes on UCSDTo:
[e-mail]-Path:
<uunet!DKAUNI2.BITNET!JK04>Posted-By:
uunet!CUNYVM.CUNY.EDU!JK04%DKAUNI2.bitnetPosted-On:    Wed, 27
Nov 91 16:41Hi there,my version of WAMPES is on ucsd.edu,
/hamradio/ka9q/incoming/wampes/isc-wampes.tar.ZHave much fun :-)
|Next weeks i'll be very busy with work so please try to
solveminor problems by yourself, but you can reach me via email
orthis list, if nothing works :-O73s,
[e-mail]==========================Many thanks to
Olaf for making this available!  Enjoy!  Mark.-- Mark J. Bailey,
N4XHX
_______/====X11====\_______USMAIL: 511 Memorial Blvd.,
Murfreesboro, TN 37129 |         JobSoft         |VOICE:  +1 615
893 0098                            | Design & Development
Co.|UUCP:   ...!uunet!mjbtn!mjb, ...!raider!mjbtn!mjb  |
Murfreesboro, TN  USA  |DOMAIN: [e-mail]      CIS:
76314,160  ---------------------------<KA9Q-UNIX-USERS Mailing
List-Subscribe:
[e-mail]>----------------------------
--Date: 26 Nov 91 22:28:09 GMTFrom:
usc!hela.iti.org!ox.com!caen!sdd.hp.com!hp-cv!hp-pcd!hpcvra.cv.hp
.com![e-mail]: Packet with Palmtop ?To:
[e-mail] this year, I had the opportunity to
play a bit and quickly set upa HAM RADIO Packet station using
the 95, the built-in COMM, a two-meter rig,a PACCOM tiny battery
operated TNC and put it all in one of those dandylittle nylon
"10 audio cassette case holder" -- it even had a belt loop
forthe truly faithful. All the pieces fit right in the case
including the 95and cables, etc.  Talking about truly portable.
(Didn't need extra RAM orany special software -- set the TNC
screen size to 40 chrs.) And yes, we quickly built two systems
and were transfering files in no time.(By the way, the key
macros are wonderful -- you can assign the sequenceof key
strokes to set up the TNC or logging in or whatever to
<char><whatever>and watch the screen fly....)By the way, Buc
Rodgers has done some work with the 95 and packet.A piece should
be on the magazine racks now..... December issue of Amateur
Radio CQ".Hope that helps,Greg May  KB4OX (in seven
land)------------------------------Date: 29 Nov 91 04:43:19
GMTFrom: [e-mail]: TAPR 1.1.7 in TNC2
ClonesTo: [e-mail] hate to ask the obvious, but
did you :a) connect to the tnc with a terminal pgm at the
correct speedand see the login msg and the   cmd:  prompt ???(as
I recall, the STA and CON lites should come on once for ashort
bit and a UI frame is sent out) ...If you didn't get this, you
gotsa a bad EPROM image or you did oneof the many bogus things
one can do installing a chip ...b) presuming you DID see the
cmd:,    did you type   KISS ON and then type RESTART at the
next cmd: prompt ??? (Note - should be RESTART andNOT RESET)
...That is what you should see/get and I apologize if I stated
the obvious,but you asked, and hey, it was worth a try ...(I
haven't used the tnc in conventional mode in ages, but that
should work).73, Dave VE3GYQTAPR
BoD------------------------------Date: 27 Nov 91 16:18:21
GMTFrom: mjbtn![e-mail]: Unix/Xenix KA9Q Net
Derivative (WAMPES) on UCSD.EDUTo: [e-mail]
FROM
[e-mail]:=======================--------
----------------------End of Packet-Radio Digest V91
#309******************************Date: Sat, 30 Nov 91 04:30:05
PSTFrom: Packet-Radio Mailing List and Newsgroup
</dev/[e-mail]>Errors-To:
[e-mail]-To:
[e-mail]: BulkSubject: Packet-Radio
Digest V91 #310To: packet-radioPacket-Radio Digest         Sat,
30 Nov 91       Volume 91 : Issue 310Today's Topics:
      9600 baud and compatable radios.             Mac's, PMP,
Baycom, SoftPC ! Any idea's ??!!
PK-80/TNC-2 battery Why is the AX.25 address field needed for
TCP/IP networks? (2 msgs)Send Replies or notes for publication
to: <[e-mail]>Send subscription requests to:
<[e-mail]>Problems you can't solve
otherwise to [e-mail] of past issues of the
Packet-Radio Digest are available (by FTP only) from UCSD.Edu in
directory "mailarchives/packet-radio".We trust that readers are
intelligent enough to realize that all textherein consists of
personal comments and does not represent the officialpolicies or
positions of any party.  Your mileage may vary.  So
there.-----------------------------------------------------------
-----------Date: 28 Nov 91 19:06:55 GMTFrom:
mcsun!sun4nl!nikhefk![e-mail]: 9600 baud and
compatable radios.To: [e-mail] article
<[e-mail]> [e-mail] (Steve Urich) writes:
    Well I just bought the DEC. 91 "CQ" magazine because it had an
interesting article in it from Buck Rogers K4ABT. In his article
where  he gives info on "Which radios can be used at 9600 bauds
with the G3RUH  modem, he has a list of radios that have been
used at 9600 baud.   The most curent sets are reported in lists
of radios been used at 9600 baudG3RUH modems. Only to get good
results you must used set with a real fmmodulator. (Personal
comunication with G3RUH.) The most pll fm radiosdon't work very
good, but I don't say they don't work!The most allmode sets have
a real fm modulator.     Does G3RUH or K4ABT have an email
address? G3ruh is curent actieve on oscar14 (9600 baud packet).
There are a fewgateway stations to oscar14.    Who knows about
the modifications on these  units and are they available
anywhere to get?I have some at home, but the most are in german.
 Henk, PA0HZP------------------------------Date: 27 Nov 91
16:39:17 GMTFrom: hayes![e-mail]: Mac's,
PMP, Baycom, SoftPC ! Any idea's ??!!To: [e-mail]
article <[e-mail]>,
[e-mail] (Rob Mayfield,
vk5xxx@vk5xip.#sa.aus.oc) writes:> This query origionated from
VK5GU, but it got me thinking ....> > Is there any software in
existance that provides Baycom/PMP facilities on> the mac ?? I
realise that the mac serial port may not lend itself to this >
sort of software as well as the pc ......Actually, that's not
entirely true. Unlike the PC, the Mac has a USARTchip used for
serial I/O. The PC uses UART chips, which are restricted
torunning asynchronously. The Mac 8530 serial chip can run
synchronously,and could conceivably run the AX.25 HDLC directly
from the chip.Unfortunately, also unlike the PC, the Mac has a
built in serial driverthat does not speak synchronous. You can
do synchronous, but only if youwrite your own driver and bypass
the build-in serial driver. This isconsidered exceedinly bad
form in the Macintosh community, and it won'twork correctly on
Macintosh IIfx or Quadra 900 computers without disablingthe
serial port IOPs (I/O Processors).Jack Brindle had something
like this running at one time, but that wasyears ago. (And he
never distributed it to my knowledge, it was justan experiment)>
> Also, has ayone played with running the above pc packages on a
mac using> SoftPC ??> Interesting idea. There's no telling how
complete the SoftPC hardware emulationis. The only way to know
if this will work is simply to try it.   Bill-- Bill Coleman,
AA4LR                ! CIS: 76067,2327    AppleLink:
D1958Principal Software Engineer        ! Packet Radio: AA4LR @
W4QOHayes Microcomputer Products, Inc. ! UUCP:
uunet!hayes!bcolemanPOB 105203 Atlanta, GA 30348 USA   !
Internet: [e-mail]: "My employer
doesn't pay me to have opinions."Quote: "If you think a serious
business computer must be painfully difficult        to use,
Macintosh isn't it."------------------------------Date: 30 Nov
91 01:54:55 GMTFrom:
news.hawaii.edu!mpg.phys.hawaii.edu![e-mail]:
PK-80/TNC-2 batteryTo: [e-mail] anyone know of
a source for the battery used in the PK-80 (TNC-2 clone)?I've
gone to the major electronic stores here and nobody seems to
have one.  It's marked CR-1/3N.-- Antonio Querubin
[e-mail] / [e-mail] /
[e-mail]------------------------------Date: 28 Nov
91 19:19:55 GMTFrom:
sdd.hp.com!think.com!mips!pacbell.com!att!news.cs.indiana.edu!cic
a!ogre![e-mail]: Why is the AX.25 address field
needed for TCP/IP networks?To: [e-mail] reading
the AX.25 standard and I see that there is avariable length
address field to include all hops the packet wasrouted to.  Is
this field used when encapsulating tcp/ip?  If so,why?  It seem
to me that you could leave these field blank whenusing tcp/ip or
am I missing
something.--=====================================================
===============Steven Wallace                |
[e-mail] (internet)Manager Network Operations
|  wallaces@iubacs          (bitnet)Indiana University
 |  (812) 855 - 0960
(voice)==========================================================
==========------------------------------Date: 29 Nov 91 19:58:52
GMTFrom:
munnari.oz.au!manuel!sserve!hhcs.gov.au![e-mail]
.eduSubject: Why is the AX.25 address field needed for TCP/IP
networks?To: [e-mail] article
<ssw.691355995@ogre>, [e-mail] (Steve Wallace)
writes:> Just reading the AX.25 standard and I see that there is
a> variable length address field to include all hops the packet
was> routed to.  Is this field used when encapsulating tcp/ip?
If so,> why?  It seem to me that you could leave these field
blank when> using tcp/ip or am I missing something.Hmmm..  I had
this great spiel typed out about "to" addressingwhen I suddenly
realised you meant digipeater fields.  If the only path to
another IP station that you want route IPthrough (or to) is via
a standard AX.25 station then you caninclude the digipeat field
when you manually define the route andyour frame will be
digipeated for you.  Otherwise, if you can seethe station you
want to send the IP frame to (or via) then thedigipeat fields
are not included. Clear as mud? :-(Carl. -- Carl Makin, Systems
Programmer - MVS/ESA, Dabbler - VAX/VMS Dept. Health, Housing
and Community Services, Canberra,
Australiasserve.cc.adfa.oz.au!hhcs!makinc   -
[e-mail]           -   [e-mail]
  -   Packet Radio"I'm from the Government and we're here to
help you."------------------------------Date: 27 Nov 91 18:37:28
GMTFrom:
qualcom.qualcomm.com!qualcom.qualcomm.com![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>Reply-To :
[e-mail] : Re: Simplex Chains vs Duplex
RepeatersIn article <[e-mail]>, [e-mail]
(Willis Marti) writes:|> And a power supply is $20-$80, a case
is $$, a monitor is $$, etc.  Have you |> noticed how many
people posting in this group aren't willing to spend ~$120|> for
a TNC?  Yes, computers are (relatively) cheap.  But I don't
think you've|> answered the question about the density being
there for the algorithm.|> {btw, I do run NOS under Desqview --
and sometimes I still have to take it down|>  because of other
program requirements.}Yes, but the prices are still declining.
Sooner or later, even the mostcheapskate ham won't be able to
use cost as an argument.|> Are you advocating two different
networks, one for file transfer, one for|> interactive use?
Interactive use (not necessarily keyboard to keyboard)|> will
suffer the same delays as other data.  What about user access to
a|> callbook server?  Or just request/response to a Domain Name
Server?No, it can be done with one network. Nothing *requires*
each node touse the min-captured-receiver-count criteria for
*all* of its routingdecisions. It would be very easy to provide
*two* routing tables ineach node: a default one that maximizes
total network throughput (bythe min-captured-receiver metric)
and another one, for delay-sensitiveor emergency traffic, that
minimizes the total hop count irrespectiveof the capacity hit on
the network. Individual packets could carryflags to indicate
which table is to be used. The type-of-service bitsin the IP
header are ready-made for this purpose.Having said that, I think
it's also safe to say that we should moveaway from interactive
uses of the network. For example, personalmailboxes eliminate
the need to use the network in an interactive modewhen reading
your mail. Broadcast protocols eliminate the need to usethe
network interactively to read bulletins.  As end-user
computersbecome more widespread, the demand for "dumb terminal"
interactiveuses of the network will decrease. This is something
that shouldhappen anyway, since interactive applications are
much more wastefulof network capacity than bulk transfer (packet
overheads are greater,channel contention is more serious,
etc).|> It isn't window size restrictions as much as it is
acknowledgements and|> user/application behaviour.  The proposed
design may work well with bulk|> file transfer, but not with
anything else!Again, we need to move in the direction of less
interactive usage ofthe network.|> This is still rough, but
decreasing the spacing *increases* the number of |> hops needed,
which increases the probability of collision.Nope, because as
the spacing decreases the average nodal transmitpower also
decreases. The number of neighbors to a given node
remainsrelatively constant.  (Somewhere I remember a DARPA SURAN
study thatshowed that the optimum number of neighbors to have in
a packet radionetwork was about 6.  This number was varied by
power control -- thetopology and density of the nodes was
assumed to be given. Needless tosay, most of our simplex
networks greatly exceed this figure.)|> Retransmissions|> take
up part of multiple small cells bandwidth.  Of course, not all
traffic|> will need to traverse the maximum number of hops.  My
first guess is that|> if you decrease coverage (by each single
transmitter) by a factor of 10, you|> will get less than a
factor of 3 thruput increase.  Even that assumes that|> *every*
node is on-the-air AND *nobody* has to increase power to get to
a|> neighbor that 'leaks' into someone else's area...}This
doesn't follow. Can you present an analysis?|> Thanks for the
response.  This is still an interesting proposal.  I think|>
we're agreed on some things, and some left open:|> |> (a)
File/mail bulk transfer could take good advantage of
this.Agreed.|> (b) Interactive traffic would suffer delays/loss
of throughput.Not necessarily, as long as an alternate routing
table is available fordelay-sensitive traffic. And, as I said,
we should find new applicationmodels that are less dependent on
interactive network access.|> (c) Implementation would
(probably) mean a whole new link layer protocol|>    and
format.No big deal. It's time to toss out AX.25 and do it
right.|> (d) There is probably a better system than 'one big
duplex repeater'.Not proven.|> (e) It's still an open question
as to whether one would have the density|>    needed to make it
reliable or different from some small number of duplex|>
repeaters.This depends on the area. Clearly if you only have a
few nodes out inthe boonies where you don't have a shortage of
spectrum, your duplex repeaterwill work fine. I'm worried about
the congested metropolitan areas in whichI've lived most of my
life (Baltimore-washington, Chicago, New York/New Jersey,and now
southern California) where spectrum is at a premium.|> (f) It's
still open as to how much the thruput could go up for whatever|>
   decrease in power/coverage, given the increase in number of
hops and|>    chances for collision.|> (g) Since we haven't
(yet) figured out the measurable benefit, it's hard to|>
compare against the (also not yet figured out) costs. {Yeah, I
know we |>    all sometimes do something 'cause it's technically
elegant. 8-)}Yes, it's time to do some simulations. A *lot* has
also been produced bythe DARPA SURAN project, and I think we can
avoid a lot of wheel reinventionby paying attention to what
they've done.Phil------------------------------Date: 27 Nov 91
20:43:23 GMTFrom:
elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.colu
mbia.edu!emory!kd4nc!ke4zv![e-mail]:
[e-mail] <[e-mail]>,
<[e-mail]>,
<[e-mail]>yReply-To : [e-mail] (Gary
Coffman)Subject : Re: Digital Packet Repeater Info WantedIn
article <[e-mail]> [e-mail] (Willis Marti)
writes:>>I'm not sure what you mean by 'passive' stations; it
really doesn't matter>whether a station does or does not need to
transmit -- it matters whether>a transmission would 'reach' that
node & that's part of the metric.  If the>station is turned off,
then it won't be exchanging power data & won't be>counted.I'm
calling a "passive" station one that currently doesn't have any
traffic for the net. If it's receiver is captured by a packet,
itdoesn't matter. This changes the nature of the ideal route. A
longroundabout route that impacts only currently passive
stations ismore efficient than a short route that impacts a
currently activestation. Not all stations have traffic for the
net at the same time.Gary KE4ZV------------------------------End
of Packet-Radio Digest V91 #310******************************