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

Text File | 1993-12-31 | 284.4 KB | 6,619 lines

Packet-Radio Digest         Wed,  1 Aug 90       Volume 90 : Issue 103

Today's Topics:
             Multi-cast and packet radio
             Noise performance of modems
            packet groups in Ann Arbor, MI
              Tip for PK-232/PK-88 Users

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 31 Jul 90 21:21:34 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: Multi-cast and packet radio
To: [e-mail]

Dana,

It's certainly *possible* to add multicast filtering to the KISS TNC,
but at the channel speeds where it would make a difference (i.e., much
faster than 9600bps) you really shouldn't be using external TNCs
anyway.

K3MC and I intended the KISS TNC to be a short term hack to get us
going with TCP/IP until dedicated host interface cards were available.
Unfortunately, in the computer field there seems to be no such thing as
a "short term hack"...

Phil

------------------------------

Date: 31 Jul 90 21:31:02 GMT
From: mejac!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Noise performance of modems
To: [e-mail]

 I just finally bought several of the Computer Networking Conference books.
These are excellent, much better than I'd expected. I'd HIGHLY recommend
going out and buying them.

  Anyway, I've heard people complain (myself included) that the Carrier
Detect mechanism on the Am7910 is poor, while the XR-2211 is quite a bit
better. Of course, using a DPLL/State Machine for coherent data carrier
detect is by far the best approach, so it really doesn't matter how poor
the carrier detect provided by the demodulator is. What is important,
however, is good data recovery in the modem.

  What is ironic, is how poor the XR-2211 fares in terms of noise performance.
Page 110 of the 6th Computer Network Conference contains LU4DXT's paper
on measuring th noise performance of several popular modems. In order to
achieve a Bit Error Rate of less than 1e-04, the 2211 requires a S/N of
24.2 dB, while the 7910 requires only 12.3 dB S/N.
*****************************************************************
* Dana H. Myers KK6JQ           | Views expressed here are      *
* [phone] (ex WA6ZGB)    | mine and do not necessarily   *
* [e-mail]                | reflect those of my employer  *
*****************************************************************

------------------------------

Date: 1 Aug 90 08:25:33 GMT
From: uhccux![e-mail]  (Antonio Querubin)
Subject: packet groups in Ann Arbor, MI
To: [e-mail]

I will be moving to Ann Arbor, MI two weeks from now and will be staying for
about a half year.  I am debating whether it would be worth the effort to take
my packet equipment with me.  Could anyone near that area fill me in on the
state of packet radio and TCP/IP activity there?

Also looking into continued access to Internet from there so I can get my
e-mail.  Anyone know of any kind of dial-up service in Michigan to a Telnet
server?

73's
AH6BW
[e-mail]
querubin@uhccux (BITNET)

------------------------------

Date: 31 Jul 90 20:57:59 GMT
From: uop!quack![e-mail]  (Nick Sayer)
Subject: Tip for PK-232/PK-88 Users
To: [e-mail]

[e-mail] (R M Kriss) writes:

[hint about changing CUSTOM to remove DCD check]

> ...I question if it really increases [DCD]
> sensitivity...

It doesn't. It removes the consideration of DCD when receiving data.
The only remaining use for DCD is colision avoidance.

Have you tried increasing your AF gain from the receiver? If
the node you're talking to can't break DCD, you either have your
squelch off (in which case DCD is probably blinking a lot if it's not
too low), the AF gain too low (in which case DCD never comes on), or
the node you're talking to does not have TXDELAY set high enough (There
should be a slight amount of audible flagging before the actual
packet starts. When you adjust TXD to slam the packet up right against
the begining of RF output, you don't give (bad) receivers enough
time to release squelch).

Anyway, that's been my (limited) experience. I used to be quite active,
but now I can't even find a BBS in my area. Packet's goin' to hell
in a handbasket! :-)

--
Nick Sayer               | Disclaimer:                      ___
N6QQQ                    |    "I ain't gonna touch it,     /   \    snap
quack![e-mail]    |     but the title alone         |. .|  x snap
209-952-5347 (Telebit)   |     gets two snaps up."         ( o ) ||

------------------------------

End of Packet-Radio Digest
******************************
Date: Thu,  2 Aug 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #104
To: packet-radio


Packet-Radio Digest         Thu,  2 Aug 90       Volume 90 : Issue 104

Today's Topics:
         Multi-cast and packet radio (3 msgs)
                 NOS for CPM
           packet groups in Ann Arbor, MI (2 msgs)
           what kinds of speeds are in use?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: Wed, 1 Aug 90 09:06:06 -0400
From: [e-mail] (Charlie Ross, Jr.)
Subject: Multi-cast and packet radio
To: "[e-mail]"@gte.com

Phil, KA9Q, writes:

<<K3MC and I intended the KISS TNC to be a short term hack to get us
going with TCP/IP until dedicated host interface cards were available.
Unfortunately, in the computer field there seems to be no such thing as
a "short term hack"...>>

I agree with the status of the KISS TNC to be a stop-gap measure.  There is
an interesting implication, however, to the philosophy you mention:
the requirement for dedicated interface cards essentially means that
the use of a PC-Compatible as a host would become mandatory.  Even granting
the PC's status as a defacto standard, it is still desireable--in my opinion--
to be inclusive of other computers which have sufficient "horsepower" to
run the networking code (Macs, Amigas, etc.).

Of course, there's always the option to "roll your own" but that significantly
restricts access by adding a filter of technical proficiency.

I'm not arguing against the development of dedicated cards--far from it.
I think it's the best overall solution.  I sense a need, however, for a
generic, "low-cost" hardware product that would provide a machine-independent
interface using a standard interface to the host computer.  From a purely
economic standpoint, it might be hard to justify (since the cost of used
clones is approaching the cost of today's fancier interface boxes anyway)...
but when you try to sell a newcomer on ham radio, the pitch of "here's
something new you can do with your EXISTING computer" is a powerful one.
I'd hate to condemn them to the same obsolete physical/link layer suite that's
around today...

------------------------------

Date: 1 Aug 90 20:47:15 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: Multi-cast and packet radio
To: [e-mail]

In article <[e-mail]>, [e-mail]
(Charlie Ross, Jr.) writes:
|> I agree with the status of the KISS TNC to be a stop-gap measure.  There is
|> an interesting implication, however, to the philosophy you mention:
|> the requirement for dedicated interface cards essentially means that
|> the use of a PC-Compatible as a host would become mandatory.

No, this does not follow at all. Your host doesn't have to be a PC to
avoid having to use a KISS TNC. It only has to have an HDLC interface. Many
computers with more reasonable hardware architectures than the PC already
have HDLC capability; the Mac is one example.  All somebody has to do is
to write the appropriate driver.

I've stuck with the PC mainly because they are too inexpensive to
ignore.  But that doesn't mean I won't encourage others to make
effective use of NOS on whatever non-PC computer they have.

Phil

------------------------------

Date: 1 Aug 90 20:03:24 GMT
From: sdd.hp.com!samsung!umich!pmsmam![e-mail]  (Bill Meahan)
Subject: Multi-cast and packet radio
To: [e-mail]

In article <[e-mail]> [e-mail] (Charlie Ross, Jr.) writes:
>Phil, KA9Q, writes:
>
><<K3MC and I intended the KISS TNC to be a short term hack to get us
>going with TCP/IP until dedicated host interface cards were available.
>Unfortunately, in the computer field there seems to be no such thing as
>a "short term hack"...>>
>
>I agree with the status of the KISS TNC to be a stop-gap measure.  There is
>an interesting implication, however, to the philosophy you mention:
>the requirement for dedicated interface cards essentially means that
>the use of a PC-Compatible as a host would become mandatory.  Even granting
>the PC's status as a defacto standard, it is still desireable--in my opinion--
>to be inclusive of other computers which have sufficient "horsepower" to
>run the networking code (Macs, Amigas, etc.).
>
[stuff deleted]

Or what about HIGH-horsepower UNIX boxes that are not built on a PC-bus?
If I invest several $K in such a beast, I sure as h*** don't want to ALSO
have to buy an XT/clone just as an interface.
--
Bill Meahan  WA8TZG             uunet!mailrus!umich!pmsmam!wwm
I don't speak for Ford - the PR department does that!

Any attempt at wit is liable to offend _somebody_!

------------------------------

Date: 1 Aug 90 22:22:08 GMT
From: uc!shamash![e-mail]  ( VTC)
Subject: NOS for CPM
To: [e-mail]

In article <[e-mail]> [e-mail] (Antonio Querubin) writes:
>A friend of mine wants to connect a homebrew micro to an ethernet lan and was
>considering using KA9Q for the software.  He is looking for a version that will
>compile and run under CPM.  Anyone know where the source code for such a beast
>exists?
>
>AH6BW
>[e-mail]
>querubin@uhccux (BITNET)

Oh oh,  here we go again...........

This came up on the net not too long ago.   The answer was NO, and then it
was suggested that people write their own based on Phils software.  I just
bought a CPM machine and know nothing about it, nor have I even used it.  I
would be interested in getting TCP/IP running on it.  As far as I am concerned,
a Z80 beats the hell out of any 80xx CPU.  It would probably be kind of fun.

What the hell - if you want to work on TCP/IP for the C64 send me email.  It
looks like a project for a small crew of people.  Maybe we could start a
mailing list and coordinate things like that.

Jeffrey Comstock - NR0D
[e-mail]
shamash!brainiac!jrc

------------------------------

Date: 1 Aug 90 15:53:01 GMT
From: zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu![e-mail]  (Edward Vielmetti)
Subject: packet groups in Ann Arbor, MI
To: [e-mail]

In article <[e-mail]> [e-mail] (Antonio Querubin) writes:

   I will be moving to Ann Arbor, MI two weeks from now and will be staying for
   about a half year.  I am debating whether it would be worth the effort to take
   my packet equipment with me.  Could anyone near that area fill me in on the
   state of packet radio and TCP/IP activity there?

   Also looking into continued access to Internet from there so I can get my
   e-mail.  Anyone know of any kind of dial-up service in Michigan to a Telnet
   server?

TCP/IP activity is pretty good; you can dial up a local number and get
access to a piece of the internet (the Merit regional network) tho
not the whole thing.  As such there are a bunch of people running KA9Q
who aren't hams.

I'd take the gear with you, i'm pretty sure there's enough traffic here
to warrant it.

--Ed

Edward Vielmetti, U of Michigan math dept <[e-mail]>

------------------------------

Date: 1 Aug 90 18:53:26 GMT
From: usc!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu![e-mail]  (Edward Vielmetti)
Subject: packet groups in Ann Arbor, MI
To: [e-mail]

In article <[e-mail]> [e-mail] (Antonio Querubin) writes:

   I will be moving to Ann Arbor, MI two weeks from now and will be staying for
   about a half year.  I am debating whether it would be worth the effort to take
   my packet equipment with me.  Could anyone near that area fill me in on the
   state of packet radio and TCP/IP activity there?

   Also looking into continued access to Internet from there so I can get my
   e-mail.  Anyone know of any kind of dial-up service in Michigan to a Telnet
   server?

TCP/IP activity is pretty good; you can dial up a local number and get
access to a piece of the internet (the Merit regional network) tho
not the whole thing.  As such there are a bunch of people running KA9Q
who aren't hams.

I'd take the gear with you, i'm pretty sure there's enough traffic here
to warrant it.

--Ed

Edward Vielmetti, U of Michigan math dept <[e-mail]>

------------------------------

Date: 1 Aug 90 21:28:00 GMT
From: ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: what kinds of speeds are in use?
To: [e-mail]

I'd like to find out just what kinds of levels of experimentation and
usage is being done with packet radio broken down in the speed ranges.

    1200 baud
    2400 baud
    9600 baud
   19200 baud
      56 K baud
   1.544 M baud
      10 M baud

My current thoughts are to pursue 56 K baud to start out with.  It looks
more and more like a TNC based setup is not going to do me much good, so
I'm now back to looking at a PC/clone based setup with high speed modems.

--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society
<[e-mail]> | no matter what the particular issue is all about.

------------------------------

End of Packet-Radio Digest
******************************
Date: Fri,  3 Aug 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #105
To: packet-radio


Packet-Radio Digest         Fri,  3 Aug 90       Volume 90 : Issue 105

Today's Topics:
         Driving a High-Speed Modem (3 msgs)
               DRSI i/o port conflicts?
         Multi-cast and packet radio (3 msgs)
           packet groups in Ann Arbor, MI (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: Thu, 2 Aug 90 11:51:27 -0400
From: [e-mail] (Charlie Ross, Jr.)
Subject: Driving a High-Speed Modem
To: "[e-mail]"@gte.com, @KA9Q

In reply to my comment about dedicated interface cards, Phil Karn writes:

<<No, this does not follow at all. Your host doesn't have to be a PC to
avoid having to use a KISS TNC. It only has to have an HDLC interface. Many
computers with more reasonable hardware architectures than the PC already
have HDLC capability; the Mac is one example.  All somebody has to do is
to write the appropriate driver.>>

If you define the KISS TNC's functions to include providing HDLC and a modem
only, I agree with you.

Let me suggest a somewhat different perspective.  The KISS TNC today has
another function:  it provides buffering, and isolates the PC-to-TNC data rate
from that of the channel.  Given today's slow 1200-baud (or even 4800 or 9600)
system, you are right to say that there's no good reason not to move the HDLC
back into the host and dispense with all but the modem.

When you get to 56kbs and up, however, I suggest that a specialized
interface is needed.  Within the PC-compatible environment, the best
implementation is likely a dedicated DMA card, and it's no big deal to design
that card to drive the modem at the channel's data rate.  Things are more
complicated on some other machines.  Having a generic box using a "standard"
host interface could be quite useful.  What form would it take?  Ideally,
it would talk to the host using something like SCSI, running faster than
the channel (the future equivalent of hitting a KISS TNC at 9600 while running
the channel at 1200).  A less-favorable alternative would be a system which
interfaced using the PC's maximum RS-232 (or whatever) data rate, buffered the
data, and interfaced to the modem at a higher rate.  (Clearly, such a system
would not allow the user to make full use of the channel bandwidth, but we
shouldn't constrain the channel to run at the rate of the slowest PC
interface!)

Someone has to write a software driver in any event.

Please remember that I'm *not* arguing in favor of perpetuating KISS TNCs!
Far from it.  Thinking ahead, I'm concerned about how to drive a moderate-to-
high speed channel using a host other than a PC-compatible.  I particularly
wanted to mention the advantages of having a turnkey solution available for
nontechnical newcomers.  We should keep it in mind.  That's all.


Charlie Ross, NC1N

[e-mail]
[e-mail]
NC1N @ WA1PHY

------------------------------

Date: 2 Aug 90 19:02:29 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: Driving a High-Speed Modem
To: [e-mail]

For the dedicated network router/interface box approach to work, there
needs to be a standard local interface that is supported by all of the
local machines that want to use it.  Various proposals have been made,
including RS-232 and SCSI.

I argue that Ethernet is clearly the way to go here, since it is by
far the most popular local area networking standard. Unlike SCSI it is
designed specifically for networking between separate peer machines
(e.g., Ethernet isolates equipment grounds while SCSI does not) and it
can operate over much longer distances (500m without repeaters) and at
much higher speeds than RS-232. It is already available for almost
every modern personal computer. Even laptops can use Xircom
controllers plugged into their parallel printer ports.  Ethernet
boards for the PC are now down to the $100 level, and Ethernet is
already standard equipment on almost every engineering workstation
(some of which will soon start competing directly with 386 systems).

I've been urging those building the "next generation of NNCs" to incorporate
Ethernet into their designs, but so far without luck.

Phil

------------------------------

Date: 2 Aug 90 22:22:15 GMT
From: bacchus.pa.dec.com!jumbo![e-mail]  (Ed Satterthwaite)
Subject: Driving a High-Speed Modem
To: [e-mail]

Here are some more tests to help you decide between SCSI and
Ethernet.

(1) Pick up a SCSI cable and a thinwire Ethernet cable.  Which would you
rather string around your shack?

(2) Pick up a SCSI cable connecting a Mac to its disk.  Pick up another
one connecting your favorite workstation to its external disk.  Count the
number of different kinds of connectors you see.  (I got 4).  Repeat with
a pair of Ethernet cables.

(3) This one is harder to do at home, but I think it's important.
Ethernet has been around for a while.  There are very detailed standards
for almost every aspect.  While there are the usual number of slipups,
most if not all the major players work *very* hard to conform to them.

Ed n6plo

------------------------------

Date: Thu, 2 Aug 90 18:38:13 EST
From: "Mark Bramwell" <[e-mail]>
Subject: DRSI i/o port conflicts?
To: "Packet Radio Digest" <[e-mail]>

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

I recently picked up a DRSI PCPA.  I tried to install it in my 286 clone, but
it would not work ok.  I read the manual and it explains how to use debug to
check for a free i/o area.

I tried   -i 300   and should get 'FF' if free.  I do not get this.  I get the
wrong response on the various areas the manual suggests.  I have removed all
boards except the floppy drive controller.  I still get the conflict.  I have
an eprom programmer.  Before I start trying different bios chips, has anyone
came across this before.  The system board is a 4meg ram  12mhz 286 board.
The board is fairly new (less than 2 months old).  The bios has built-in
diagnostics.  I am just guessing that the 'extras' on the bios might be giving
me problems.



=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mark Bramwell, VE3PZR                Located in sunny London, Ontario

Internet: [e-mail]  IP Address: 129.100.29.33
  Packet:  VE3PZR @ VE3GYQ               UWO Phone: [phone]

------------------------------

Date: 2 Aug 90 07:01:43 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!wuarchive!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: Multi-cast and packet radio
To: [e-mail]

In article <[e-mail]> [e-mail] (Bill Meahan) writes:
>In article <[e-mail]> [e-mail] (Charlie Ross, Jr.) writes:
>>Phil, KA9Q, writes:
>>
>><<K3MC and I intended the KISS TNC to be a short term hack to get us
>>going with TCP/IP until dedicated host interface cards were available.
>>Unfortunately, in the computer field there seems to be no such thing as
>>a "short term hack"...>>
>>
>>I agree with the status of the KISS TNC to be a stop-gap measure.  There is
>>an interesting implication, however, to the philosophy you mention:
>>the requirement for dedicated interface cards essentially means that
>>the use of a PC-Compatible as a host would become mandatory.  Even granting
>>the PC's status as a defacto standard, it is still desireable--in my opinion--
>>to be inclusive of other computers which have sufficient "horsepower" to
>>run the networking code (Macs, Amigas, etc.).
>>
>[stuff deleted]
>
>Or what about HIGH-horsepower UNIX boxes that are not built on a PC-bus?
>If I invest several $K in such a beast, I sure as h*** don't want to ALSO
>have to buy an XT/clone just as an interface.

Indeed this has been a concern of mine lately. I recently bought a used
Sun at an attractive price. I thought about using a Kantronic DE56 as
a frontend for the Sun. But, since I can buy a barebones PC for $299
at the local Clone Emporium, it hardly seems worth the effort to develop
the code. The Sun already has an ethernet interface and tcp/ip so all
I need is a ethernet card for the PC and a DRSI card. Ok, this adds up
to more than a DE56, but I get ethernet speed between the machines and
no need to develop new code.

The major problem with the TNC approach as I see it is the loosely
coupled async link to the PC. This is the performance bottleneck.
Even the Z80 has no trouble keeping up with a 56k HDLC link, but
ask it to also pump a 56k async link and it dies, as does the PC.
We have to either tightly couple the PC using an internal card with DMA,
or use a smarter TNC with a buffered high speed link (ethernet) to the
host. That smarter TNC is most cost effective today as a PC with
interface card and ethernet.

We currently have a need to develop a pure switch that can be controlled
over the landline on a mountaintop. The switch must efficently switch
packets coming in on two 56k links, three 1200 baud links, and a 9600
baud link. Currently we are handling 3 1200 baud links on interrupt
per character from kiss tncs and a single 56k link using our specially
soupped up kiss56 tnc that only feeds the PC at 19.2kb, also interrupt
per character. The switch is controlled by a 2400 baud phone link to
Remote2 also interrupt per character. Not only have we run out of
spare interrupts, but we have also run out of performance. The approach
we are taking to solve this problem is to develop smart cards with
a 64180, ram buffering, and a DMA channel to the PC. This allows
interrupt per packet and greatly offloads the host. The Grace Packet
board could probably also handle our needs, but we don't have one
to experiment with yet.

One criteria for sucessful mountaintop switches is the ability to
be repaired easily, cheaply, and quickly. With lightning as a constant
threat, we don't want to have to wait weeks for a replacement part.
Using cheap commonly available PC clone parts means we don't have
to inventory expensive or hard to get parts to keep our switch running.

A nearly ideal solution to our problems would be a much smarter TNC
with HDLC and ethernet interfaces. We could dedicate a TNC to each
link and tie them together with an ethernet cable to the host doing
the actual routing. A small boot eprom in each TNC could allow them
to download their operating code from the host. This sounds vaguely
like the late lamented NNC with the SCSI chipset replaced by an
Ethernet chipset. Whether this could be developed cheaply enough
to meet our cost goals is unknown. If anyone wants to start producing
these in the $200 range, let me know.

Gary KE4ZV

------------------------------

Date: 2 Aug 90 18:51:49 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: Multi-cast and packet radio
To: [e-mail]

Looks like Gary, KE4ZV, and I think very much alike. With clone PC
hardware being so cheap and readily available, it's hard to get
excited about having to hack direct packet radio support into every
type of personal computer.

This discussion parallels one that has been going on in the regular
Internet world for some time. The consensus is that you should try to
keep host and router (gateway) functions separate. A few dedicated IP
router designs can handle the plethora of subnetwork interfaces, new
routing algorithms, congestion control schemes and network management
functions much more easily than the dozens of general purpose hosts
and operating systems that also have to support user applications.
Very few computers around here support T1 interfaces, but that doesn't
matter because we have one Cisco router that does, and all the hosts
can talk to it over Ethernet.

My only complaint about the PC/XT that I use as an IP router at home
is the noise -- it sure would be nice to find a PC that didn't require
a fan.

Phil

------------------------------

Date: 3 Aug 90 01:18:16 GMT
From: elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Multi-cast and packet radio
To: [e-mail]

In article <[e-mail]> [e-mail] (Charlie Ross, Jr.) writes:
>Phil, KA9Q, writes:
>
><<K3MC and I intended the KISS TNC to be a short term hack to get us
>going with TCP/IP until dedicated host interface cards were available.
>Unfortunately, in the computer field there seems to be no such thing as
>a "short term hack"...>>
>
>I agree with the status of the KISS TNC to be a stop-gap measure.  There is
>an interesting implication, however, to the philosophy you mention:
>the requirement for dedicated interface cards essentially means that
>the use of a PC-Compatible as a host would become mandatory.  Even granting
>the PC's status as a defacto standard, it is still desireable--in my opinion--
>to be inclusive of other computers which have sufficient "horsepower" to
>run the networking code (Macs, Amigas, etc.).
>
>Of course, there's always the option to "roll your own" but that significantly
>restricts access by adding a filter of technical proficiency.
>
>I'm not arguing against the development of dedicated cards--far from it.
>I think it's the best overall solution.  I sense a need, however, for a
>generic, "low-cost" hardware product that would provide a machine-independent
>interface using a standard interface to the host computer.

  I don't know if you caught the thread a while back regarding the issue of
a machine independent packet-assembler-disassembler. I'd suggested using a
common 'high-end' interface such as SCSI. Time permitting, I've been slowly
putting a 9600-56000 baud PAD together which talks to a parallel i/f,
initially a PS/2 parallel port (they're designed to be bi-directional),
later on a SCSI port. The design goal is a low cost PAD which people
could attach to their Macs, Amigas, Suns, RS/6000s or PCs (assuming they've
already got a SCSI controller).

   The issue of putting more smarts in a TNC could keep the current
generation of 'machine-independent TNCs viable while more permanent
solutions are developed. It also has the advantage that a single station
would have trouble hogging a channel.  Making a TNC smart enough to
pre-process packets even when running in KISS mode has some real appeal.
The changes could be made in such a manner that a user need only 'pump'
the TNC before running NET/NOS, downloading a multi-cast list and other
pre-process configuration (such as enabling digipeating of AX.25 frames).
NET/NOS would require no changes.

  We DON'T have bus attach PADs for Amigas, Suns or RS/6000s. Consider for
a moment the commercial feasibility of developing these things; how
many of each one do you think will be sold? On the other hand, a single
SCSI attach PAD would work with all of these. If you were a ham radio
dealer, what would you prefer to stock?
*****************************************************************
* Dana H. Myers KK6JQ           | Views expressed here are      *
* [phone] (ex WA6ZGB)    | mine and do not necessarily   *
* [e-mail]                | reflect those of my employer  *
*****************************************************************

------------------------------

Date: 2 Aug 90 13:52:52 GMT
From: cs.utexas.edu!samsung!umich!vela![e-mail]  (Thomas J. Hacker)
Subject: packet groups in Ann Arbor, MI
To: [e-mail]

In article <[e-mail]> [e-mail] (Edward Vielmetti) writes:
>
>In article <[e-mail]> [e-mail] (Antonio Querubin) writes:
>
>   I will be moving to Ann Arbor, MI two weeks from now and will be staying for
>   about a half year.  I am debating whether it would be worth the effort to take
>   my packet equipment with me.  Could anyone near that area fill me in on the
>   state of packet radio and TCP/IP activity there?
>


You might also send mail to Manfred Prange (uunet!umich!vela!cetus!prange
I think) or Steve Grevemeyer ([e-mail]).  They're
both into computers and Ham radio pretty heavily.  I think there is some
packet radio going on around here, but they would know better.


-Tom


--
Thomas Hacker         "Criticism is something we can avoid easily - by saying
Systems Programmer     nothing, doing nothing, and being nothing"  - Aristotle
Oakland University, Rochester Mich                  [phone]
[e-mail] HACKER@OAKLAND uunet!umich!vela!hacker

------------------------------

Date: 2 Aug 90 16:58:24 GMT
From: cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!spsd3260a.erim.org![e-mail]  (Steve Hideg (Mr. Fabulous))
Subject: packet groups in Ann Arbor, MI
To: [e-mail]

In southeastern Michigan, there is much activiy on 145.03 (humans and
personal BBSs), 145.05 (BBSs), 145.09 (BBSs, nodes, and the MEPN--the
Michigan Emergency Packet Network).

I suggest you get on 03 or 09 and monitor for a while.

--Steve

____________________________________
Steve Hideg (N8HSC)

[e-mail]

------------------------------

End of Packet-Radio Digest
******************************
Date: Sat,  4 Aug 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #106
To: packet-radio


Packet-Radio Digest         Sat,  4 Aug 90       Volume 90 : Issue 106

Today's Topics:
         Driving a High-Speed Modem (6 msgs)
                 NOS for CPM
               PC/XT as router (2 msgs)
            pk-232 recommendations

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: Fri, 3 Aug 90 12:06:53 -0400
From: [e-mail] (Charlie Ross, Jr.)
Subject: Driving a High-Speed Modem
To: "[e-mail]"@gte.com, @KA9Q

To avoid flames that I'm thinking only of myself, let me say up front
that, although I'm currently running tcp/ip on a Mac, I *do* intend to get a
PC-compatible sometime in the next year or so and dedicate it as
my communications controller.  I'm motivated in this discussion *not*
from self-interest, but from my experience working with the Boston Computer
Society ham group, where we are working with newcomers who want to use their
existing PCs.  I repeat, I don't want to condemn them to the obsolete
layer 1/2 suite available in today's TNCs.

OK, into the meat:

Phil, KA9Q, writes:

<<I argue that Ethernet is clearly the way to go here, since it is by
far the most popular local area networking standard. Unlike SCSI it is
designed specifically for networking between separate peer machines...
It is already available for almost
every modern personal computer. Even laptops can use Xircom
controllers plugged into their parallel printer ports.  Ethernet
boards for the PC are now down to the $100 level...>>

Ethernet would be my choice, too, if it were as universally available as
you say.  However, Ethernet for the Mac is very expensive, particularly
if you're dealing with a compact Mac (the majority of home Mac users)
where you need a SCSI<->Ethernet converter.  $700-$1000 if memory serves
me correctly.  The other popular machine we run into is the Amiga.  I must
profess to know virtually nothing about the Amiga and I'd be interested in
any "net wisdom" on whether Ethernet is easily available for it.

N6PLO's posting also favored Ethernet on technical grounds.  I have to agree--
if you base the decision on technical issues only.  But cost?...

Back to Phil:

<<Looks like Gary, KE4ZV, and I think very much alike. With clone PC
hardware being so cheap and readily available, it's hard to get
excited about having to hack direct packet radio support into every
type of personal computer.>>

I can easily understand this, especially seeing it from your point
of view.  I wouldn't get excited either!  As I've said, my cut on the issue is
from doing "missionary" work into the world of non-ham computer users.  The
last thing that a passionate, "The Macintosh is my religion and IBM PCs are
worthless junk for any application whatsoever" type wants to hear is that
he/she should buy a clone.  (Actually, I toned down the typical wording a
bit...  :-)  )  You have to remember, people aren't always rational about such
things.

Dana, KK6JQ, writes:

<<Time permitting, I've been slowly putting a 9600-56000 baud PAD together
which talks to a parallel i/f, initially a PS/2 parallel port (they're designed
to be bi-directional), later on a SCSI port. The design goal is a low cost PAD
which people could attach to their Macs, Amigas, Suns, RS/6000s or PCs
(assuming they've already got a SCSI controller). >>

That's exactly the kind of thing I'm thinking about.  KK6JQ again:

<<The issue of putting more smarts in a TNC could keep the current
generation of 'machine-independent TNCs viable while more permanent
solutions are developed. It also has the advantage that a single station
would have trouble hogging a channel.  Making a TNC smart enough to pre-process
packets even when running in KISS mode has some real appeal.>>

It's necessary if (a) the host interface runs slower than the network, and
(b) the channel is TDMA/shared.  If we evolve toward point-to-point service,
the only real advantage of smarts in the "TNC" is to offload processing tasks
from the PC.  On a point-to-point channel, throughput will be determined
by the slowest link in the system, regardless of channel signalling rate.

Along this line, perhaps we just need a "NOS-in-a-Box" Data Engine
(or equivalent) that brings a fully-implemented protocol suite in hardware.
Because of Bdale's and others' work, this is nearly a reality today.  N6GN has
also discussed the desirability of a hardware packaging that includes at least
level 3.  So maybe that's the turnkey solution we offer newcomers.  Keep the
"TNC" mentality alive for those who want it.  Those of us who want greater
flexibility/performance go the route of dedicated clones and keep the "smarts"
in the PC.

Charlie Ross, NC1N
[e-mail]
[e-mail]
NC1N @ WA1PHY

------------------------------

Date: 3 Aug 90 15:25:44 GMT
From: usc!snorkelwacker!spdcc!merk!alliant!linus!linus!luke.mitre.org![e-mail]  (Douglas S. Rand)
Subject: Driving a High-Speed Modem
To: [e-mail]

In article <[e-mail]>,
[e-mail] (Phil R. Karn) writes:
|>
|>For the dedicated network router/interface box approach to work, there
|>needs to be a standard local interface that is supported by all of the
|>local machines that want to use it.  Various proposals have been made,
|>including RS-232 and SCSI.
|>
|>I argue that Ethernet is clearly the way to go here, since it is by
|>far the most popular local area networking standard. Unlike SCSI it is
|>designed specifically for networking between separate peer machines
|>(e.g., Ethernet isolates equipment grounds while SCSI does not) and it
|>can operate over much longer distances (500m without repeaters) and at
|>much higher speeds than RS-232. It is already available for almost
|>every modern personal computer. Even laptops can use Xircom
|>controllers plugged into their parallel printer ports.  Ethernet
|>boards for the PC are now down to the $100 level, and Ethernet is
|>already standard equipment on almost every engineering workstation
|>(some of which will soon start competing directly with 386 systems).
|>
|>I've been urging those building the "next generation of NNCs" to incorporate
|>Ethernet into their designs, but so far without luck.
|>
|>Phil


A second argument in favor of Phil's claim about ethernet.  You can
even get a SCSI based ethernet gateway for your Mac -- kind of the
best of both worlds if you have a Mac Plus like me.

Douglas S. Rand
Internet:   <[e-mail]>
Snail:      MITRE, Burlington Road, Bedford, MA
Disclaimer: MITRE might agree with me - then again...
Amateur Radio: KC1KJ

------------------------------

Date: 3 Aug 90 21:30:56 GMT
From: ameristar![e-mail]  (Rick Spanbauer)
Subject: Driving a High-Speed Modem
To: [e-mail]

In article <[e-mail]> [e-mail] (Charlie Ross, Jr.) writes:
>me correctly.  The other popular machine we run into is the Amiga.  I must
>profess to know virtually nothing about the Amiga and I'd be interested in
>any "net wisdom" on whether Ethernet is easily available for it.

    Ethernet is available for the Amiga 2000/2500/3000 from Commodore.  The
    cost is about $350 retail w/o software.  Educational users can do
    much better than retail pricing.  There are also third party ethernet
    boards for the Amiga available for similar cost.

    My $0.02 on this subject is to agree that ethernet is probably the
    port of choice for new TNC's, so long as a "fast" serial port is
    also provided for people who want it.  Something like LocalTalk
    (@ 230.4 kBps) would also be attractive, but this can be done as
    part of the "fast" serial port almost for free.  Note that LocalTalk
    using phonenet is particularly easy to use & install.

>Charlie Ross, NC1N

                    Rick Spanbauer, WB2CFV

------------------------------

Date: 3 Aug 90 23:17:16 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: Driving a High-Speed Modem
To: [e-mail]

In article <[e-mail]>, [e-mail]
(Charlie Ross, Jr.) writes:
|> However, Ethernet for the Mac is very expensive, particularly
|> if you're dealing with a compact Mac (the majority of home Mac users)
|> where you need a SCSI<->Ethernet converter.

EVERYTHING for the Mac is very expensive. That's why I don't own one.
It's nice to borrow one once in a while when I need to run off some
viewgraphs (it's a toaster that makes pretty pictures) but for serious
hardware and software hacking I'll stick with open, commodity hardware
like PC clones. And with Microsoft Windows I expect that even die-hard
Mac users will discover that there are alternatives.

Having said that, I still don't know why we're having an argument. I
may not like the Mac, but I'm not stopping anybody else from buying
one.  Nor will I stop anyone who wants to build a network controller
with a SCSI interface.  Just don't argue that I should be the one to
do the work.

BTW, there's another alternative for Mac users: Localtalk. Localtalk
adaptor cards are available for the PC, and if someone would like to
contribute a localtalk driver for NOS, I would be happy to accept it.

Phil

------------------------------

Date: 3 Aug 90 22:43:00 GMT
From: sdd.hp.com!samsung!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: Driving a High-Speed Modem
To: [e-mail]

> Ethernet would be my choice, too, if it were as universally available as
> you say.  However, Ethernet for the Mac is very expensive, particularly
> if you're dealing with a compact Mac (the majority of home Mac users)
> where you need a SCSI<->Ethernet converter.  $700-$1000 if memory serves
> me correctly.  The other popular machine we run into is the Amiga.  I must
> profess to know virtually nothing about the Amiga and I'd be interested in
> any "net wisdom" on whether Ethernet is easily available for it.
>
> N6PLO's posting also favored Ethernet on technical grounds.  I have to agree-
> if you base the decision on technical issues only.  But cost?...

Cost.... that is LONGTERM COST, was my original reason for not going with the
Mac.  Seeing ethernet at the $100-200 range for a PC/clone vs. $700 for a Mac,
I believe the decision to avoid Mac was correct on this basis.  Mac owners
are big losers when it comes to finding attachment hardware from a very
competitive market.  If Apple had licensed second sourcing for their machine,
the Mac today might have been leading in units sold.

The Mac has its place.  Pushing data through a network cheaply is NOT what a
Mac is for.

> I can easily understand this, especially seeing it from your point
> of view.  I wouldn't get excited either!  As I've said, my cut on the issue i
> from doing "missionary" work into the world of non-ham computer users.  The
> last thing that a passionate, "The Macintosh is my religion and IBM PCs are
> worthless junk for any application whatsoever" type wants to hear is that
> he/she should buy a clone.  (Actually, I toned down the typical wording a
> bit...  :-)  )  You have to remember, people aren't always rational about suc
> things.

This is (one reason) why a PC bus based board is not in big time running.
Designing a modem with at least part of its functionality, if not all of
it, on a add-on clone board, would not be that hard to do.  Then you would
REALLY see the Mac/Amiga/Atari/etc owners fuss/cuss/whine.

> Along this line, perhaps we just need a "NOS-in-a-Box" Data Engine
> (or equivalent) that brings a fully-implemented protocol suite in hardware.
> Because of Bdale's and others' work, this is nearly a reality today.  N6GN ha
> also discussed the desirability of a hardware packaging that includes at leas
> level 3.  So maybe that's the turnkey solution we offer newcomers.  Keep the
> "TNC" mentality alive for those who want it.  Those of us who want greater
> flexibility/performance go the route of dedicated clones and keep the "smarts
> in the PC.

Take a PC, install NOS, trim off the fat --> TNC.  Maybe the Kantronics
DataEngine might do this.

But there is still the issue of how to connect this "TNC" to the host and
get the maximum data throughput.  Serial ports just don't cut it, parallel
ports often are not implemented right, and we may be back to ethernet again.

While we don't need more than 1200 baud for typing back and forth between
people, we do need the higher speeds for many other things, such as FTP,
X-windows, and RVR (Radio Virtual Reality).  At work we use ethernet between
hosts here, and I've already found it to be speed limiting, though adequate.
Consider the concept of linking voice repeaters via packet radio.  Serial
ports are just not going to handle it.

--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society
<[e-mail]> | no matter what the particular issue is all about.

------------------------------

Date: 4 Aug 90 06:59:46 GMT
From: sgi![e-mail]  (Rob Warnock)
Subject: Driving a High-Speed Modem
To: [e-mail]

In article <[e-mail]>
[e-mail] writes:
+---------------
| I've been urging those building the "next generation of NNCs" to incorporate
| Ethernet into their designs, but so far without luck.  | Phil
+---------------

Here, here! Ethernet *is* a bus! And it's a machine-independent one. And you
only have to have one slot on your PC/Amiga/Mac/Sun/DEC/SGI/<whatever> no
matter how many things you plug into the "bus". [SCSI = 8, including you.]
And it's inherently a "multi-master" bus. [Some SCSI interfaces still don't
truly support full multi-master disconnect/reconnect SCSI.] And it's fast
enough that we can put this question to bed for some time.

And if we ever *do* need more than 10 Mb/s between our hosts and our
packet-radio modems, FDDI may be cheap enough by then...  ;-}  ;-}


