Date: Tue, 16 Nov 93 04:30:02 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #298
To: tcp-group-digest
TCP-Group Digest Tue, 16 Nov 93 Volume 93 : Issue 298
Today's Topics:
10 Ghz links
Borland Turbo C++ Visual
G8BPQ/SLIP
Ham Emergency Service 20 Years From Now (2 msgs)
help
Kiss
On the merits of KISS
SLIP, AX.25, KISS, Etc... (2 msgs)
Subscribe
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Mon, 15 Nov 1993 21:24:43 -0600 (CST)
From: Steve Sampson <ssampson@sabea-oc.af.mil>
Subject: 10 Ghz links
To: TCP-Group@ucsd.edu
kf5mg@kf5mg.ampr.org writes:
> Someone posted a message saying that a PC board was available for a 10ghz
> packet link a couple of months ago. Anyone know what that was supposed to do
> exactly.
The PC boards are available from FAR Circuits (advertises in most magazines)
and is meant to be used with the ARRL handbook reprint of the Ham Radio article
which modulates and demodulates the link. You hook up a 1 Mbps ethernet AUI
cable and the settup replaces the normal coax. 1 Mbps ethernet was superceded
by 10 Mbps ethernet, so don't know if any cards are available anymore. Isn't
Arcnet a 2 Mbps technology?? The reason being is that the Gunn diode is
modulated directly, rather than like the Gunnplexer which has a varactor diode
which is modulated. Evidently (I don't know) the varactor can handle a wider
bandwidth.
I've found a real nice 10 Ghz dipole, but the dish is only a foot in diameter.
It doesn't look like much, and I'm wondering how expensive it would be to
make a dozen or so, with a bracket for a bigger dish, and a flange for the
circulator, and Gunn diode oscillator.
> Is anyone here actually using a 2 Mbit link on 10ghz for packet? Is this
> do-able for the average ham or does it require a micro-wave engineering
> degree to figure this stuff out.
There's very few rules, and mostly the RF part is plug-n-play. The interface
is what's holding everyone up. Probably the best bet is to just run with a
DMA card of some sort, and do it raw FSK?? The mixer diodes are rather
expensive, but you just adjust the screw in front of the circulator for 0 dBm
(1 mW), out of the mixer and that's that. I found that OU has a cavity
frequency meter and have adjusted mine for 30 MHz seperation (don't know what
to use, but that sounded like a good start). That's all there is basically,
then you get to point it and line it up with the remote. The less the
beamwidth, the more trouble this becomes, especially on a windy day :-)
That's all I have, nothing working yet.
---
Steve
------------------------------
Date: Mon, 15 Nov 93 07:38:33 EST
From: "Jon Maguire redsox@vnet.ibm.com" <redsox@vnet.IBM.COM>
Subject: Borland Turbo C++ Visual
To: TCP-group@UCSD.edu
I just received a copy of the aforementioned compiler. Can this be used
to compile WG7J NOS? Thanks in advance.
-----------
Jon Maguire N1CQE/4 | ibm-vm: maguire@sppvm1 usib2tfc@ibmmail
Advantis | Packet: N1CQE@KC4LDT.#CLW.FL.USA.NA
Dept NB4 / Bldg PAV | voice: t/l:438-3038 external:(813)-878-3038
3105 W. M.L.King Blvd.| fax : t/l:438-3922 external:(813)-878-3922
Tampa, FL 33607 | AMSAT #21847 TAPR #2916 TPALAN BARS
| Internet: redsox@vnet.ibm.com
| IP 44.98.0.136 N1CQE.ampr.org
------------------------------
Date: Wed Nov 17 11:09:18 1993
From: iiitac@pyramid.swansea.ac.uk
Subject: G8BPQ/SLIP
To: tcp-group@ucsd.edu
No it provides intxx based interfaces for AX.25 and netrom. It also has
an AX.25 packet driver and supports running NOS on top (very nicely).
Alan
------------------------------
Date: Mon, 15 Nov 1993 13:01:03 -0500
From: chk@alias.com (C. Harald Koch)
Subject: Ham Emergency Service 20 Years From Now
To: karn@qualcomm.com (Phil Karn)
> >Just imagine 20,000 people trying to access Iridium simultaneously! :-}
>
> Just imagine 20,000 hams trying to access 146.34/146.94 simultaneously.
I think you missed the point here :-)
The reason the phone system breaks down under load in an emergency is
because there are no access controls; anyone, anywhere, can pick up the
phone and attempt to make a call.
Ham radio is more restricted access, both by licensing and (hopefully) by
restraint; during an emergency most hams will stay clear of emergency
communications. (I realize that there are hams who will interfere with
emergency comms, but at least up here they're still ignorable).
While I agree that the emergency services (and commercial providers) are
getting much better at staying alive during an emergency, they still have a
long way to go before they make hams obsolete...
Hams are a useful supplement to existing emergency communications. Fire,
Ambulance, and Police all have good networks, but we often find that they
can't talk to each other (especially in an emergency); hams can act as
liasons between these groups.
Hams are "expendable". It's expensive to park a police car with radios at an
emergency shelter to supply communications; it's much easier to place a
couple of hams with portable radios there.
The real advantage hams have over the commercial boys is the ability to
cobble together a communications link, from anywhere to anywhere, in a short
period of time, with "spare parts". The emergency services groups can't
afford to have a full complement of highly trained staff with the necessary
equipment to handle all necessary communications during an emergency. Ditto
the commercial communications people; they're in the business of supplying
normal communications, not emergency service.
--
C. Harald Koch, Network Analyst | "Heredity is what sets the parents of a
Alias Research Inc. Toronto, ON | teen-ager wondering about each other."
chk@alias.com | -- Laurence J. Peter
chk@utcc.utoronto.ca | (author of The Peter Principle)
------------------------------
Date: Mon, 15 Nov 93 12:27:31 PST
From: MUSCHINSKE%39A.decnet@sunman.chinalake.navy.mil
Subject: Ham Emergency Service 20 Years From Now
To: "tcp-group@ucsd.edu"%SUNMAN.decnet@sunman.chinalake.navy.mil
Phil says:
>Many of the cell sites I've seen (though not all) have microwave dishes
>halfway up the tower for the backhauls to the MTSO. And if one cell goes
>down, you can often use a neighbor as the service areas usually overlap.
Agreed, the cell sites often backhaul using microwaves, but the 40 dB dishes
used tolerate almost no misalignment. The beamwidth is on the order of a
couple of degrees. As long as the earth at both ends of the path is the
same as before the earthquake, the link should work. This is not a safe
bet after a large tremor.
Using neighbor cells just adds to the load after a disaster. Loma Prieata
was a poor test because it was such a small quake, located far from an
urban area. A good test would be something along the lines of the 1933
Long Beach quake.
------------------------------
Date: Mon, 15 Nov 93 08:55:45 CST
From: "John Martin" <martin@server.cdpa.state.ms.us>
Subject: help
To: tcp-group@ucsd.edu
quit
------------------------------
Date: Mon, 15 Nov 1993 13:34:55 -0600 (CST)
From: Steve Sampson <ssampson@sabea-oc.af.mil>
Subject: Kiss
To: TCP-Group@ucsd.edu
klarsen@acca.nmsu.edu writes:
> So With that I say, don't be afraid of Kiss. It does work fine.
You completely missed the theme. While we were discussing KISS, the real
theme was "should AX.25 be on the main CPU, or should it be in a chip, board,
or box". The general consensus was that it belongs on the main CPU, that most
do not want SLIP, and a simple majority want it as cheap as possible, and not
as easy as possible. (programming is cheaper than hardware, PC programming is
cheaper than Z-80 programming, etc).
>And if you have 4 TNC's to connect to your packet bbs look at the BPQ
>Switch version of Kiss. You can have 4 or more TNC's connected to a single
>dos com port and it does work.
OK BBS's are nice, but I thought TCP/IP was the group subject?? I wonder if
the BPQ switch can handle SLIP...
> And it's free. Can't beat that price!
Yes, cheap, my ham radio motto :-)
---
Steve
------------------------------
Date: Mon, 15 Nov 1993 12:12:14 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: On the merits of KISS
To: tcp-group@ucsd.edu
Steve Sampson writes,
>No one is going to make
>an AX.25 chip, so an AX.25 TNC is the only answer. The only plug-in card
I want would have to unload the CPU. I don't want the main CPU doing stuff
that a modem can do. Just as no one puts X.25 routines in the main CPU, they
shouldn't put AX.25 routines in either. They have plug-in cards, and modem
boxes that do that for you. The main CPU should work with the lowest
protocol level, an IP.
Not entirely accurate. X.25 itself consists of two or three different
layers, depending on how you slice it. X.25 Level 2 (LAP-B) has two
identifiable sub-layers. The "Core aspects" portion consists of the
framing (flags), transparency (bit-stuffing) and checksum (CRC-CCITT-16).
This is almost ALWAYS done in hardware, usually by a chip like the 85C30
or 68302. All HDLC variants, of which LAP-B is only one, can use similar
hardware. This is handled by the Ottawa PI card, to give one example
found in the ham world; there are various third-party cards too. Sadly,
the PeeCee world doesn't have a "standard" for this. I think the Mac
does -- the Localtalk port can at least be reprogrammed for lower-speed
HDLC.
The upper half of LAP-B, the elements of procedure, is almost always
done in software on a CPU. Most ham IP-over-AX.25 uses "UI" frames,
which minimizes this work, but in any case it's software.
Real X.25 has a Level 3 (Packet Layer Protocol) which is always done in
software. AX.25 does not have this layer, though it shows up in ROSE.
This indicates to me that the TNC is doing one of two valid functions.
It is either providing the Core Aspects of HDLC outboard, for lack of
a suitable PC card, or it is doing protocol translation for which you
lack software.
If it's doing async-to-HDLC, then you could replace the TNC with a cheap
8-bit card. You might even be able to bind this to NOS via a Packet
Driver, though that might be a bit kludgey. I rather like this in
principle: Outboard TNCs were designed for dumb terminals, and the
whole KISS think is a kludge (not that SLIP is not a worse kludge).
If the TNC is doing protocol translations, then you need to look at the
software angle. I use QVTnet myself, but I couldn't run it over AX.25;
it doesn't know from AX.25 and there's no glue. Conceivably a fancy
Packet Driver could fake it. But NOS does have AX.25 inside, so if you
are running this sort of software, you shouldn't need a real TNC.
I think we'd do well to have a "standard" (cheap, home-brewable) sync
card for PeeCees. Just one thing; it shouldn't use per-character
interrupt, but should use either FIFO (like a 16550A in async) or DMA
to receive data. TOO cheap won't work at high speed, and the cheapo
card should be good for at least 64 kbps, preferably "Glenn Elmore"
:-) speeds, like T1. And unlike commercial sync cards, it will need
on-board transmit clocking. Room for an integral modem (daughtercard?)
would be nice too; sometimes a TNCis only used because it has a modem
built-in, but what passes for modems in ham packet is embarrasing.
I normally use ISDN to the house so I know what the commercial world
can handle.
fred k1io
------------------------------
Date: 15 Nov 1993 14:30:29 -0600 (cst)
From: jks@giskard.utmem.edu
Subject: SLIP, AX.25, KISS, Etc...
To: tcp-group@ucsd.edu
Todd...
You are making one bogus assumption... The PC/micro world is Intel/DOS
dominated, but remember, the remainder of "computerdom" is not. The point many
of us have been trying to make is that there is a place for a TNC that contains
ALL the "intelligence" needed for a particular network hardware layer. Those
who own Macs, or use Intel boxes without DOS (yes we DO exist!) for example can
not use internal SCC type cards or the BAYCOM device without writing a driver
specifically for it. The packet driver spec is for a DOS TSR.... while you can
use them in OS/2 in a virtual DOS machine session, you are back to limiting
yourself to a single task where you have network access. Those folks with the
know-how have been able to do some of this in UNIX variants, but for the
typical PC user (including most Hams) this is out of reach.
There are TCP/IP stacks and tons of PD and shareware TCP/IP apps that could be
used over high speed radio links if a TNC was designed to talk SLIP or ETHERNET
(Ron... I like that idea.... but cost?) locally. Doing it all on the PC takes
up memory, slows thruput (ask DRSI owners if they wish they had DMA driven
boards now!) and locks the user into a monolithic program like NOS. In System
7, OS/2, Windoze, NT, and UNIX variants, one should be able to use the
native TCP stack and "your own favorite Telnet" app window/session to log on at
a remote host while "FTP'ing" from another -or- better yet, not using either...
but rather using Gopher, which does both in a very friendly way!
I would welcome "friendlier" systems than NOS (I have tried to help support
PMNOS) that do not require the intricate setup files that NOS does. Take a look
at MacTCP sometime..... it is a far cry from the BSD-oid UNIX syntax needed in
autoexec.nos. Fill-in-the-blank is what the average end-user wants, they could
care less about the power that they get from the "blood 'n guts" setup of NOS.
They would rather just get online!
None of what I am saying should be taken as denigrating NOS... It is simply
overkill for a PC using ham that is confused by the setup of PC-Packratt II.
The point is, by moving the AX.25 (or successor protocol) stuff completely away
from the PC, the user can chose his own access medium... and because it talks
TCP/IP, it should work. If your OS comes with a TCP stack... and your machine
has the appropriate port hardware... you should be able to talk to the TNC, and
use generic TCP apps over packet radio.
73,
KD4IZ
*********************************************************************
* Dr. John Spitznagel * Sancho Panza Institute *
* Internet: jks@giskard.utmem.edu * for Advanced Studies *
* AMPRNet: kd4iz@kd4iz.ampr.org * Department of Bogometrics *
* CIS: 76044,476 * *
* Tel: (901) 528-6441 * (C) JKS, 1993 *
*********************************************************************
------------------------------
Date: Mon, 15 Nov 1993 19:09:37 -0800
From: brian@nothing.ucsd.edu (Brian Kantor)
Subject: SLIP, AX.25, KISS, Etc...
To: tcp-group@ucsd.edu
>autoexec.nos. Fill-in-the-blank is what the average end-user wants, they could
>care less about the power that they get from the "blood 'n guts" setup of NOS.
>They would rather just get online!
I feel that tcp over ham radio is a good subject for experimentation and
development. I do not think it is anywhere ready for the 'average end-user'
to be using; I think we have some fundamental problems that have yet to
be solved.
Frankly, whenever someone starts talking about "bringing the word of
tcp/ip to the masses", I switch off. It's not time to do that yet, and
anyone who wants to do so is going to have an enormous task ahead of him.
Y'see, as I view it, even if you make NOS or something like it pretty
and user-friendly and warm and cuddly, the damn NETWORK isn't going to
be any of those things any time soon, so all you're doing is painting
the leaves gold while the roots wither.
We have to get the NETWORK working better first before we can even try
to spread things to the masses, and I don't see very many people working
on THAT.
Hams have much to much of a reputation for accepting any old shit
that'll work, regardless of how poor the performance is. Let's see if
we can't do better than that here. Sure, chrome sells, but performance
is what is really needed.
- Brian
------------------------------
Date: Mon, 15 Nov 93 08:34:32 CST
From: mfoster@amoco.com (Michael H. Foster)
Subject: Subscribe
To: tcp-group@UCSD.EDU
Subscribe
------------------------------
End of TCP-Group Digest V93 #298
******************************
******************************