-Rob

-----
Rob Warnock, MS-9U/510          [e-mail]            [e-mail]
Silicon Graphics, Inc.          [phone]           Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

------------------------------

Date: 3 Aug 90 22:36:02 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: NOS for CPM
To: [e-mail]

>A friend of mine wants to connect a homebrew micro to an ethernet lan and was
>considering using KA9Q for the software.  He is looking for a version that will
>compile and run under CPM.  Anyone know where the source code for such a beast
>exists?

It doesn't.  Your friend is more than welcome to grab the source and try to
make it work, but I warn you/him that the current executable under DOS, with
a code density about twice that of a Z80, is well over 200k... it'll be a
tight squeeze, at best.

Bdale

------------------------------

Date: Fri, 3 Aug 90 12:28:45 -0400
From: [e-mail] (Charlie Ross, Jr.)
Subject: PC/XT as router
To: @KA9Q, "[e-mail]"@gte.com

Phil,

In the thread on pc-to-modem interfaces, you wrote:

<<My only complaint about the PC/XT that I use as an IP router at home
is the noise -- it sure would be nice to find a PC that didn't require
a fan.>>

If you've got a minute, a paragraph on how you're configured there...
what the PC interfaces to, data rates, and how loaded the CPU is...
would be interesting.

TNX,
Charlie
[e-mail]
[e-mail]
NC1N @ WA1PHY

------------------------------

Date: 3 Aug 90 23:52:59 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: PC/XT as router
To: [e-mail]

In article <[e-mail]>, [e-mail]
(Charlie Ross, Jr.) writes:
|> If you've got a minute, a paragraph on how you're configured there...
|> what the PC interfaces to, data rates, and how loaded the CPU is...
|> would be interesting.

There's not much to it. The machine is a 3-4 year old PC/XT "turbo"
clone with a V-20 chip. (The chips on the motherboard are all socketed
- that tells you something about how old it is.) Plugged into it are
four boards:

1. A 3Com 3C503 Ethernet controller. (Previously this was a TRW
PC-2000 Ethernet card. It worked fine, but the 3Com card draws much
less power.)

2. A 4 year old no-name "multi I/O" card of Taiwanese origin. This
card has a floppy controller, two serial ports, a parallel port, a
game interface and a clock/calendar. The floppy controller is
connected to a single DSDD (360K) 5 1/4" floppy used for booting. The
serial ports have had their 8250 chips replaced with National NS16550A
chips (fortunately this board also sockets its chips, so this was
easy.) The parallel and game ports are unused.

3. A monochrome display adaptor.

4. A modified "eagle" 8530 interface card (similar to a DRSI PCPA card).

The ethernet controller is connected to my house Ethernet. Also on
this net is my 386 NOS development system and an old Sun3/75
workstation on which I do Bellcore work. A Dell laptop is also
occasionally connected to this Ethernet.

One serial port on the XT is presently connected to a 9600 bps V.32
modem that is kept dialed up into a SLIP-mode port on an Annex
terminal server/gateway back at Bellcore. The Eagle card had been
connected to my WA4DSY modem, but I have temporarily disconnected it
so that I could use the XT as a SLIP gateway. (The Sun had been doing
the SLIP gateway function but I moved SLIP off the Sun when I
"upgraded" it to SunOS 4.1).

Proxy ARP and IP routing entries are installed on the Annex box so
that I can reach the entire Internet from a system on my home Ethernet
as easily as from work (except for the lower data rate, of course.)

At the moment I can't handle both the SLIP and 56kb functions on the
same machine because my "hs" driver for the latter would freeze the
machine whenever the 56k modem is busy, and that would cause SLIP
characters to be lost. I will get around this in one of two ways:
modifying the Eagle board to operate in DMA mode, or using a Grace
Communications PackeTen card to handle the 56k modem.

The XT boots and starts up NOS automatically whenever it is powered
on.  The modem is currently dialed manually, but I will probably add a
software dialer routine to NOS soon. Using LZEXE on net.exe has
greatly alleviated a space crunch I had on the 360K floppy.  Now it
has plenty of room for MS-DOS, a packet driver, config files, a copy
of MicroEmacs for local maintenance, etc.

I could strip the machine down even further if I wanted (it will boot
and run just fine without a keyboard or display adaptor) but having them
attached is useful for monitoring what's going on (or for doing a quick
telnet session when my other machines are off).

My problems/complaints are as follows:

1. The XT is pretty old technology, and it is rather power hungry for
such a small system. Upgrading to a newer set of boards with LSI chips
replacing old LS TTL would reduce the load on my UPS. And with the
incremental summer electric rate here now at $.13/kw-hr, every little
bit helps when you run something 24 hours/day.

BTW, it seems like every chip Intel makes is a power hog.  The hottest
chips on the motherboard are all made by Intel. The main power hog on
the TRW PC-2000 I had been using was the Intel 82586 Ethernet
controller, which ran too hot to touch. The board drew 1.73A at 5V,
with that one chip drawing half an amp! The National chip used on
almost all of the newer Ethernet boards draws only 40 mA. The 3C503
draws only 390 mA.

2. The V-20 is pretty slow. It is actually reasonably fast at
switching packets between the Ethernet and SLIP link, but when used as
a local terminal it updates the screen more slowly than I'd like.

3. The XT has a noisy fan. I tried turning it off while watching the
temperature of the power supply's internal heatsink with an electronic
thermometer. It rose to 50C so I decided not to risk it. Possibly a
newer system would draw sufficiently less power that I could safely
disable the fan in its power supply.

4. My multi-I/O card's serial ports go deaf occasionally. Based on
comments from others with the same board, this is almost certainly the
fault of a design problem on the board. Newer serial boards have given
me no trouble.

In sum, most of the problems I've run into with this system would be
avoided by simply buying newer boards. There's still the need for a
standard, well supported DMA-driven HDLC interface card to handle high
speed radio modems along with SLIP links. That's being worked on.

Phil

------------------------------

Date: 3 Aug 90 18:58:22 GMT
From: sdd.hp.com!uakari.primate.wisc.edu!samsung!umich!csd4330a!newsserv![e-mail]  (Ron Majewski)
Subject: pk-232 recommendations
To: [e-mail]

I am interested in purchasing an all-mode controller for
primarily HF use (my focus would be packet, but I'd like to
copy and try other modes too).

Based on specs, the AEA pk-232mbx looks like a pretty good unit, but
I'd like to hear from other netlanders as to their experiences -- both
good and bad -- with the 232.

Please e-mail to me direct.  Thanks and 73!


Ron (wb8ruq).
--

Ron Majewski                 The Environmental Research Institute of Michigan

[e-mail]

------------------------------

End of Packet-Radio Digest
******************************
Date: Sun,  5 Aug 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #107
To: packet-radio


Packet-Radio Digest         Sun,  5 Aug 90       Volume 90 : Issue 107

Today's Topics:
               Ethernet TNCs? (3 msgs)
           Request for help with HF packet

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 4 Aug 90 12:11:55 GMT
From: nuchat!splut![e-mail]  (Jay "you ignorant splut!" Maynard)
Subject: Ethernet TNCs?
To: [e-mail]

Just how hard is it to build an Ethernet interface into a dedicated box,
anyway? Is it simplicity itself, or does it take wailing and gnashing of
teeth?

For that matter, we could get there by adding an Ethernet interface to
something like the Kantronics Data Engine...

Also, are we talking about stringing RG-62, or whatever the coax used
is, or are we talking about stringing transceiver cables (which are a
bit thicker)? Does it make a big difference?

I suppose I'm going to have to learn about Ethernet fairly soon, since
the Tower has an Ethernet board in it (but the only connection on the
back is a transceiver port - is there a thinwire transceiver I can
get?); the only LAN I'm familiar with is ARCNET.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
[e-mail]       (eieio)| adequately be explained by stupidity.
"It's a hardware bug!" "It's a      +----------------------------------------
software bug!" "It's two...two...two bugs in one!" - _Engineer's Rap_

------------------------------

Date: 4 Aug 90 17:02:51 GMT
From: [e-mail]  (Brian Kantor)
Subject: Ethernet TNCs?
To: [e-mail]

Thin Ethernet is RG58, same as non-foam in-the-shack ham coax.

RG58 runs under the rug quite nicely, and as long as you aren't wearing
sharp pointy heels, you won't hurt it by walking on it.

Crimp-on 'commercial' BNC connectors are cheap and real easy to put on.

You can get really nice thinnet transceivers from Cabletron and lots of
other people, and I've seen them around $150 or so.
    - Brian

------------------------------

Date: 4 Aug 90 19:12:20 GMT
From: bacchus.pa.dec.com!jumbo![e-mail]  (Ed Satterthwaite)
Subject: Ethernet TNCs?
To: [e-mail]

In article <0_1&K&@splut.conmicro.com>, [e-mail] (Jay "you ignorant splut!" Maynard) writes:
>
> Just how hard is it to build an Ethernet interface into a dedicated box,
> anyway? Is it simplicity itself, or does it take wailing and gnashing of
> teeth?
>

I'm assuming you mean a dedicated box with some other ports and a micro to
serve as protocol engine or whatever.  If you only want a cable
transceiver (aka Medium Attachment Unit or MAU), just buy it.

In my opinion, the difficulty is somewhere in between.  With the currently
available chip sets, the logic design is pretty easy.  There really aren't
very many degrees of freedom between the uP bus interface and the coax;
the chip manufacturers publish application notes that recommend specific
isolation transformers, etc.  Some of the new chips integrate most of the
bus interface as well.  For example, one of the SEEQ parts has a pin to
tell it whether it's talking to an Intel or Motorola bus, and it
configures itself accordingly.

Most of the application notes also give sample designs for the popular
buses.  National, for example, has a range of application notes for the
popular 839x chip set ranging from a simple 8-bit polled port to PS/2 and
NuBus DMA.  Most of these appear to be adequate but leave some room for a
designer to "add value."

What's still a bit tricky is the layout and packaging, although there are
usually guidelines for this as well.  A multilayer board with power and
ground planes is pretty much mandatory.  Unfortunately for AR, such boards
are fairly expensive, especially in small quantities.  Some CAD packages
also are not very good at routing critical nets in the way you'd like.

Another issue is EMI.  I think Phil Karn posted some of his war stories
here a while back.  One recommended technique uses surface-mount
decoupling capacitors (for low lead inductance) rated at 1000 WVDC (to
meet isolation requirements).  You don't find these at Radio Shack. Or
very many other places either.  Putting everything into a dedicated box
under your own control helps some.

> Also, are we talking about stringing RG-62, or whatever the coax used
> is, or are we talking about stringing transceiver cables (which are a
> bit thicker)? Does it make a big difference?

For thin-wire Ethernet (aka 10BASE2 or Cheapernet), RG58A with BNC
connectors is standard, although I've seen other types of thin 50 ohm coax
used as well (variations in flame resistance and the like, I think).  For
AR applications, I favor this over 10BASE5 with the thick coax and the
separate transceivers.  On the other hand, the n6gn/n6rce 10 GHz bit pumps
use the same 15-pin interface as an Ethernet MAU.

Ed n6plo
[e-mail]  {...}!decwrl!ehs

------------------------------

Date: 4 Aug 90 07:22:45 GMT
From: ub![e-mail]  (darrin b jewell)
Subject: Request for help with HF packet
To: [e-mail]

Greetings and salutations...

   I decided to jump into the world of packet radio...
yesterday... the thought hit me that perhaps i could connect my modem
directly to the radio for a packet station...

so...i looked some stuff up and discovered that...
  my modem...at hayes compatable 2400 baud modem...runs bell 103 when
using 300 baud...according to my 1988 ARRL Handbook...and any articles i
could get my hands on...this is the mode used on hf packet...
so...after playing with my rig...and my modem commands...i managed to get
my modem to accept signals from the radio... but i am not getting anything
legible...so...here's some questions...

     0.  Is this realistically feasable...?

     1.  Has anyone tried this...or know of anyone who has...?

     2.  What parity, stop bits, etc...are used...?

     3.  I am having a lot of trouble with noise...as just about any noise
          coming from the audio of my rig will show up as characters on
          the screen...

     4.  Which tone pairs are used?
        originate: 1070 space/1270 mark...
        answer :   2025 space/2225 mark...
        and is the 200 Hz shift correct...
        ...although bell 103 is duplex...i should be able to receive
        something on one of the sets of tones....
        ...all it means is that i will have to change originate/answer
        mode if/when...i get around to tranmitting anything...
        because all packet transmissons are made on the same
        set of tones (not duplex)...


      5.  anyone have any ideas that could help?


   i never touched packet before yesterday...but i've read some...and i've
 seen it in operation...but being involved in ham radio...and being
 fluent with computers...i really ought to get involved in packet...
 but...at the immediate moment ...i don't really want to spend even a
 little money on a tnc...( which would make life many times easier...)...
  ...but hey...experimentation is what ham radio is for right??>...

        ...well maybe...

    anyway...

      i'd appreciate any help/thoughts/suggestions/ideas/experiences/etc...
  that i could use...


           thanks a lot...

            -darrin   KA2ZLZ

........................................................................
this message brought to you by the hypocritical cynic...

    HAVE A DAY

    Home address: (where i live...and where mail goes...
            ...send some...i appreciate mail...)

       Darrin B. Jewell       +-------------------------------------+
       8 Thomaston Lane       | at the State University of New York |
       Orchard Park, NY       |             at Buffalo              |
       USA   14127-2526       +-------------------------------------+

    e-mail addresses:

    [e-mail] /* this account is liable to be closed */
     [e-mail]       /* use this e-mail address first.      */

------------------------------

End of Packet-Radio Digest
******************************
Date: Mon,  6 Aug 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V1 #108
To: packet-radio


Packet-Radio Digest         Mon,  6 Aug 90       Volume 90 : Issue 108

Today's Topics:
             Transputers in packet-radio

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: Sun, 5 Aug 90 20:32 GMT+1
From: Andy Bakkers <[e-mail]>
Subject: Transputers in packet-radio
To: [e-mail]

THE USE OF TRANSPUTERS IN THE NEXT GENERATION PACKET RADIO HARDWARE

Andre P. Bakkers PA0APA,
PI4THT E.T.G.D. Club Station,
Dept. of Electrical Engineering,
University of Twente,
P.O. Box 217,
7500 AE Enschede, Netherlands,
e-mail: elbscbks @ utwente.nl


1       INTRODUCTION

Traditional microprocessors have to be programmed from scratch. Every
processor requires some kind of an operating system to let you execute a
program. Multi tasking will require again a different operating system and
non of this stuff is standard. Oh I am sorry you want to call Unix a
standard. Go ahead! Now there is this new chip the transputer, it handles
processes instead of assembler instructions. It has a built-in "on chip" round
robin scheduler. Typical time slices are 1 milliseconds and a context
switch (process switch) takes 1 micro second. Oh I forgot HAMS always want
to know the price. A PC plug-in board is $236 without memory. Interested?
Read on!


2       THE TRANSPUTER AND OCCAM

One way out of the traditional computing requirements has has long been
sought in the use of parallel computing. In the past, many attempts to
realize parallel systems with traditional processors have failed due to the
software overhead. This is why the interfaces all require special
hardware or busses, e.g. ethernet, SCSI you name it.

Here is a new concept of communication between processors and processes.
Communication between processors and processes is done by means of
channels. Due to the synchronization properties of these channels, the
restriction to one processor no longer exists. The transputer hardware and
companion Occam software development has implemented this concept. By using
a formal specification language, the correct behavior of the implementation
of the Occam constructs in hardware was formally proven. The
hardware-software integration resulted in the transputer-Occam combination.
The transputer may be considered as a building block for parallel
computers. Occam enables programming across these parallel transputers. In
the following paragraphs the operation of the transputer will be explained,
based on the following list of major characteristics. From this list a
number of significant elements of the transputer chip can be identified.

The following elements have been integrated as one micro computer chip.

1. Communication to other transputers is performed over four
   self-synchronizing, high speed (20 Mbit/sec), DMA driven, bi-directional,
   serial links.
2. A round-robin process (task) scheduler is implemented in micro-code
   realizing a process switching time of 1 microsecond.
3. A floating point processor realizing 1.5 Megaflops.
4. A built-in timer with an accuracy of 1 microseconds in high priority mode
   or 64 microseconds in the low priority mode.
5. Fast (50 nano-seconds) internal memory of 4 Kbyte.
6. A 32 bit 10 MIPS CPU.

2.1  The Occam process

The underlying idea of Occam is the notion of a process. A process is a
part of a program that starts, performs an action and then terminates. The
idea is that processes may be executed in parallel. The communication
between processes is done via self-synchronizing channels. A channel is a
one way point-to-point connection from one process to another. The
processes may be located on different transputers. In that case the
communication over channels changes into communication over links. There is
no need for the programmer to worry about the implementation of the channel
or link protocol because it is implemented in micro-code on the transputer
chip.

Examples of so-called primitive processes in Occam are:

    x := 3          assigns the value of three to the variable x

    channel1 ? p    takes a value from an input channel1 and puts it in p

    channel2 ! q    takes the value of q and outputs it over the channel2


An Occam program consists of combinations of primitive processes so that a
number of these primitive processes may be combined into a larger
construction. For this purpose Occam supports the following constructs:

    SEQ             To indicate the start of a series of sequential
      process1      processes.
      process2

    PAR             To indicate the start of a series of parallel
      process1      processes.
      process2

Note that the indentation under the SEQ and PAR constructs are syntactic
and are used to indicate the begin and end of the construct.

2.2  Links and Channels

In Occam communication via links looks as follows:

    In transputer A                         In transputer B
    we have the code:                       we have the code:
                  communication
    Link.2 ? var.y     <-----------------   Link.2 ! var.b
                via Link.2

The input ? and the output ! processes may be considered as the
synchronization between processes running on transputers A and B. If the
process on transputer-A arrives at the input instruction on Link.2 and
transputer-B is not yet ready to provide its output on Link.2, the process
running on transputer-A will be de-scheduled until transputer-B signals
that it is ready to send the data over Link.2. At that point the inputting
process on transputer-A is resumed and the data is transferred via Link.2.
This results in a synchronizing action between the processes running on
different transputers. In this way the transputer links provide the
necessary system interconnection and synchronization. The only thing the
programmer has to do is to define the appropriate input and output actions.

Identical to the link concept, the channel concept is used to communicate
between processes located on the same transputer as illustrated below.

    In process A                            In process B
    we have the code:                       we have the code:
                  communication
    Chan.1 ? var.x     ----------------->   Chan.1 ? var.a
                via Chan.1

This unifying link/channel concept is very convenient during the system
design and check-out phase. Different hardware and software layers can be
developed independently as long as the software and hardware interface
format has been defined.

Inside the transputer the channel/link administration is kept in one memory
word. This memory word will contain the most negative value to indicate
that the channel has not yet been called, or a value that is interpreted as
a workspace pointer of a (de-scheduled) process. The transputer channels
may therefore be considered as a standard system interface because they
provide the necessary system interconnection and synchronization.


2.3  Interrupts

The transputer has an interrupt signal pin connected to the event channel.
This event channel is read identically to a link, although no data can be
transferred. It can only be used to activate a process that is waiting on
an input ? from the event channel. As soon as the event channel is
activated, the waiting process is scheduled by inserting it at the back of
the ready queue in the low priority mode, or it may be scheduled at once as
a high priority process. The use of the transputer interrupt signal is
illustrated in the following Occam interrupt process that is activated
every time the event pin is triggered. The program starts with the
definition of the process name with the external channel definition. The
internal event channel is declared as the type ANY because there is no data
transport over the event channel. This event channel is associated with the
actual hardware pin. This is illustrated in the following program.


        PROC interrupt (CHAN OF INT16 output)
          CHAN  OF  ANY event:
          PLACE event AT event..in:
          WHILE TRUE                 <<< Do forever loop!
            SEQ                      <<< Start sequential process
              event ? any            <<< Wait for interrupt
              ....execute handler code

        :                            <<< Occam terminator of a process


The transputer has one high-priority and one low-priority operating mode.
The interrupt process should preferably be executed in the high priority
mode in order to reduce the interrupt response time.

2.4  The Timer

The timer channel should also be considered an input channel. Times of the
internal running clock are obtained by reading the timer channel and
operating on the time value. The Occam code to use the timer is illustrated
with the following SEQuential process that causes a delay:


        PROC delay (VAL INT interval)
          TIMER clock:
          INT time:
            SEQ
              clock ? time
              clock ? AFTER time PLUS interval
        :


Internally the timer queue differs from the ready queue in that it is kept
sorted in the  sequence of the wake up times of the different timed
processes.


2.5  The Scheduler

In addition to the channel protocol concept, there is another important
difference between transputers and other microprocessors. That is the
built-in scheduler. The transputer should be considered as handling tasks
or processes rather than machine instructions. These processes are
controlled by a built-in scheduler. The process administration is the main
activity of the scheduler. The scheduler keeps track of the different
processes by keeping a list of processes in an area of memory that is
called the workspace. The workspace of the current process is pointed to by
the transputer register called workspace pointer. The workspaces are linked
together to form a queue. The scheduler keeps track of four queues, i.e.
for each priority a ready queue and a timer queue. The beginning and end
pointer to a queue are maintained in the transputer registers called Front
pointer and Back pointer. Workspaces are added to the ready queue by
reference to the back pointer and workspaces are extracted by reference to
the front pointer.


2.5.1  High-priority mode

The process (or task) scheduler can operate in one of two modes, i.e. the
high-priority or the low-priority mode. In the high-priority mode the
executing process cannot be interrupted by another process (non-preemptive
scheduling). De-scheduling can only occur when:

    o   a process is completed
    o   communication with a channel/link is not (yet) possible
    o   the process waits for a timer to elapse


2.5.2  Low-priority mode

In the low-priority mode the processes are, by means of time-slicing,
scheduled in a round-robin manner. Here processes will be de-scheduled by:

    o   completion of the process
    o   awaiting link or channel communication
    o   expiration of a time slice
    o   a high-priority process becoming ready

The de-scheduled process will be added to the back of the ready queue and
the process from the front of the ready queue will be executed. The time
slice in a transputer is typically 1 msec. and the process switching time
is of the order of 1 microsecond. In Occam the priority may be assigned
using a PRIority addition to the PAR construct.


Without priority:                       With priority:

    PAR                                     PRI PAR
      process.1                               process.1
      process.2                               process.2


The processes 1 and 2 are executed in parallel, either both at the same
priority, or with the PRI PAR:  process 1 will be executed in high priority
and process 2 in low priority. The PAR process is only finished after both
processes have been executed.


3   THE BASIC BUILDING BLOCK METHOD

A systematic way to introduce parallelism is to start with very small
processes and build a system with these elementary processes. This approach
is similar to methods used in past in analog computers. The internal scheduler
on the transputer will realize parallelism while running these processes.
As an example I like to mention the realization of a control program with
the use of only five basic elements. The basic elements in this system
were:

    a splitter block:               tee
    a gain block:                   gain
    a summer block:                 sum
    a minus block:                  min
    an integrator block:            int

Let's first define these basic elements and then look at the controller
program using these basic elements.


    PROC tee (CHAN OF REAL32 in, out0, out1)
      REAL32 x :
      WHILE TRUE
        SEQ                                         /|
        in ? x                              in ---/  |----out0
        PAR                                       \  |----out1
          out0 ! x                                  \|
          out1 ! x
    :

    PROC gain (CHAN OF REAL32 in, out, init)
      REAL32 x,k :
      SEQ
        init ? k                                   |-------|
        WHILE TRUE                          in  ---| gain  |--- out
        PRI ALT                                    |       |
          init ? k                                 |---|---|
        SKIP                                       |
          in ? x                                       |init
        out ! k * x
    :

    PROC sum (CHAN OF REAL32 in1, in2, out )
      REAL32 x1, x2 :
      WHILE TRUE                                  |--------|
      SEQ                                in1 -----|        |
        PAR                                       |  sum   |---- out
          in1 ? x1                       in2 -----|        |
          in2 ? x2                                |--------|
        out ! x1 + x2
    :

    PROC min (CHAN OF REAL32 in1, in2, in3, out)
      REAL32 x1, x2, x3 :
      WHILE TRUE                                  |--------|

        SEQ                              in1 -----|        |
          PAR                                     |        |
        in1 ? x1                     in2 -----|  minus |---- out
        in2 ? x2                              |        |
        in3 ? x3                     in3 -----|        |
          out ! -((x1 + x2) + x3 )                |--------|
    :

    PROC int (CHAN OF REAL32 in, out, init)
      REAL32 x,t :   <<< SYSTEM STATE AND TIME
        SEQ
          init ? x;t <<< INITIALIZE STATE AND TIME
          WHILE TRUE                              |-------|
        PRI ALT                               |       |
          init ? x;t                  in -----| inte- |---- out
            SKIP                              | grator|
          TRUE & SKIP                         |---|---|
            REAL32 dx :                           |
            SEQ                                   | init
              PAR
            in ? dx       -- Input in parallel
            out ! x        -- with output
              x:= x + (dx*t)
    :

These building blocks defined above may now be used to convert for example
a control system defined as a block diagram (think of it as an analog
computer) into an Occam program to run on a transputer. The application
realized in our control laboratory is given below. It is not necessary for
you to study this program it is only given as an illustration. Note
that the insertion of the SPLITTER blocks is necessary because the Occam
channels are point-to-point connections. Installation of a SPLITTER block
looks like a solder joint.

After the definition of the basic building blocks, the complete calculation
process for one control mode looks like the following Occam process:
The channel names have been changed to a vector type representation.

     PROC calc ([4]CHAN OF REAL32 in, CHAN OF REAL32 outM,
      [13]CHAN OF REAL32 I)
       [27]CHAN OF REAL32 D :
       PAR
       gain ( in[0], D[0],  I[0]  )
       gain ( in[1], D[1],  I[1]  )
       gain ( in[2], D[2],  I[2]  )
       gain ( in[3], D[3],  I[3]  )
       min ( D[0],  D[1],  D[2],  D[8] )
       min ( D[3],  D[4],  D[5],  D[9] )
       sum ( D[6],  D[7],  outM  )
       gain ( D[8],  D[12], I[6]  )
       gain ( D[10], D[6],  I[4]  )
       gain ( D[11], D[7],  I[5]  )
       tee ( D[9],  D[13], D[14] )
       sum ( D[12], D[13], D[15] )
       sum ( D[16], D[14], D[17] )
       gain ( D[18], D[5],  I[10] )
       gain ( D[19], D[4],  I[11] )
       tee ( D[15], D[20], D[21] )
       int ( D[17], D[23], I[9]  )
       sum ( D[22], D[24], D[26] )
       gain ( D[20], D[22], I[7]  )
       gain ( D[21], D[16], I[8]  )
       tee ( D[23], D[24], D[25] )
       tee ( D[25], D[10], D[18] )
       int ( D[26], D[27], I[11] )
       tee ( D[27], D[19], D[11] )
     :


With these instructions the scheduler of the transputer can go to work and
schedule all these parallel processes for execution. The advantage of this
method is the speed of the development of the program. The above program is
for a digital controller.

There are, however, some remarks to be made about this design method.
Because a large number of building blocks are interconnected, there is a
danger of deadlock. It is a property of so-called I/O-parallel blocks that
if combined into networks, they will exhibit deadlock free properties. An
I/O parallel block executes the input and output in parallel and not
sequentially. The careful use of a few I/O-parallel blocks in a network
will result in a deadlock free behavior of the network. For that reason the
integrators used above are I/O parallel as indicated in the corresponding
Occam program, resulting in a deadlock free program.



4       CONCLUSIONS AND SUGGESTIONS


The overall conclusion of the experience gained over a number of projects
is that the application of transputers allows the design of
high-performance systems. For complex systems the basic element method is a
very good approach to realize the parallel programs.

I would like to invite all you TCP IP NET etc. software to suggest which
application according to your opinion would be interesting for packet radio.
Just to make you feel better: it is possible to program a transputer in C,
Pascal or even FORTRAN. It is also possible to cast C program in an Occam
harness so that Occam will take care of the parlellism. But Occam is a nice
parallel language and it illustrates the parallel implementations very well.

If you have any questions please direct them to my email address. I will
try reply in the form of another write-up

73's
PA0APA

------------------------------

End of Packet-Radio Digest
******************************
Date: Tue,  7 Aug 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #109
To: packet-radio


Packet-Radio Digest         Tue,  7 Aug 90       Volume 90 : Issue 109

Today's Topics:
                Ethernet TNCs?
             Mac SCSI<->Ethernet
            Packet Software for Apple //e

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 6 Aug 90 13:49:39 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: Ethernet TNCs?
To: [e-mail]

I and my friends have done working designs using the National chipset.  If
pressed, I could probably scrape up a schematic fragment.  It's not many
chips.

I also agree that ether cards for the DE, PS-186, and Grace PackeTen would
be nice.  I'd also like to see SCSI...

Can't I have my cake and eat it too?  :-)

Bdale

------------------------------

Date: Mon, 6 Aug 90 08:19:53 -0400
From: [e-mail] (Charlie Ross, Jr.)
Subject: Mac SCSI<->Ethernet
To: "[e-mail]"@gte.com

Phil Karn writes:

"EVERYTHING for the Mac is very expensive. That's why I don't own one. "

Touche.

--Charlie

------------------------------

Date: 6 Aug 90 20:34:31 GMT
From: crash![e-mail]  (Scott O'Connell)
Subject: Packet Software for Apple //e
To: [e-mail]

I have an old 2m HT and an Apple //e.  I want to get into packet and
know I need a TNC and software.  My questions is: Can I use a plain
old terminal program on the Apple or must it be TNC specific?

What are your reccomendations?

Please e-mail and I will post a summary on request.
Scott O'Connell - N6ZEK      UUCP: {nosc, hplabs!hp-sdd}!crash!ipars!scotto
                 ARPA: crash!ipars![e-mail]
                 INET: [e-mail]
--
Scott O'Connell - N6ZEK      UUCP: {nosc, hplabs!hp-sdd}!crash!ipars!scotto
                 ARPA: crash!ipars![e-mail]
                 INET: [e-mail]

------------------------------

End of Packet-Radio Digest
******************************
Date: Wed,  8 Aug 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #110
To: packet-radio


Packet-Radio Digest         Wed,  8 Aug 90       Volume 90 : Issue 110

Today's Topics:
               AX.25 Forwarding to NOS
          AX.25 to NOS.EXE Forwarding Error
            Corrupted SEQUENCE.SEQ
               DRSI i/o port conflicts?
            NOS/BM SMTP SEQUENCE.SEQ Error

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: Mon, 06 Aug 90 23:32:30 EDT
From: [e-mail]
Subject: AX.25 Forwarding to NOS
To: uucp@remote.n8hsp

My apologies to the net for eating up this bandwidth, I'm not sure who
should really get this.

There APPEARS to be a problem with NOS.EXE when AX.25 PBBS systems try
to forward bulletins. I can't speak for all PBBS software but the local
MSYS system here seems to burp when it attempts to forward.

NOS.EXE will go into the shortened prompt okay and after receiving the
AX.25 PBBS ID. (ie: [MSYS-1.08-H$]) will respond with ">". Now after
playing with it here I can send the statement: "SB ALL@N8HSP <N8HSP $001"<cr>
and the system responds properly with "OK <cr>". Here now is the trouble,
after sending the next line of data (the SUBJECT:) "FORWARD TEST" <cr>
I as an AX.25 PBBS am expecting the NOSE.EXE system to reply with a
<cr><lf> to signal the start of message forwarding. NOS.EXE does not
reply with the <cr><lf>. Does this format hold true for other PBBS
software? Do they also expect the <cr><lf> to start the message forwarding?

Thanks es 73,
Terry
--
Terry Bell N8HSP @WA8BXN.OH.USA.NA  AMSAT-NA [44.70.4.10] [e-mail]
Internet: [e-mail]           UUCP: uunet!cwjcc!ncoast!tbell

--
*****************************************************************
Terry Bell N8HSP @WA8BXN.OH.USA.NA     AMSAT-NA      [44.70.4.10]
Internet: [e-mail]    UUCP: cwjcc!ncoast!tbell
American Red Cross    Emergency Communications    Cleveland, Ohio
*****************************************************************

------------------------------

Date: 7 Aug 90 14:04:07 GMT
From: usenet.ins.cwru.edu!ncoast![e-mail]  (Terry Bell)
Subject: AX.25 to NOS.EXE Forwarding Error
To: [e-mail]



------------------------------

Date: Mon, 06 Aug 90 23:51:47 EDT
From: [e-mail]
Subject: Corrupted SEQUENCE.SEQ
To: uucp@remote.n8hsp

Is anybody having trouble with NOS.EXE and getting their SEQUENCE.SEQ
out of sequence from time to time? I was at message id 7000 something
and now take a look at the messsage id number? hmmmmmmmm.........
This has happened before but I haven't put a pattern to it yet.
73 Terry
--
Terry Bell N8HSP @WA8BXN.OH.USA.NA  AMSAT-NA [44.70.4.10] [e-mail]
Internet: [e-mail]           UUCP: uunet!cwjcc!ncoast!tbell


--
*****************************************************************
Terry Bell N8HSP @WA8BXN.OH.USA.NA     AMSAT-NA      [44.70.4.10]
Internet: [e-mail]    UUCP: cwjcc!ncoast!tbell
American Red Cross    Emergency Communications    Cleveland, Ohio
*****************************************************************

------------------------------

Date: 3 Aug 90 13:05:16 GMT
From: uop!milton!dali.cs.montana.edu!samsung!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: DRSI i/o port conflicts?
To: [e-mail]

In article <[e-mail]> <[e-mail]> writes:
>==============================================================================
>
>I recently picked up a DRSI PCPA.  I tried to install it in my 286 clone, but
>it would not work ok.  I read the manual and it explains how to use debug to
>check for a free i/o area.
>
>I tried   -i 300   and should get 'FF' if free.  I do not get this.  I get the
>wrong response on the various areas the manual suggests.  I have removed all
>boards except the floppy drive controller.  I still get the conflict.  I have
>an eprom programmer.  Before I start trying different bios chips, has anyone
>came across this before.  The system board is a 4meg ram  12mhz 286 board.
>The board is fairly new (less than 2 months old).  The bios has built-in
>diagnostics.  I am just guessing that the 'extras' on the bios might be giving
>me problems.

It is not unusual to see something other than FF at a empty location
on the PC bus because there are no pullups on the PC bus. So don't get
too excited about that. Exactly what symptoms does the DRSI exhibit
that leads you to believe you have a conflict?

Gary KE4ZV

------------------------------

Date: 7 Aug 90 14:05:46 GMT
From: usenet.ins.cwru.edu!ncoast![e-mail]  (Terry Bell)
Subject: NOS/BM SMTP SEQUENCE.SEQ Error
To: [e-mail]



------------------------------

End of Packet-Radio Digest
******************************
Date: Thu,  9 Aug 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #111
To: packet-radio


Packet-Radio Digest         Thu,  9 Aug 90       Volume 90 : Issue 111

Today's Topics:
              Driving a high-speed modem
         Ethernet TNC's? No thanks! (4 msgs)
                Ethernet TNCs?
               Kiss for TNC-1?
            New DOVE Telemetry Equations?
            packet groups in Ann Arbor, MI

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 3 Aug 90 19:35:12 GMT
From: usc!elroy.jpl.nasa.gov!grian!puffin!wd6ehr.ampr.org![e-mail]  (Mike Curtis)
Subject: Driving a high-speed modem
To: [e-mail]

In article <[e-mail]> [e-mail] (Charlie Ross, Jr.) writes:
> In reply to my comment about dedicated interface cards, Phil Karn writes:
>
>> <<No, this does not follow at all. Your host doesn't have to be a PC to
>> avoid having to use a KISS TNC. It only has to have an HDLC interface. Many
>> computers with more reasonable hardware architectures than the PC already
>                 --------------------------------------------------
>> have HDLC capability; the Mac is one example.  All somebody has to do is
>> to write the appropriate driver.>>

I have a schematic for the Atari ST that allows up to 7 8530 SCC chips
to be wired in, giving 14 additional ports, be they RS232, KISS, or
even TNC2.  The driver for this is contained in the PE1CHL version
of net, and will support packet with only a modem - no TNC!
>
> If you define the KISS TNC's functions to include providing HDLC and a modem
> only, I agree with you.
>
> Let me suggest a somewhat different perspective.  The KISS TNC today has
> another function:  it provides buffering, and isolates the PC-to-TNC data rate
> from that of the channel.  Given today's slow 1200-baud (or even 4800 or 9600)
> system, you are right to say that there's no good reason not to move the HDLC
> back into the host and dispense with all but the modem.
>
> When you get to 56kbs and up, however, I suggest that a specialized
> interface is needed.  Within the PC-compatible environment, the best
> implementation is likely a dedicated DMA card, and it's no big deal to design
                       ^^^
All right!  NOW we're getting somewhere.  All this RS232 (does RS stand
for Really Slow??? :-), etc., junk is really a dead end hack anyway.
DMA would seem to be the real future of all serious high-speed data
transfer.

> it would talk to the host using something like SCSI, running faster than
> the channel (the future equivalent of hitting a KISS TNC at 9600 while
> running  the channel at 1200).

The Atari ST, a _very_ underrated computer, already has a DMA port which
is used as the HD port, and I already have a BMS-100 SCSI adaptor card
for my HD.  (also Re: kk6jq's articles on a possible SCSI highspeed hack.)

>         A less-favorable alternative would be a system which interfaced
> using the PC's maximum RS-232 (or whatever) data rate, buffered the
> data, and interfaced to the modem at a higher rate.

This is what the Kantronics DE56 is attempting to do, more or less.
Yes, it'll probably work fine for now at 1200, and 9600 baud, or
maybe even on a busy 56K channel.  But what about on a _real_ man's
1 mB channel, etc.?  Considering what's possible with todays technology,
it's quite reasonable to consider 56 kB ham packet as only "medium speed".

>  (Clearly, such a system
> would not allow the user to make full use of the channel bandwidth, but we
> shouldn't constrain the channel to run at the rate of the slowest PC
> interface!)

yup - isn't that basically (pun intended) why the C-64 is now obsolete?
This is also one reason those with high IQ's do poorly in public school.
The class is restricted to the speed of the slowest student that learns
what the class teaches.  So to school AND packet I say - let's let the
faster ones go at their own pace, and put the slower ones in a special
area where they'll benefit more.  (This is a view from the other side
of traditional thinking, which puts "normal" kids at the crux.) (Yes,
I was one of the "gifted" kids, and had a totally boring, miserable
time in grade/high school.)
>
> Someone has to write a software driver in any event.

yup - and this will be the best part!  Software is not machine
dependent, i.e., the driver could be written for virtually ANY machine.
>
>          I particularly wanted to mention the advantages of having
> a turnkey solution available for nontechnical newcomers.  We should
> keep it in mind.  That's all.

Good idea.  You would've never gotten me into packet with a megabuck
pricetag.  I groused about $129 for my first MFJ 1274!  And I speak
for virtually all packeteers. (does 90% count as "virtually all"? :-)

I'm not as concerned about "non-technical newcomers" as you are.  I
basically feel that the "cutting edge" of technology is no place for
the non-technical.  I'm sure being an Engineer jades my viewpoint,
so take this as intended, with a grain of salt.  Also consider: to pass
any ham license, one should have a modicum of tech knowledge.  This
means that some hams we know must be non-legit - but in the immortal
words of John Cleese, that's "something completely different".

> Charlie Ross, NC1N

    73, Mike
  --------------------------------------------------------------------------
  Mike Curtis, wd6ehr@k6iyk            Take care of the most important thing
  wd6ehr.ampr.org![e-mail]   each day, sticking with it until it's
  7921 Wilkinson Avenue                done; then go on  to  the  next  most
  North Hollywood CA 91605-2210        important thing and finish it.   What
  [phone]                       you've put off was not  as  important
  Nature abhors a vacuum almost as     as what you've completed, and  you've
  much as we hate spaces in footers.   gotten your most important task done.
  --------------------------------------------------------------------------

------------------------------

Date: Wed, 08 Aug 90 14:12:36 BST
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: Ethernet TNC's? No thanks!
To: [e-mail]

Why stick with Ethernet for linking TNC's. CSMA/CD and TCP/IP are from a
protocol point of view, at best both kludges. Some of us (who use IBM kit
exclusively) would like a Token-ring version. Bear in mind that the current
unit sales of ethernet & token-ring are approximately equal in the commercial
world. Equally, I would *LOVE* a MCA-bus version of the DRSI card (or
equivalent) to appear. AT-buses and 8088's just dont thrill me anymore.
Ethernet, particularly for intensive real-time applications, is seriously
flawed (well, CSMA/CD is flawed full stop!) maybe someone should implement a
token-based amateur packet protocol?
Would possibly get round the current scenario where everybody collides so
nobody gets through.


73's de Pete G6WBJ@GB7SDN


   Pete Lucas         [e-mail]       0793 411613
              [e-mail]
              [e-mail]

------------------------------

Date: 8 Aug 90 20:48:15 GMT
From: pacbell.com!tandem!moe![e-mail]  (Kevin J. Rowett)
Subject: Ethernet TNC's? No thanks!
To: [e-mail]

In article <08.Aug.90.14:16:50.BST.#[e-mail]>,
[e-mail] ("Pete Lucas, NCS-TLC, Holbrook House,
Swindon") writes:
|> Why stick with Ethernet for linking TNC's. CSMA/CD and TCP/IP are from a
|> protocol point of view, at best both kludges. Some of us (who use IBM kit

I think the notion was what medium to link the NNC to the host computer.
The smae medium or protocol doesn't have to be used on the air.

|> exclusively) would like a Token-ring version. Bear in mind that the current

At present, I believe ethernet cards are much cheaper than token-ring
cards.  Since it's only the *transport* medium to the NNC, then how it
gets done should be as cost effective as possible.

Also, from a cards builders perspective, I'd tackle a ethernet design
before a TR design.  Six vendors sell ethernet chipsets, one or two
sell TR chip sets (well, three, but they won't sell to me).

PCB Real Estate and chip costs quickly become factors.

|> Ethernet, particularly for intensive real-time applications, is seriously

In general, that hard to argue with. However, if we could come up with some
serious ideas about what RT applications should be implemented, we can
then decide how to adapt what we have.

|> flawed (well, CSMA/CD is flawed full stop!) maybe someone should implement a
|> token-based amateur packet protocol?

Token-based protoocols start to make sense when you consider the use of
point to point RF.  One could build an amateur radio network that is
much like a token-ring, but I think that might require more cooperation
among ourselves than we're presently willing to do.

N6RCE

------------------------------

Date: 8 Aug 90 21:50:10 GMT
From: bellcore-2!envy![e-mail]  (Phil R. Karn)
Subject: Ethernet TNC's? No thanks!
To: [e-mail]

In article <08.Aug.90.14:16:50.BST.#[e-mail]>,
[e-mail] ("Pete Lucas, NCS-TLC, Holbrook House,
Swindon") writes:

> Why stick with Ethernet for linking TNC's. CSMA/CD and TCP/IP are from a
> protocol point of view, at best both kludges.

Oh boy, here we go again with the token-ring vs bus wars. I hope
you're being facetious, but just in case...  What's so "kludgey" about
Ethernet and TCP/IP, and more importantly, what do you have to offer
that's truly better?

> Ethernet, particularly for intensive real-time applications, is seriously
> flawed (well, CSMA/CD is flawed full stop!)

This is a bit of particularly egregious misinformation kept alive by
the token ring salesmen. See the excellent paper by Boggs, Mogul and
Kent in the 1988 SIGCOMM procedings ("Measured Capacity of an
Ethernet: Myths and Reality"). Basically, Ethernet continues to
operate at nearly its full capacity of 10 Mb/s even when the offered
load is far greater. Obviously not everyone gets their traffic through
under such conditions, but neither will a token ring!

Another point made in the paper is that even under heavy overload,
each Ethernet station gets a roughly equal share of the bandwidth when
averaged over several packets. Since fairness under overload is usually
touted as the big advantage of a token ring, this is a most interesting
result.

In other words, a properly built Ethernet and a properly built token
ring will both work just fine as long as the aggregate traffic is less
than the data rate of the medium, and neither Ethernet nor token ring
will satisfy their users when the aggregate demand exceeds the
capacity of the media. And given that most hams probably won't
overload their shack Ethernets very often, the issue is moot anyway.

So a decision between them should be made on the basis of other
factors such as the cost, quality, availability and vendor support of
each type of interface. And on this basis Ethernet wins hands down.
Ethernet is much more widely supported than token ring by every vendor
except IBM, and the Ethernet market is much more competitive. If you
want a multi-vendor LAN, you don't have much choice.

> maybe someone should implement a
> token-based amateur packet protocol?
> Would possibly get round the current scenario where everybody collides so
> nobody gets through.

This is an entirely different issue, and you may well have a point.
Every channel access algorithm has a regime in which it works well.
Just because CSMA/CD works fine at 10 Mb/s on coax cables up to 1500m
doesn't mean it will work well on packet radio where the conditions
are quite different. Our experiences bear this out.  Token passing is
definitely one of the schemes that should be tried, although it too
has many practical problems that need to be dealt with.

Phil

------------------------------

Date: 8 Aug 90 21:22:18 GMT
From: sdd.hp.com!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Ethernet TNC's? No thanks!
To: [e-mail]

In article <08.Aug.90.14:16:50.BST.#[e-mail]> [e-mail] ("Pete Lucas, NCS-TLC, Holbrook House, Swindon") writes:
>Ethernet, particularly for intensive real-time applications, is seriously
>flawed (well, CSMA/CD is flawed full stop!) maybe someone should implement a
>token-based amateur packet protocol?
>Would possibly get round the current scenario where everybody collides so
>nobody gets through.

    Well, the good old argument, token passing vs. csma/cd. How do you
implement a practical token passing network over a relatively unreliable
link?

    It isn't too hard at first to envision a topolgy which isn't outright
functionless. A mountain top digipeater would act as the 'active monitor'
and somehow build a list of nodes, passing the token to each one in turn.
(This ends up a token bus, not a ring). When a node wishes to leave the
net, it would wait for the token to come around and then transmit a message
removing itself from the topology. What about a node wishing to join the
topology? Oops, now we've got a CSMA scenario again.... since the node
wishing to join the topology will never be passed the token, any transmission
from him is in danger of colliding with some other node. What about nodes
which can't see the mountain top but can see another node who is in the
topology... what kind of protocol can be developed to allow the hidden nodes
to join the topology?

    CSMA does indeed have some problems, compounded by the fact that
Collision Detection is impractical in the scenario. A node using a
duplex repeater could possibly be able to listen to output of the repeater
and detect a collision, but a simplex station can not do this (if you don't
believe me, send me a note and I'll explain why even a diverse node - where
the transmitter is some distance from the receiver - would not be practical).
It seems most packeteers insist on running with a persistance of 1 (that is
a P of 255) which rapidly clogs a channel beyond usefulness as loading
increases. So, we encourage collisions and have no way of providing a
rapid recovery. Yuck.

  But, what else can we do? We don't have any 'packet network czars', so
every station is free to run whatever parameters they wish. Furthermore,
the performance from each node is essentially dependent on what every
OTHER node is doing; try being the nice guy running p=.1 on a normal
channel (where everyone else is running p=1)....

  As for interfacing to a TNC over a network, it really makes no
difference which kind of network is in use if the loading is light
and topology is small.  Furthermore, the cheapest token ring interface
I've seen is still a lot more money than the cheapest ethernet interface.
Token-Ring (802.5) is a MUCH more complicated network than Ethernet.

*****************************************************************
* Dana H. Myers KK6JQ           | Views expressed here are      *
* [phone] (ex WA6ZGB)    | mine and do not necessarily   *
* [e-mail]                | reflect those of my employer  *
*****************************************************************

------------------------------

Date: 7 Aug 90 19:30:23 GMT
From: pacbell.com!tandem!moe![e-mail]  (Kevin J. Rowett)
Subject: Ethernet TNCs?
To: [e-mail]

In article <[e-mail]>, [e-mail] (Bdale Garbee) writes:
|> I and my friends have done working designs using the National chipset.  If
|> pressed, I could probably scrape up a schematic fragment.  It's not many
|> chips.

For that matter, National publishes a complete Ethernet PC adapter card
in their App notes.

N6RCE

------------------------------

Date: 8 Aug 90 18:23:46 GMT
From: sun-barr!newstop!east!hienergy![e-mail]  (Jim Vienneau - Sun Microsystems)
Subject: Kiss for TNC-1?
To: [e-mail]

Anyone know where I can get KISS ROM code for a TAPR TNC-1? I was
fairly certain it exists, but haven't been able to locate it. I would
appreciate any and all leads.

Jim Vienneau, Sun Microsystems Inc - Billerica, MA
Email: [e-mail]   Amateur Radio: WB1B
Good old Ma Bell (well old anyway): [phone]

------------------------------

Date: Wed, 8 Aug 90 09:42:17 EDT
From: [e-mail]
Subject: New DOVE Telemetry Equations?
To: "Packet-Radio Digest" <[e-mail]>

DOVE, the Digital Orbiting Voice Encoder microsat seems to be stead-
fastly back on 2m now.  But the telemetry packets have two fewer
channels than before.  Does this mean that the whole set of telemetry
channels has been changed or reorganized or that just the last two
(related to the S-band xmtr) have been dropped?  Also, is there a new
set of telemetry equations to go along with the new format?  There
appear to be more non-zero values in the status bits now too.  Is there
an up-to-date description of what they all mean?  Many thanks in advance
for any help anyone can offer.

================================================================================
 Richard B. Langley                            BITnet: [e-mail] or [e-mail]
 Geodetic Research Laboratory                  Phone:  [phone]
 Dept. of Surveying Engineering                Telex:  014-46202
 University of New Brunswick                   FAX:    [phone]
 Fredericton, N.B., Canada  E3B 5A3
================================================================================

------------------------------

Date: 8 Aug 90 22:13:05 GMT
From: umich!vela![e-mail]  (Brent Besler)
Subject: packet groups in Ann Arbor, MI
To: [e-mail]

The regional MERIT network has direct connection into the Internet.  There are
local dialups at 1200/2400 baud all over Michigan.  There are V.32 9600 and
19200 baud modem dialups in Ann Arbor also.

------------------------------

End of Packet-Radio Digest
******************************
Date: Fri, 10 Aug 90 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #112
To: packet-radio


Packet-Radio Digest         Fri, 10 Aug 90       Volume 90 : Issue 112

Today's Topics:
         Ethernet TNC's? No thanks! (2 msgs)
            Packet Software for Apple //e
              PK-232MBX Auto-Forwarding
    Token-ring? Ethernet? Why not use the parallel-port? (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 8 Aug 90 17:14:16 GMT
From: bacchus.pa.dec.com!shlump.nac.dec.com!ryn.esg.dec.com!ultnix![e-mail]  (Patrick Taber)
Subject: Ethernet TNC's? No thanks!
To: [e-mail]

In article <08.Aug.90.14:16:50.BST.#[e-mail]>,
[e-mail] ("Pete Lucas, NCS-TLC, Holbrook House,
Swindon") writes:
|> Why stick with Ethernet for linking TNC's. CSMA/CD and TCP/IP are from a
|> protocol point of view, at best both kludges. Some of us (who use IBM kit
|> exclusively) would like a Token-ring version.

No offense, but prejudice aside, how robust do you think token is going to be in
a radio environment?  My guess is that in any interesting radio net you'd spend
more than half the bandwidth would be wasted recovering from lost tokens.
CSMA/CD is much less flawed once you consider token loss.

                         >>>==>PStJTT
                     Patrick St. Joseph Teahan Taber

My employer doesn't care what I think.  I, in turn, don't care what
you think.  You probably don't care what my empolyer thinks.  Thus is
life a circle.

------------------------------

Date: 9 Aug 90 09:59:23 GMT
From: sdd.hp.com!samsung!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: Ethernet TNC's? No thanks!
To: [e-mail]

In article <08.Aug.90.14:16:50.BST.#[e-mail]> [e-mail] ("Pete Lucas, NCS-TLC, Holbrook House, Swindon") writes:
>Ethernet, particularly for intensive real-time applications, is seriously
>flawed (well, CSMA/CD is flawed full stop!) maybe someone should implement a
>token-based amateur packet protocol?
>Would possibly get round the current scenario where everybody collides so
>nobody gets through.

Current amateur packet operation does not fit well with the CSMA/CD
model due to the infamous hidden terminal problem. This is a level 1
issue of course and could, in principle, be solved by going to full
duplex operation or by using some form of microwave point to point
links. Neither solution is universally available. On HF, a full duplex
channel is impossible due to propagation. On VHF/UHF/SHF, point to point
is impossible for some of our users since they can hear no one else
directly and must use the high site digi to operate at all. At least
with p-persistence and exponential backoff, Phil's TCP/IP code allows
some thruput while preventing congestive collapse.

Current amateur packet channels are very lossey with many packets never
reaching their destinations, not because of collisions, but because
the radio channel is not 100% reliable. This is not likely to change.
This gives backoff algorithms fits and makes a backoff cap mandatory.

Further, amateur operation is by nature chaotic. Stations join or
leave the channel at random times. User expectations of packet
capability vary wildly. And the technical sophistication of user
equipment covers a wide spectrum.

Thus, while the current CSMA scheme has serious warts, implementing a
token ring amateur packet protocol appears nearly hopeless. Token
ring demands much better radio paths than we are likely to get.
Token ring requires a known, well understood, network topology that
does not change minute by minute. And given the relatively long
key up delays of current packet equipment, much channel  capacity
is going to be wasted simply passing the token by stations that
currently have no traffic for the net. The problem of regenerating
lost tokens is severe as is the problem of users dropping in and out
at random.

Taking the realities of packet operation into account, does anyone
have suggestions for realistic protocol improvements?

Gary KE4ZV

------------------------------

Date: 8 Aug 90 18:14:12 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!rsiatl!nanovx!ke4zv![e-mail]  (Gary Coffman)
Subject: Packet Software for Apple //e
To: [e-mail]

In article <[e-mail]> [e-mail] (Scott O'Connell) writes:
>
>I have an old 2m HT and an Apple //e.  I want to get into packet and
>know I need a TNC and software.  My questions is: Can I use a plain
>old terminal program on the Apple or must it be TNC specific?

Use a plain old terminal program. TNC=Terminal Node Controller.

Gary

------------------------------

Date: 10 Aug 90 03:09:32 GMT
From: cs.utexas.edu!ut-emx!lad-shrike![e-mail]  (R M Kriss)
Subject: PK-232MBX Auto-Forwarding
To: [e-mail]

I just received the new PK-232MBX firmware upgrade from AEA and the docs
say it supports Auto-forwarding. I have tried it with a W0RLI and AA4RE
BBS and I cannot get it to work either 'to' or 'from' the PBBS. I did
all the tricks suggested about the flags and setting the HOMebb command.

Has anyone broke the code on how to make this thing work?

The AEA doc says .......Auto-Forwarding is fairly involved and requires
planning and cooperation by both you and your community BBS Operator. Not
all community BBSs are able to forward to and from individual users. You
must contact your BBS SysOp to determine what guidelines apply in your
area......

Sure would like to know what 'guidlines' are? Another ham here just got
the PK-88 upgrade and he is having the same problem.

I am referring to the following AEA firmware release:

AEA PK-232M Data Controller
Copyright (C) 1986-1990 by
Advanced Electronic Applications, Inc.
Release 19.JUL.90

BTW, the new Maildrop is a 100% improvement over the origional release. Has
all kind of neat features. The best is the the internal battery keeps the
messages stored when you RESTART. It is worth the $35 upgrade fee.

73 de Dick, KD5VU
=====================================================================
   Richard (Dick) Kriss    E-Mail: [e-mail]
      904 Dartmoor Cove    Packet Radio: SP KD5VU @ KB5PM.#AUS.TX.USA.NA
    Austin, Texas 78746    Phone: [phone] (day) or 327-9566 (evenings)
  My employer has nothing to do with this message! ...  _._
=====================================================================

------------------------------

Date: Thu, 09 Aug 90 15:11:16 BST
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: Token-ring? Ethernet? Why not use the parallel-port?
To: [e-mail]

OK so Token-ring is more expensive; at the moment.......

 In the meantime, has anybody thought of using the parallel printer
port? Bi-directional (if you have kosher hardware), essentially TTL
levels (so should be dead easy to hook straight into the TNC),
factory-fitted on most industry-standard computers, and oodles faster than
poor slow serial RS232!
This port is wasted on most dot-matrix printers; stick your printer on
the RS232 and use that parallel-port for something exciting.

   73's de Pete [e-mail]

   Pete Lucas         [e-mail]       0793411613

------------------------------

Date: 9 Aug 90 22:51:55 GMT
From: hayes.fai.alaska.edu!acad3.fai.alaska.edu![e-mail]  (MUNTS PHILLIP A)
Subject: Token-ring? Ethernet? Why not use the parallel-port?
To: [e-mail]

In article <09.Aug.90.15:12:21.BST.#[e-mail]>, [e-mail] ("Pete Lucas, NCS-TLC, Holbrook House, Swindon") writes...
> In the meantime, has anybody thought of using the parallel printer
> port? Bi-directional (if you have kosher hardware), essentially TTL

     I have investigated this recently for another application.  My T1000 laptop
(4.77 MHz 80C88) is only good for about 10-20 Kbytes/sec, with hand-optimized
assembly language.  I am normally an Intel fan but I/O on 80x86 machines is a
horrible pain.  (Load DX with one port address, input to AL, move it somewhere,
load DX with a different port address...Argh)  My 286 desktop doesn't have
a bidirectional printer port (monographics/printer card with one ASIC) and no
visible provisions for making it so.  Everything has to be done serially thru
the handshake lines...

     Now 10-20 Kbytes/sec is nothing to sneeze at compared to RS232 but it is
nothing at all compared to some sort of a DMA channel like a LAN or SCSI.

Philip Munts N7AHL
NRA Extremist, etc.
University of Alaska, Fairbanks

------------------------------

End of Packet-Radio Digest
******************************
Date: Sat, 11 Aug 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #113
To: packet-radio


Packet-Radio Digest         Sat, 11 Aug 90       Volume 90 : Issue 113

Today's Topics:
                   DCD mods
         Ethernet TNC's? No thanks! (2 msgs)
                pk232 bitinv?
     Token-ring? Ethernet? Why not use the parallel-port?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 10 Aug 90 13:15:59 GMT
From: mcsun!ukc!acorn![e-mail]  (Adrian Godwin)
Subject: DCD mods
To: [e-mail]

I've seen a number of references to a 'DCD mod' to be applied to
TNCs in order to provide enhanced carrier-detect performance when
the radio is used unsquelched. However, I can't find any
documentation on this mod.

Does it look for valid data (less than 5 1's, or a flag), or RX
clock in fixed phase-relationship to TX clock, or data transitions
at no faster rate than recovered RX clock, or what ?

Do they perform any function that can't be performed in software
using the HDLC controller's flag and abort detect hardware ?

-adrian

------------------------------

Date: 10 Aug 90 15:59:48 GMT
From: [e-mail]  (Mike Chepponis)
Subject: Ethernet TNC's? No thanks!
To: [e-mail]

Gary, reconsider a token-passing scheme using pairs of microwave dishes at
every QTH.  Or one central site with one dish per user, and one dish per
user (star configuration, actually, and rather like the Hubmaster concept
discussed by N6GN, N6RCE and N6PLO in the upcoming CNC).

Token-passing looks pretty good in those situations, I think.

Best -Mike k3mc

------------------------------

Date: 10 Aug 90 21:02:00 GMT
From: pacbell.com!tandem!moe![e-mail]  (Kevin J. Rowett)
Subject: Ethernet TNC's? No thanks!
To: [e-mail]

In article <[e-mail]>, [e-mail] (Dana H.
Myers) writes:
|>     Well, the good old argument, token passing vs. csma/cd. How do you
|> implement a practical token passing network over a relatively unreliable
|> link?

Why attempt it?  Let's fix the link problems.  Packet isn't weak signal
work, and we're not trying to get WA BBasses.

Lets approach the packet networking problem *assuming*:

1) C/N ratios such that we get BER in the range of 10**8
2) NO hidden transmitters on the links.

Well, at least most of the time, 'cept for the occasional
tropo duct, in which case I'm off the air for packet anyway,
working someone S9 in LA on 100mW.

N6RCE

------------------------------

Date: 8 Aug 90 18:10:00 GMT
From: sun-barr!newstop!texsun!letni!merch!cpe!techsup![e-mail]
Subject: pk232 bitinv?
To: [e-mail]

has anyone experimented using the pk232's bitinv command to
decode encrypted rtty?  how about a program to make this a little
easier?  anyone heard/know of one?

any info will be appeciated.  thanks!

ken brookner, n5lpi

     [e-mail]    [this path may be broken now]
     trsvax!techsup!kenb

------------------------------

Date: 10 Aug 90 20:48:38 GMT
From: mejac!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Token-ring? Ethernet? Why not use the parallel-port?
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>In article <09.Aug.90.15:12:21.BST.#[e-mail]>, [e-mail] ("Pete Lucas, NCS-TLC, Holbrook House, Swindon") writes...
>> In the meantime, has anybody thought of using the parallel printer
>> port? Bi-directional (if you have kosher hardware), essentially TTL
>
>  I have investigated this recently for another application.  My T1000 laptop
>(4.77 MHz 80C88) is only good for about 10-20 Kbytes/sec, with hand-optimized
>assembly language.  I am normally an Intel fan but I/O on 80x86 machines is a
>horrible pain.  (Load DX with one port address, input to AL, move it somewhere,
>load DX with a different port address...Argh)  My 286 desktop doesn't have
>a bidirectional printer port (monographics/printer card with one ASIC) and no
>visible provisions for making it so.  Everything has to be done serially thru
>the handshake lines...

   Now, wait a minute.... you could cheat. The 'standard' IBM printer port
has the ability to read back the data on the output pins. If you write
0xFF to the output port, then have an external device pull-down the pins
he wants to be 0s, you'd read back the correct data.

  This is quite nasty, though. I've been hesitant to post it. The worst
case is that all 8 bits are pulled low... this results in something like
250 mA of current flowing through the 74LS374 latch. If you keep the duty
cycle low you'd probably be just fine. So, you could run bi-dir at a
much higher rate (over 100 Kbytes/sec) if you wish...


>
>     Now 10-20 Kbytes/sec is nothing to sneeze at compared to RS232 but it is
>nothing at all compared to some sort of a DMA channel like a LAN or SCSI.
>
>Philip Munts N7AHL
>NRA Extremist, etc.
>University of Alaska, Fairbanks


*****************************************************************
* Dana H. Myers KK6JQ           | Views expressed here are      *
* [phone] (ex WA6ZGB)    | mine and do not necessarily   *
* [e-mail]                | reflect those of my employer  *
*****************************************************************

------------------------------

End of Packet-Radio Digest
******************************
Date: Sun, 12 Aug 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #114
To: packet-radio


Packet-Radio Digest         Sun, 12 Aug 90       Volume 90 : Issue 114

Today's Topics:
              Ethernet TNC's? No thanks!
             Multi-cast and packet radio
     Token-ring? Ethernet? Why not use the parallel-port?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 11 Aug 90 12:31:31 GMT
From: swrinde!zaphod.mps.ohio-state.edu!samsung!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: Ethernet TNC's? No thanks!
To: [e-mail]

In article <[e-mail]> [e-mail] (Mike Chepponis) writes:
>
>Gary, reconsider a token-passing scheme using pairs of microwave dishes at
>every QTH.  Or one central site with one dish per user, and one dish per
>user (star configuration, actually, and rather like the Hubmaster concept
>discussed by N6GN, N6RCE and N6PLO in the upcoming CNC).
>
>Token-passing looks pretty good in those situations, I think.
>
>Best -Mike k3mc

This looks very good Mike for those who can arrange line-of-sight
access for permanant links. It leaves out the portable and possibly
mobile users completely. It would work on many backbone links and
in some special cases for general users. I see no problem with
this for special cases and see no compelling reason why everyone
must use the same link level protocol. However, I fear that with
the limited resources most of our groups have, we would slight
one or the other group of users by dividing our ranks. As you
know, we aggressively support 56kb here, but we are still allowing
users direct access to the 56kb backbone trunk switches because
we haven't mustered the people resources to put up a dedicated
56kb lan switch. In fact we are spending a lot of our limited time
trying to keep existing 1200 baud links running for our users who
haven't yet taken the 56kb plunge. Our user base breaks down to
about 600 active 1200 baud users, 200 2400 baud users, 12 56 kilobaud
users, and one lonely 9600 baud user (me). These are spread over
5 56kb trunk switches and 10,000 sq miles of hilly terrain. I
love this fast high tech stuff, but I can't hit a 56kb switch
from my location.

Gary KE4ZV

------------------------------

Date: 12 Aug 90 04:15:52 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica![e-mail]  (Steve Wallace)
Subject: Multi-cast and packet radio
To: [e-mail]

Televideo Made at least one IBM compatible with out a fan.

------------------------------

Date: 11 Aug 90 23:51:14 GMT
From: clyde.concordia.ca!news-server.csri.toronto.edu!utgpu!utzoo![e-mail]  (Henry Spencer)
Subject: Token-ring? Ethernet? Why not use the parallel-port?
To: [e-mail]

In article <15088@.la.locus.com> [e-mail] (Dana H. Myers) writes:
>   Now, wait a minute.... you could cheat. The 'standard' IBM printer port
>has the ability to read back the data on the output pins. If you write
>0xFF to the output port, then have an external device pull-down the pins
>he wants to be 0s, you'd read back the correct data.

The words "standard" and "IBM" do not belong in the same phrase. :-)  Most
microcomputer manufacturers are more interested in minimizing cost and chip
count than in adhering to standards.  (Case in point:  I'm not sure there
is *any* PC which really adheres strictly to RS232.  If your serial port
advertises reliable functioning faster than about 19.2k, for example, it
is ignoring the RS232 slew-rate limits.)  It's not at all unlikely that
some manufacturers, particularly the AT-on-3-chips types or the battery-
portable manufacturers, are reading back the register rather than the
pins, or implementing the port in CMOS that will fry if you make a habit
of out-muscling its output transistors.
--
It is not possible to both understand  | Henry Spencer at U of Toronto Zoology
and appreciate Intel CPUs. -D.Wolfskill|  [e-mail]   utzoo!henry

------------------------------

End of Packet-Radio Digest
******************************
Date: Mon, 13 Aug 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #115
To: packet-radio


Packet-Radio Digest         Mon, 13 Aug 90       Volume 90 : Issue 115

Today's Topics:
             TNC Software for the IBM PC
           Token-ring? - no - Henry Spencer

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 12 Aug 90 21:59:13 GMT
From: mountn.dec.com!atccad.enet.dec.com![e-mail]
Subject: TNC Software for the IBM PC
To: [e-mail]

Several months ago there was a posting about a program for the IBM PC
that would emulate all of
the functions of a TNC.  This software was to come from the same German
Ham group that wrote
a TNC emulator for the Commodore 64.  Has anyone seen this program ?
The promise was that
with this program all you needed was a radio, the program, and a simple
modem to connect into
the world of Packet Radio.



Thanks,


Lee Stogner,   N4XBD

------------------------------

Date: 12 Aug 90 20:49:05 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!kth.se![e-mail]  (Per Andersson)
Subject: Token-ring? - no - Henry Spencer
To: [e-mail]

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
>--
>It is not possible to both understand  | Henry Spencer at U of Toronto Zoology
>and appreciate Intel CPUs. -D.Wolfskill|  [e-mail]   utzoo!henry


I'll have to applaud your .signatures. They are always funny, and often too
true. Keep it up !

Per
--
---
Per Andersson
Royal Institute of Technology, Stockholm, Sweden
[e-mail], @nada.kth.se

------------------------------

End of Packet-Radio Digest
******************************
Date: Tue, 14 Aug 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #116
To: packet-radio


Packet-Radio Digest         Tue, 14 Aug 90       Volume 90 : Issue 116

Today's Topics:
            Backbone connections?
       Collision detect, or controlled-access? (2 msgs)
                Help: TCP info
             Possible alternative to CSMA
     Token-ring? Ethernet? Why not use the parallel-port?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 13 Aug 90 17:59:53 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!rit!cci632![e-mail]  (Just another hired gun (n2hkd))
Subject: Backbone connections?
To: [e-mail]

I was thinking about the NEDA backbone network the other day. Then
I also recalled about the other networks (some were discussed at Dayton).
I guess there's lots I don't understand yet. In all the discussions
here , I don't seem to recall any discussions about T1 carrier, etc.
As far As I can tell the Backbone networks are pretty well single
point interconnects using 9600 (1200-56kb)baud on 220 or 440 and the like.
Having heard that ISDN is nearing it's implementation stage (at least
around here), and knowing that T1 is used to tie ethernet networks
together between buildings across town, I have to start asking myself
about the feasiblity of use. From What I recall a T1 interface is pretty
easy to build and I don't remember it being that expensive, actually
I thought the parts were reasonable in price.
That brings ne to wondering what it would take to interface a
xtal two-way radio to the t1 parts (directly) and make it work.
I know that it's used to microwave, but why can't it be used on
a commercial 440 rig that's modified similiar to the Texas
backbone at 56kb?
Why not do what ISDN is doing and split up the t1 microwave 24
channel between major cities to small 2or 4 channel or even
single channel feeds on standard commercial UHF radios?
If I understand this correctly a ISDN 'B' connection
can handle 1 9600 digital port and (as in at the same time) 2
voice grade lines. It would seem to me that a full duplex
(split channel) connection should not be too difficult to put together.
We could then by using this scheme,
interface and interconnect our voice repeaters as well as send mail
traffic (ftp etc) between our major cities (or hill tops).

I know I'm probably just dreaming, but I'm wondering why there's been
no discussion about this approach coupled with the basic networking
schemes to get from the backbone to my house?

Also has anyone tried a direct digital to radio interface (without
modem)? By using a carrier(rf) detect circuit to qualify the data
on the reciever and then send a preamble (like in a floppy system
format or rs232 asynch) so that the decodeing system can qualify the
data, shouldn't it be possible to achieve fairly decent throughput?
By changing the deviation swing for higher bandwidth, might it
be acceptable, and then connect this to the aforementioned system?

Good God, maybe I should have stayed on vacation a little longer,
I may still not be back to normal....

--

email:   cb@cci632  or !rochester!kodak!n2hkd!curtis
Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450

------------------------------

Date: Mon, 13 Aug 90 17:29:09 BST
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: Collision detect, or controlled-access?
To: [e-mail]

I notice that the moment I mention 'token based' systems, everyone
assumes I meant 'Token-ring'. You can have token-based systems based
on any topology (not necessarily a ring - there are token-buses too!)
Also, someone raised the point of 'how would an unconnected station join in?'.
Well, precisely! Thats half the point. There are many scenarios where
you do not *want* another station to join in! (forwarding or a congested channel
for example; that person joining may collapse the WHOLE system for everyone else
so maybe they should be made to wait till someone drops out and an 'invitation
to join' frame can be sent from the master station?)
The big advantage with a token-based system is that it can be controlled;
nobody speaks until spoken to, so you can limit numbers of connects.
Remember we have in most cases a half-duplex system; a centrally
controlled 'polled' system (think of it as being like a multidrop halfduplex
SDLC circuit) can make some attempt at guaranteeing response times by
using a deterministic algorithm; the current CSMA/CD system cannot
make any such guarantee; particularly at times of high congestion
(like when there are 30 or 40 stations all doing mailbox access on one
1200-baud channel) the CSMA/CD system collapses because everyone shouts
at once and so nobody is heard. Allocation by decibel-count is crude; we can do
better!
Question: Is it better to guarantee a service level to an existing group
by temporarily denying others access, or should anyone be allowed in
irrespective of current loading, even if they crash the system for the
rest of the users?
And has anyone actually analysed working strategies? (for example, I tend to
compile mail messages offline, then connect to the mailbox and do an ASCII
file send, then disconnect again, so keeping my connect times short and
allowing others to use the slot; is this better than connecting and typing
the message a line at a time? When I want net bandwidth I want lots of it
for maybe 5 minutes, as opposed to little of it for, maybe, the hour it
took to compose the messages. Which is best? I guess it might depend on
the loading at the time (which varies..!)).

           Pete Lucas  [e-mail]  0793-411613

------------------------------

Date: 13 Aug 90 19:10:01 GMT
From: pacbell.com!tandem!moe![e-mail]  (Kevin J. Rowett)
Subject: Collision detect, or controlled-access?
To: [e-mail]

In article <13.Aug.90.17:44:08.BST.#[e-mail]>,
[e-mail] ("Pete Lucas, NCS-TLC, Holbrook House,
Swindon") writes:

|> And has anyone actually analysed working strategies?

See the (up coming) 9th CNC proceedings.  Two papers were submitted
which indirectly deal with some of these issues, along with proposed
solutions.

In the analysis done on *one* polling scheme, we learned that overall
throughput does go up, but individual latency degrades *very* quickly
and very badly.

However, I must point out that our goal wasn't to implement a
polling scheme.  We ended up with polling because we wanted to
implemement point to point RF.  Point to Point RF is a little hard to
organize and get going initially, so we settled on a the NBFM rpt
model on a *small* scale.  Our thoughts are along the lines of
a hubmaster with an omni antenna, and cluster members using YAGI
or some other style directional antenna pointing at the hubmaster.

Since secondaries can't hear each other, and the master is HD, we
ended up using polling.

N6RCE

------------------------------

Date: 13 Aug 90 17:27:20 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!rit!cci632![e-mail]  (Just another hired gun (n2hkd))
Subject: Help: TCP info
To: [e-mail]

Hi,
I read some where that there was a TCP newsletter available, but have not
been able to find a pointer in the right direction to order it.
If anyone would be so kind to let me know what would be available...
Also is there a TCP mailing list on Usenet?
Thanks
--

email:   cb@cci632  or !rochester!kodak!n2hkd!curtis
Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450

------------------------------

Date: 13 Aug 90 06:57:05 GMT
From: bellcore-2!thumper.bellcore.com![e-mail]  (Phil R. Karn)
Subject: Possible alternative to CSMA
To: [e-mail]

Since the topic of channel access algorithms has come up, I
thought I might post the paper I just submitted to the ARRL
Computer Networking Conference. Comments are solicited.

To print this paper, run it through [tn]roff -ms. --Phil

.TL
MACA\** - A New Channel Access Method for Packet Radio
.AU
Phil Karn, KA9Q
.AB
The existing Carrier Sense Multiple Access (CSMA) method widely used
in amateur packet radio on shared simplex packet radio channels
frequently suffers from the well-known "hidden terminal problem" and
the less well known but related problem of the "exposed terminal."
This paper proposes a new scheme, Multiple Access with Collision
Avoidance (MACA), that could greatly relieve these problems.  MACA can
also be easily extended to provide automatic transmitter
power control. This could increase the carrying capacity of a channel
substantially.
.AE
.2C
.PP
.FS
MACA is an acronym, not a Spanish word.
.FE
.NH 1
Introduction
.PP
In the classic hidden terminal situation, station Y can hear both
stations X and Z, but X and Z cannot hear each other.
X and Z are therefore unable to avoid colliding with each
other at Y. (See figure 1.)
.PP
In the exposed terminal case (figure 2), a well-sited station X can hear
far away station Y. Even though X is too far from Y to interfere with
its traffic to other nearby stations, X will defer to it unnecessarily, thus
wasting an opportunity to reuse the channel locally. Sometimes there
can be so much traffic in the remote area that the well-sited station
seldom transmits. This is a common problem with hilltop digipeaters.
.PP
This paper suggests a new channel access algorithm for amateur packet
radio use that can minimize both problems. This method, Multiple Access
with Collision Avoidance (MACA), was inspired by the CSMA/CA method
(used by the Apple Localtalk network for somewhat different reasons) and by
the "prioritized ACK" scheme suggested by Eric Gustafson, N7CL, for
AX.25. It is not
only an elegant solution to the hidden and exposed terminal problems,
but with the necessary hardware support it can be extended
to do automatic per-packet transmitter power control. This
could substantially increase the "carrying capacity" of a simplex
packet radio channel used for local communications in a densely
populated area, thus satisfying both the FCC mandate to use "the
minimum power necessary to carry out the desired communications" (Part
97.313) and to "contribute to the advancement of the radio art" (Part
97.1 (b)).
.NH 1
How CSMA/CA Works
.PP
CSMA/CA as used by Localtalk works as follows. When a station wants to
send data to another, it first sends a short Request To Send (RTS)
packet to the destination. The receiver responds with a Clear to Send
(CTS) packet.  On receipt of the CTS, the sender sends its queued data
packet(s). If the sender does not receive a CTS after a timeout, it
resends its RTS and waits a little longer for a reply. This three-step
process (not counting retransmissions) is called a \fIdialogue\fP. Since
a dialogue involves transmissions by both stations, I will avoid
confusion by referring to the station that sends the RTS and data
packets as the \fIinitiator\fP, and the station that sends the CTS as
the \fIresponder\fP.
.PP
The RTS packet tells a responder that data follows. This gives the
responder a chance to prepare, e.g., by allocating buffer space or by
entering a "spin loop" on a programmed-I/O interface.  This is the
main reason Localtalk uses the CSMA/CA dialogue. The Zilog 8530 HDLC
chip used in the Apple Macintosh can buffer the 3-byte Localtalk RTS
packet in its FIFO, but without a DMA path to memory it needs the CPU
to transfer data to memory as it arrives. The CPU responds to the
arrival of an RTS packet by returning a CTS and entering a tight read
loop, waiting for the data to arrive. \** (A timeout prevents a system
lockup if the data never arrives.)
.FS
It would be nice if we could use this feature on packet radio with our
programmed-I/O HDLC interfaces (e.g., DRSI PCPA, Paccomm PC-100).
Unfortunately, if our RTS/CTS packets carry full source and
destination call signs, they would not fit into the 3-byte 8530 FIFOs.
So high speed operation will still require either DMA or a dedicated
I/O processor.
.FE
.PP
As is standard for CSMA schemes, CSMA/CA requires stations to stay off
the channel when another transmission is already in progress.
CSMA/CA also requires any station that overhears an RTS or
CTS packet directed elsewhere to inhibit its transmitter for a
specified time.  This helps reduce the probability of a collision with
a subsequent CTS or data packet.  This is the CA or \fICollision
Avoidance\fP part of CSMA/CA. However, collisions are not a major
problem on Localtalk; the network is physically small, carrier sensing
is fairly rapid, the data rate is relatively low, and (if the network
is properly built) there are no hidden terminals.  Plain CSMA would
work well, but there was little extra cost to the CA feature (given
that the RTS/CTS dialogue was already needed for other reasons) so it
was included.
.NH 1
Turning CSMA/CA into MACA
.PP
Hidden and exposed terminals abound on simplex packet radio channels,
and this makes them very different from Localtalk and most other types
of local area networks.  When hidden terminals exist, lack of carrier
doesn't always mean it's OK to transmit. Conversely, when exposed
terminals exist, presence of carrier doesn't always mean that it's bad
to transmit. In other words, the data carrier detect line from your
modem is often useless. So I'll make a radical proposal: let's ignore
DCD! In other words, let's get rid of the CS in CSMA/CA. (It's too hard
to build good DCD circuits anyway...)
.PP
Instead we'll extend the CA part of what we'll call MA/CA (or just
plain MACA).  The key to collision avoidance is the effect that RTS
and CTS packets have on the other stations on the channel. When a
station overhears an RTS addressed to another station, it inhibits its
own transmitter long enough for the addressed station to respond with
a CTS. When a station overhears a CTS addressed to another station, it
inhibits its own transmitter long enough for the other station to send
its data.  The transmitter is inhibited for the proper time even if
nothing is heard in response to an RTS or CTS packet.
.PP
Figure 3
shows an example.  Station Z cannot hear X's transmissions to Y, but it
\fIcan\fP hear Y's CTS packets to X. If Z overhears a CTS packet from Y
to X, it will know not to transmit until after Y has received its data from X.
.PP
But how does Z know how long to wait after overhearing Y's CTS?
That's easy.
We have X, the initiator of the dialogue, include in its RTS packet the amount
of data it plans to send, and we have Y, the responder, echo that
information in its CTS packet. Now everyone overhearing Y's CTS knows just
how long to wait to avoid clobbering a data packet that it might not
even hear.
.PP
As long as the link between each pair of stations in the network is
reciprocal (i.e., all the stations have comparable transmitter powers
and receiver noise levels), the receipt of a CTS packet by a station
not party to a dialogue tells it that if it were to transmit, it would
probably interfere with the reception of data by the responder (the
sender of the CTS). MACA thus inhibits transmission when ordinary CSMA
would permit it (and allow a collision), thus relieving the hidden
terminal problem. (Collisions are not \fItotally\fP avoided; more on this
point later.)
.PP
Conversely, if a station hears no response to an overheard RTS,
then it may assume that the intended recipient of the RTS is either down or
out of range.  An example is shown in figure 4.
Station X is within range of Y, but not
Z. When Y sends traffic to Z, X will hear Y's RTS packets but not Z's
CTS responses.  X may therefore transmit on the channel without fear
of interfering with Y's data transmissions to Z even though it can hear
them.  In this case, MACA allows a transmission to proceed when
ordinary CSMA would prevent it unnecessarily, thus relieving the
exposed terminal problem. (Because modems have a capture effect,
hearing a CTS doesn't \fIalways\fP mean that you'd cause a collision
if you transmit, so the problem isn't yet completely solved. More on
this point later.)
.NH 1
Metaphors for MACA
.PP
MACA is not really a novel idea; it merely formalizes a procedure many
people (not just radio amateurs) instinctively use in personal
conversation. A typical cocktail party has many simultaneous
conversations. The average guest seldom waits for total silence in the
room before he speaks, but if someone asks him to pause because he is
trying to hear someone else, he will usually do so. The MACA RTS
packet is analogous to Bob saying "Hey, Tom!" and CTS packet is
analogous to Tom responding with "Yeah, Bob?". This causes most people to stop
talking if they are close to Tom (except, of course, for Bob). The same
thing (should) happen in manual amateur radio operation whenever a
station finishes a transmission with "go only" (or "KN" on CW or RTTY).
.PP
The Prioritized ACK scheme also involves overheard packets that
inhibit other stations for specified periods of time.  In this case,
the inhibiting packet is a data packet and the protected station is
sending an acknowledgement that may not be audible at the inhibited
stations.  Full protection against collisions is not provided (data
packets can still collide) but the performance improvement due to the
lower ACK loss rate is reported to be substantial.
.PP
More formally, MACA can also be seen as a single-channel,
time-multiplexed form of Busy Tone Multiple Access (BTMA). In BTMA,
receivers transmit "busy tones" on secondary channels whenever their
receivers are active. This warns the other stations in range that they
should not transmit even if they hear nothing on the data channel. On
the other hand, stations not hearing busy tones are free to transmit
even if there is already a signal on the data channel. Indeed,
stations need not pay any attention at all to the data
channel when deciding to transmit; only the busy channel matters. As
long as the propagation characteristics are identical between the main
and secondary (busy tone) channels, BTMA is effective. Unfortunately,
the need to use widely separated frequencies to avoid
self-interference tends to make the link characteristics less
symmetrical. BTMA also obviously increases the hardware complexity and
spectrum requirements of each user station. On the other hand, because
MACA uses the same channel for the "busy tone" and data, paths
between pairs of stations are much more likely to be symmetrical.
.NH 1
Collisions in MACA
.PP
Unlike BTMA, however, collisions between RTS packets can still occur
in MACA. These are minimized with a randomized exponential back-off
strategy similar to that used in regular CSMA.  Since there is no
carrier sensing in MACA, each station simply adds a random amount to
the minimum interval each station is required to wait after
overhearing an RTS or CTS packet. As in regular CSMA, this strategy
minimizes the chance that several stations will all jump on the
channel at the instant it becomes free. The extra random interval
would be an integral multiple of the "slot time", and in MACA the slot
time is the duration of an RTS packet. If two RTS packets collide
nonetheless, each station waits a randomly chosen interval and tries
again, doubling the average interval on each successive attempt.
Eventually one of them will "win" (i.e., transmit first) and the CTS
from its responder will inhibit the "losing" station until the winning
station can complete its dialogue.
.PP
Even though collisions can occur between RTS packets, MACA still has
the advantage over CSMA as long as the RTS packets are significantly
smaller than the data packets. As long as this is true, collisions
between RTS packets are much less "costly" than the collisions that
would otherwise occur between data packets. The savings in collision
time also pays for the overhead of the RTS and CTS packets.
.PP
As mentioned earlier, the basic MACA protocol only reduces the chances
of collisions involving data packets; it does not guarantee that they
will never occur. This is because a CTS packet requires a certain
minimum signal-to-noise ratio at a station for it to be understood and
obeyed.  Even if the station powers are well matched, a pair of
stations might have just enough of a path between them to allow them
to interfere with each other's reception of weak signals, but not
enough of a path to allow them to hear each other's CTS packets.
Although the seriousness of this problem is unknown, it does appear that
the power-controlled version of MACA discussed later would greatly reduce it.
.NH 1
Bypassing the MACA Dialogue
.PP
If the data packets are of comparable size to the
RTS packets, the overhead of the RTS/CTS dialogue may be excessive. In
this case, a station may choose to bypass the normal dialogue by simply
sending its data without the dialogue. It must, of course, still defer
to any RTS or CTS packets it may overhear.
.PP
Of course, the bypass mechanism carries with it the risk of a
collision. However, for some types of data packets this may be an
acceptable tradeoff. An example might be the acknowledgements in a
sliding-window TCP transfer.\** TCP ACKs are cumulative, so the loss of a
single ACK causes no harm as long as another one gets through before
the sending TCP fills its window.
.FS
The use of sliding windows in TCP might seem to contradict the advice I
gave several years ago to always operate in stop-and-wait
mode (\fBMAXFRAME\fP 1) on half duplex channels. However, that conclusion
applied only to link level protocols; TCP is an
end-to-end transport protocol. Sliding
windows are usually appropriate in a transport protocol even when the
individual hops in the network path are half duplex.
.FE
.NH 1
Automatic Power Control
.PP
MACA lends itself well to automatic transmitter power control. To
support this we need some extra hardware: a D/A
converter that controls transmitter power level, and an A/D converter
that gives received signal strengths. By including calibrated
"S-meter" readings\** in CTS packets, responders could help initiators to
adjust their power levels accordingly.
.FS
Only one point in the S-meter scale really needs to be calibrated.
This is the signal level just high enough to achieve an
acceptable bit error rate. A more completely calibrated scale
makes it easier for the transmitter to zero in on the correct power setting,
but even a simple "too strong/too weak/OK" indication is enough
for a transmitter to determine the correct power level by Newtonian
iteration.
.FE
.PP
Each RTS/CTS exchange updates the initiator's estimate of the power
needed to reach a particular responder so that future packets
(including the data packet in the current dialogue) can be sent with only
the necessary power. Even RTS packets could be sent at reduced power,
since their main purpose is to elicit a CTS from the responder. This
reduces the probability of collision between RTS packets.
.PP
By changing the MACA rule to "inhibit a transmitter when a CTS
packet is overheard" to "temporarily limit power output when a CTS
packet is overheard,"
geographic reuse of the channel can be significantly improved.
For example, if
station X has recently sent traffic to station Y, it knows how much
power is required to reach Y. If X overhears station Y responding with a
CTS to a third station Z, then X need not remain completely silent for the
required interval; it need only limit its transmitter power to, say, 20
dB \** below the level needed to reach Y. During this time it would be free
.FS
This figure depends on the capture ratio of the modems in use.
.FE
to transmit to any station that it could reach with that reduced power
level, because its signal at Y would be overridden by Z's
signal. (This is analogous to the people at the cocktail party
continuing their conversations in whispers instead of stopping
completely when Tom tells Bob to go ahead.)
.PP
The CTS packets, however, pose a problem. In addition to telling the
initiator to send its data, the CTS must inhibit all potential
interferers from transmitting. It may therefore need more power than
that needed just to reach the initiator to ensure that everyone "gets
the message." (A CTS packet might therefore be more like Tom shouting
"Hey, everyone, shut up! I'm trying to hear Bob speak!" at the cocktail
party mentioned earlier.)
.PP
All this shouting potentially limits the geographic channel reuse
ability we've worked so hard to get. But all is not lost.  A station
responding to an RTS with a CTS can always expect data to follow. If it
doesn't arrive within a reasonable period, or if a retransmitted RTS
arrives instead, then either the CTS was stepped on, or the CTS wasn't
heard widely enough to prevent the data transmission that follows from
being stepped on. It should then respond to the next RTS from the same
station (which will likely be a repeated attempt to send the same data)
with a CTS at higher power. On the other hand, if a responder has had
good luck in getting data in response to its CTS packets, it might try
lowering the power it uses to transmit them in order to help limit
channel loading. Of course, it would never lower its CTS power below
the level it knows is necessary to reach the initiator.
.PP
In sum, MACA with power control automatically determines the exact
amount of power required for each RTS and data transmission, and learns
by experience (i.e., trial and error) the power required for CTS
transmissions. It also appears to avoid the runaway power escalation
that can occur when power control is done on a conventional CSMA
channel when stations naively "turn up the wick" each time they fail to get
through. About the only time power escalation seems possible
in MACA is when an initiator's receiver fails so it is not able to hear
CTS responses to its RTS packets no matter how much power the responder
uses. This possibility should be handled by back-offs and/or retry
limits in the dialogue code.
.NH 1
Applications for MACA
.PP
 If MACA proves effective, it may
\fIfinally\fP make single-frequency amateur packet radio networks
practical.  Although it would still be preferable for fixed backbones
to use separate, dedicated channels or point-to-point links whenever
possible, the ability to create usable, ad-hoc, single frequency
networks could be very useful in certain situations. These include
user access channels (such as 145.01 MHz in many areas) and in
temporary portable and mobile operations where it is often infeasible
to coordinate a multi-frequency network in advance. This would be
especially useful for emergency situations in remote areas without
dedicated packet facilities.
.PP
An ideal emergency packet radio network would consist of identical
stations operating on a common frequency (to maximize
interchangeability) placed in arbitrary locations. These stations
would automatically discover their neighbors and build routing and
power control tables that maximize the total amount of traffic that
can be carried in the coverage area. To do this, routing algorithms
would use a different metric than usual. Instead of simply minimizing
the number of hops needed to reach a given destination, the routing
algorithm would instead minimize the \fItotal transmitter energy\fP
required by all the stations along a path to the destination. Because
of the laws of RF propagation (doubling the range of a signal in free
space requires four times as much transmitter power, and on the ground
it may take much more), this approach would often \fIincrease\fP
the number of hops required to reach a given destination. However,
overall network throughput would increase because the lower
transmitter power levels would permit more simultaneous transmissions
to occur in different parts of the network without interference.  This
would also minimize the power consumed at the stations, and this could
be important when operating from batteries. The direct,
minimum-hop path could
still be provided as an option for special applications requiring
minimum delay.
.NH 1
Conclusion and Open Questions
.PP
At the moment, MACA is just an idea. Much simulation and experimental
work needs to be done to answer many questions about how well it will
really work. Here are just some of the questions that can be asked.
How much of the savings from avoided collisions in MACA is spent on
RTS/CTS overhead given typical modem turnaround times and data packet
sizes? How much better does power-controlled MACA perform than the
basic MACA scheme? How about a partial implementation of power
control, e.g., one that relies on trial-and-error instead of explicit
S-meter feedback? How do the various forms of MACA behave as modem
capture ratios change? How serious is the problem of interference from
stations just below threshold?
And how does MACA compare in overall spectral
efficiency with other improved multiple access methods, such as
conventional CSMA or CSMA/CD operation through full duplex repeaters?  I
invite anyone interested in pursuing these topics to contact me.

------------------------------

Date: 13 Aug 90 19:41:29 GMT
From: mejac!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Token-ring? Ethernet? Why not use the parallel-port?
To: [e-mail]

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
>In article <15088@.la.locus.com> [e-mail] (Dana H. Myers) writes:
>>   Now, wait a minute.... you could cheat. The 'standard' IBM printer port
>
>The words "standard" and "IBM" do not belong in the same phrase. :-)  Most
>microcomputer manufacturers are more interested in minimizing cost and chip
>count than in adhering to standards.

   Wellll, you'll notice that I enclosed the word standard in quotes...

> It's not at all unlikely that
>some manufacturers, particularly the AT-on-3-chips types or the battery-
>portable manufacturers, are reading back the register rather than the
>pins, or implementing the port in CMOS that will fry if you make a habit
>of out-muscling its output transistors.

   The intent of providing the ability to read back the pins is for
self-test; I get the impression this includes testing the attached cable
and printer for shorts. It would be inappropriate and incompatible with the
IBM 'standard' not to implement the port this way.

  As for high integrated PCs, I'm a little concerned about the implementation
of the port, also (I was hesitant to post this in the first place). I would
suggest anybody considering method investigate the port; and consider an
alternative -- lifting the /OE pin of the 'LS374 and attaching it to an
I/O port pin somewhere else (I haven't researched this) to allow disabling
the output drivers. This doesn't help you if the 'LS374 has been sucked into
an ASIC :-)

[ BTW - Henry, is there a newsgroup you DON'T read? Do you hire people to
  screen stuff for you? Are you actually a committee of people? :-) ]

*****************************************************************
* Dana H. Myers KK6JQ           | Views expressed here are      *
* [phone] (ex WA6ZGB)    | mine and do not necessarily   *
* [e-mail]                | reflect those of my employer  *
*****************************************************************

------------------------------

End of Packet-Radio Digest
******************************
Date: Wed, 15 Aug 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #117
To: packet-radio


Packet-Radio Digest         Wed, 15 Aug 90       Volume 90 : Issue 117

Today's Topics:
            Backbone connections?
           Collision detect, or controlled-access?
           Need help will 'RLI, 'MBL, email
             TNC Software for the IBM PC
     Token-ring? Ethernet? Why not use the parallel-port?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 14 Aug 90 21:47:31 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: Backbone connections?
To: [e-mail]

>I know that it's used to microwave, but why can't it be used on
>a commercial 440 rig that's modified similiar to the Texas
>backbone at 56kb?

Actually, the TexNet backbone is 9600 baud links on modified commercial UHF
radios using FSK modulation.  The 56kb modems you hear about are a custom RF
modem design by WA4DSY, that uses linear transverter elements to get to/from
the 70cm or whatever bands... it is *not* compatible with existing radios.

>I know I'm probably just dreaming, but I'm wondering why there's been
>no discussion about this approach coupled with the basic networking
>schemes to get from the backbone to my house?

There has been considerable discussion about running megabit datarates on
amateur radio links.  Look at the 12/89 (I think) issue of Ham Radio for the
article by N6GN and N6RCE, the 10/89 issue of 73 for an article by N3EUA, at
the most recent and upcoming ARRL conference proceedings, and at my columns in
the last handful of TAPR Packet Status Registers...

The info is there.  People are working on faster links.  Very little is on the
air right now

Bdale

------------------------------

Date: 14 Aug 90 18:24:43 GMT
From: news-server.csri.toronto.edu!utgpu!utzoo![e-mail]  (Henry Spencer)
Subject: Collision detect, or controlled-access?
To: [e-mail]

In article <13.Aug.90.17:44:08.BST.#[e-mail]> [e-mail] ("Pete Lucas, NCS-TLC, Holbrook House, Swindon") writes:
>... a centrally
>controlled 'polled' system (think of it as being like a multidrop halfduplex
>SDLC circuit) can make some attempt at guaranteeing response times by
>using a deterministic algorithm; the current CSMA/CD system cannot
>make any such guarantee...

Unless you do have a central site, to which the token must always be
returned after one transmission (so that it can be recovered quickly
if lost, by a timeout at that central site), lost tokens make hash of
the "guaranteed" response time of token-based schemes.
--
It is not possible to both understand  | Henry Spencer at U of Toronto Zoology
and appreciate Intel CPUs. -D.Wolfskill|  [e-mail]   utzoo!henry

------------------------------

Date: 14 Aug 90 15:59:14 GMT
From: usc!snorkelwacker!spdcc!mirror!necntc!necis![e-mail]  ( NM1D)
Subject: Need help will 'RLI, 'MBL, email
To: [e-mail]

Ok, Ok, I'll do it!!   I have been under 'considerable' pressure to make
the simple mail system that comes with DOSGATE compatible with the forwarding
mechanism that the AX.25 BBS systems use.   So, to that end:

  Can anyone email me the specifications for interfacing (via AX.25) with
the more popular BBS software (i.e.: 'RLI, 'MBL, etc).

  I need to know how to accept autoforwarded mail, and what the protocol in
detail is...

  Also, I would like to know the details on how to initiate an 'autoforward'
piece of email, either by my system, or by causing one of the BBS's to pick
up mail when it connects to my system.

  Any (and all) help will be appreciated.

  I will incorporate these changes into the next release of DOSGATE.  This and
other improvements should make DOSGATE more interesting to the general
packet community.

  Projects that are currently under development for DOSGATE are:

    AUTOCALL support for the BUCKMASTER HAMCALL CD-ROM  (almost done)

    Improved TNC support (now under test)
    Menu driven EMAIL that works like other BBS's (almost done)
    Autoforwarded EMAIL (under development, see above).

What is DOSGATE?????

   DOSGATE is an MS-DOS device driver (plus some simple DOS application
programs that are included as examples) that allows one to *use* a
PC-compatible DOS computer remotely via AX.25 packet radio.  A user connecting
(via Amateur Packet Radio) finds him/her-self sitting at the DOS prompt, and
can invoke any program that is available on the system from there.
  *Almost* any program that performs only DOS I/O calls can be run and used.
This limits the potential of DOSGATE to your imagination (and possibly to
your programming skills :-) ).

   Enough propoganda.... Thanks in advance for any help,

    Rich (NM1D)

 /**************************************************************************\
 * Rich Bono (NM1D)    If I could only 'C' forever!!    [e-mail] *
 * [phone]          NEC Technologies Inc.                NM1D@WB1DSW *
 \**************************************************************************/

------------------------------

Date: 13 Aug 90 22:55:28 GMT
From: pikes!mercury.cair.du.edu!isis!scicom!zebra![e-mail]  (Vernon C. Hoxie)
Subject: TNC Software for the IBM PC
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
> Several months ago there was a posting about a program for the IBM PC
> that would emulate all of the functions of a TNC.  This software was
> to come from the same German Ham group that wrote a TNC emulator for
> the Commodore 64.  Has anyone seen this program ?

    If any such program is available in source format, I would like
to get a copy to compile on a Unix-PC.

vern
--
Vernon C. Hoxie                {ncar,nbires,boulder,isis}!scicom!zebra!vern
3975 W. 29th Ave.                                       voice: 303-477-1780
Denver, Colo., 80212                              TB+    uucp: 303-455-2670

------------------------------

Date: 14 Aug 90 18:27:47 GMT
From: news-server.csri.toronto.edu!utgpu!utzoo![e-mail]  (Henry Spencer)
Subject: Token-ring? Ethernet? Why not use the parallel-port?
To: [e-mail]

In article <[e-mail]> [e-mail] (Dana H. Myers) writes:
>   The intent of providing the ability to read back the pins is for
>self-test; I get the impression this includes testing the attached cable
>and printer for shorts. It would be inappropriate and incompatible with the
>IBM 'standard' not to implement the port this way.

Unfortunately, unless there is software that actually uses that self-test
capability and will notice if it goes away -- possible, but it's not
something most people run often -- then if it ends up saving five cents
under some set of assumptions, somebody will have done it.

>[ BTW - Henry, is there a newsgroup you DON'T read? Do you hire people to
>  screen stuff for you? Are you actually a committee of people? :-) ]

Lots of newsgroups I don't read, alas. :-)  Thee was a time when I read
everything, but that was long ago.  I wish I *could* hire people to screen
it for me...!  Rumors that I am an AI project are totally unfoundedddd#@$@
<panic ka6=34234 segmentation violation in followup subsystem, rebooting...
current posting truncated...>
--
It is not possible to both understand  | Henry Spencer at U of Toronto Zoology
and appreciate Intel CPUs. -D.Wolfskill|  [e-mail]   utzoo!henry

------------------------------

End of Packet-Radio Digest
******************************
Date: Thu, 16 Aug 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #118
To: packet-radio


Packet-Radio Digest         Thu, 16 Aug 90       Volume 90 : Issue 118

Today's Topics:
             9600 BPS FAX modem on packet
          ?: TAPR DCD modification (2 msgs)
            Backbone connections? (2 msgs)
           Collision detect, or controlled-access?
                Help: TCP info
             Noise performance of modems
     Token-ring? Ethernet? Why not use the parallel-port?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 15 Aug 90 15:18:29 GMT
From: news!cartan!ndmath!nstar!w8grt!f216.n120.z1.fidonet.org![e-mail]  (Jim Grubs)
Subject: 9600 BPS FAX modem on packet
To: [e-mail]

 * Forwarded from "PACKET - 13"
 * Originally from Jeff King
 * Originally dated 08-12-90 22:25

 @MSGID: 1:120/216 150cb329


         9600 BAUD (BPS) FAX TEST RESULTS


Conducted between WB8WKA (NOS TCP/IP) and WA8OOH (MSYS v1.08)

(Please reference my earlier posting "9600 baud FAX MODEM" for a more
detailed description of the circuit.)


Between 7/25/90 and 8/6/90, the amateur radio stations of WB8WKA and WA8OOH
tested a "V.29 FAX modem" chip, the YAMAHA 7109, between there respective
packet radio stations. Distances involved where about 7-8 miles over urban
terrain. Results where quite positive with respect to the performance of the
radio link. Equipment and power levels used at each station follow:


RADIO EQUIPMENT:


WA8OOH                                    WB8WKA
Livonia MI                                Farmington MI

ICOM28A (5 watts)                         KENWOOD 7950+amp (160watts)
MFJ 1270 TNC                              GLB TNC2A
MSYS V1.08 on IBM AT                      NOS on IBM AT

Additional radios where also tested. At WA8OOH, good results where also
obtained with a 215 Kenwood HT at 200-300 milliwatts. A Kenwood 7730 was
also tested with very poor results. Past experience with this radio and the
failure of any PL to function correctly on it may need further investigation.

At WB8WKA, tests where also run at power levels less then 160 watts with
excellent results, but due to the sharing of the radio with one of the
Detroit/Windsor TCP/IP lan's, running lower power full time was not practical.
In addition, a ICOM 2AT was tested at 100mw with excellent results.

Signal strengths at both stations where full scale, even at lower power
levels. Antennas used at WB8WKA consisted of a AEA ISOPOLE at 50' while
at WA8OOH we had a Hustler G7 at 20 feet. All tests where conducted on
2 meters.


THROUGHPUT:

As was to be expected, throughput took a dramatic step up. About one megabyte
of files where moved via tcp/ip, with the throughput hovering around 100
bytes/sec. While this is certainly nowhere near "9600 baud", it was a signifi-
cant jump over earlier tcp/ip testing at 1200 baud. It is thought that there
may be some incompatibilities between msys tcp/ip and net/nos. Tests will
be run latter this week between two msys stations to see if this figure can
be improved upon.

In AX.25 operations, ("user" to bbs) operation was simply put, a dream. By
using the "XF" command in msys, full packets where transferred. Setting "X22"
allowed a full screen to be transferred at a time. Throughput was about
1 page a second, which worked out to be about 6000-8000 bits per second. From
a "user" perspective (I was the user in this case) it made operating the bbs
much more enjoyable. As many of our LAN's in the southeastern MI area our
crowded, the additional speed did not go to waste.

If I may quote WA4DSY, "Oh where oh where is my HIGH SPEED DIGITAL"? What this
means of course, is that we where not able to fully exercise the modems due to
MSYS and/or our TNC's not being able to go beyond 9600 baud. The tnc's where
modified for 19200 baud operations but we experienced dropped characters. In
any type of KISS operation, it is important for maximum throughput, that your
DATA link (async link) be at least twice as fast as your radio link. As we
where not able to achieve this, then our hope is that much faster throughput
can be obtained.


GENERAL IMPRESSIONS:

Audio setup is much more critical. Tones will tend to sound undermodulated.
In addition to audio setup, a "keyup delay" circuit must be setup as well.
This is due to the fact that these modems send a "training sequence" upon
keyup. This must be held off until the radio is fully keyed up. (generally
100-200ms) Once these parameters are set up, things seem to be fairly
stable and the modems can be relied upon in day to day operations.

IMPROVEMENTS:

A easier method for tuneup needs to be developed. If possible, mounting inside
the TNC would also help. Current carrier detect in YAMAHA chip is useless.
Have been unable to get state machine DCD to work on this chip but it is what
is needed. Current layout use's +-5V, this needs to go. Must run on only +5V.
Also will add programming header and mode select DIP switch.

Existing PC (a carbon copy of the PRUG circuit board) needs to be improved.
Quite a bit of digital noise exists on this chip and a re-layout of the
PC board would help greatly.


THOUGHTS:

While my original idea of the use of this modem was "networking", more and more
I am beginning to feel this will be the next step for the end user. In many
applications such as the DX cluster, TCP/IP and bbs operation, increase of
speed on the user LAN is becoming more important. While this modem should be
a fine performer on our "network backbones", the ease of implementation and
the fact that IT CAN BE USED ON EXISTING RADIOS UNMODIFIED should be quite
appealing for the amateur that wishes to increase LAN throughput.

WHATS NEXT:

In the next week or two, I need to re-layout out the circuit board to include
the improvements I have found. In addition, I DESPERATELY need schematics for
TNC's. I have schematics so far for the TNC1, TNC2, PK232 and DRSI. If you
have schematics for any *other* tnc, PLEASE send me a copy to the address
below:

Jeff King WB8WKA
22816 Maple Ave
Farmington, MI 48336.

Also, if you would like copies of the article describing this chip, please
send a SASE to me at the above address.

BETA TEST:

So far, about 16 people have expressed interest in participating in a beta
test of this modem. What this basically means, is that we will all get to-
gether and make a group buy of parts and such to reduce our costs. In addition
of course to the sharing of information that a beta test implies. With a
professionally done PC board and all parts I expect costs to be on the order
of 60-70 dollars. This is of course assuming we can get a decent discount of
the YM7109 (fax chip) as it alone goes for $55!!



73's

Jeff King WB8WKA
Farmington, MI
44.102.0.52        @WA8OOH.MI.USA

--- TAGMAIL v2.30
 * Origin: The <<< Air Studio >>> BBS 313-546-7045 (120:216) (1:120/216)

--
  |\/\/\/|
  |      | Jim Grubs - via FidoNet node 1:234/1
  | (o)(o) UUCP: ...!ncar!asuvax!stjhmc!w8grt!120!216!Jim.Grubs
  |     _) INTERNET: [e-mail]
  | ,___|  ____________________________________________
  |   /     "I wanna go to the ham radio National Park
 /____\         of the Mind and ride the NOS!"

------------------------------

Date: 15 Aug 90 18:17:53 GMT
From: sun-barr!newstop!texsun!sunbird.central.sun.com![e-mail]
Subject: ?: TAPR DCD modification
To: [e-mail]

What exactly is the TAPR DCD modification for the TNC-2?  A new filter
circuit?  An improved demodulator?  New firmware?

I know it lets you run with the squelch open all the time, but I need to
figure out if it is going to be at all useful with a 2400-baud add-on modem.

73,
  Mike  KA9WSB
  [e-mail]    #include <std.disclaimer>

------------------------------

Date: 16 Aug 90 05:46:50 GMT
From: [e-mail]  (Brian Kantor)
Subject: ?: TAPR DCD modification
To: [e-mail]

There are two TAPR DCD mods, depending on the demodulator you have.  If
you have an XR2211 PLL demod (i.e, a TNC-1 or TNC-2), it's just a shift
in the operating parameters of the 2211 to give a much faster lock time
and a little delay circuit to add some hysteresis.  When you install
this in a TNC-2, you also remove a bandpass filter that regrettably had
the effect of making the demodulator worse.  (The TNC-1 had a better
filter - you leave it in place.)

For TNCs with lesser demodulators, such as the 3105, you add a
state machine EPROM to change DCD from an energy-detection circuit to
a real data detection type.

Both mods allow you to leave the squelch open on your FM receiver, which
will often cut your data detect time better than in half.  Since a lot
of the time, people are running with TXDelay of around 30 or so to allow
for the incredibly slow receiver squelches, you can often reduce TXD to
6 or 8 (60 to 80 ms).

Reducing the receiver detect time also reduces the "dead time" - that's
the time between when your transmitter gets on the air and when the
receiving stations figure out that you are on the air - which greatly
reduces the window in which collisions can take place.

By making the DCD actually detect HDLC data instead of energy, you also
get many fewer false data detects, and your TNC won't back off in the
presence of computer noise, idiots whistling on the channel, touchtone,
or RTTY from people with their TNCs in the wrong mode.

The five of the six mountaintop packet nodes that I've installed have
the DCD mod in them, in several different brands of TNC-2 clones, and
they all work excellently (the sixth runs 4800 bps with a K9NG modem
and doesn't need the mod).  The MFJ-1278 comes with the mod already
installed; as far as I know, that's the only TNC that doesn't need it.

One down side: you can't reduce TXD unless everyone you're going to be
talking to has the mods in too - which makes me wonder why so many hams
around here will spend hundreds or thousands of dollars setting up a
packet station but won't spend ELEVEN DOLLARS to put in the DCD mod kit
from TAPR.  All I can figure is that they're too old and feeble to work
on their own equipment - afraid they might drop the soldering iron in
their lap, I guess.  Would do them some good, though.  Sigh. Lead a
horse to water....

For more information, see "Can We Continue to Ignore Level One" by N7CL
in the ARRL Computer Networking papers from a couple of years ago.
        - Brian

------------------------------

Date: 14 Aug 90 13:03:38 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!emcard!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: Backbone connections?
To: [e-mail]

In article <[e-mail]> [e-mail] (Just another hired gun (n2hkd)) writes:
>That brings ne to wondering what it would take to interface a
>xtal two-way radio to the t1 parts (directly) and make it work.
>I know that it's used to microwave, but why can't it be used on
>a commercial 440 rig that's modified similiar to the Texas
>backbone at 56kb?

If you direct FSK the radio, it will need a flat phase bandpass out to
about 6Mhz (just approx, somebody else can do the math:-)) on
transmit and receive. This probably isn't hard for transmit, but
receive would be tough with conventional radios. You really need
a purpose built radio to do this right. Signal to noise ratio degrades
rapidly with increasing bandwidth so high power and short range
compared to FM voice would be the order of the day. Finding 12 Mhz for a
duplex channel on 440 would require drastically rewriting the bandplan.

>Why not do what ISDN is doing and split up the t1 microwave 24
>channel between major cities to small 2or 4 channel or even
>single channel feeds on standard commercial UHF radios?
>If I understand this correctly a ISDN 'B' connection
>can handle 1 9600 digital port and (as in at the same time) 2
>voice grade lines. It would seem to me that a full duplex
>(split channel) connection should not be too difficult to put together.
>We could then by using this scheme,
>interface and interconnect our voice repeaters as well as send mail
>traffic (ftp etc) between our major cities (or hill tops).

Great idea!

>I know I'm probably just dreaming, but I'm wondering why there's been
>no discussion about this approach coupled with the basic networking
>schemes to get from the backbone to my house?

Work is being done on T1 rates over microwave links. Bdale has mentioned
this before and even showed some hardware at Dayton.

>Also has anyone tried a direct digital to radio interface (without
>modem)? By using a carrier(rf) detect circuit to qualify the data
>on the reciever and then send a preamble (like in a floppy system
>format or rs232 asynch) so that the decodeing system can qualify the
>data, shouldn't it be possible to achieve fairly decent throughput?
>By changing the deviation swing for higher bandwidth, might it
>be acceptable, and then connect this to the aforementioned system?

GLB tried this with their 19.2kb digital radios. There are severe
problems with this approach. Some of the problems are; excessive
bandwidth per baud, the signal has a major dc component making AFC
difficult, temperature drift without workable AFC becomes a serious
problem, poor signal to noise ratio due to excessive bandwidth and
poor frequency control. The Grapes 56kb modem uses QPSK for 4 bits
per hertz and minimum shift keying to hold down bandwidth. With a
data randomizer, there is no dc component and the tracking data
detector can handle up to 20khz drift. This modem is basically
a purpose built radio for data, it's input and output are at 29Mhz
allowing a transverter to place it on any VHF/UHF band. The design
is scalable to higher baudrates with faster A/D converters and
waveform lookup ROMS.

Gary KE4ZV

------------------------------

Date: 15 Aug 90 13:05:01 GMT
From: [e-mail]  (Mike Chepponis)
Subject: Backbone connections?
To: [e-mail]

In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>
>GLB tried this with their 19.2kb digital radios. There are severe
>problems with this approach. Some of the problems are; excessive
>bandwidth per baud, the signal has a major dc component making AFC
>difficult, temperature drift without workable AFC becomes a serious
>problem, poor signal to noise ratio due to excessive bandwidth and
>poor frequency control. The Grapes 56kb modem uses QPSK for 4 bits
>per hertz and minimum shift keying to hold down bandwidth. With a
>data randomizer, there is no dc component and the tracking data
>detector can handle up to 20khz drift. This modem is basically
>a purpose built radio for data, it's input and output are at 29Mhz
>allowing a transverter to place it on any VHF/UHF band. The design
>is scalable to higher baudrates with faster A/D converters and
>waveform lookup ROMS.
>
>Gary KE4ZV

The TAPR PacketRadio is FSK, with a scrambler to remove the DC component.
It reportedly works very well.

The WA4DSY 56k modem uses band limited MSK (Straight MSK is sometimes called
fast FSK, because the data rate is high relative to the bandwidth compared with
traditional FSK).  The spectral efficency is approximately 56k bits/sec / 70
kHz = 0.8 bits/sec/Hz.  It is definitely NOT QPSK, which transmits 4 states (2
bits) per baud.  QPSK is also called 4-PSK.  (For comparison, the current crop
of digital satellites use BPSK, also known as 2-PSK, mostly because there is no
amplitude variation in the signal and simple receivers using digital logic can
be built because the signal can be hard limited.  But that's a different
story...).

Marc Kaufman, WB6ECE, has designed a modulation EPROM for straight MSK; this
results in a spectral efficency of 56k b/sec / 105 kHz = 0.53 bit/sec/Hz, but
with the tradeoff of having a constant envelope; therefore, class C
transmit converters be used with his modulation EPROM.

Lastly, there are no A/D converters in the WA4DSY design, only a pair of
D/A converters that are used to convert the EPROM numerical values into I and
Q channels for modulation.  And although I haven't tried it, the specified
D/A converters (DAC-08) are supposed to easily work at higher data rates,
like 128 kbit/sec.

I know that Phil Karn reviewed this modem for 73 Magazine last year for the
special packet issue (the one with the N6GN/N6RCE/N3EUA Microwave Dish on the
front cover), and Phil had an excellent summary of how this modem works.

The WA4DSY modem is indeed a nifty design!  It has been in existence for
nearly 4 years now, available to the ham population from GRAPES.  Now, if
we could just suck up that random logic into a Xliinx chip or one of the
super PALs" that are now appearing, and use some of the Signetics or Plessey
chips for a lot of the RF part, and use surface mount technology, that modem
could shrink to be maybe 2" x 4" (!).

Lastly, for those of you doing modem design out there, consider using the
WA4DSY 17-bit shift register as your scrambler.  Dale, WA4DSY, told me that
there are problems with the (then most common) K9NG scrambler that the DSY
scrambler avoided.  I don't understand this, maybe Dale or somebody else can
explain this!


-Mike K3MC

------------------------------

Date: 16 Aug 90 04:53:22 GMT
From: pacbell.com!tandem!moe![e-mail]  (Kevin J. Rowett)
Subject: Collision detect, or controlled-access?
To: [e-mail]

In article <[e-mail]>,
[e-mail] (Henry Spencer) writes:
|>
|> Unless you do have a central site, to which the token must always be
|> returned after one transmission (so that it can be recovered quickly
|> if lost, by a timeout at that central site), lost tokens make hash of
|> the "guaranteed" response time of token-based schemes.

A technique that works for Token-Bus is for the token passer to listen
for activity from the station he passed it to.

N6RCE

------------------------------

Date: 15 Aug 90 14:46:20 GMT
From: wang!tegra![e-mail]  (Johnathan Vail)
Subject: Help: TCP info
To: [e-mail]

In article <[e-mail]> [e-mail] (Just another hired gun (n2hkd)) writes:

   I read some where that there was a TCP newsletter available, but have not
   been able to find a pointer in the right direction to order it.
   If anyone would be so kind to let me know what would be available...
   Also is there a TCP mailing list on Usenet?

The New England TCPer is one such newsletter.  I probably have an old
copy around in postscript if anyone would like a sample issue. The
info to subscribe is:

 6 ISSUES 1 YR  FOR ONLY$12.00
12 ISSUES 2 YRS FOR ONLY $22.00
18 ISSUES 3 YRS FOR ONLY $32.00

Send to:        The NE TCPer
        252 Stow Rd.
        Harvard, MA
        01451


There is a mailing list both is raw and digested form.  The info for
that is:

    Send Replies or notes for publication to: <[e-mail]>
    Send requests of an administrative nature (addition to, deletion from the
    distribution list, et al) to: <[e-mail]>

    Archives of past issues of the TCP-Group Digest are available
    (by FTP only) from UCSD.Edu in directory "mailarchives".



Stattinger's Law: It works better if you plug it in.
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

------------------------------

Date: Wed, 15 Aug 90 15:00:00 EDT
From: [e-mail] (Barry McLarnon DGBT/DIP)
Subject: Noise performance of modems
To: [e-mail]

Dana Meyers writes:
>I just finally bought several of the Computer Networking Conference books.
>These are excellent, much better than I'd expected. I'd HIGHLY recommend
>going out and buying them.
>
>Anyway, I've heard people complain (myself included) that the Carrier
>Detect mechanism on the Am7910 is poor, while the XR-2211 is quite a bit
>better. Of course, using a DPLL/State Machine for coherent data carrier
>detect is by far the best approach, so it really doesn't matter how poor
>the carrier detect provided by the demodulator is. What is important,
>however, is good data recovery in the modem.
>
>What is ironic, is how poor the XR-2211 fares in terms of noise performance.
>Page 110 of the 6th Computer Network Conference contains LU4DXT's paper
>on measuring th noise performance of several popular modems. In order to
>achieve a Bit Error Rate of less than 1e-04, the 2211 requires a S/N of
>24.2 dB, while the 7910 requires only 12.3 dB S/N.

This is a bit late, but I haven't noticed any replies to this posting.
I was surprised when those results came out, and shortly after they were
published, I had an opportunity to ask Lyle Johnson of TAPR about them.
He said that the author had not used the proper component values in his
XR-2211 test circuit.  Instead of duplicating the 2211 modem from the
TNC-2, he had used a circuit from an Exar application note, one which
apparently contained several errors.  Lyle was confident that the 2211
modem performance was *not* worse than the 7910 and other single-chip
modems.  Subsequent comparative tests by N7CL have borne out this
conclusion.

Barry VE3JF

---
| Barry McLarnon     Communications Research Center, Ottawa, ON, Canada |
| Internet: [e-mail]           UUCP: ...uunet!mitel!dgbt!barry |
| Packet BBS: VE3JF@VE3JF        AMPRnet: [e-mail]3jf [44.135.96.6] |

------------------------------

Date: 15 Aug 90 20:37:57 GMT
From: usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!cunews!bcars8!bnrgate!bcarh342![e-mail]  (Marcus Leech)
Subject: Token-ring? Ethernet? Why not use the parallel-port?
To: [e-mail]

In article <[e-mail]>, [e-mail] (Henry Spencer) writes:
> In article <[e-mail]> [e-mail] (Dana H. Myers) writes:
>
> >[ BTW - Henry, is there a newsgroup you DON'T read? Do you hire people to
> >  screen stuff for you? Are you actually a committee of people? :-) ]
>
Having worked with [e-mail] for a couple of years, I can
  assure everyone that he is an AI project.  ;-) ;-) ;-)

-----------------
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
[e-mail]                  P.O. Box 3511, Stn. C   |are my own, and not
[e-mail]         Ottawa, ON, CANADA      |necessarily BNRs

------------------------------

End of Packet-Radio Digest
******************************
Date: Fri, 17 Aug 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #119
To: packet-radio


Packet-Radio Digest         Fri, 17 Aug 90       Volume 90 : Issue 119

Today's Topics:
        9600 BPS FAX modem on packet (2 msgs)
               ?: TAPR DCD modification
            Backbone connections?
           Collision detect, or controlled-access?
         French firms making Packet radio equipment?
                Help: TCP info
             NOS.EXE & "--more--"

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 16 Aug 90 23:41:59 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: 9600 BPS FAX modem on packet
To: [e-mail]

>While my original idea of the use of this modem was "networking", more and more
>I am beginning to feel this will be the next step for the end user. In many
>applications such as the DX cluster, TCP/IP and bbs operation, increase of
>speed on the user LAN is becoming more important.

I firmly believe this, and it's why we're working hard on speed improvements
in our local groups in Colorado right now, instead of losing too much sleep
over upgrading our stinking 1200 baud wide area links...  maybe next year.

Bdale

------------------------------

Date: 17 Aug 90 01:36:11 GMT
From: fernwood!portal!cup.portal.com![e-mail]
Subject: 9600 BPS FAX modem on packet
To: [e-mail]

has anyone used the standard fax cards that plug into an ibm to send and
receive data.between two or more computers.ie transferring the bytes
thru the parallel ports?i am working on a point to multipoint application
via satellite and the fax cards are available for as low as 149.00 which
makes them very attractive
rgds.

------------------------------

Date: 16 Aug 90 16:09:12 GMT
From: hpl-opus!hpspdra![e-mail]  (Henry Black)
Subject: ?: TAPR DCD modification
To: [e-mail]

[e-mail] writes:

> What exactly is the TAPR DCD modification for the TNC-2?  A new filter
> circuit?  An improved demodulator?  New firmware?
> . . .
>  Mike  KA9WSB

 Try  Tucson Amateur Packet Radio
      P.O. Box 12925
      Tucson
      AZ 85732
      [phone] (Voice)       [phone] (FAX)
---------------------------------------------------------------------------
Henry Black   G4NOC, KK6JR     [e-mail]
Purely my personal views

------------------------------

Date: 15 Aug 90 21:39:34 GMT
From: usc!wuarchive!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: Backbone connections?
To: [e-mail]

In article <[e-mail]> [e-mail] (Mike Chepponis) writes:
>In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>>
>>GLB tried this with their 19.2kb digital radios. There are severe
>>problems with this approach. Some of the problems are; excessive
>>bandwidth per baud, the signal has a major dc component making AFC
>>difficult, temperature drift without workable AFC becomes a serious
>>problem, poor signal to noise ratio due to excessive bandwidth and
>>poor frequency control. The Grapes 56kb modem uses QPSK for 4 bits
>>per hertz and minimum shift keying to hold down bandwidth. With a
>>data randomizer, there is no dc component and the tracking data
>>detector can handle up to 20khz drift. This modem is basically
>>a purpose built radio for data, it's input and output are at 29Mhz
>>allowing a transverter to place it on any VHF/UHF band. The design
>>is scalable to higher baudrates with faster A/D converters and
>>waveform lookup ROMS.
>>
>>Gary KE4ZV
>
>The TAPR PacketRadio is FSK, with a scrambler to remove the DC component.
>It reportedly works very well.
>
>The WA4DSY 56k modem uses band limited MSK (Straight MSK is sometimes called
>fast FSK, because the data rate is high relative to the bandwidth compared with
>traditional FSK).  The spectral efficency is approximately 56k bits/sec / 70
>kHz = 0.8 bits/sec/Hz.  It is definitely NOT QPSK, which transmits 4 states (2
>bits) per baud.  QPSK is also called 4-PSK.  (For comparison, the current crop
>of digital satellites use BPSK, also known as 2-PSK, mostly because there is no
>amplitude variation in the signal and simple receivers using digital logic can
>be built because the signal can be hard limited.  But that's a different
>story...).
>
>Marc Kaufman, WB6ECE, has designed a modulation EPROM for straight MSK; this
>results in a spectral efficency of 56k b/sec / 105 kHz = 0.53 bit/sec/Hz, but
>with the tradeoff of having a constant envelope; therefore, class C
>transmit converters be used with his modulation EPROM.
>
>Lastly, there are no A/D converters in the WA4DSY design, only a pair of
>D/A converters that are used to convert the EPROM numerical values into I and
>Q channels for modulation.  And although I haven't tried it, the specified
>D/A converters (DAC-08) are supposed to easily work at higher data rates,
>like 128 kbit/sec.
>
>I know that Phil Karn reviewed this modem for 73 Magazine last year for the
>special packet issue (the one with the N6GN/N6RCE/N3EUA Microwave Dish on the
>front cover), and Phil had an excellent summary of how this modem works.
>
>The WA4DSY modem is indeed a nifty design!  It has been in existence for
>nearly 4 years now, available to the ham population from GRAPES.  Now, if
>we could just suck up that random logic into a Xliinx chip or one of the
>super PALs" that are now appearing, and use some of the Signetics or Plessey
>chips for a lot of the RF part, and use surface mount technology, that modem
>could shrink to be maybe 2" x 4" (!).
>
>Lastly, for those of you doing modem design out there, consider using the
>WA4DSY 17-bit shift register as your scrambler.  Dale, WA4DSY, told me that
>there are problems with the (then most common) K9NG scrambler that the DSY
>scrambler avoided.  I don't understand this, maybe Dale or somebody else can
>explain this!
>
>
>-Mike K3MC

Mike is correct. The A/D D/A thing was a typo. QPSK is the wrong term,
the modem shifts 90 degrees for each bit time. The signal constellation
looks like a diamond inscribed in a circle with four points. At the
risk of using the wrong terms again :-(, the modem "carrier" is
14,000 hertz and is shifted plus or minus 90 degrees for each zero
or one in the data stream. According to the manual, the modulation
method is called bandwidth limited MSK which has a -26db bandwidth
of 1.25hz/baud or 70khz for 56kb. The waveform has a 3.5db amplitude
variation designed to eliminate unwanted sidebands.

The scrambler, in Dale's words, "makes the RF spectrum look and sound
like band limited white noise". In other words, the RF energy is
spread evenly over the bandpass and shows no single frequency spectral
lines regardless of the data being transmitted. This makes the tracking
data detector and clock recovery circuits work better because there
is no DC component. It also means that adjacent channels would, at
worst, see only a slight increase in the noise floor rather than
assorted squeaks and squawks.

I am no expert in modem theory, I have built two of these modems
and tuned them up. They work as advertised. My personal experience
with them is that they are extremely stable and have required no
tweaks over a two year period in unconditioned locations.

Gary KE4ZV

------------------------------

Date: 16 Aug 90 19:52:47 GMT
From: ncrlnk!ncrstp!npdiss1![e-mail]  (John Montague)
Subject: Collision detect, or controlled-access?
To: [e-mail]

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
>Unless you do have a central site, to which the token must always be
>returned after one transmission (so that it can be recovered quickly
>if lost, by a timeout at that central site), lost tokens make hash of
>the "guaranteed" response time of token-based schemes.

While it is true that a token passing scheme must accomodate the recovery of a
lost token condition, there is no requirement for a "central site" to monitor
or parcel out the token.  An example of a scheme that does not use a central
site is the ANSI/IEEE Standard 802.5 {aka ISO 8802-5} MAC protocol which not
only decentralizes the token monitoring process but provides a robust and rapid
token recovery scheme.  There are many others; I refer you to the Cambridge
Ring, and Token Bus (ANSI/IEEE 802.4) for other examples.

John Montague           [e-mail]         W0RUE@WB0GDB

------------------------------

Date: Thu, 16 Aug 90 17:11:03 GMT
From: uunet!f4.n494.z5.fidonet.org!VICSHAW.FRDVAX (VICSHAW FRDVAX)
Subject: French firms making Packet radio equipment?
To: [e-mail]

X-Envelope-to: [e-mail]
X-VMS-To: UCTVAX::IN%"[e-mail]",VICSHAW

Can anyone tell me the names of firms in France which manufacture and supply
packet-radio equipment?

Vic Shaw
[e-mail]
--
uucp: uunet!m2xenix!puddle!5!494!4!VICSHAW.FRDVAX
Internet: [e-mail]

------------------------------

Date: 17 Aug 90 03:16:00 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: Help: TCP info
To: [e-mail]

> If I understand this correctly a ISDN 'B' connection
> can handle 1 9600 digital port and (as in at the same time) 2
> voice grade lines. It would seem to me that a full duplex
> (split channel) connection should not be too difficult to put together.
> We could then by using this scheme,
> interface and interconnect our voice repeaters as well as send mail
> traffic (ftp etc) between our major cities (or hill tops).

How about letting the full bandwith of the connection be used by TCP/IP
and run the voice grade as an application over that?

> I know I'm probably just dreaming, but I'm wondering why there's been
> no discussion about this approach coupled with the basic networking
> schemes to get from the backbone to my house?

Probably because everyone else has been afraid of being called a dreamer :-)

> Also has anyone tried a direct digital to radio interface (without
> modem)? By using a carrier(rf) detect circuit to qualify the data
> on the reciever and then send a preamble (like in a floppy system
> format or rs232 asynch) so that the decodeing system can qualify the
> data, shouldn't it be possible to achieve fairly decent throughput?
> By changing the deviation swing for higher bandwidth, might it
> be acceptable, and then connect this to the aforementioned system?

I can't quite follow what you are talking about, but I think you will
run into some technical problems, and once you solve them you will have
re-invented the modem.  A "modem" is a (MO)dulator-(DEM)odulator.  You
do have to "modulate" even if it is simple ON-OFF digital.

--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society
<[e-mail]> | no matter what the particular issue is all about.

------------------------------

Date: 16 Aug 90 19:13:50 GMT
From: mailrus!usenet.ins.cwru.edu!ncoast![e-mail]  (Terry Bell)
Subject: NOS.EXE & "--more--"
To: [e-mail]

Can the "--more--" prompt be disabled from the mailbox prompt line?
--
Terry Bell N8HSP @WA8BXN.OH.USA.NA  AMSAT-NA [44.70.4.10] [e-mail]
Internet: [e-mail]           UUCP: uunet!cwjcc!ncoast!tbell
American Red Cross           Emergency Communications          Cleveland, Ohio

------------------------------

End of Packet-Radio Digest
******************************
Date: Sat, 18 Aug 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #120
To: packet-radio


Packet-Radio Digest         Sat, 18 Aug 90       Volume 90 : Issue 120

Today's Topics:
       Collision detect, or controlled-access? (2 msgs)
              French packet manufacturer
              GRAPES modem and Macintosh
             Noise performance of modems
             NOS.EXE & "--more--"
    Token-ring? Ethernet? Why not use the parallel-port? (3 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 17 Aug 90 14:54:59 GMT
From: cellar![e-mail]  (Martin Harriss (ACP))
Subject: Collision detect, or controlled-access?
To: [e-mail]

In article <[e-mail]> [e-mail] (John Montague) writes:

[stuff deleted ]

>  There are many others; I refer you to the Cambridge
>Ring, and Token Bus (ANSI/IEEE 802.4) for other examples.
>
>John Montague           [e-mail]         W0RUE@WB0GDB

Last I knew, the Cambridge Ring used a central control station to
regenerate the token if it got lost.  Is there now a new version which
does not require this? if so, can someone point me to a reference?

Martin Harriss kb2jyz
[e-mail]

------------------------------

Date: 17 Aug 90 17:29:39 GMT
From: mailrus!news-server.csri.toronto.edu!utgpu!utzoo![e-mail]  (Henry Spencer)
Subject: Collision detect, or controlled-access?
To: [e-mail]

In article <[e-mail]> [e-mail] (John Montague) writes:
>>Unless you do have a central site, to which the token must always be
>>returned after one transmission (so that it can be recovered quickly
>>if lost, by a timeout at that central site), lost tokens make hash of
>>the "guaranteed" response time of token-based schemes.
>
>While it is true that a token passing scheme must accomodate the recovery of a
>lost token condition, there is no requirement for a "central site" to monitor
>or parcel out the token...

Please read what I wrote.  The question is not whether you need a central
site -- of course you don't -- but whether you can meet *guaranteed response
times* with a decentralized recovery algorithm.  Real-time ones, I mean.
Last I heard, the worst-case delay in an 802.5 system was a fair fraction
of a second in certain cases of token loss.
--
It is not possible to both understand  | Henry Spencer at U of Toronto Zoology
and appreciate Intel CPUs. -D.Wolfskill|  [e-mail]   utzoo!henry

------------------------------

Date: Fri, 17 Aug 90 13:42:22 CDT
From: [e-mail]
Subject: French packet manufacturer
To: [e-mail]

From:   HUTIN@PSI%EPSX25@MRGATE@PRSRTR
To:     "[e-mail]"@M_INTERNET@MRGATE@PRSRTR


As far as i know , there is no french packet equipment manufacturer.
The main dealer for US equipments is:
GES
172 rue de charenton
75012 PARIS
FRANCE
Phone: [phone]
above is FAX number
Phone: [phone]

73s from Paris
FE6CNB Remi

------------------------------

Date: Fri, 17 Aug 90 14:09 MET
From: "Adam van Gaalen (PA2AGA/PI8MAC) DGV-TNO (31)15697283" <[e-mail]>
Subject: GRAPES modem and Macintosh
To: [e-mail]

Hello all

Does anybody have any experience on GRAPES modems connected to a Mac?

If so:

1) Can we connect this moden to one of the serialports or
2) Do we need extra hardware (software)

Any reply will be appreciated.

73 de Adam van Gaalen.

+------------------------------------------------------------------------+
| Please send your reply to:                 | Where  | Mac  | Software  |
|--------------------------------------------+--------+------+-----------|
|     Internet: [e-mail]              | office | SE   | NCSATelnet|
|           or: [e-mail]                |  same  | same | DynaComm  |
| Packet-radio: pa2aga@pa2aga  (44.137.32.9) | at home| Plus | NET/Mac   |
|           or: pa2aga@pa2aga-2(44.137.32.19)| at home| 512Ke| NET/Mac   |
|           or: pa2aga@pi8mac  (44.137.32.22)| at home| SE/30| NET/Mac   |
+------------------------------------------------------------------------+

------------------------------

Date: 17 Aug 90 19:16:30 GMT
From: usc!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Noise performance of modems
To: [e-mail]

In article <[e-mail]> [e-mail] (Barry McLarnon DGBT/DIP) writes:
>Dana Meyers writes:
      ^^^^^^ heh-heh. I spell it Myers; look in my signature below :-)
>>I've heard people complain (myself included) that the Carrier
>>Detect mechanism on the Am7910 is poor, while the XR-2211 is quite a bit
>>better. Of course, using a DPLL/State Machine for coherent data carrier
>>detect is by far the best approach, so it really doesn't matter how poor
>>the carrier detect provided by the demodulator is. What is important,
>>however, is good data recovery in the modem.
>>
>>What is ironic, is how poor the XR-2211 fares in terms of noise performance.
>>Page 110 of the 6th Computer Network Conference contains LU4DXT's paper
>>on measuring the noise performance of several popular modems. In order to
>>achieve a Bit Error Rate of less than 1e-04, the 2211 requires a S/N of
>>24.2 dB, while the 7910 requires only 12.3 dB S/N.
>
>This is a bit late, but I haven't noticed any replies to this posting.
>I was surprised when those results came out, and shortly after they were
>published, I had an opportunity to ask Lyle Johnson of TAPR about them.
>He said that the author had not used the proper component values in his
>XR-2211 test circuit.  Instead of duplicating the 2211 modem from the
>TNC-2, he had used a circuit from an Exar application note, one which
>apparently contained several errors.  Lyle was confident that the 2211
>modem performance was *not* worse than the 7910 and other single-chip
>modems.  Subsequent comparative tests by N7CL have borne out this
>conclusion.

    I should point out that I was surprised also. I suspect the
presence of the 'equalizer' filter in the TNC-2 probably does a lot
to help. On the other hand, the researcher probably picked up the
XR-2211 data sheet and used the manufacturer's recommended circuit,
and picked up the Am7910 data sheet and used the manufacturer's
recommended circuit. This, from a research point of view, is valid,
though not terribly useful in the packet context where most folks
are using the TNC-2 circuit. What would have been most useful in
the original paper by LU4DXT would have been to include the
specific circuit he used in his tests; I recall noting the
absence.

   I'd be interested in the results of comparing the TNC-2 demodulator
with a 'standard' XR-2211 demodulator. Furthermore, I'd be interested
in comparing an Am7910 with and without the internal equalizer filter
enabled.

  Of course, as soon as DSP based modems become cost competitive in
packet radio, this is all moot... 1/2 :-), since I think the DSP
concept is excellent but the cost is a prohibitive factor... Maybe
what we really need is a $75-$125 do-it-all modem based on a DSP.. :-)

*****************************************************************
* Dana H. Myers KK6JQ           | Views expressed here are      *
* [phone] (ex WA6ZGB)    | mine and do not necessarily   *
* [e-mail]                | reflect those of my employer  *
*****************************************************************

------------------------------

Date: 17 Aug 90 16:52:49 GMT
From: idacrd![e-mail]  (Robert McGwier)
Subject: NOS.EXE & "--more--"
To: [e-mail]



------------------------------

Date: 15 Aug 90 14:43:04 GMT
From: hpfcso!hppad![e-mail]  (David Lapp)
Subject: Token-ring? Ethernet? Why not use the parallel-port?
To: [e-mail]

Re. 'bidirectional' printer ports on IBM's

The 'standard' IBM printer adapter does support reading of the
data pins on the printer port but the IBM documentation also
warns against an external device driving them. On the other
hand many people seem to use the printer port for input and
get away with it. I'm fairly sure that they aren't all using
the control lines to pass data!

Some of the 'integrated' chips used for the parallel (and serial
and ...) port in newer clones provide a pin that controls the 'direction'
of the printer port. The IBM PS2 adapter defines a bit in the control
register to do this. But all this is hardly universal. If the resulting
box is IBM specific then why not design it as an expansion card?
(OK that leaves out MCA (ie. PS2) but surely ISA based clones are going
to be more common for sometime to come?)

This suggestion has come up before on this group.
Has anyone (who reads this group of course :-) got any experince
writing software to use an IBM printer port bidirectionally?
Do printer ports on other machines work bidirectionally?

Dave Lapp
[e-mail]

The above thoughts all came out of my head through my fingers -
they are all mine - of course i'm giving of them freely...

------------------------------

Date: 17 Aug 90 16:01:43 GMT
From: [e-mail]  (Brian Kantor)
Subject: Token-ring? Ethernet? Why not use the parallel-port?
To: [e-mail]

On most of the PC/XT/AT and clones, the parallel printer port data lines
are driven by a tri-state latch or driver that has its output enable
nailed on.  There is also an input port attached to these lines to
enable the self-test to read back the data when doing a looparound test.

If you drive the pins hard enough, you'll overcome the output drive of
the latch in the adaptor board, and you'll be able to read the data
you've shoved into the adapator.  This is a bad idea, since it will
definitely shorten the life of both the adaptor's output latch and
whatever it is you're attaching's output latch.

A simple way to make the port bidirectional is to cut the trace going to
the output latch's output enable, and run it out to one of the
otherwise-unused pins on the blue-ribbon connector.  If you do it
through an unused inverter and add a pullup resistor, it will default to
the normal mode, and you need only pull the line down when you want the
PC to be able to read from the port.

Some Taiwan-Tailgate parallel adaptor boards have a jumper to do just
that, or may already be wired that way.

The commercial i/o-on-the-parallel-port widgets I've seen DO use just
the handshaking and status lines, since you can't depend on the
bidirectional capability of the data lines being present.
    - Brian

------------------------------

Date: 18 Aug 90 03:43:42 GMT
From: [e-mail]  (David Boyes)
Subject: Token-ring? Ethernet? Why not use the parallel-port?
To: [e-mail]

In article <[e-mail]> [e-mail] (David Lapp) writes:
>Re. 'bidirectional' printer ports on IBM's
>This suggestion has come up before on this group.
>Has anyone (who reads this group of course :-) got any experince
>writing software to use an IBM printer port bidirectionally?

Far, far too much. The only case where I was able to dependably
make reading from the parallel adapter work was on a PS/2. The
original monochrome display/printer adapter would work 50-60% of
the time -- it depended on the card -- and most of the clones
I had access to (no-name Asian make) didn't bother worrying about
what would happen if someone tried to input from the parallel
printer port -- they designed it to published IBM spec, which
only does output.

(if anyone cares, the project was to monitor some 1-bit sensors
surgically embedded in a bunch of sea anemones to see how muscle
contractions work in invertebrates. It was kind of a silly study,
but it had some cool gadgetry involved...)

>Do printer ports on other machines work bidirectionally?

Many machines have bidirectional parallel ports -- warm fuzzies
to you guys at HP for putting one on darn near everything you
make -- but not all "printer" ports are bidirectional. Like
everything else, it's a question of design. Well-designed I/O
ports work both ways, and the others .... 8-(.

>Dave Lapp
>[e-mail]
--
David Boyes       |  "Where's the ka-boom? There's supposed to be an
[e-mail]   |  Earth-shattering ka-boom!...Heavens! Someone has
          |  stolen the Illudium Q-38 Explosive Space Modulator!
"Delays, delays!" |  The Earth creature has *stolen* the Space Modulator!"

------------------------------

Date: (null)
From: (null)
NOOO, please don't!!  I want it to look as much like my Unix box as possible!

Bob

--
____________________________________________________________________________
    My opinions are my own no matter    |       Robert W. McGwier, N4HY
    who I work for! ;-)                 |       CCR, AMSAT, etc.
----------------------------------------------------------------------------

------------------------------

End of Packet-Radio Digest
******************************
Date: Sun, 19 Aug 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #121
To: packet-radio


Packet-Radio Digest         Sun, 19 Aug 90       Volume 90 : Issue 121

Today's Topics:
              GRAPES modem and Macintosh

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: Sat, 18 Aug 90 22:39:24 EDT
From: [e-mail] (Doug Yuill)
Subject: GRAPES modem and Macintosh
To: [e-mail]

Adam van Gaalen asks:
"Does anybody have any experience on GRAPES modems connected to a Mac?"

  I have been using a Grapes modem with my Mac for about a year now and happy
to report VERY good results!
On the software side I am running KA9Q's NET for the Mac which supports
separate windows for all your sessions, very nice when you want to run with
trace on. I use a 10 meter long cable to connect to a Pac-Comm tiny-2 TNC
running KISS-56. I use the modem port at a data rate of 57.6k baud.
I had to REALLY soup-up the tnc to get this data rate. The maximum rate
supported by the tnc on the terminal port was 19.2k baud, I surmised that by
tripling the master clock, I could achieve the desired 57.6k baud. This worked
ok. I did however have to jumper the tnc for 1/2 speed operation of the Z-80
cpu, aprox. 7.5Mhz. I believe that Pac-Comm no longer provides a half speed
jumper in which case you would require a flip-flop to divide the clock down.
It was also necessary to replace the SIO with a 6Mhz part.
I razored the traces used for the ttl level terminal port connector on the tnc
and used that connector for interfacing the WA4DSY modem.
Right now I'm using a Hamtronics 28Mhz>220Mhz 1 watt xmit converter with a
1/2 wave ant. to access the input of our cross band repeater. On the receive
side I'm using a Microwave modules 70cm> 28Mhz converter. The DSY modem seems
to false a lot, ie: the carrier detect is always coming on in the presence of
intermod. I installed a bandpass cavity filter on the input of the receive
converter to cure that problem.
Performance wise I'm getting about 2k bytes/sec during ftp's. This figure would
be higher except the tnc runs in stop and wait mode, ie: it can not be sending
a frame to the Mac at the same time as it is receiving a new frame from the
modem.
I am able to run any number of applications under Multi-Finder with NET
always running in the background. I almost never have a crash and I run my
machine 24 hours a day (Mac+ with 68030 &4meg's RAM).
Bdale has previously noted that the high data rates used by the DSY modem can
"flat-line" your machine while it's busy servicing all that I/O. I *never*
had that problem on the Mac (even before the 68030). However, now that some
of the users on our 56k LAN are experimenting with DMA drivers and running
"full bore" I do occasionally suffer from my machine "flat-lining". This
only happens when two stations are ftping and using most of the available
bandwidth.
As has been said before: The Grapes WA4DSY modem provides a MUCH higher
cost/performance ratio, ie: you get a bigger bang for your buck.
I have not documented my modifications to the Pac-Comm tiny-2 tnc.
The procedure should not be too difficult for an advanced experimenter to
figure out from reading the DSY documentation and from looking at the tnc's
schematic. Alternately if your already have a tnc-2 clone you can follow the
procedure described in the Grapes doc's and use your tnc as a host interface
at 19.2k baud. (This works pretty well to start..)
Phil Karn has suggested that it should be possible to run HDLC straight out
the serial port of the Mac. In practice this is not possible due to the
absence of separate rx & tx clock signals.
I plan to have my station at the London Ontario Computer Networking Conference
for anyone interested in seeing it in action.
--dy
Doug Yuill, [e-mail] or [e-mail]

------------------------------

End of Packet-Radio Digest
******************************
Date: Mon, 20 Aug 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #122
To: packet-radio


Packet-Radio Digest         Mon, 20 Aug 90       Volume 90 : Issue 122

Today's Topics:
            Can you guys help a beginner?
              Mac and DSY modems
           PC Printer Port as a general purpose I/O
           PK232 mod to reduce op-amp noise
     Token-ring? Ethernet? Why not use the parallel-port?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: Mon, 20 Aug 90 00:47:38 EDT
From: [e-mail] (Caleb Strockbine)
Subject: Can you guys help a beginner?
To: [e-mail]

Hello...

I've been reading the Packet Radio digest for some time now, and I'm really
interested in what I've read. I am, however, just a beginner (not even,
really) and _very_ new to the idea of packet radio. I've picked up a few
ham magazines like CQ, and they help a little, but not a lot. With this in
mind, I'd be delighted if one of you would help me with some basic
questions:

What sort of license do I need to get started in packet radio? What's the
best way to go about getting such a license? I've seen some ads for
correspondance courses. Are these a good idea? What will it cost me, in
both time and money?

What sort of equipment will I need? Intuition tells me I'll need some sort
of radio setup, which I guess must include some sort of transciever and an
antenna. I would also guess I'd need some sort of modem, plus specialized
software. I've already got a Macintosh SE. Is that any use at all? All the
ads I've seen mention _only_ PCs... I haven't seen anything about the Mac
thus far. If there are people using Macs with packet radio, where can I
find them? Also, what will all this equipment cost me? I'm a student, so
the cheaper the better.

If I _do_ get into packet radio, what will I be able to access? I like the
idea of having a SLIP connection via airwaves, but that's a while off. Are
there a great many packet BBS's out there? And how many people actually use
packet radio?

I realize that this is all pretty basic stuff, and most of you probably
don't want to spend your time telling everyone else what they already know.
If there's some good way to find all this out... a few files FTPable from
somewhere, a good book or two on the subject, a magazine article that I'll
be able to find in a reasonable public library, whatever... I'd be grateful
for the pointer.

Thanks very much.

Caleb Strockbine
[e-mail]

Caleb Strockbine

[e-mail]     190 Caldwell Hall     607-255-5997 (work)
[e-mail]    Cornell University    607-272-4410 (home)

------------------------------

Date: Sun, 19 Aug 90 15:40:16 -0700
From: Mike Chepponis <[e-mail]>
Subject: Mac and DSY modems
To: [e-mail]

Doug gave a great overview how he did it.

I just want to mention that somebody mentioned to me that if you run your
DSY modem half duplex, then you can easily hook it up to the Mac.  You get a
2 to 1 multiplexer (which can be easily wired up from a 74HC00 quad CMOS NAND
gate chip, costs 10 cents) and hook DSY TXclock onto one input, RXclock onto
the other, and the select pin would go to DSY RTS.  The output of the mux goes
to the clock input of the Mac.

This allows you to eliminate the TNC.

All you have to do is write the code on the Mac to use this h/w arrangement.
(It's only software!)

Best -Mike

------------------------------

Date: 19 Aug 90 03:30:57 GMT
From: soleil!mlb.semi.harris.com!jujeh.mlb.semi.harris.com![e-mail]  (Ken Lyons)
Subject: PC Printer Port as a general purpose I/O
To: [e-mail]

I have seen several postings about using the printer port for
general purpose I/O, or more likely for directly driving an RF
modem (Which I, too, am considering as a way to make a cheap
packet setup for the PC similar to the Digi-com for the
Comodore), but since I have not read them all, this may have
been covered already.  Indeed, I hoped it would be covered,
which is why I did not take the time to read all the postings.
Nonetheless, after seeing the subject reappear every time I
scanned the newsgroup for weeks, I decided to read the
postings to make sure my computer was not broken :-).  At any
rate I apologize for the wanton use of bandwidth if this has
already been covered.

Anyway the gist of what I am driving at is this:  You can use
the parallel port for anything if you forget about the
grouping of signals as they are used by a printer and just
think about them as a collection of inputs and outputs.  More
specifically, 12 outputs and 5 inputs.  This is done
commercially by software such as Laplink and Fastwire, and I
have used it to provide a high speed communications link
between a PC and a single board computer.  Also, Latice
Semiconductor uses this technique for programming their line
of In Circuit Programmable (ISP) GALs.

At this point I assume that you all have enough information
about the parallel port that you can figure it out yourselves.
If this is not the case, I will be glad to pull the stuff out
of my files and type it in so I can E-Mail it to any interested.

73s
Ken Lyons KC4QEN

------------------------------

Date: 19 Aug 90 04:36:58 GMT
From: pacbell.com!mips!prls!philabs!briar![e-mail]  (Robert Casey)
Subject: PK232 mod to reduce op-amp noise
To: [e-mail]

copied from packet:
 Msg# TSF  Size #Rd  Date  Time From   MsgID        To
32511 BF   2032   3 16-Aug 1124 KE2QT  43070_WB2COY ALL@ALLBBS ()
  Sb: PK-232 MOD; HEARS BETTER

  FOLLOWING INFORMATION RECEIVED FROM WOLF ZS6KE:
  CONCERNING A MOD TO ELIMINATE NOISE FROM THE OP-AMPS.

  ON RECOMMENDATION OF OM PIET, ZS6AQC I CHECKED THE NOISE ON THE
  POWER BUS TO THE MC34074P OP-AMPS AND FOUND (JUST LIKE HE SAID) THAT
  THERE IS A LOT OF RUBBISH BETWEEN THE PINS 4 AND 11 OF U23, 26, 28,
  30, 32 AND 34. SO I PLACED SOME 1UF CAP'S ACROSS THEM AND MY
  RECEIVE NOISE (MEASURED ON A MARK-SPACE SCOPE CROSS-DISPLAY) IS MUCH
  MUCH LESS. IN FACT, I CAN NOW EVEN COPY SOME STEADY SIGNALS THAT
  DON'T EVEN RAISE THE S-METER NEEDLE. HOPE YOU CAN IMPROVE YOURS
  ALSO?

  THIS WAS RECEIVED FROM OD5NG: HE MADE THIS MOD AND RESULTS WERE
  OUTSTANDING.

  THEN CLARK, W9CD MADE THE MODIFICATION AND WAS PLEASED WITH THE RESULTS.

  CONSEQUENTLY I BOUGHT FROM RADIO SHACK 6 EACH 1 MF TANTALIUM CAPACITORS
  AND MOUNTED THEM ON THE BOTTOM OF THE BOARD, WITH THE SHORTEST POSIBLE
  LEADS IN THE POSITIONS DESCRIBED ABOVE. THE RESULTS ARE OUTSTANDING.
  RTTY SIGNALS I COULD NOT COPY BEFORE NOW COPY PERFECT, EVEN WHEN YOU
  CAN BARELY SEE THE TRACES ON THE SCOPE. ARQ LINKS WHICH COULD NOT BE
  MADE BEFORE NOW FLOW SMOOTH.

  THE POSTIVE SIDE OF THE TANTALIUM CAP GOES TO PIN 4 OF THE SIX MC34074P
  ICS AND THE NEGATIVE SIDE TO PIN 11.

  GIVE IT A TRY AND YOU WILL BE PLEASANTLY SURPRISED.
  73 AND GL DE JOHN, TG9VT

  -------------------------------------------------------
   KE2QT: The above file was copied from the TG9VT APLINK BBS by me, on
   Aug. 16, 1990  on 14076 Khz. This file is is for your information. I
   have not tried the modifications. Good luck, and if you are
   sucessful, please drop me a line: KE2QT @ WB2COY. 73 Bob.
------------------------------------------------------------
Note: I haven't tried or verified this, proceed at your own risk.  WA2ISE

------------------------------

Date: 19 Aug 90 22:02:26 GMT
From: netnews.upenn.edu!eniac.seas.upenn.edu![e-mail]  (Jeff DePolo)
Subject: Token-ring? Ethernet? Why not use the parallel-port?
To: [e-mail]

In article <[e-mail]> [e-mail] (David Lapp) writes:
>Re. 'bidirectional' printer ports on IBM's
>
>The 'standard' IBM printer adapter does support reading of the
>data pins on the printer port but the IBM documentation also
>warns against an external device driving them. On the other
>hand many people seem to use the printer port for input and
>get away with it. I'm fairly sure that they aren't all using
>the control lines to pass data!

>Has anyone (who reads this group of course :-) got any experince
>writing software to use an IBM printer port bidirectionally?
>Do printer ports on other machines work bidirectionally?
>
>Dave Lapp
>[e-mail]

I don't know about other machines, but many of the current file transfer
programs (Lap-Link and the hopefully-soon-to-be-release Duette 3.0) that
run on IBM PC-compatable machines do.  The parallel port is (for
lack of a better description or term) pseudo-latched in both directions.
When sending data, you load the latch and then pulse the strobe line,
which effectively tells the device on the other end to read the
port.  The data stays in the latch after the strobe - it isn't cleared.
The device on the other end has a high enough Z so that the values
don't get distrubed.  This assumes a read-only device, such as a
printer, is on the other end.

To read data the other way, you have the the machine on the other end
load it's latch and pulse its strobe.  The receiving computer should
have cleared its latch prior to the sending computer loading its latch.
When the receiving computer sees the strobe, it reads the current contents
of its port, which should contain whatever the sending computer put there.

Obviously this whole scheme requires some deviation from the normal
handshaking line scheme in order for each computer to be able to use
its strobe line.

The IBM documention is probably a bit overprotective.  As long as the
voltages on the pins don't exceed specs, there should be no problem.
The IBM technical manual also warns against transfer speeds above
9,600 baud on the serial port, which is a crock, so you can't believe
everything you read.

I haven't spent that much time on parallel port transfer routines.  I
started on the project in writing Duette (formerly Lap-Link prior to
a trademark dispute, but that's another story), but turned it over to
a different programmer when I went away to college.  Apparently, from
the reviews I've seen, the parallel port transfers work somewhat
faster than the 115,200 baud serial transfers.  I'd estimate you would
get a throughput approaching the equivilent of 200,000 baud on a
well-designed parallel port routine, but for ease of development,
115,200 on the serial port isn't too bad either.  The only problem
in an application like a token-ring network is allowing more than two
machines to communicate, as RS-232 is inherently designed for only 2
devices.  But then again, so is Centronics parallel, so who's to say
what can and can't be done.

Anyone had any more experience on this?  I'm by no means an expert.

                            --- Jeff
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jeff DePolo  N3HBZ             Twisted Pair: [phone]
[e-mail]    RF: 146.685- 442.70+ 144.455s (Philadelphia)
University of Pennsylvania     Carrier Pigeon: 420 S. 42nd St. Phila PA 19104

------------------------------

End of Packet-Radio Digest
******************************
Date: Tue, 21 Aug 90 04:30:20 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #123
To: packet-radio


Packet-Radio Digest         Tue, 21 Aug 90       Volume 90 : Issue 123

Today's Topics:
            PK232 Mod Information
           PK232 mod to reduce op-amp noise
           Using the Parallel port as a bidir port

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 20 Aug 90 16:47:44 GMT
From: zaphod.mps.ohio-state.edu!math.lsa.umich.edu!sharkey!bnlux0!bnlls1.nsls.bnl.gov![e-mail]  (Bob Foxworth)
Subject: PK232 Mod Information
To: [e-mail]

Article 4347 in the packet group carries the PK232 Mod information
which looks like the same info that circulated several months ago,
and the sources sound familiar. This mod (tantalums across the op-amps)
was tried by several local experienced people, including W2JUP who is
a consultant for AEA. Their joint determination was that, if you have a
proper 12v power supply driving the PK232, the mod is a waste of time,
as well as voiding your warranty. They feel that the people who claim
improvements from this mod are using ripply, poorly regulated supplies.
And, that is where attention should be placed.  73.

------------------------------

Date: 20 Aug 90 16:40:09 GMT
From: uop!quack![e-mail]  (Nick Sayer)
Subject: PK232 mod to reduce op-amp noise
To: [e-mail]

[e-mail] (Robert Casey) writes:

>  -------------------------------------------------------
>   KE2QT: The above file was copied from the TG9VT APLINK BBS by me, on
>   Aug. 16, 1990  on 14076 Khz. This file is is for your information. I
>   have not tried the modifications. Good luck, and if you are
>   sucessful, please drop me a line: KE2QT @ WB2COY. 73 Bob.
>------------------------------------------------------------
>Note: I haven't tried or verified this, proceed at your own risk.  WA2ISE

I HAVE tried it, but unfortunately my access to HF is problematic at
this time. My PK-232 certainly does no worse with the mod, and
I may have seen a little improvement, but that may have been the placebo
effect. I can say with certainty that the mod did no harm in my case.
You do, however, have to be careful and make sure that you don't mix up
4 and 11. I mounted the caps on the bottom of the board, and thought
long and hard to make sure I did it right.

Proceed at your own risk, of course, but I think this benefit:price
ratio is higher than 1:1.
--
Nick Sayer               |  Disclaimer:
N6QQQ                    |    "Just because you're reading my post doesn't
[e-mail]  |     mean we're gonna take long showers together."
209-952-5347 (Telebit)   |                      -- Gunnery Sgt. Thomas Highway

------------------------------

Date: 21 Aug 90 07:53:18 GMT
From: elroy.jpl.nasa.gov!grian![e-mail]  (Alex Pournelle)
Subject: Using the Parallel port as a bidir port
To: [e-mail]

[e-mail] (David Boyes) ['n' about 27 bizillion others] writes:

>Many machines have bidirectional parallel ports -- warm fuzzies
>to you guys at HP for putting one on darn near everything you
>make -- but not all "printer" ports are bidirectional. Like
>everything else, it's a question of design. Well-designed I/O
>ports work both ways, and the others .... 8-(.

LapLink III and FastWire (nee FastLynx) both provide a
parallel-to-parallel port cable for xferring data between nearly any two
PClones.  It's about 3 to 4x faster than serial.  There are, from my
limited remembery, about 5 bits that are useable bidirectionally on just
about every parallel port.  (The only exception I know of is the Sanyo
MBC-555, not known as being very compatible!)  I've never heard of any
machines breaking from using this, either.

I'm sure either Rupp or Travelling Software will give more tech. details
if you explain at length you're not competing with them... :-)


>David Boyes       |  "Where's the ka-boom? There's supposed to be an
>[e-mail]   |  Earth-shattering ka-boom!...Heavens! Someone has
>                  |  stolen the Illudium Q-38 Explosive Space Modulator!
>"Delays, delays!" |  The Earth creature has *stolen* the Space Modulator!"

I always thot that was "Pu-238 Explosive Space Modulator", as in
"Putonium".  God rest ye, Mel Blanc.


    Alex
--
        Alex Pournelle, freelance thinker
        Also: Workman & Associates, Data recovery for PCs, Macs, others
        ...elroy!grian!alex; BIX: alex; voice: [phone]
        fax: [phone]    bbs: 791-1013; 8N1 24/12/3

------------------------------

End of Packet-Radio Digest
******************************
Date: Wed, 22 Aug 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #124
To: packet-radio


Packet-Radio Digest         Wed, 22 Aug 90       Volume 90 : Issue 124

Today's Topics:
             Ethernet drivers for net/nos
            KA9Q package for the Atari ST
                 PacketRadio
               PC Printer Ports
             Thanks for the help!
           Token-ring? Ethernet? Why not u

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 21 Aug 90 20:01:52 GMT
From: ncrlnk!ciss!lawday![e-mail]  ([e-mail])
Subject: Ethernet drivers for net/nos
To: [e-mail]

I am running net on a pc and on an NCR Tower (the unix version is kd8wk's
modified 890421.01 bits).

I have a Novell ethernet card available for the pc, and an Exelan ethernet
card available for the Tower.

What kind of undertaking (major, minor, or impossible) will it be to get
these machines talking to each other over the ethernet, using net?  I have
no other networking software on these machines.  Are there drivers available
for these cards that will interface to the FTP spec and net?

Thanks much.

--
John R. Ackermann, Jr.                                           [phone]
Law Department, NCR Corporation                              VoicePlus 622-2966
Dayton, Ohio                                      [e-mail]
     ***** Amateur Radio: ag9v@n8acv or [e-mail] *****

------------------------------

Date: 21 Aug 90 16:25:31 GMT
From: mcsun!inria!laas![e-mail]  (Ralph P. Sobek)
Subject: KA9Q package for the Atari ST
To: [e-mail]

Hi folks!

In article <[e-mail]> [e-mail] writes:

|    I managed to get a hold of the KA9Q package for the Atari ST. It took quite a
|    bit of looking and asking, until a kind sould in Europe uucp'd me the files.
|
|    If someone would like a copy of the files, I'd be happy to uucp them to you.

I tried replying but if anyone (especially in Europe) has the ka9q
source for the Atari ST, I *sure* am interested.  I had a copy on a
Sun cassette and accidently destroyed it with everything else ;-(

--
Ralph P. Sobek                    Disclaimer: The above ruminations are my own.
[e-mail]                              Addresses are ordered by importance.
[e-mail], or ...!uunet!laas!ralph
If all else fails, try:                               [e-mail]
===============================================================================
Reliable software should kill people reliably! -Andy Mickel, Pascal News #13,78

------------------------------

Date: 22 Aug 90 03:19:18 GMT
From: g.gp.cs.cmu.edu![e-mail]  (Eric Lehmann)
Subject: PacketRadio
To: [e-mail]

  I have seen several references to PacketRadio being developed by Tapr.
It is apprently a 2 meter 9600 baud rf modem. Can someone here in the
know post a complete description? I would also like to know when it
will be available and how much it will cost. Thanks.
                -Eric, kd3sp

------------------------------

Date: Mon, 20 Aug 90 08:11:28 CDT
From: [e-mail]
Subject: PC Printer Ports
To: [e-mail], [e-mail]

The first generation IBM }brand{ _printer_ ports were limited to Centronics
"standard" interface.  (Eight bits out, five bits back).

The later standalone _parallel_ ports AND the combined Serial/Paralell board
are really fully bidirectional.  Some coding gymnastics are required to deal
with the handshaking lines, but no more than usual with the PC.

As a matter of fact, it's pretty simple the read and write the main eight
bit path.  You just read and write the same I/O address.  Reading the hand
shaking lines requires that you first write ones to them.  The reason for this
is that the handshaking lines are, _in general_, pulled-up open collector
outputs.

It's actually pretty hard to find a machine that has a printer-only port.
They ARE there, but they seem to be a barely significant minority.  Laptops,
chipset based motherboard ports, and LSI based addons all seem to be truly
bi-directional.  I haven't seen a printer-only add-on card for about 4 years.

Oz

------------------------------

Date: Tue, 21 Aug 90 20:13:31 EDT
From: [e-mail] (Caleb Strockbine)
Subject: Thanks for the help!
To: [e-mail]

I'd like to take a few lines to say thanks to all the people who took the
time to help me get a start in my quest for a ham license. "Thanks."

Also, if there's anyone else who's just starting off and would like a
summary of the replies I got to my query about how to get started in radio,
just drop me a line. It may be a few days (or even weeks) before I get back
to you, since I'll be away from an easy network connection for a while (I'm
moving). But I'll eventually get my mail and reply as soon as I can.

Thanks again for all the help. More than anything, it was the kindness of
the people that responded that convinced me I'd like to be part of the ham
culture.

Caleb.
[e-mail]

Caleb Strockbine

[e-mail]     190 Caldwell Hall     607-255-5997 (work)
[e-mail]    Cornell University    607-272-4410 (home)

------------------------------

Date: 21 Aug 90 22:26:00 GMT
From: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu![e-mail]
Subject: Token-ring? Ethernet? Why not u
To: [e-mail]

What is the maximum speed a parallel port can be practically driven to, in
terms of total bits per second of useful data (so as to compare against a
reference of say 9600 bps)?  My impression is that a parallel port requires
byte-by-byte operations by the CPU, which are likely to be bogging it down.

--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society
<[e-mail]> | no matter what the particular issue is all about.

------------------------------

End of Packet-Radio Digest
******************************
Date: Thu, 23 Aug 90 04:30:05 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #125
To: packet-radio


Packet-Radio Digest         Thu, 23 Aug 90       Volume 90 : Issue 125

Today's Topics:
             Latest TCP/IP NET.EXE Wanted
                 TCP/IP on HF

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 22 Aug 90 05:19:12 GMT
From: att!cbnewsd![e-mail]  (nils.t.carlson)
Subject: Latest TCP/IP NET.EXE Wanted
To: [e-mail]

If anyone knows where I can obtain the latest version of NET.EXE
(and all the supporting files), please post a reply to this newsgroup
or call me at [phone] days only.

The version that I have is one that I picked up at the Dayton
Hamvention this past year and is several versions behind, I believe.

Thanks,
Nils Carlson
AT&T Bell Laboratories
Naperville, IL
(K4IWL)

------------------------------

Date: 22 Aug 90 10:52:01 GMT
From: zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!peregrine!sceard!ncr-sd!ncrcae!secola![e-mail]  (Randy Mechling)
Subject: TCP/IP on HF
To: [e-mail]

I was wondering if anyone in this newsgroup has had experience with TCP/IP
on HF.  I don't even know if this is possible with the bandwidth restrictions.
Are there certain FCC regulations that only allow digital encoding on certain
HF freqs?  What are the bandwidth regualtions?  I assume the reason for using
300 baud on HF packet is because of bandwidth.  I would like to investigate
ways of increasing the bits/sec (throughput) and still stay within any FCC
bandwidth restrictions.  If anyone can share their knowledge on this subject
with me, I would appreciate it greatly.  Thanks

Randy Mechling WA4HOX

--
*******************************************************************************
*  Randy Mechling    NCR Comten Columbia | 1+1=2  1-1=0   etc.                *
*  [e-mail]      | 2+2=4  2-2=0                       *
*******************************************************************************

------------------------------

End of Packet-Radio Digest
******************************
Date: Fri, 24 Aug 90 04:30:07 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #126
To: packet-radio


Packet-Radio Digest         Fri, 24 Aug 90       Volume 90 : Issue 126

Today's Topics:
             Latest TCP/IP NET.EXE Wanted

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 22 Aug 90 18:38:14 GMT
From: uc!shamash!brainiac![e-mail]
Subject: Latest TCP/IP NET.EXE Wanted
To: [e-mail]

The latest un-released version of the TCP/IP (NOS) software is available from
thumper.bellcore.com . The executable, src, and reference manual reside in the
directory pub/ka9q/nos.  There are also other goodies on thumper under pub/ka9q.
Thumper.bellcore.com is the machine that always has the latest version of
the TCP/IP package from KA9Q and others.

The last released version of TCP/IP ( 890421.1 NET) can be found on
hpcsos.col.hp.com in the directory ka9q/890421.1 .  The source code for many
target machines can be found here, as well as the BM mailer.  HPCSOS also
has alot of software for packet radio.


Jeff Comstock - NR0D

------------------------------

End of Packet-Radio Digest
******************************
Date: Sat, 25 Aug 90 04:30:05 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #127
To: packet-radio


Packet-Radio Digest         Sat, 25 Aug 90       Volume 90 : Issue 127

Today's Topics:
              GOLD for your PK-88/PK-232
                 PacketRadio

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 20 Aug 90 14:38:11 GMT
From: news!cartan!ndmath!nstar!w8grt!f32.n266.z1.fidonet.org![e-mail]  (Jim Grubs)
Subject: GOLD for your PK-88/PK-232
To: [e-mail]

 * Forwarded from "PACKET - 13"
 * Originally from Robb Topolski
 * Originally dated 08-17-90 12:57


           Packet-GOLD!   A product review...

I have read many messages about the AEA PK-88 and PK-232 and some of
it's problems with the software that is provided with it.  Let me tell
you about a program that I have been using for two years, and has just
been updated to support the new AEA ROM releases.

The program is Packet-GOLD, an upgrade from an earlier program called
Packet-PLUS (Plus Multimode stuff).  This is truly the most "friendly"
program I've ever used.  It is extremely easy, yet very powerful.  It
makes connecting, even multiple connecting, a breeze!

Packet-GOLD is true multi-connect software, able to handle up to 10
packet connections at the same time!  Each connection is given it's
own display page - no getting lines of text confused with lines from
other connections! Just press F4 to switch from page to page and QSO
to QSO.  You can be casually chatting with someone on one page, while
reading the latest poop from your local BBS on another page, while
"auto-connecting" with someone several nodes away on another page.
The program tells you if you have received any new text on a page, so
you'll know to check that page.

If you don't happen to be looking when I connect to you, Packet-GOLD
can announce me by sending "DE KJ6YT" in Morse Code over the PC
speaker.
Neat!

There's also a separate page for monitoring what's happening on the
frequency.  Just press F2 and find out who's on, who's calling CQ, and
who's DX!  Your monitor screen works even while other stations are
connected, and doesn't interfere with your on-going QSO's which remain
undisturbed, each on their own page.  You can also have the best of
both worlds by using a split-screen with monitored packets in the
upper part and the lower part dedicated to your QSO.  Shift-F2
brings a running list (MHeard style) in a pop-up window.  No other
packet program has all this power!

One of the better features is it's file transfer capability.  You can
transfer files using it's special file transfer protocol, insuring
error-free reception from computer-to-computer (unlike YAPP which just
makes it from TNC-to-TNC).  Using Packet-GOLD, you can request a
directory of another station's file-transfer directory.  You can even
carry-on a conversation with that station during the transfer, along
with all the other stations you are connected to.

Many of its functions use "point-and-shoot" (or pick-list) technology,
which means if you can read, and know up from down, you're in business!

   - Quick Connects.   Press F7, you get a list of everyone you've
taught
     Packet-GOLD how to connect to.  Use your cursor keys to select who
     you want, press ENTER.

   - Using NET/ROM is easy. The program does all the intermediate
     NET/ROM connect commands automatically, you don't have to sit
     there waiting for each node to connect. Let the program do that
     automatically. Connecting to N6CWF in arizona, for me it's:
     AGOURA VIA MVIEJO|PHX|N6CWF [F7]. The program gets me there
     automatically. When it connects to CWF, I see a QSO log, and his
     call -- name at the top of my screen.

   - Brag Tape.  Pick a text file, press ENTER, it's on its way.

   - Send Text files.  Same as above!

   - Cut-and-Paste.  Select a line, or several lines, from another
     connection, a previous connection, your monitor screen, or even
     earlier in the same connection -- and send it back out, save it
     on disk, put it in the editor and fix a word or two.  Real power,
     and very simple.

   - QSO log: Keeps track of names, addresses, station info, and the
     last date you connected.  No more guessing, "is his name Herb?"

Packet-GOLD supports all PK-232 modes except FAX. This means it
handles the maildrop, SIAM, NAVTEX, Baudot, Morse, Amtor.

In closing, this is BY-FAR the easiest and most powerful Packet Radio
program. The authors apparently are looking at other TNCs, but for
now, if you own a PK-88 or 232, this is the best program available.

Packet-GOLD is $49.95 and is available only from:

     Interflex Systems, 714-496-6639

I am not affiliated with Interflex Systems in any way -- I just want
some
of you PK-88/232 owners to enjoy some of the power I've enjoyed!!

If you have any questions, or in the unlikely event you'll need any
help, you can write me at the address below.  I'd like to hear from
you if you try the program -- tell me what you think!

73
-- Robb, KJ6YT @ KJ6YT.#SOCAL.CA.USA.NA


--- ConfMail V3.31
 * Origin: Pinelands RBBS 609-859-1910 (8:950/2) (1:266/32)

--
  |\/\/\/|
  |      | Jim Grubs - via FidoNet node 1:234/1
  | (o)(o) UUCP: ...!ncar!asuvax!stjhmc!w8grt!266!32!Jim.Grubs
  |     _) INTERNET: [e-mail]
  | ,___|  ____________________________________________
  |   /     "I wanna go to the ham radio National Park
 /____\         of the Mind and ride the NOS!"

------------------------------

Date: 24 Aug 90 00:29:28 GMT
From: hpcc01!col![e-mail]  (Bdale Garbee)
Subject: PacketRadio
To: [e-mail]

>  I have seen several references to PacketRadio being developed by Tapr.
>It is apprently a 2 meter 9600 baud rf modem. Can someone here in the
>know post a complete description? I would also like to know when it
>will be available and how much it will cost. Thanks.
>                               -Eric, kd3sp

Call TAPR and ask for a copy of the glossy blurb from Dayton last year, and
a current status report.  I'm a little out of sync with the project right
now, or I'd comment further.

Bdale


TAPR
PO Box 12925
Tucson, AZ  85732
[phone]

------------------------------

End of Packet-Radio Digest
******************************
Date: Sun, 26 Aug 90 04:30:03 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #128
To: packet-radio


Packet-Radio Digest         Sun, 26 Aug 90       Volume 90 : Issue 128

Today's Topics:
          Open squelch DCD in Kantronix TNCs

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 24 Aug 90 15:28:20 GMT
From: bu.edu!mirror!necntc!necis![e-mail]  ( NM1D)
Subject: Open squelch DCD in Kantronix TNCs
To: [e-mail]

Since people on this newsgroup seem to like this sort of thing, I thought
that I would pass this along.

  The new version of ROMS for the Kantronix TNCs (KPC-2, KAM, KPC4, etc)
now supports open squelch DCD.   This has been done in software by their
programmers, and has been working FINE for me.   I have both the KPC-2 and
the KAM.... They allow the parameters for the DCD algorithm to be tuned
by the user.  The KAM (and other dual port units) allows separate parameters
for each port.   The user is allowed to choose between the various DCD
'circuits' available, and to use the one that suits his/her operation
the best.   The choices are INTERNAL (the on board DCD hardware), EXTERNAL
(an input that can come from a receivers squealch open circuit, or from any
other external hardware), and SOFTWARE (the new open squealch DCD software
algorithm).

   The SOFTWARE method has been used at my station for a couple of weeks now,
and it seems to be working fine.  I have been leaving my squealch open...
it works!!!  Sorry, I have not made any actuall measurements to see what
the response time of this is... Kantronix claims that it is as fast (or
faster) than the TAPR DCD state machine.

  The version of the new ROMS will be 3.0.  It should be available soon.
Other features include the ability for the built-in PBBS to accept
autoforwarded email, and some other nice user commands.  Also the KAM now
has improved support for NAVTEX reception.


  I have a question with the type of DCD circuit that detects data instead
of a generic signal that is occupying the packet channel.   Why is it an
improvement to NOT wait when there is a signal without data that is
occupying the channel?   Wouldn't it be better for the TNC's to wait for
the offending signal to go away, rather than attempt to transmit 'over'
the offentind signal?   Seems to me, if someone is transmitting a dead
carrier on the frequency, then waiting for it to go away would be better
than attempting to transmit through it and end up 'retrying out' from
data errors, or the receiver not hearing any packets because the offending
signal may be stronger than many packets.

  On the other hand, if the offending signal was weak, it could be possible
that most of the packets may get through....

   Am I missing a point here??? (I am not a network algorithm expert by
any means, but am trying to understand why the detect-data, not an
occupied channel woule de desirable).


   Rich (NM1D)

p.s.  If anyone has Hank Oredson's (W0RLI) email address would you please
       email it to me.... I seem to have lost his address... I was looking
       for the details on how to support forwarding on my DOSGATE simple
       mail system... I have not received any answers from the net, so I
       thought taht I would go to the source, thanks...


 /**************************************************************************\
 * Rich Bono (NM1D)    If I could only 'C' forever!!    [e-mail] *
 * [phone]          NEC Technologies Inc.                NM1D@WB1DSW *
 \**************************************************************************/

------------------------------

End of Packet-Radio Digest
******************************
Date: Mon, 27 Aug 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #129
To: packet-radio


Packet-Radio Digest         Mon, 27 Aug 90       Volume 90 : Issue 129

Today's Topics:
            Packet software for 386/Unix?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 27 Aug 90 00:56:59 GMT
From: swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!isgate!hafro![e-mail]  (Heimir Sverrisson)
Subject: Packet software for 386/Unix?
To: [e-mail]

Is there any packet radio software available for Sys-V Unix?

--
---
Heimir Thor Sverrisson          Uucp: uunet!mcsun!sunic!isgate!hafro!heimir
                Internet: [e-mail]

------------------------------

End of Packet-Radio Digest
******************************
Date: Tue, 28 Aug 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #130
To: packet-radio


Packet-Radio Digest         Tue, 28 Aug 90       Volume 90 : Issue 130

Today's Topics:
               The Amateur Radio BBS...
              Using MFJ for Node
               WEBERSAT images

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: 27 Aug 90 21:56:40 GMT
From: swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv![e-mail]  ( WB3FFV)
Subject: The Amateur Radio BBS...
To: [e-mail]

  Here is my perodic posting of the information on accessing the Amateur
Radio BBS.  I constantly see requests for software like NET and NOS, so
here is where you can get the latest stuff!


+------------------------------------------------------------------------------+
    HOW TO ACCESS THE WB3FFV AMATEUR RADIO TELEPHONE BBS !!!


 I have placed a BBS system on-line that is mainly oriented towards the
Amateur Community (but there is other stuff on-line). As of now I have not
attempted to promote this system any place except in the amateur channels
(PACKET, USENET, & word of mouth), and will continue under this policy, as
I hope to keep it oriented toward amateur radio. The various software for
UP/DOWNload is available via telephone dialup and Packet TCP/IP, and through
user support I hope to keep the latest and greatest ham software on-line.
Below is the information that is needed in order to access the BBS via
Telephone -or- TCP/IP, please pass it around to as many ham's as possible.

 System Name: WB3FFV
 User Login: bbs
 Number: (301)-625-0817 -- 1200 & 2400 (Non-MNP)
 Number: (301)-625-9482 -- 1200 & 2400 (MNP5), 4800 & 9600 V.32 (V.42/MNP5)
 Number: (301)-625-9663 -- 1200 & 2400 (MNP5), 9600 & 19200 (PEP)
 Data Settings: 8 Bits, NO Parity, 1 Stop Bit
 Times: 24hrs/365days  (except for routine maintenance)
 Software: XBBS  (UNIX/Xenix Multiuser BBS)
 IP Address: 44.60.0.1 {wb3ffv.ampr.org}  [for FTP access on 145.550 mhz ONLY]
 Misc. Info: Machine is an 80386 computer running UNIX V.3.2 and features 700
         Meg of on-line storage. Most transfer protocols are available!!


 I attempt to keep the latest and greatest HAM software on-line, and encourage
all to upload anything new that they come up with, as it is of benefit to all.
Here is a sample of a couple pieces of software that is available for DOWNLOAD:

 KA9Q TCP/IP Software for the PC (Latest OFFICIAL release + TEST Versions)
 KA9Q TCP/IP for the Atari-ST, MAC, & Amiga
 KA9Q TCP/IP for UNIX based systems
 KA9Q TCP/IP (The NOS release)  [UNIX, MS/DOS, Amiga]
 WA7MBL BBS for the PC (Versions 3.31, 4.31 & 5.1[2,3,4])
 W0RLI BBS for the PC (Versions 6.xx, 7.xx, 8.xx, 9.xx, 10.xx)
 MSYS BBS for the PC running KISS TNC's  (Version 1.08)
 AA4RE BBS for the PC (Version 2.10)
 Various BBS utilities and enhancements
 Several MORSE CODE Tutors
 TheNet software by NORD><LINK  (Version 1.01)
 Modifications for many HAM Rigs and Scanners
 Digital Signal Processing software (DSP)
 DX and contesting programs
 ARRL Newsletters & Gateway
 W5YI Electronic Edition

 There is much more available on the BBS, and I don't want to waste a lot of
PACKET BBS space trying to list it all, so if you are interested give it a
call and see for yourself !!!

If you are interested in using UUCP to connect to the BBS, this can also be
done as I support Anon-uucp. The login to the system is 'uucpanon', and there
is NO password. The listing of avalible archives are stored in a file called
'FILES', and it is located in the /usr/spool/uucppublic. To retrieve the files
listing just use the following command:

uucp wb3ffv!~/FILES /usr/spool/uucppublic

This will move a copy of my files listing into your uucppublic directory.  If
you have any questions or problems, feel free to contact me at one of the
numbers/adresses below. Good Luck...

------------------------------

Date: 28 Aug 90 02:15:45 GMT
From: mist.CS.ORST.EDU![e-mail]  (Mike Bates)
Subject: Using MFJ for Node
To: [e-mail]

   I am trying use MFJ 1270B for TheNet Node's. One is a backbone
   port and the other is for lan port. I am having problems getting
   the two to communicate togeather. I heard that in the TheNet
   documentation it describes hardware mods for the TAPR TNC-2, the
   MFJ-1270B is a clone of this. What mods do I need to make to get
   the two to communicate??

   Thanks in advance

   Mike Bates, KF7DQ
   Linn-Benton Community College
   Albany, Or

   [e-mail]
   KF7DQ@WA7SHP

------------------------------

Date: 27 Aug 90 19:35:09 GMT
From: swrinde!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bcarh342![e-mail]  (Marcus Leech)
Subject: WEBERSAT images
To: [e-mail]

Anyone know if any of the WEBERSAT images are available in
  any of the popular formats for anonymous FTP?
  GIF, Sun-raster, TIFF, XBM, XWD are all acceptable formats
  for me.

-----------------
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
[e-mail]                  P.O. Box 3511, Stn. C   |are my own, and not
[e-mail]         Ottawa, ON, CANADA      |necessarily BNRs

------------------------------

End of Packet-Radio Digest
******************************
Date: Wed, 29 Aug 90 04:30:04 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #131
To: packet-radio


Packet-Radio Digest         Wed, 29 Aug 90       Volume 90 : Issue 131

Today's Topics:
               drsi pc*pa board
                 KISS
            Packet software for 386/Unix?
            The Fool on the Hill (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: Tue, 28 Aug 90 15:00:20 MET
From: [e-mail] (Vincenzo G. Capuano)
Subject: drsi pc*pa board
To: [e-mail]

Hi,
I would like to know the address of DRSI to buy a pc*pa board
and the price of the board?

Thanks,
Vincenzo.
------
Vincenzo G. Capuano
[e-mail]
[e-mail]

------------------------------

Date: 28 Aug 90 20:06:10 GMT
From: altos!altos86![e-mail]  (Jerry Gardner)
Subject: KISS
To: [e-mail]

Does anyone have a specification for KISS mode?  What does a TNC send on its
RS-232 port and what does it expect to see in KISS mode?

--
Jerry Gardner, NJ6A                                     Altos Computer Systems
UUCP: {sun|pyramid|sco|amdahl|uunet}!altos86!jerry      2641 Orchard Parkway
Internet: [e-mail]                               San Jose, CA  95134
Guns don't kill people, bullets do.                     [phone]

------------------------------

Date: 29 Aug 90 04:24:13 GMT
From: dsl.pitt.edu!pitt!w2xo![e-mail]  (Jim Durham)
Subject: Packet software for 386/Unix?
To: [e-mail]

In article <[e-mail]> [e-mail] (Heimir Sverrisson) writes:
>Is there any packet radio software available for Sys-V Unix?
>
Yes.. There is a version of KA9Q's 'net' program for Sys-V and
I have written a PBBS for use with Phil's program. Both
are available on vax.cs.pitt.edu.

-Jim


--
Jim Durham
internet:  [e-mail]       ham packet radio:
       [e-mail]              w2xo@w2xo.#wpa.pa.usa.na

------------------------------

Date: Tue, 28 Aug 90 13:57:55 MDT
From: [e-mail] (Dave Wade)
Subject: The Fool on the Hill
To: [e-mail]

I've been reading the Packet Radio mailing list for several years now, but
I've not gotten excited about "Packet" until fairly recently.  Specifically,
Last week I ran out of gas up by "The Valle Grande" and while I was waiting
for the gasoline to be brought up to me, ( Two-meters has its uses...) I got
to talking with some old friends.

Seems that Scott was donating a packet repeater to be put up above Jemez
Springs, to give a ham down there a way out of his valley.  We got to
talking and I offerred that I had a better site, and much better coverage
if we could get permission, etc, etc...

I got the permission, and now I've got some questions about my next steps.

I live in the high mountains of New Mexico, and this repeater will be able to
talk to Southern Colorado, Mount Taylor (over by Grants/Gallup), and
Capitan (down by Roswell), and West Texas.  So it seems appropriate to
do a little extra.

Also, I have a 16 mHz AT-clone to spare, though at heart I am an Apple
person.  So I want a solution which will work on both types of hardware.

I'd like to know whether I can run Phil Karn's TCP/IP stuff on my PC&Mac,
(We call it a MikeIntosh, because it is a 128K Mac board stuffed up to
be a 512E and inside an IBM-PC Clone case with an IBM monitor... Gets
some stares from those who should know better...).

I have an early version of Phil's Mac program and I've FTP'd over the
latest IBM version of something-or-other,

But, I'm not too sure about what to connect to where.  I understand that
a TNC is basically a Color-Computer with a special output port, and what I
want to know is,  What Radio-Frequency modem can plug into my serial port,
(either the Mac or the AT-Clone) and, running TCP/IP sit off in my house
and provide a 56KBaud Node?  I think I don't need a TNC if I have a
smart enough computer, is that true?

I expect to put SCO XENIX on the AT, just because of DOS.  But the 386's
I've tried to put Xenix on haven't worked, I've got to hope that a
286 version will work better...  And with the software running TCP/IP
itself, I shouldn't need too much hardware, should I?  I suspect
that there's nothing running out here but a bunch of generic 1200 Baud
TNC packet BBS's.  I have the opportunity here to set up a fast link
if I understood what I am getting into.  Although I may not be capable
of building a "very high speed" modem, I have friends who could, so
the availability of equipment is more a function of cost than skill
required.

Can we run this thing (assuming 56KBaud and TCP/IP is considered "different"
by the "true believers" of 1200Baud Packet) on the same frequency as the
regular packet links? (i.e. will this just be another node, and the
hardware oblivious to the RFModem tone's differences?)  Will I require
Two modems?  I suspect that I want to be a "node", not just a digipeater;
or do I?

    1)  IBM-AT-CLONE or Macintosh operation...
    2)  TCP/IP operation
    3)  Unix is better than DOS,  The Mac doesn't do enough windows,
        but it does 'one window' really well.
    4)  I live above 8000 feet, I've had snow for 9-months straight
        several years...
    5)  Icom-22s for the radio, probably.
    6) Node, or leaf?  BBS with mail, etc.  Store & forward etc...
    7)  High speed connectivity.
    8)  I "Hate" watching a slow typist backspace to correct a typing
error.  So good connectivity is important, I can read faster than
1200Baud, and I won't watch someone type...

I am talking of two separate machines.  The digipeater up on the side of
the hill will have some hardware digipeating connections so it will just
retransmit whatever hits it, (although there is some discussion about
putting it close to my kitchen so the computer could become more intimately
connected if required by something or other that I don't understand yet.)

The second machine is down in my kitchen, an Icom 22s connected to an AT-Clone
or Mikeintosh and some type of RFModem which pushes the 22S's Transmit
button while screeching down the "Mike" line at 56K using TCP/IP.

Have I got it right?

    Dave, WB5PFS

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

I promised myself ( when I turned 21, ) that I wouldn't ever again do
anything just once.  I think that solves a lot of problems;
no high speed crashes into bridge abutments, no one-night stands, etc.
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

------------------------------

Date: 28 Aug 90 21:54:54 GMT
From: [e-mail]  (Patty Winter)
Subject: The Fool on the Hill
To: [e-mail]

In article <[e-mail]> [e-mail] (Dave Wade) writes:
>
>I'd like to know whether I can run Phil Karn's TCP/IP stuff on my PC&Mac,
>(We call it a MikeIntosh, because it is a 128K Mac board stuffed up to
>be a 512E and inside an IBM-PC Clone case with an IBM monitor... Gets
>some stares from those who should know better...).


Dave--

I'm not sure I understand all of your questions, but I'll try answering
the ones I think I understand. :-)


>I have an early version of Phil's Mac program and I've FTP'd over the
>latest IBM version of something-or-other,

You can get the latest Mac version via anonymous FTP from apple.com.


>       1)  IBM-AT-CLONE or Macintosh operation...
>       2)  TCP/IP operation
>       3)  Unix is better than DOS,  The Mac doesn't do enough windows,
>               but it does 'one window' really well.

Are these statements of fact or a wish list? In any event, the Mac
version of Phil's software has had multiple windows for quite a while
now; you probably have a fairly old version.

It also runs great under MultiFinder, in case you want to run BM and a
text editor simultaneously. (I'm using 1 Meg for that; you might not be
able to do it with 512K.)

Hope this helps.


73,
Patty


--
*****************************************************************************
Patty Winter N6BIS                        INTERNET: [e-mail]
AMPR.ORG: [44.4.0.44]                     UUCP: {decwrl,nsc,sun}!apple!winter
*****************************************************************************

------------------------------

End of Packet-Radio Digest
******************************
Date: Thu, 30 Aug 90 04:30:06 PDT
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V90 #132
To: packet-radio


Packet-Radio Digest         Thu, 30 Aug 90       Volume 90 : Issue 132

Today's Topics:
              packet radio subscription
             The Fool on the Hill

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
----------------------------------------------------------------------

Date: Wed, 29 Aug 90 19:17 CDT
From: [e-mail]
Subject: packet radio subscription
To: [e-mail]

Dear sender:
I received some packet radio news via bitnet at Auburn University.  I have
been trying to figure out how to subscribe to this service.  Can you
tell me how I do that?

Thanks,

Stephen W. white
NFPKP@auducvax

------------------------------

Date: 29 Aug 90 19:35:43 GMT
From: swrinde!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: The Fool on the Hill
To: [e-mail]

In article <[e-mail]> [e-mail] (Dave Wade) writes:
>
>I've been reading the Packet Radio mailing list for several years now, but
>I've not gotten excited about "Packet" until fairly recently.  Specifically,
>Last week I ran out of gas up by "The Valle Grande" and while I was waiting
>for the gasoline to be brought up to me, ( Two-meters has its uses...) I got
>to talking with some old friends.
>
>Seems that Scott was donating a packet repeater to be put up above Jemez
>Springs, to give a ham down there a way out of his valley.  We got to
>talking and I offerred that I had a better site, and much better coverage
>if we could get permission, etc, etc...
>
>I got the permission, and now I've got some questions about my next steps.
>
>I live in the high mountains of New Mexico, and this repeater will be able to
>talk to Southern Colorado, Mount Taylor (over by Grants/Gallup), and
>Capitan (down by Roswell), and West Texas.  So it seems appropriate to
>do a little extra.
>
>Also, I have a 16 mHz AT-clone to spare, though at heart I am an Apple
>person.  So I want a solution which will work on both types of hardware.
>
>I'd like to know whether I can run Phil Karn's TCP/IP stuff on my PC&Mac,
>(We call it a MikeIntosh, because it is a 128K Mac board stuffed up to
>be a 512E and inside an IBM-PC Clone case with an IBM monitor... Gets
>some stares from those who should know better...).
>
>I have an early version of Phil's Mac program and I've FTP'd over the
>latest IBM version of something-or-other,
>
>But, I'm not too sure about what to connect to where.  I understand that
>a TNC is basically a Color-Computer with a special output port, and what I
>want to know is,  What Radio-Frequency modem can plug into my serial port,
>(either the Mac or the AT-Clone) and, running TCP/IP sit off in my house
>and provide a 56KBaud Node?  I think I don't need a TNC if I have a
>smart enough computer, is that true?

The TNC1 could have been considered similar to the CoCo in that it used
the 6809 processor. The current TNC2 evolved out of the Xerox 820 and
uses a Z80. The TNC1 is no longer made and the TNC2 is much lower cost.
When used with Phil's code, the TNC runs in a special mode called KISS.
It does channel contention management, HDLC stuffing and unstuffing,
and acts as a smart buffer between the Async port to your computer
and the radio via it's internal 1200 baud modem. The TNC2 has a standard
disconnect header that allows other, faster, modems to be attached.
Currently available modems are 2400 baud, 9600 baud, and the Grapes
56 kbaud modems. The internal 1200 baud modem, the external 2400 baud
modem, and the external 9600 baud modem require external radios. The
56 kbaud modem is a radio and outputs on 29 Mhz. It requires a transverter
to boost it to the VHF/UHF band of choice. If you have a 8530 in the
computer, you can eliminate the TNC under certain special conditions.
For the PC you can use a card called the DRSI to replace the TNC,
the DRSI has a 8530 and an internal bypassable 1200 baud modem. There are
software drivers for this card in Phil's PC code for low speed work and
there is a driver for the 56 kbaud modem for the DRSI in Phil's code.
For the Mac, there is already an internal 8530, but both external
clock lines are not brought out. There was a tricky way to use it
half duplex posted here recently. You would need to do your own
high speed software driver unless someone has written one that
I am not aware of.
>
>I expect to put SCO XENIX on the AT, just because of DOS.  But the 386's
>I've tried to put Xenix on haven't worked, I've got to hope that a
>286 version will work better...  And with the software running TCP/IP
>itself, I shouldn't need too much hardware, should I?  I suspect

I use Sys V on a 386 with Phil's code. The standard TCP/IP for Unix
boxes doesn't understand AX25 link level nor are there drivers for
internal 8530 cards. I am using Phil's Net code version 890421
compiled for Sys V. It talks to a KISS TNC out a standard Async
port. This works well up to at least 19.2 Kb, this is the speed
I use to talk to the TNC. The TNC can talk to the world at 56 kb
thru a Grapes modem. There has been some recent work on an AX25
streams driver and a later version of Phil's code for Unix, but I
haven't kept up on this.

>that there's nothing running out here but a bunch of generic 1200 Baud
>TNC packet BBS's.  I have the opportunity here to set up a fast link
>if I understood what I am getting into.  Although I may not be capable
>of building a "very high speed" modem, I have friends who could, so
>the availability of equipment is more a function of cost than skill
>required.
>
>Can we run this thing (assuming 56KBaud and TCP/IP is considered "different"
>by the "true believers" of 1200Baud Packet) on the same frequency as the
>regular packet links? (i.e. will this just be another node, and the
>hardware oblivious to the RFModem tone's differences?)  Will I require
>Two modems?  I suspect that I want to be a "node", not just a digipeater;
>or do I?

56 kb occupies 70 khz and is not permitted below 220 Mhz by the rules.
In general, it is not a good idea to run different speeds on the same
channel. The modems will not detect different speed activity since they
use different modulation methods and there will be many collisions.

>I am talking of two separate machines.  The digipeater up on the side of
>the hill will have some hardware digipeating connections so it will just
>retransmit whatever hits it, (although there is some discussion about
>putting it close to my kitchen so the computer could become more intimately
>connected if required by something or other that I don't understand yet.)
>
>The second machine is down in my kitchen, an Icom 22s connected to an AT-Clone
>or Mikeintosh and some type of RFModem which pushes the 22S's Transmit
>button while screeching down the "Mike" line at 56K using TCP/IP.
>
>Have I got it right?

To my knowledge there is only one 56 kb "digipeater" operating in the
world. It is a full duplex machine using two 56 kb modems on two different
bands with a bit regenerator in between. All the other 56 kb modems are
attached to computers either thru a 8530 interface or one of our special
soupped up TNC2s. They act as true packet switches using Phil's TCP/IP
code. With current versions of Phil's code, you have the ability to
simulate a Netrom node, do full TCP/IP packet switching and routing,
and with my Mulport code you can do multiport digipeating for the
plain AX25 users who can't or won't use the Netrom routing. In Atlanta
we have switches handling up to four low speed channels and one high
speed channel operating. They form the backbone of our Lan system in
North Georgia with the 56 kb trunks carrying mixed traffic of Netrom,
digipeated AX25, and TCP/IP between the Lans. Our users are unaware
of how their traffic moves, to them it seems as if everyone is on
the same frequency using the same speed and mode they are using, but
without all the contention and collisions that would normally kill
the system.

Setting up a switched network like this is not "plug and play". It
takes a lot of hard work to coordinate the links and a little hardware
and software hacking to make it fly.

Gary KE4ZV

------------------------------

Date: Wed, 29 Aug 90 17:11:02 +0200
From: [e-mail]
To: [e-mail]

Subject: Re: The Fool on the Hill

Hello Jim and Patty,

Someone once donated me a PC clone...
I removed everything out of the case, and installed a 512Ke Mac motherboard...
Connected a powersupply and a floppydrive and started up NET/Mac...

It has been running perfectly well until I had to shut it down, because I
managed to get hold of a 20 MB harddisk...

Then I started it up again, and NET/Mac has been running in it ever since...

I cannot run it under MultiFinder, so Finder is the one you'll need, together
with SYSTEM 4.1.

73 de
   __
  / /   /
 /-/ __/ __/ ____
/ / (_/ (_/ / / /


+-------------------------------------------------------------------------+
| Please send your reply to:                  | Where  | Mac  | Software  |
|---------------------------------------------+--------+------+-----------|
|   TNO ZP-LAN: adam@tnoal1  (134.221.128.128)| office | SE   | NCSATelnet|
|     Internet: [e-mail]            |  same  | same |   same    |
|           or: [e-mail]          |  same  | same |   same    |
| Packet-radio: pa2aga@pa2aga   (44.137.32.9) | at home| Plus | NET/Mac   |
|           or: pa2aga@pa2aga-2 (44.137.32.19)| at home| 512Ke| NET/Mac   |
|           or: pa2aga@pi8mac   (44.137.32.22)| at home| SE/30| NET/Mac   |
+-------------------------------------------------------------------------+

------------------------------

Date: Thu, 30 Aug 90 10:06:34 +0200
From: [e-mail]
To: [e-mail], [e-mail], [e-mail]

Subject: Re: Fool on the hill (2)

Hello Patty and Dave,

Why system 4.1? Because I think the docs that come with NET/Mac tell you
to do so when running on a 512K Mac, and because I just happend to have
that lying around. I guess it might as well be 4.2 or 4.3 as well!

The version of NET/Mac I'm running is 2.0 (as in Apple.com) with some
extra mods to get rid of the most serious bugs. The released version may
crash every now and then (not really often), but the one I've generated
didn't crash so far (it's been running for about 3 months now).

Regards,
   __
  / /   /
 /-/ __/ __/ ____
/ / (_/ (_/ / / /


+-------------------------------------------------------------------------+
| Please send your reply to:                  | Where  | Mac  | Software  |
|---------------------------------------------+--------+------+-----------|
|   TNO ZP-LAN: adam@tnoal1  (134.221.128.128)| office | SE   | NCSATelnet|
|     Internet: [e-mail]            |  same  | same |   same    |
|           or: [e-mail]          |  same  | same |   same    |
| Packet-radio: pa2aga@pa2aga   (44.137.32.9) | at home| Plus | NET/Mac   |
|           or: pa2aga@pa2aga-2 (44.137.32.19)| at home| 512Ke| NET/Mac   |
|           or: pa2aga@pi8mac   (44.137.32.22)| at home| SE/30| NET/Mac   |
+-------------------------------------------------------------------------+

------------------------------

End of Packet-Radio Digest
******************************