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

Text File | 1993-12-31 | 278.3 KB | 6,943 lines

Tue,  1 Jan 91 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #1
To: packet-radio


Packet-Radio Digest         Tue,  1 Jan 91       Volume 91 : Issue   1

Today's Topics:
            Administrivia - Happy New Year
            DX Cluster protocol? (5 msgs)
          How do I get Mail forwarded from my BBS ?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 31 Dec 90 16:25:46 -0800
From: brian (Brian Kantor)
Subject: Administrivia - Happy New Year
To: dsp, info-hams, packet-radio, tcp-group

May you have peace, happiness, and prosperity in the new year.
    - Brian

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

Date: 1 Jan 91 01:02:04 GMT
From: envy![e-mail]  (Phil R. Karn)
Subject: DX Cluster protocol?
To: [e-mail]

In article <[e-mail]> [e-mail] (Ari Husa OH8NUP) writes:
>I had in mind something like a simple 'dx server' to my U*IX machine
>(hopefully soon to be connected with the packet network), where the
>user (client?) connects by 'telnet mymachine somenumber' and then uses
>the connection to acquire desired dx information. Wasteful or not -
>but there is a great need for this kind of service. Some of the local
>guys have been talking about putting up a cluster - I just hate to
>hear them say 'A-ha! your fancy tcp/ip can't do it!' ;-)

Sorry if I flamed a little, but this whole issue really hits my hot button.
I get very frustrated when I see amateurs wasting precious spectrum.  When I
suggest that there might be a more efficient way to do something, many hams
immediately take offense, protesting either that they aren't PhDs in EE or
computer science or that they don't have the million dollars they presume is
necessary to do the job right.

I don't have a PhD or a million dollars either, but that doesn't seem to get
past the cries of "elitist! elitist!"

Anyway, my point is that we hams had better start treating our spectrum with
some more respect if we're to save it from reallocation to commercial
interests who are used to investing BILLIONS (not just millions) of dollars
to shave a MHz or two off their RF requirements. There's no reason we
amateurs have to spend that kind of money, especially since we're SO far
down on the efficiency curve that some major gains could be had with very
simple and inexpensive techniques (like the use of a packet protocol
specifically designed for multicasting).

I always thought that radio amateurs were supposed to pride themselves on
being able to replace "brawn" (i.e., money) with brains (i.e., clever and
resourceful solutions to a problem.) This should be especially true in the
age of software, where one or two people can create something that can
easily be replicated and used by thousands of others.

Unfortunately, all too many amateurs seem willing to squander precious
spectrum to cover a lack of both brains and money. This results in "pissing
contests" like the one between AMSAT and W6GO over the use of 144.95 MHz for
the SAREX packet uplink (in my opinion, the SAREX "packet contest protocol"
and especially the W6GO "DX packet cluster" are BOTH egregious misuses of
the AX.25 protocol for things it was never designed to do.) And then when
somebody does come along who wants to try something new, he's told that all
of the spectrum is already in use - by the old, inefficient systems, of
course. Grrrr!

Luru, please don't take these comments personally; I know you only meant
well in trying to make NOS more useful to the general amateur population.
But I think we implementers have a duty to resist demands for inefficient
services, especially when there are much more efficient ways to provide
the same thing (even if they're not backwards compatible).

73, Phil

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

Date: 1 Jan 91 01:17:17 GMT
From: envy![e-mail]  (Phil R. Karn)
Subject: DX Cluster protocol?
To: [e-mail]

In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>However, many, many users of the DX clusters are not on a "broadcast"
>channel with the cluster. They are frequently one, two, or even three
>Netrom or digipeater (shudder) hops away.

Gary,

This still doesn't preclude doing it much more efficiently than now.  You
simply build logical spanning trees out of the links you do have, and then
you use controlled flooding (a la USENET) to send exactly one copy of each
data packet across each link.

A better way to handle this problem would be to build a parallel "broadcast"
packet network alongside the point-to-point packet networks now in use. A
channel would be reserved in each area for broadcast services, and the best
available site in the area would be chosen for the transmitter.  (This
differs from the point-to-point network, where overall spectral efficiency
is maximized by a cellular design with the smallest practical cell sizes).

Users would submit packets to the broadcast transmitter by means of the
regular point-to-point network. There would be no user sharing of the
broadcast channels - this is important to get the packet loss rate down to
where a packet-level FEC algorithm can provide almost perfect reception,
minimizing the time spent on repeats.

This system would not be limited to DX cluster type announcements - there's
an even more urgent need to distribute bulletins and "ALL@ALL" BBS messages
this way.

Phil

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

Date: 1 Jan 91 04:30:16 GMT
From: eru!hagbard!sunic!news.funet.fi!ousrvr!ousrvr![e-mail]  (Ari Husa OH8NUP)
Subject: DX Cluster protocol?
To: [e-mail]

In article <[e-mail]> karn@envy..bellcore.com (Phil R. Karn) writes:

> Sorry if I flamed a little, but this whole issue really hits my hot button.

Ah, well, don't you worry.. I can take it. In fact, I picture us
"digital guys" as about the only DEVELOPING branch of amateur radio
today. Flaming is always welcome!

> I get very frustrated when I see amateurs wasting precious spectrum.  When I
> suggest that there might be a more efficient way to do something, many hams
> immediately take offense, protesting either that they aren't PhDs in EE or
> computer science or that they don't have the million dollars they presume is
> necessary to do the job right.

Not really. I can picture myself trying to get together a protocol
specs or some sort, but I realize someone else can put it all together
much better. However, this digital development is the only Real
Development I see within the whole of the Amateur Radio Service today.
Naturally, I am all for the benefit of us all!

> past the cries of "elitist!  elitist!"

I don't really think this is the problem. "Elitist" contributors have
been welcome before. People just don't realize that the focus of the
development of amateur radio technology is not what it used to be a
few years ago.

> Anyway, my point is that we hams had better start treating our spectrum with
> some more respect if we're to save it from reallocation to commercial

I SHALL comment more on this when we have our FIRST 56kbit/s DSY MSK
network QSO's established. We're a little bit behind, but I figure DSY
is a couple of times more efficient than the regular AFSK.

This will be a big step forward. And HOPEFULLY the techiques we use
will inspire some RF people to develop an inexpensive 28/432 linear
transverter.

We're all that up to date as far as shaving off the few extragenous
kHz here. We wanna get going with SOMETHING ELSE but 1200 bps AFSK.

> amateurs have to spend that kind of money, especially since we're SO far
> down on the efficiency curve that some major gains could be had with very
> simple and inexpensive techniques (like the use of a packet protocol
> specifically designed for multicasting).

All for! We're the first in our couto put up a 56kbit/s network. I'd like to see the others come after us!

> I always thought that radio amateurs were supposed to pride themselves on
> being able to replace "brawn" (i.e., money) with brains (i.e., clever and
> resourceful solutions to a problem.) This should be especially true in the
> age of software, where one or two people can create something that can
> easily be replicated and used by thousands of others.

> Unfortunately, all too many amateurs seem willing to squander precious
> spectrum to cover a lack of both brains and money. This results in "pissing

I think this is THE moment to hit! The 1200 bps FSK has not yet been
replaced by anything else. I'd VBERY MUCH like to see 56 kbps DSY MSK
to be the next genaration. At least this seems to be the best choice.

> somebody does come along who wants to try something new, he's told that all
> of the spectrum is already in use - by the old, inefficient systems, of
> course. Grrrr!

GRRR!! Indeed!

IF we will get the 56kbit/s DSY local network going, we will probably
NOT be able to get a license for an automatic amateur radio station
(ie. repeater / digipeater) because IARU suggests the maximum bandwidth
to be 25 MHz on UHF bands.

This is based on the situation SOMEWHERE within Region 1 (Don't
exactly know where, since everyone I've been talking to say there's
plenty of room within the amateur spectrum). I hope there will be
change to this, though!

> Luru, please don't take these comments personally; I know you only
> meant

I won't. I am aware that I am not expert on some subjects - that's why
I ask questions about them... ;)

I am quite happy about the fact I've generated a few responses. Thank
you all!

    Luru
--
    ///
    o-o    Ham Radio Operators Do It In Higher Frequency
     o

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

Date: 1 Jan 91 05:14:54 GMT
From: att!linac!midway!ux1.cso.uiuc.edu![e-mail]  (Phil Howard KA9WGN)
Subject: DX Cluster protocol?
To: [e-mail]

[e-mail] (Ari Husa OH8NUP) writes:

>IF we will get the 56kbit/s DSY local network going, we will probably
>NOT be able to get a license for an automatic amateur radio station
>(ie. repeater / digipeater) because IARU suggests the maximum bandwidth
>to be 25 MHz on UHF bands.

I was under the impression that the bandwidth for one channel was
only 70 kHz with the DSY system at 56KB.

>This is based on the situation SOMEWHERE within Region 1 (Don't
>exactly know where, since everyone I've been talking to say there's
>plenty of room within the amateur spectrum). I hope there will be
>change to this, though!

There is plenty of room, especially if we take into consideration phasing
out old technology and replacing it with the new.

>> Luru, please don't take these comments personally; I know you only
>> meant

>I won't. I am aware that I am not expert on some subjects - that's why
>I ask questions about them... ;)

>I am quite happy about the fact I've generated a few responses. Thank
>you all!

How about developing new protocols (at the appropriate levels, etc.) for
the purpose of broadcast-like services (such as DX cluster) the RIGHT WAY
and, to get people switch over, run a gateway between the old and new for
a while.  Is that what you had in mind?
--

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

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

Date: 1 Jan 91 08:24:32 GMT
From: eru!hagbard!sunic!news.funet.fi!ousrvr!ousrvr![e-mail]  (Ari Husa OH8NUP)
Subject: DX Cluster protocol?
To: [e-mail]

In article <[e-mail]> [e-mail] (Phil Howard KA9WGN) writes:

> [e-mail] (Ari Husa OH8NUP) writes:
> >to be 25 MHz on UHF bands.
> I was under the impression that the bandwidth for one channel was
> only 70 kHz with the DSY system at 56KB.

Got me! 25 kHz, of course..

> How about developing new protocols (at the appropriate levels, etc.) for
> the purpose of broadcast-like services (such as DX cluster) the RIGHT WAY
> and, to get people switch over, run a gateway between the old and new for
> a while.  Is that what you had in mind?

Yes, that's what I had in mind..

    Luru
--
    ///
    o-o    Ham Radio Operators Do It In Higher Frequency
     o

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

Date: Mon, 31 Dec 90 22:24:43 PST
From: [e-mail] (CAL-LAB (MS:JER2-85 TEL:7589))
Subject: How do I get Mail forwarded from my BBS ?
To: "[e-mail]"@HERMES.intel.com

Help !

I'm trying to get our BBS to Forward mail to  my personal mailbox.
The BBS is running MBL 5.14  software and I'm using an AEA PK-232MBX.
I added the following lines to the forwarding file (which at the moment just
forwards and reverse forwards with other BBS's)
----------
GA 4X1DA
00-23
@ 4X1DA
4X1DA
----------
I set the maildrop of the PK232 to ON.
I also set the MYBBS properly

The BBS connects to me during the forwarding minute if I have mail
but it doesn't forward anything. (It just sits there connected until
it times out - then resumes normal operation).

Any suggestions ?? How sould my TNC be set and what has to be changed in the
forwarding file ??

73,
Rich
------------------------------------------------------------------------------
..."The only thing we should be absolutely SURE about is that we can't be
ABSOLUTELY sure of anything"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
E-Mail:                  |Pigeon:          |Land Line:  |Packet:|Heart:
[e-mail] |P.O. BOX 6457    |972-2-785578|4X1DA  |Cute blondes
             |JERUSALEM, ISRAEL|            |@4Z4SV |with blue eyes
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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

End of Packet-Radio Digest
******************************
Date: Wed,  2 Jan 91 04:30:02 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #2
To: packet-radio


Packet-Radio Digest         Wed,  2 Jan 91       Volume 91 : Issue   2

Today's Topics:
             DX Cluster protocol?
          How do I get Mail forwarded from my BBS ?
              MSYS 1.19? Latest version
            Packet-using-PICCOLO?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 1 Jan 91 17:31:50 GMT
From: cica!sol.ctr.columbia.edu!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: DX Cluster protocol?
To: [e-mail]

In article <[e-mail]> [e-mail] (Phil R. Karn) writes:
>In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>>However, many, many users of the DX clusters are not on a "broadcast"
>>channel with the cluster. They are frequently one, two, or even three
>>Netrom or digipeater (shudder) hops away.
>
>Gary,
>
>This still doesn't preclude doing it much more efficiently than now.  You
>simply build logical spanning trees out of the links you do have, and then
>you use controlled flooding (a la USENET) to send exactly one copy of each
>data packet across each link.
>
>A better way to handle this problem would be to build a parallel "broadcast"
>packet network alongside the point-to-point packet networks now in use. A
>channel would be reserved in each area for broadcast services, and the best
>available site in the area would be chosen for the transmitter.  (This
>differs from the point-to-point network, where overall spectral efficiency
>is maximized by a cellular design with the smallest practical cell sizes).
>
>Users would submit packets to the broadcast transmitter by means of the
>regular point-to-point network. There would be no user sharing of the
>broadcast channels - this is important to get the packet loss rate down to
>where a packet-level FEC algorithm can provide almost perfect reception,
>minimizing the time spent on repeats.
>
>This system would not be limited to DX cluster type announcements - there's
>an even more urgent need to distribute bulletins and "ALL@ALL" BBS messages
>this way.
>
>Phil

See, I'm not so dumb. :-) I thought a little prodding would get the
creative juices flowing. Unfortunately we are already using a cell
size with a radius of 30 miles due to a scattered user population.
With our terrain this is hidden terminal city. We have neither the
sites nor user support to shrink our cells. We do have a sort of
parallel trunking arrangement, but it is strictly point to point,
high site to high site. I think that a prearranged system with
a permanently connected termination on each route that can supply
ACKs to insure that a copy of the message makes it through the network,
could allow many of our users to passively monitor the broadcasts and
relieve much of the load placed on the system by things like the
packet cluster. It seems that a practical first step would be to
design a listener program that could piece together messages from
monitored packets. Perhaps bulletins could use a line numbering
scheme to facilitate this (I overheard this suggestion at Dayton
by N4HY). Ideally, if a new protocol were implemented with FEC
then one ACK per message by the terminator would suffice with the added
possiblility of NAKing individual frames found uncorrectable by the FEC.
Of course we need to figure a way to stop the ACKs and NAKs from
getting clobbered or it's all for naught. This is where the ideal
separate network for broadcasts would be nice.

Gary KE4ZV

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

Date: 1 Jan 91 19:58:07 GMT
From: usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: How do I get Mail forwarded from my BBS ?
To: [e-mail]

As quoted from <[e-mail]> by [e-mail] (CAL-LAB (MS:JER2-85 TEL:7589)):
+---------------
| I'm trying to get our BBS to Forward mail to  my personal mailbox.
| The BBS is running MBL 5.14  software and I'm using an AEA PK-232MBX.
| I added the following lines to the forwarding file (which at the moment just
| forwards and reverse forwards with other BBS's)
+---------------

You have to arrange for the PK232 to send a "host ID" (I believe that's the
right term) when it connects.  You know that when you connect to a BBS, the
first thing it sends looks like "[XXX-V.VV-H$]"?  That's the host ID.  The XXX
and V.VV are pretty much irrelevant but should identify the software you're
using (in this case, something like "PK232-v.vv" where v.vv is the rev level
on the PK232 firmware); the H indicates hierarchical forwarding and should
*not* be sent by a PK232 or other personal mailbox; the $ indicates bulletin
handling.  Since my PK88 supports bulletin handling, the PK232 should.

You need to set your MTEXT or something similar to send as the first line:

[PK232-v.vv-$]

This will tell the BBS that it's talking to something that supports forwarding.
After this, the BBS will send its own host ID, which should switch the PK232
mailbox into a special mode indicated by its issuing a simple ">" prompt.
(If it doesn't, your PK232 rev level doesn't support forwarding/reverse
forwarding.)  After that, the BBS will send SP commands to send individual
messages, then send "F>".  The F> switches roles; if the PK232 is set to
reverse forward messages and it has any to send, it will issue SP commands
--- otherwise, it disconnects.

NB:  This is what I've observed.  I'm still a bit hazy on MBL/RLI mail
forwarding.  Anyone want to post a full description?

In any case, the host ID in [] is REQUIRED.

++Brandon
--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

Date: 1 Jan 91 17:40:54 GMT
From: cs.utexas.edu!asuvax!stjhmc![e-mail]  (David Dodell)
Subject: MSYS 1.19? Latest version
To: [e-mail]

I'm trying to locate the latest version of MSYS to install, which I
understand is version 1.19.  Anyone know of someplace I can either download
it at 9600 speeds (HST/V32/PEP) ... or ftp it from on the internet?

73,

David WB7TPY

----


--
   -------------------------------------------------------------------------
      St. Joseph's Hospital and Medical Center, Phoenix, Arizona
    uucp: {gatech, ames, rutgers}!ncar!asuvax!stjhmc!ddodell
    Bitnet: ATW1H @ ASUACAD                    FidoNet=> 1:114/15
    Internet: [e-mail]       FAX: [phone]

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

Date: Wed, 02 Jan 91 10:15:56 GMT
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: Packet-using-PICCOLO?
To: [e-mail]

Hi. Has anyone considered using alternatives to the usual modes of
modulation for packet? All the existing packet systems seem to use
modems that were designed for telephone-line service; this is not
necessarily the best way, particularly on HF. There *are* better
modulation systems (I am thinking here of the PICCOLO system that
was developed in the 'sixties; used multiple tones, and achieved a
very great resilience against noise; i remember seeing one of these
things generating 100%% error-free RTTY over a HF link on which i could
not even tell that there was a signal.....)
OK its not the fastest (or it wasnt when i saw it, but that *WAS* 15
years ago, and the terminal unit was a rack full of L-C filters)
With modern LSI modems things would be more compact.  I am told that
Racal made some Piccolo modems for the commercial market. Anyone
know anything about these??

73 de Pete G6WBJ

Please use the following addresses for reply:          +     \/Natural
                               +    \/\Environment
JANET    : [e-mail]            +   \/\/Research
Internet : [e-mail]        +  \/\/\Council
EARN     : PJML%UK.AC.NWL.IA@UKACRL                    +  NERC Computer Services
RADIO    : [e-mail]  {144.650MHz}           +   Holbrook House
SPAN     : STAR::\[e-mail] +    Station Road
PHONE    : [phone]                            +     SWINDON SN1 1DE
FAX      : [phone]                            +      GREAT BRITAIN

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

End of Packet-Radio Digest
******************************
Date: Thu,  3 Jan 91 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #3
To: packet-radio


Packet-Radio Digest         Thu,  3 Jan 91       Volume 91 : Issue   3

Today's Topics:
             9600 baud operation
               AX.25 Network Simulation
            Broadcast Protocols...
          connecting to Dallas Remote Imaging Group
             Digicom 64 TNC, SOLD
             DX Cluster protocol?
           High speed point to point Backbones ...
             TNC generates noise
           unsubscribe $[e-mail]
        Wanted TNC,internet<-->packet question

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 2 Jan 91 14:17:06 GMT
From: netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
Subject: 9600 baud operation
To: [e-mail]

Does anyone have experience with using the 9600 baud modems sold by
PACCOMM, Hamtronics or Kantronics??  What types of radios work with them??
Are all the 9600 baud systems compatable??

I have finally got some TCPIP activity going and the first thing everyone
agrees on, is the need for higher baud rates than 1200.  I plan on keeping
a 1200 baud channel as an introduction to get other people interested,
but I want to move the bulk to higher speed.  I think 9600 baud is it
for at least a little while.

Can anyone offer any info??

bill    KB3YV


--

     Bill Gunshannon          |        If this statement wasn't here,
     [e-mail]   |  This space would be left intentionally blank

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

Date: Wed, 2 Jan 91 10:14:06 -0800
From: brian (Brian Kantor)
Subject: AX.25 Network Simulation
To: packet-radio, tcp-group

Has anyone done any network simulation on a prototypical AX.25 network using
software tools like CACI's NETWORK or other network simulators?
    - Brian

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

Date: Wed, 02 Jan 91 12:30:34 GMT
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: Broadcast Protocols...
To: [e-mail]

Seems to me that the sensible way to do a broadcast protocol would be some
sort of polling mechanism; Possibly like this:

Stations wanting to enter the 'broadcast list' send a frame to the
broadcasting node - this frame contains callsign and the 'broadcast list'
the new station wishes to enter.

Broadcasting node adds callsign of new station to its list, and allocates
new station a polling address. It transmits this polling address to the
new station as an acknowledgement that the new station has entered the
list.

When broadcasting station transmits, it sends the information in much the
same way as NETROM 'NODES' broadcasts.

Broadcasting node then issues short 'poll' frames to each of the stations
in its list; these reply with an acknowledge that they heard the broadcast.
If a station does not hear the initial broadcast, the broadcast is repeated
(and of course everybody will hear it, so the number of subsequent stations
that failed to hear it will be less....)

Stations not responding to some set number of polls will be dropped from
the broadcast-station's list.

Stations wishing to send data to the broadcast node must wait till they are
polled. So you may have to wait for a slot.

A protocol based on this was written by me some years ago, to allow unused
PCs on a network to receive status broadcasts from a central server; it
also allowed any unused PC to be used to send brief messages to our support
staff from terminal rooms etc.  Admittedly, I wrote most of it in BASIC
so fast it was not, but it worked!


     Pete Lucas [e-mail]  [e-mail]

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

Date: 2 Jan 91 18:46:35 GMT
From: cica!news.cs.indiana.edu!ariel.unm.edu!nmsu!opus![e-mail]  (smouldering dog)
Subject: connecting to Dallas Remote Imaging Group
To: [e-mail]

packet people:
can someone help me contact the Dallas Remote Imaging Group?  I wish
to ask them for some software.  Alternatively, if someone knows of an
e-mail address for these guys, please let me know.

    owen white

--

-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-
    got my head on a pole (for better reception)
-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-=-*-=-

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

Date: 1 Jan 91 20:58:24 GMT
From: voder!wlbr!lonex.radc.af.mil![e-mail]  (Lee Ritter)
Subject: Digicom 64 TNC, SOLD
To: [e-mail]

The Digicom 64 TNC previously listed has been sold

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

Date: 2 Jan 91 17:04:29 GMT
From: zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!trantor.harris-atd.com!x102c![e-mail]  (Gary Bastin 60293)
Subject: DX Cluster protocol?
To: [e-mail]

In article <[e-mail]> [e-mail] (Phil R. Karn) writes:
>
>Sorry if I flamed a little, but this whole issue really hits my hot button.
>I get very frustrated when I see amateurs wasting precious spectrum.  When I
>suggest that there might be a more efficient way to do something, many hams
>immediately take offense, protesting either that they aren't PhDs in EE or
>computer science or that they don't have the million dollars they presume is
>necessary to do the job right.
>
...
>
>Unfortunately, all too many amateurs seem willing to squander precious
>spectrum to cover a lack of both brains and money. This results in "pissing
>contests" like the one between AMSAT and W6GO over the use of 144.95 MHz for
>the SAREX packet uplink (in my opinion, the SAREX "packet contest protocol"
>and especially the W6GO "DX packet cluster" are BOTH egregious misuses of
>the AX.25 protocol for things it was never designed to do.) And then when
>somebody does come along who wants to try something new, he's told that all
>of the spectrum is already in use - by the old, inefficient systems, of
>course. Grrrr!

Phil, I agree that both the SAREX experiment and the packetcluster nodes
are different than the typical AX.25 uses.  They also were not even
around when the AX.25 protocol was developed.  However, I do not see them
as squandering precious resources.  Rather, they are the first step in
developing NEW SYSTEMS.  Should uses such as the packetcluster wait
until an optimum protocol IS developed, or should hams, in typical
ham fashion, go ahead, working on a shoe-string budget, use
existing software and hardware (tncs, etc.) and dream up and implement
new systems WITHOUT HAVING TO WRITE ALL NEW SOFTWARE AND BUY NEW HARDWARE.  I
agree that the AX.25 protocol is best suited for point-to-point communications,
but it is also quite suitable for handling long distance dx packetcluster
activity.  Here in Florida, we have a packetcluster system that links
Melrose (Gainesville/Jacksonville), Apopka (Orlando), Melbourne (the
spacecoast), and Boca Raton (Miami).  So the whole state is essentially
linked from North to South.  The existing AX.25 protocol WORKS.  Not optimally,
of course, but it WORKS TODAY.  Each node has its own local users, and
some chatting between adjacent nodes does occur.  But over the whole
network, the only thing that is shared is really just DX spots.  High
numbers of users regularly go over 30 for the network, and weekends see
numbers over 50.  I personally found very little use for old-style
typical packet BBS'es, but find the packetcluster activity much more
interesting.  (Of course, I am primarily a DXer :-)  But I do not see
the point of flaming systems that, although not optimal, do fulfill a
need today in Ham Radio.  If we waited for optimal systems, then there
would never be any development of better systems!  As for newer systems,
they can be developed.  And they certainly can force the demise of
certain communications modes, although not overnight (consider the
case for AM versus SSB).  It was unfortunate that SAREX chose the
same frequency for the space shuttle experiment due to congestion.  However,
one of the local 'Big Gun' dxers did give me a call, knowing that I was
active on RS10/11, wanting information on how to work the shuttle. So
perhaps the choice of frequency did some good afterall!  All in all, it
seems that people forget that Ham Radio is not one hobby, but is really
a whole set of similar hobbies wrapped up in one package.  I will celebrate
my 20th year as a ham this year, and I am still interested in new
activities in ham radio.  And no, I do not call any activity having
to do with ham radio technology a 'waste of resources'.  Now some of the
behavior, such as occurs on 20m SSB, is a waste of resources :-)

Happy New Year!  73, Gary

Gary Bastin, WB4YAF      /-/-/      Internet: [e-mail]
Mail Stop 102-4826         |        phone: [phone]
Harris Corporation GASD    |
P.O.B. 94000, Melbourne FL 32902    Speaking from, but not for, Harris!

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

Date: 2 Jan 91 20:58:10 GMT
From: deccrl!news.crl.dec.com!pa.dec.com!shlump.nac.dec.com!delni.enet.dec.com![e-mail]  (Fred R. Goldstein)
Subject: High speed point to point Backbones ...
To: [e-mail]

The idea of embedding ham callsigns in Ethernet is silly.

Ethernet is a subnet technology which uses 48-bit addresses that
guarantee uniqueness, IF taken from the globally-administered
blocks and used correctly.  It is a "dense" coding, though,
with successive values assigned. So are callsigns, but only mod-26.
And callsigns are assigned quite differently.

Better to simply use an appropriate technology. Ethernet per se
won't work on radio too well because it's very hard to get true
CSMA/CD, and even if you do, you have to keep alpha below 1
(ratio of propagation delay to minimum packet duration) for the
CD to work.

If it turns out that "true Ethernet" chips can be slowed down and
used on radio, better to use "local" Ethernet space IDs with
some funny local value, and encapsulate the real ham calls inside the
frames in the next level (variable-length) header.  Better yet,
use a protocol designed for radio.  Ethernet was inspired by radio
(I know one of the inventors and he's a ham) but it's a very different
beast in practice.

BTW, if you really want to embed callsigns in a "real" protocol,
look at OSI network layer addresses.  They're variable length, and
it's quite easy to embed anything within them.  But that's another
discussion.
    fred
---
Fred R. Goldstein    k1io      Digital Equipment Corp., Littleton MA
[e-mail]   voice: [phone]
 Do you think anyone else on the planet would share my opinions, let
 alone a multi-billion dollar corporation?

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

Date: 2 Jan 91 14:55:12 GMT
From: world!ksr![e-mail]  (Tom Varga)
Subject: TNC generates noise
To: [e-mail]

I have just set up a packet station based on a Mac SE/30, PK-232 and
an IC-24AT HT.  I have read in various places that an HT would be
sufficient for packet. (I now think that this is only true if no one
else is using the same digipeater that I am since I don't have a very
strong signal)

My problem is that the TNC generates a lot of noise. (Whereas the
Macintosh generates almost none)  The noise pins the HT's S-meter
on most frequencies. OK, I know the HT is prone to intermod problems,
but if a 2 MIP computer running at 16 Mhz doesn't cause problems,
shouldn't I expect to not have problems with a TNC that is supposed to
run in an RF environment?

OK so now I walk up to the attic with the HT and still receive some
noise.  I imagine with a gain antenna on the roof, it will again be
worse.  Unfortunately after the fact, I checked the noise generated by
a KAM and it was significantly less.

Question : Does anybody else use the PK232 with an HT?  Do you have
noise problems?  Do you have any other ideas for solutions? Is my only
solution to buy another radio and antenna? Or should I switch to a
KAM?

Thanks in advance for your help,
Tom

--
================================================================================
= Tom Varga N2UA/1                617-895-9415          packet : N2UA @ KA1MGO =
=                  [e-mail]                      uunet!ksr!tom              =
=   There's never time to do it right, but there's always time to do it over.  =
================================================================================

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

Date: Wed, 02 Jan 91 16:11 EST
From: "Geri S. Ellis"                      <[e-mail]>
Subject: unsubscribe $[e-mail]
To: [e-mail]

Please unsubscribe $[e-mail] from your
packet-radio list (and any related mailing list
for I-PACRAD or /dev/null). This user is no longer
on this computer and we are trying to clean up
obsolete mail deliveries. Thank you very much.
Geri Ellis, BITNET Techrep

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

Date: 2 Jan 91 19:11:03 GMT
From: uoft02.utoledo.edu![e-mail]
Subject: Wanted TNC,internet<-->packet question
To: [e-mail]

I am looking for a TNC for my commodore 128. I perfer a used model. I can
connect it to my RS-232 interface or directly to use computer (depending on the
TNC).  I am not able to pay lots of money (or I'd buy a new model).

Also, I read this news group over Internet and I have a friend who is a packet
user and I want to know if I can send him E-Mail to his packet account on a
packet bbs.  I am new to ham and packet and I am currently learning the code to
Earn my first ticket.

Thanks in advance

Tony

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

End of Packet-Radio Digest
******************************
Date: Fri,  4 Jan 91 04:30:02 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #4
To: packet-radio


Packet-Radio Digest         Fri,  4 Jan 91       Volume 91 : Issue   4

Today's Topics:
             High speed networks
            Packet-using-PICCOLO? (2 msgs)
           Setting up multi-port NET/ROM or TheNet.
              TNC-1 in 300 bps KISS-mode
             TNC generates noise (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

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

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 3 Jan 91 23:30:44 GMT
From: bu.edu!rpi!julius.cs.uiuc.edu!news.cs.indiana.edu!bsu-cs![e-mail]  (Joel L. Duerksen)
Subject: High speed networks
To: [e-mail]

There have been several articles in "Lan Times" about high speed
wireless networks.   In reading about them at least one operates
in the 902-928 MHz range.  Would it be feasible to take their card
and boost the signal for more range?  I believe they operate on
Spread Spectrum technology.

Joel Duerksen

USnail: 410 N. McKinley, Apt. 305, Muncie, IN. 47303
  AT&T: 1-317-289-0430  ICBM: 85 24 31 W / 40 12 16 N   RF: KB9EKY
  UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!duerksen
  ARPA: [e-mail]

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

Date: 3 Jan 91 21:23:29 GMT
From: idacrd![e-mail]  (Robert McGwier)
Subject: Packet-using-PICCOLO?
To: [e-mail]



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

Date: 4 Jan 91 10:07:33 GMT
From: mcsun!unido!infoac![e-mail]  (DL3NO Aachen)
Subject: Packet-using-PICCOLO?
To: [e-mail]

[e-mail] ("Pete Lucas, NCS-TLC, Holbrook House, Swindon") writes:

>I am told that
>Racal made some Piccolo modems for the commercial market. Anyone
>know anything about these??

>73 de Pete G6WBJ

As far as I know, Picolo is used for traffic of some french embassies.
The Dutch "Code-3" Box does decode this (optional $$$). There are only
few frequencies in use with this system..

73
Rupert,
[e-mail]

--
*****************************************************************
   ___  ____  ___    _  _ ___ ___   ___ ___ ___     ___ _  _
  /__/ / / /   /    /\ / /__   /   /__//__//   /__//__ /\ /
 / \  /   / __/_   /  / /__   /   /  //  //__ /  //__ /  /

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

Date: 27 Dec 90 19:09:21 GMT
From: hpcc05!col![e-mail]  (Bdale Garbee)
Subject: Setting up multi-port NET/ROM or TheNet.
To: [e-mail]

>You may wish to investigate the use of KISS TNCs or DRSI cards and the
>G8BPQ software; assuming you have a PC/XT class of machine to dedicate
>to networking, it would probably be a better fit to what it sounds like
>you want to do.

Also, look into the Kantronis Data Engine, for which a G8BPQ EPROM image is
available that makes it a very nice Net/Wrong compatible switch...

I've not run the code personally, but I looked it over and it seemed fine.

Bdale

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

Date: 2 Jan 91 16:05:14 GMT
From: hpcc05!col![e-mail]  (Bdale Garbee)
Subject: TNC-1 in 300 bps KISS-mode
To: [e-mail]

>I have tried to put one of my TNC-1's in KISS on HF...
>Does anyone know of a version of KISS that will work on 300 bps?

There are at least two variants of the KISS EPROM for the TNC-1.  One wants
you to set the NVRAM baud rate parameter using a normal TNC-1 EPROM, and then
it uses the same parameter.  The other, by PA0GRI, hard-codes the baudrate as
a constant near the front of the EPROM.  If you have the first, I'm not sure
I remember the process well enough to help.  If you have the second, then you
are likely trying to send frames at 1200 baud.

Bdale

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

Date: 3 Jan 91 14:02:16 GMT
From: sdd.hp.com!wuarchive!emory!emcard!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: TNC generates noise
To: [e-mail]

In article <[e-mail]> [e-mail] (Tom Varga) writes:
>
>I have just set up a packet station based on a Mac SE/30, PK-232 and
>an IC-24AT HT.  I have read in various places that an HT would be
>sufficient for packet. (I now think that this is only true if no one
>else is using the same digipeater that I am since I don't have a very
>strong signal)
>
>My problem is that the TNC generates a lot of noise. (Whereas the
>Macintosh generates almost none)  The noise pins the HT's S-meter
>on most frequencies. OK, I know the HT is prone to intermod problems,
>but if a 2 MIP computer running at 16 Mhz doesn't cause problems,
>shouldn't I expect to not have problems with a TNC that is supposed to
>run in an RF environment?
>
>OK so now I walk up to the attic with the HT and still receive some
>noise.  I imagine with a gain antenna on the roof, it will again be
>worse.  Unfortunately after the fact, I checked the noise generated by
>a KAM and it was significantly less.
>
>Question : Does anybody else use the PK232 with an HT?  Do you have
>noise problems?  Do you have any other ideas for solutions? Is my only
>solution to buy another radio and antenna? Or should I switch to a
>KAM?
>
>Thanks in advance for your help,
>Tom

The PK232 is a horrible noise generator alright. There are simple steps
that you can take to solve the problems however. The first thing you
*must* do is disassemble the case and sand the paint from all mating
surfaces. Achieving a good case bond will remove a lot of the hash.
Use star washers under all screws. The second step is to use toroidal
cores on all cables entering and leaving the unit. Be sure you are using
shielded cables for all leads.  The third step requires the liberal
sprinkling of bypass capacitors on the circuit board. AEA has a bulletin
describing where to add the capacitors.

Even with all this, however, you may still experience problems with
the HT. The basic problem here is that the rubber ducky antenna on
the HT will couple RF back into the audio and PTT leads. This can
cause all kinds of bizzarre problems. The solution to this problem
is also simple. Don't use a rubber ducky. Always use an external
antenna, preferably an outside antenna mounted high and in the clear.

These problems are not unique to the PK232 and most users trying to
use a TNC with a HT will suffer at least some of these problems.
The absolute quietest TNC as it comes from the factory is the MFJ
1270B. Their cheap little tin box is a rather effective shield.
You still need to use shielded cables and it's still best to use
an external antenna on your HT. Try not to use too high a gain
antenna, however, as HTs *are* prone to overloading and intermod.

Gary KE4ZV

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

Date: 4 Jan 91 01:34:01 GMT
From: usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: TNC generates noise
To: [e-mail]

As quoted from <[e-mail]> by [e-mail] (Tom Varga):
+---------------
| My problem is that the TNC generates a lot of noise. (Whereas the
| Macintosh generates almost none)  The noise pins the HT's S-meter
| on most frequencies. OK, I know the HT is prone to intermod problems,
| but if a 2 MIP computer running at 16 Mhz doesn't cause problems,
| shouldn't I expect to not have problems with a TNC that is supposed to
| run in an RF environment?
+---------------

You missed my message about this on packet 3 weeks ago.  ;-)

Wrap the cable from the TNC to the HT around a ferrite RFI line filter,
close to the TNC.  It worked with my MFJ-1278, and I've had reports that it
cleans up PK232's as well.

On the other hand, I don't get QRM from my 1278 when the radio is
disconnected.  Contact AEA --- your PK232 may have something wrong with it.

++Brandon
--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

Date: (null)
From: (null)
I am doing this at this time for AEA and their upcoming DSP box.
As you might imagine, since this is not intended for a target radio,
it must have some careful thought go into.  It must work reliably
with many different radios, each with different response.  Your rack
of LC filters had to have been very carefully designed for it to
achieve the performance you have observed.  The same is true in
DSP.  I have been working on 3 different designs for 6 months on
and off but with my recent retirement from Microsat operations, I
have returned to it full time.  Tom CLark, W3IWI and I are running
experiments using the intended hardware.  Ray Pettit (whose call
I can never remember) has written two or three articles about
a DSP based, extremely slow system, which is a real `mudder'
as WA3ZIA calls it.  It really digs into the mud. I hope to get
this performace out of a system that runs a little faster than
we currently use for packet (300 bps).  More on this will follows
later as I have more results in.  Frankly, I have been spending
a lot of time making all the PK-232 equivalent modems outperform
the PK-232. This will continue for the next 3 weeks or so and then
it is back to strictly new development.

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: Sat,  5 Jan 91 04:30:02 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #5
To: packet-radio


Packet-Radio Digest         Sat,  5 Jan 91       Volume 91 : Issue   5

Today's Topics:
             A question about DSP
             DX Cluster protocol?
              MSYS 1.09 sent to archives
                Newcomer (ME)
            Packet Radio to Georgian SSR?
              Unsub $[e-mail]

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 4 Jan 91 13:40:10 GMT
From: netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
Subject: A question about DSP
To: [e-mail]

I have heard that the current DSP chips can detect extremely narrow signals.
Assuming this, why would it not be possible to make a packet modem that
used a standard voice radio, but got greater thruput by sending more bits
at one time (ie. not synchronous or asynchronous.)

The concept I have in mind is a modem where the transmit side sends 9
discrete tones spaced 100 hz apart.  8 tones are data bits and the 9th
tone is data strobe. (A lot like the parallel port on a PC.)  I would
expect that keeping this 1Khz audio signal within the passband of a
voice reciever would not be dificult, the only real problem would be
detecting it on receive.  This is where I think a DSP system would be
ideal.

Am I completely off track?  Is there some other reason why this wouldn't
work?  Where does Shannon come into play here?  If it is possble, where
does one find a source for things like DSP chipsets if one wants to learn
by doing?


bill    KB3YV


--

     Bill Gunshannon          |        If this statement wasn't here,
     [e-mail]   |  This space would be left intentionally blank

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

Date: 4 Jan 91 22:55:01 GMT
From: envy![e-mail]  (Phil R. Karn)
Subject: DX Cluster protocol?
To: [e-mail]

In article <[e-mail]>, [e-mail]
(Gary Bastin 60293) writes:
|> Phil, I agree that both the SAREX experiment and the packetcluster
nodes
|> are different than the typical AX.25 uses.  They also were not even
|> around when the AX.25 protocol was developed.  However, I do not see
them
|> as squandering precious resources.

Gary,

It all depends on the area. If the population density is low enough so
that everyone's spectrum needs are satisified even when inefficient
protocols are used, then there's no problem. But we're seeing
increasing friction between contending uses for the spectrum that
could have been avoided had more efficient methods been used. The
SAREX/W6GO conflict is a good example of this. The 2m packet segment
could carry far more traffic than it does now, but because of the
inefficient modulation, channel access methods and protocols in use,
the segment is "full" in most areas and there's little if any room to
try something new, even if it's more efficient.

By way of analogy, you could say that gas guzzler cars and coal-fired
power plants "work today" but that doesn't mean there is no need to
develop anything new. Sooner or later we'll pay the price.

Phil

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

Date: 5 Jan 91 03:42:15 GMT
From: VAX1.CC.UAKRON.EDU!mcs.kent.edu!usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: MSYS 1.09 sent to archives
To: [e-mail]

Thanks to Brian Kantor, MSYS 1.09 is on its way to the various ham-related
archive sites.  Mike Pechura WA8BXN is still testing version 1.10; I'll post
an announcement when it becomes available.

++Brandon
--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

Date: 3 Jan 91 15:48:36 GMT
From: salt!roadster![e-mail]  (Michael Garnett)
Subject: Newcomer (ME)
To: [e-mail]

I hope you'll forgive what may seem like extreme;y stupid questions to you,
but I am completely new to even READING about HAM-oriented stuff.  It is
fascinating to me.  I work as a researcher in the communications field (Broad
band network/Fiber).  My best friend and I have recently been talking about
things that we'd read/heard about packet-radio.  I'm still fuzzy on what it
can/cannot do.  Who can do it.  How much would it cost to get a moderate setup.
...stuff like that....  I know that we have a packet-radio reachable setup here
where I work.... I suppose I could go bug them too :).  If ANYONE would be
willing give me quicky overview, so I can tell where to go to get my feet
wet, I'd be most thankful.


            Hoping I made even a BIT of sense...
------------------------------------------------------------------------
    *********                  Michael S. Garnett
  **    o    **                Information Networks Research
 **   _- -_   **               Ph: 201-829-4591
**   /     \   **              Internet: [e-mail]
*   |       |   *              UUCP: ...!bellcore!thumper!garnett
**  |       |  **
 ** /_______\ ** // I speak for only myself, and NOT any company or
  **    o    **  // organization directly or indirectly associated with
    *********    // Bell Communications Research

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

Date: 4 Jan 91 22:37:27 GMT
From: midway!gargoyle.uchicago.edu![e-mail]  (La Monte Yarroll)
Subject: Packet Radio to Georgian SSR?
To: [e-mail]

I've been approached by a group of mathematicians at the Georgian
Acadamy of Sciences at Tbilisi, Georgian SSR (in the Soviet Union),
who would like an email link to mathematicians in the West.

As you may know, the phone system in the Soviet Union is unreliable at
best.  You place a long distance call by calling the operator,
requesting a call, and then hoping that the operator will call you
back in a couple days to tell you your call is ready.  This is hardly
a workable system for automated polling :-).

I heard recently that there is at least one satelite which handles
packet radio, but I've been able to find out little more.  Packet
radio sounds like the way to go, but don't know quite where to start.

If there's interest I'd be happy to post a summary of responses.

1) What's the bare minimum of hardware and software necessary to send
electronic mail via satelite packet radio?

2) How do I find out about Soviet radio licensing laws?

3) Is there a packet radio satelite which covers Georgia?

4) Does anybody know of any organizations likely to fund such a project?

5) Would they'd need to find somebody in Europe willing to forward
messages onto either UseNet or the Internet for them?  Any suggestions
on how I might find somebody willing to do this?  Or could I do that
here in the States?

Thanks.

La Monte H. Yarroll     Preferred:      [e-mail]
            Home:           [e-mail]
            sometimes:      [e-mail]
            often:          [e-mail]
La Monte H. Yarroll     Preferred:      [e-mail]
            Home:           [e-mail]
            sometimes:      [e-mail]
            often:          [e-mail]

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

Date: Fri, 04 Jan 91 15:43 EST
From: "Geri S. Ellis"                      <[e-mail]>
Subject: Unsub $[e-mail]
To: [e-mail]

Please unsubscribe $[e-mail] from the packet radio
mailing list locations (I-PACRAD@UIUCVMD,[e-mail],
[e-mail],[e-mail], and whereever)
This student is no longer here and we are trying to clean
up obsolete mail deliveries. Thank you.
Geri Ellis, BITNET Techrep, College of William and Mary

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

End of Packet-Radio Digest
******************************
Date: Sun,  6 Jan 91 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #6
To: packet-radio


Packet-Radio Digest         Sun,  6 Jan 91       Volume 91 : Issue   6

Today's Topics:
      applications of packet radio in aviation (2 msgs)
             DRSI PCPA vs. PacComm PC-100

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 5 Jan 91 15:23:04 GMT
From: nuchat![e-mail]  (Joel Breazeale)
Subject: applications of packet radio in aviation
To: [e-mail]

I am interested in finding those who are interested in mobile packet radio
from an airplane in flight.  Airplanes so equipped would be able to know the
position of other planes (interchange data) and send data to the ground
(perhaps through multiple hops).

For those who have talked to me before...  please reply so I know you are
still interested.

Thanks,
Joel Breazeale
[e-mail] -or- uunet!nuchat!jlb
home: 713/488-5235

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

Date: 5 Jan 91 18:01:03 GMT
From: w8grt![e-mail]  (Jim Grubs)
Subject: applications of packet radio in aviation
To: [e-mail]

Newsgroups: rec.ham-radio.packet,rec.aviation
 > From: [e-mail] (Joel Breazeale)
 > Date: 5 Jan 91 15:23:04 GMT
 > Organization: Houston Public Access UNIX
 > Message-ID: <[e-mail]>
 > Newsgroups: rec.ham-radio.packet,rec.aviation
 >
 >
 > I am interested in finding those who are interested in mobile packet
 > radio
 > from an airplane in flight.  Airplanes so equipped would be able to know

Wouldn't it be neat if we could get airline pilots to get codefree techs and
get their employeers to install ham gear on board. Think of those digis and
PBBS'es flying all around the country at 30,000 plus!!!

--
Jim Grubs - via the friendly folks at UUNET
UUCP: ...!uunet!w8grt!jim.grubs
INTERNET: [e-mail]

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

Date: Sat, 5 Jan 91 09:13:44 -0800
From: Doug Faunt N6TQS 415-688-8269 <[e-mail]>
Subject: DRSI PCPA vs. PacComm PC-100
To: [e-mail]

Has anyone done a comparison, at any depth, of the these two boards.
Is there a clear choice, fuzzy choice, or don't care?
I'm thinking about for 1200 and 9600bps packet, not for higher speeds.
73, and thanx,
doug

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

End of Packet-Radio Digest
******************************
Date: Mon,  7 Jan 91 04:30:02 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #7
To: packet-radio


Packet-Radio Digest         Mon,  7 Jan 91       Volume 91 : Issue   7

Today's Topics:
           applications of packet radio in aviation
          MSYS and Rose...thanks! and where?
              TNC-1 in 300 bps KISS mode

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 6 Jan 91 14:52:57 GMT
From: shlump.nac.dec.com!ryn.mro4.dec.com!muhthr.dec.com!cristl.cdad.dec.com![e-mail]  (Andy Payne)
Subject: applications of packet radio in aviation
To: [e-mail]

In article <[e-mail]>, [e-mail] (Jim Grubs) writes:
|>  > I am interested in finding those who are interested in mobile packet
|>  > radio
|>  > from an airplane in flight.  Airplanes so equipped would be able to know
|>
|> Wouldn't it be neat if we could get airline pilots to get codefree techs and
|> get their employeers to install ham gear on board. Think of those digis and
|> PBBS'es flying all around the country at 30,000 plus!!!

    Don't forget that the data can *move* with the airplane, too.  Imagine a store-and-forward system on a cross-country flight.  Upload all the eastbound traffic while the 747 is sitting at the terminal at LAX, then download it 6 hours later at JFK!

    Of course, after going through all of this trouble, you could just as well have thrown a magtape on the flight.  What's the bandwidth of a 747 with a reasonably sized magtape flying cross-country?

    :-)

--
=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
Andrew C. Payne, N8KEI       Internet:    [e-mail]
                 UUCP:        ...decwrl!ad.enet!payne

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

Date: 6 Jan 91 02:31:39 GMT
From: munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!levels![e-mail]  (Rob Mayfield, VK5XXX/ZEU)
Subject: MSYS and Rose...thanks! and where?
To: [e-mail]

Thanks Brandon, MSYS updates seemed a little out of date on the internet.
It would be fantastic for all us *remote* sites to have ftp access to the
latest versions ... :-)

Does anybody know where the latest ROSE code is archived ... Was it posted
here recently if so could someone forward it ?? Some locals here want a
copy !?

73's ..... Rob
--
Rob Mayfield    -  ASC Network Support, VK5XXX/ZEU, 44.136.171.1/44.136.171.2
Internet/AARNet -  [e-mail]        [AMPR_TCP/IP VK5 Co-ordinator]
Applelink       -  AUST0177
AMPR            -  VK5XXX@VK5WI.#SA.AUS.OC  [ or     VK5ZEU@VK5WI.#SA.AUS.OC]
OZPost          -  Post Office Box 46,  Henley Beach,  South Australia,  5022
Voice or Pix    -  Home : [phone]  Work : [phone]/7001 Voic/Fax
    ... one thing is for sure, the sheep is not a creatue of the air ...

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

Date: Mon, 7 Jan 91 08:26:56 +0100
From: [e-mail]
Subject: TNC-1 in 300 bps KISS mode
To: [e-mail], [e-mail]

Hello all,

Thanks to all who responded to my 300 bps KISS problem. I got the clue from
toth![e-mail] (who seems te be unrechable for me, at least I got
my message to him back 'undeliverable'), who advised me to set the TXTAIL
to about 200 milliSeconds. I am using the PA0GRI version of KISS for the
TNC-1, and it seems, that the transmitter it not held in transmit state
long enough to send out the complete packet-frame. Holding the transmitter
ON for an extra 200 mS cured the problem.

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    |
|    bitnet:[e-mail]        | same  |same |DynaComm  |
| Ham-radio:pa2aga@pa2aga   (44.137.32.9) |at home|IIx  |NET/Mac   |
|        or:pa2aga@pa2aga-1 (44.137.32.61)|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
******************************
Date: Mon,  7 Jan 91 11:38:17 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #8
To: packet-radio


Packet-Radio Digest         Mon,  7 Jan 91       Volume 91 : Issue   8

Today's Topics:
                 DSP
              Packet-radio at low cost?
             TNC generates noise
            TNC Noise - Solutions

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 07 Jan 91 11:09:49 GMT
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: DSP
To: [e-mail]

Bill asks::
>Date: 4 Jan 91 13:40:10 GMT
>From: netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
>Subject: A question about DSP
>To: [e-mail]
>
>I have heard that the current DSP chips can detect extremely narrow signals.
>Assuming this, why would it not be possible to make a packet modem that
>used a standard voice radio, but got greater thruput by sending more bits
>at one time (ie. not synchronous or asynchronous.)
>
>The concept I have in mind is a modem where the transmit side sends 9
>discrete tones spaced 100 hz apart.  8 tones are data bits and the 9th
>tone is data strobe. (A lot like the parallel port on a PC.)  I would
>expect that keeping this 1Khz audio signal within the passband of a
>voice reciever would not be dificult, the only real problem would be
>detecting it on receive.  This is where I think a DSP system would be
>ideal.
>
>bill    KB3YV
>
This is basically what the Piccolo system uses - several tones transmitted
simultaneously. So you get  essentially a 'parallel' data path.
You *could* use DSP to decode it, when i saw Piccolo in use about fifteen
years ago, it used a rackfull of L-C tuned filters and tube multivibrators
(yes, 12AT7's in profusion!) to recover the data. The 'modem' was about
four feet high and mounted on wheels. The same (or better) performance could
be done on a single card nowadays.
Note that its not any faster, just more reliable!


       Pete Lucas [e-mail]  [e-mail]

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

Date: Mon, 07 Jan 91 11:30:03 GMT
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: Packet-radio at low cost?
To: [e-mail], [e-mail],

I got this via my local BBS.... thought i would pass it on to you all.


>From    : G6FCL @ GB7UWS.GBR.EU
>To      : ALL @ GBR.EU
>Date    : 910102/2255
>Msgid   : B+ 570@GB7UWS, 27029@GB7SDN $570_G6FCL
>Subject : Packet Radio on PC with NO TNC!
>Path    : GB7IMB!GB7DOI!GB7GUN!GB7BNM!GB7VRB!GB7SEK!GB7UWS!GB7UWS


>From: [e-mail]
>To: ALL@GBR

Hello, here is a repeat of the Baycom bulletin for those who may have missed
it over the festive season, Baycom = TNC free Packet Radio!

Baycom  V1.20  is  the  PC  version  of  Digicom, written by the
Masters  of  Digicom,  Florian DL8MBT and Johannes DG3RBU and as
you  can  expect,  the  program  is  nothing short of brilliant.

The  program  will support upto 9 available user ports, a Binary
file  transfer  (Baycom to Baycom) that leaves YAPP in the cold.

Baycom  will  support, MDA/MGA/CGA/MCGA/EGA & VGA, the latter in
43  line  mode.  Each screen is split three ways, TX/RX/Monitor,
even the monitor can be seen in the lower few lines of the screen
even  when  connected,  you  can even re-transmit text from this
part of the screen!

Baycom,  like  Digicom uses only a simple modem to give you full
Packet  facilities,  you  simply do not need a TNC! For users or
ex-users  of  Digicom,  who have a standard Digicom modem fitted
with  AM7910 modem chip and ILQ74 style quad (or two times dual)
opto-isolators,  can  by  simply  adding  one  1N1418  diode and
replacing  one  resistor,  use  their  modem  quite happily with
Baycom, the outlay is 4 pence!

Baycom  uses  either  Serial ports COM1 or COM2, it does not use
normal  TX  Data  or  RX Data lines from the RS-232, instead the
following are used: DTR/CTS/RTS & GND.

It   is   hoped   that   Baycom  will  be  issued  with  English
documentation  and  help files (we are working on them now) very
soon,  if  you  are fairly competent with your PC, you should be
able to get up and running quickly even without these.

So  if  you'd like a copy of Baycom on either 3.5" 720K or 5.25"
360K  diskette  PRE-FORMATTED, return mailer, Postage for return
of  your  disk and letter (see below).  If you'd like details of
a  simple  (very)  modem  to  use  on  VHF  with this program or
details  of  how  to convert your existing Digicom modem, please
include a little something to cover photocopying costs.

IMPORTANT NOTE:

The  program  will be supplied only to those who accompany their
diskette  with  a  letter  stating quite clearly that: They will
make  a  donation  to  the Baycom team (20DM has been suggested)
this  is  about  eight  pounds, if the intend to use the program
and  that  they  will  not  "Reverse  engineer"  or  modify  the
program.    On  the second point, both Florian and Johannes make
it  quite  clear  at  their  dismay  at  the antics of those who
"lined  their  pockets"  from  the  ill gotten proceeds from the
sale of their program "Digicom".

Address for copies:

Jim  Mahoney  G6FCL,
89 Tyefields,
Pitsea,
Basildon,
Essex,
SS13 1JA.

If  you  wish  to  make  a  donation when sending your diskette,
please  only  send  German  Currency, so that I may pass it onto
the  Baycom  team  in  Germany.  (You  may  buy a 20DM note from
Thomas Cook's or any High Street Bank, 20DM = Under 8 pounds!).

Before I get another "will it work with my KAM or PK232" message
you simply DO NOT NEED a TNC with Baycom, just a very simply
modem to interface PC to Radio!
----- End of message 27029 from G6FCL @ GB7UWS.GBR.EU -----
2059z G6WBJ >

       Pete Lucas [e-mail]  [e-mail]

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

Date: Wed, 2 Jan 91 18:54:26 -0600
From: uunet!pc.usl.edu!jpd (Dugal James P.)
Subject: TNC generates noise
To: uunet!tom

Tom, I remember reading of similar complaints from a Heath pk-232 kit
builder and others.  Here's an article describing a fix:

Article 864 of rec.ham-radio.packet:
Path: usl-pc!usl!dalsqnt!pollux!killer!ames!pasteur!ucbvax!decwrl!decvax!tektronix!tekcrl!tekgvs!jans
From: [e-mail] (Jan Steinman)
Newsgroups: rec.ham-radio.packet
Subject: Quieting the PK232 (use finger stock)
Message-ID: <[e-mail]>
Date: 20 Feb 89 18:54:49 GMT
Organization: Tektronix Inc., Beaverton, Or.
Lines: 39

There has been much discussion about noisy packet controllers in the group, and
I've suffered with my PK232 for quite a while.

I put the PK232 across the room, and made up a hunk of coax with a 51 ohm
resistor on one end for an RF sniffer.  I discovered it was impossible to
isolate -- noise was coming right through the cover of the PK232.

My first, feeble attempt involved scraping the paint from around the screw
holes of the cover and putting star washers between the cover and the base.
This made it just a bit better, to the point where my sniffer probe could
detect a slight increase in noise around the 12VDC power cable.  When a radio
cable was connected, however, the noise went way up.

I went and bought a handful of .1 uF caps, and some small torroid cores.  The
schematic revealed good bypassing on the key and RS-232 ports, but none on the
radio ports.  I put a .1 uF to ground on every egressing lead that didn't
already have a cap across it, and cut the trace from the 12VDC as close to the
jack as I could, inserting as many turns of #18 enameled wire I could get on my
small torroid.  (It measures about 700 uH.)

At this point, I tried sniffing again.  Radiation from egressing wires was very
low, but there was still quite a bit coming right through the case.  I found
that the board was only attached to the case at one point.  I scraped the paint
>from all the board mounting locations, and ran the shortest possible wires from
board ground to all of the floating mounting points, using star washers against
the case.  Still noise.

Then I located some RF gasket finger stock, and scraped the paint along all the
edges of the case and base, cutting and applying the self-stick brass finger
stock all around the case junction.

This thing is RF tight now!  I can sometimes, on some bands, detect a small
difference between PK232 on or off, with my IC735 connected to the radio port
and sitting right on top of the PK232!  Before, such a set up would have wiped
out almost everything on HF!

:::::: Jan Steinman - N7JDB                Electronic Systems Laboratory ::::::
:::::: [e-mail]       Box 500, MS 50-370 (w)503/627-5881 ::::::
:::::: [e-mail]     Beaverton, OR 97077 (h)503/657-7703 ::::::


--
-- James Dugal, N5KNX           Internet: [e-mail]
Associate Director              Ham packet: n5knx@k5arh
Computing Center                US Mail: PO Box 42770  Lafayette, LA  70504
University of Southwestern LA.  Tel. [phone]       U.S.A.
--
================================================================================
= Tom Varga N2UA/1                617-895-9415          packet : N2UA @ KA1MGO =
=                  [e-mail]                      uunet!ksr!tom              =
=   There's never time to do it right, but there's always time to do it over.  =
================================================================================

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

Date: 7 Jan 91 15:45:01 GMT
From: ksr![e-mail]  (Tom Varga)
Subject: TNC Noise - Solutions
To: [e-mail]

I just wanted to thank everybody who helped me with my problem with
repect to my PK-232 generating way too much noise.  Some have asked me
for the results so I thought that I would post this article that I
sent.

-Tom

> Hi Tom,
>
> How are you coming with the noise problems? The reason I ask
> is one of the new PktMacs is having fits with his new PK-232
> and his new super-duper _expensive_ Kenwood 2-Meter rig.
>
> I went over to KC5ZY's house to see what he was talking about
> and something (maybe the PK-232) is really generating noise
> such that he can hardly copy packet signals.
>
> If you get some good tips on how to fix the problem, pse let
> me know or send a pkt m}isg to }iDon kc~r5zy{_~r@n5ljf.}i}i~TX
> {_
> 73 de Dick

Hi Dick,

Well, I have made progress on many fronts.

First of all, I received a copy of a letter from N5KNX (article
included at end) which gave me the belief that this problem can be
solved.

I opened the box to discover that all except one screw hole has
paint on it.  Therefore the case is either not grounded at all or is very
minimally.  I removed the pc board and scraped clean to the aluminum
all screw holes on the inside and out, except those that would be
visible.  I also connected a wire directly from ground on the pc board
to the screw clips on the side.

This effort reduced the noise significantly.  However, I realized that
if I also bring the previously mentioned wire out the back and connect
it to a good earth ground, it reduces 90% of the noise.  Sniffing
around shows that the rest comes mostly from the power lead.  I haven't
put toroids on yet, but I imagin that it will really help.

Finally, I've realized that an HT rubber ducky doesn't cut it in an area that is
very crowded with packet activity.  So I made a J-pole antenna, bought
some coax, fed it through the walls to the attic and boy what a
difference it makes.

FLAME ON ****************************** :
I am pretty DISGUSTED with AEA.  I cannot believe the poor quality of
their product with respect to this problem.  It would cost them little
or nothing but a little care to prevent their box from polluting my
shack with so much noise.  Judging from the response that I got this
is NOT an isolated problem. (When I called them, they claimed they
never heard of anyone having this problem ... HAH, PHFUUUUI).  The
people where I bought it from tried to blame it on the HT!  I say if there
is no noise, the HT wouldn't have any problems. You can
bet my next packet product won't come from AEA, and I strongly
suggest to all net readers to think twice before they purchase their noise
maker. (Besides, it's big, power hungry and old technology. Stick with
CMOS and ASICS)
FLAME OFF ****************************** :

-Tom

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

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

End of Packet-Radio Digest
******************************
Date: Tue,  8 Jan 91 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #9
To: packet-radio


Packet-Radio Digest         Tue,  8 Jan 91       Volume 91 : Issue   9

Today's Topics:
             A question about DSP
          Getting Started in Packet-Radio ??
            i want to get started

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 7 Jan 91 15:34:29 GMT
From: usc!cs.utexas.edu!asuvax!mcdphx!hrc!godzilla![e-mail]  (Brian Daly)
Subject: A question about DSP
To: [e-mail]

In article <[e-mail]>, [e-mail] (Bill Gunshannon) writes:
>
> work?  Where does Shannon come into play here?  If it is possble, where
> does one find a source for things like DSP chipsets if one wants to learn
> by doing?
>

As far as a source for DSP chipsets, I'd recommend two:

   1. Texas Instruments :  TI has a three-volume set titled "Digital
      Signal Processing Applications with the TMS320 Family". These
      manuals contain theory, algorithms, and code implementation.

   2. Motorola: DSP56116, DSP 56000/56001, DSP96002 User's Manual.
      Motorola also has several good application notes based on their
      DSP products (also includes code).


--
Brian K. Daly WB7OML @ AG Communication Systems, Phoenix, Arizona
UUCP: {...!ames!ncar!noao!asuvax | uunet!zardoz!hrc | att}!gtephx!dalyb
Phone: [phone]    FAX: [phone]
~

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

Date: 8 Jan 91 17:47:10 GMT
From: munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!levels![e-mail]
Subject: Getting Started in Packet-Radio ??
To: [e-mail]

  I too am interested in packet-radio. The concept sounds very great and if
possible I would like to join in.  Unfortunately I am not familiar with
current systems and all the terminology.  I am hoping some kind soul on the
net might point me in the direction of some reference material, standards etc.

I am not aware of any existing packet-radio networks in my area, that doesn't
mean to say there isn't though.  So I would be greatful if you suggest how
I could find out, and get in touch with them.

  Rather than buy the equipment I would prefer to built it myself. So I am
looking for pointers to the more technical aspects of how they work and not
just what they do.

Thanks

Andrew Chalmers

University of South Australia

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

Date: 7 Jan 91 15:01:17 GMT
From: usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!attcan!lsuc!canrem![peter_pijet%canrem.uucp]@ucsd.edu  (peter pijet)
Subject: i want to get started
To: [e-mail]

 Hi! I am interrested in getting started in Packet-radio! I don;t know
 much about it, but I;ve heard it;s great. If someone could leave me a
 message...ANY MESSAGE, I would greatly appreciate it.
 Many thanks,    Peter Pijet.
---
 ~ QNet 2.04: 210 The Icon Store BBS - Waterloo, ON - [phone]
--
Canada Remote Systems.  Toronto, Ontario
NorthAmeriNet Host

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

End of Packet-Radio Digest
******************************
Date: Wed,  9 Jan 91 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #10
To: packet-radio


Packet-Radio Digest         Wed,  9 Jan 91       Volume 91 : Issue  10

Today's Topics:
                 1270B & KISS
              56kb modem success
           applications of packet radio in aviation
           Header lines (was Re: ARRL news)
             Header suppression (3 msgs)
         HF packet operating (70 lines or so)
             info on solar panels
          MSYS and Rose...thanks! and where?
                New G8BPQ code

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

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

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 8 Jan 91 16:34:55 GMT
From: usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
Subject: 1270B & KISS
To: [e-mail]

A local user here has found that his 1270B does not exit from KISS mode
when instructed to do so.  The only way out is to disconnect the battery.
Is this a known bug in some ROM versions or is there something he is doing
wrong??

bill    KB3YV
--

     Bill Gunshannon          |        If this statement wasn't here,
     [e-mail]   |  This space would be left intentionally blank

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

Date: Tue, 8 Jan 91 13:25:54 -0800
From: brian (Brian Kantor)
Subject: 56kb modem success
To: packet-radio

Last weekend I finally got a pair of DSY 56kb modems interfaced to my
computers and I'm quite happy with the result; I'm getting about
3kbyte/sec FTP transfers between a pair of 8mhz XT-clones.

I used an Eagle card for the interface on one end of the link, and an
Ottawa PI card on the other end.  The PI card is nice, because it's DMA
and the computer doesn't completely die during an incoming packet like
it does with the non-DMA Eagle card.

Bdale reports transfer rates of 6.5kbyte/sec or better with faster
machines or by eliminating disk i/o, so I suspect I'm running as fast
as I can with the slow disk systems I have.  MTU and MSS were both
around 1k for this test; larger might be a bit better.

Next step is to ruggedize the modems, boost the power, and interface
something that will work dependably as a packet switch on a 5,000 ft
mountain in lightning storms and power fails.  Once we have that, we
can start building a real inter-city network.  Yah!
    - Brian

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

Date: 7 Jan 91 18:24:14 GMT
From: hpcc05!col![e-mail]  (Bdale Garbee)
Subject: applications of packet radio in aviation
To: [e-mail]

>       Of course, after going through all of this trouble, you could just as
>well have thrown a magtape on the flight.  What's the bandwidth of a 747 with
>a reasonably sized magtape flying cross-country?

Please!  Don't start this one all over again... see an archive of the
comp.protocols.tcp-ip group from a couple of years ago... it was almost as
long an involved discussion as one of our old code/no-code "discussions"...

:-)  Really.

Bdale

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

Date: 8 Jan 91 12:07:19 GMT
From: lib![e-mail]  (Jay Maynard)
Subject: Header lines (was Re: ARRL news)
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>From n8emr!N1API Mon Jan  7 14:10:16 1991
>Return-Path: <n8emr!N1API>
>Message-Id: <[e-mail]>
>[Date: Mon, 7 Jan 91 12:36 EST
>[To: <ALL@ARRL>
>R:910107/1644z @:N8JYV.#CMH.OH.USA.NA Columbus, OH #:279 Z:43232
[...and 37 more R: lines deleted.]

And people complain about headers on SMTP mail...
--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
[e-mail]  | adequately be explained by stupidity.
        "I smell a scientific fish." -- Chip Salzenberg

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

Date: Tue, 08 Jan 91 18:32:05 PST
From: "Roy Engehausen" <[e-mail]>
Subject: Header suppression
To: [e-mail]

A suggestion has been made to put an upper limit on the number of
headers in a message.  What you would then get is the last 'N' headers
plus the original header.

Comments, suggestions???

Roy -- AA4RE

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

Date: 9 Jan 91 08:20:30 GMT
From: mcsun!ukc!axion!kitkat![e-mail]  (Brian Lloyd)
Subject: Header suppression
To: [e-mail]



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

Date: 9 Jan 91 12:08:56 GMT
From: usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!gvlf3.gvl.unisys.com!gvlv3![e-mail]  (Ed Naratil)
Subject: Header suppression
To: [e-mail]

In article <[e-mail]> [e-mail] ("Roy Engehausen") writes:
>A suggestion has been made to put an upper limit on the number of
>headers in a message.  What you would then get is the last 'N' headers
>plus the original header.
>
>Comments, suggestions???
>
>Roy -- AA4RE

Sounds like this is a "Catch 22" situation, Roy.  One problem with NOT
limiting the number of headers is on BBS's that have a byte limit on
forwarding.  The headers are added into the message total and may take
SYSOP intervention to be forwarded if they surpass the byte limit.

Also, a number of BBS's use the header information to add to their
routing files.

Too many headers make work for SYSOPs and eliminating the middle headers
prevents some BBS's from determining forwarding paths.
----

Ed Naratil                                     (All standard disclaimers apply)
Amateur Radio Packet: W3BNR@N3LA.#epa.PA.USA.NA        [e-mail]

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

Date: 9 Jan 91 05:00:07 GMT
From: mejac!orchard.la.locus.com!fafnir.la.locus.com![e-mail]  (Dana H. Myers)
Subject: HF packet operating (70 lines or so)
To: [e-mail]

  During my Christmas vacation, I had a chance to give HF packet a try.
I've enjoyed it quite a bit. It took some geeting used to, VHF FM uses
AFSK Bell 202; not much one can do wrong there. HF (in general) uses
Bell 103 audio tones into a conventional SSB radio. There are two
variables here:

1. The Bell 103 tone pair can be either 1070/1270 or 2025/2225.
2. One can set the radio for USB or LSB.

  Each of the variables actually, in a strict sense, doesn't really
matter. The tone pair one chooses determines where, in the RF spectrum,
the transmitted FSK signal appears (recall that feeding AFSK of constant
amplitude to a SSB radio will generate what appears to be FSK). Using
USB or LSB also shifts the absolute frequency of the transmitted FSK,
and also will invert the tones when changing from upper to lower sideband.

  So, given all this, the problem is, suppose one sees a published
frequency for an HF BBS of 14.1033 Mhz. How does one set up to contact
this BBS? One well known convention is that LSB is used; which tone pair
is used? I'd assumed the lower tone pair was better, since the 2225 Hz
uppermost frequency may be into the attenuation of some SSB filters,
either during transmission or reception (keep in mind most, if not all,
SSB transceivers share the SSB filter for both reception and transmission).

  I got on the air and tuned around 14.1033. Wouldn't you know it, to
connect to stations there, I need to tune in 14.1023 Mhz. Hmmm. I assume
I'm using the wrong tone pair (BTW, my PK-88 defaults to 1070/1270 for
HF use...) but one station I contact insists he's running 1070/1270 and
his dial sez 14.1033. Hmmmmmm.... he must have been in error, given that
I started using the 2025/2225 tone pair and now packet stations appear
to be on their published frequencies. Once again, it goes to show,
be certain of your facts and don't let other folks whimsically change
your mind.

   I sure had a lot of fun, even as much to contact several South Americans,
including PZ2AC in Surinam. [ There's only a couple of dozen hams in that
country (from looking at the Callbook) ] If any of you have been thinking
of trying HF packet, I encourage you to put in the effort. Be patient,
though; the lower baud rate and (often) higher error rates can make it
tedious, tuning stations in without the benefit of a tuning aid can be
frustrating (though one quickly gets to know the correct tones 'by ear')
and older, 'analog VFO' radios may require attention to stay on frequency.
(Even PLL synthesized radios are prone to some drift; for example, my FT-747
has an option available to replace the PLL reference xtal with a TCXO).
Furthermore, 'coherent' DCD becomes a must on HF (though one should be
ashamed if he isn't already using it on VHF :-) but, even then, collisions
are more frequent.

  All in all, a lot of fun. I've had nearly no one suggest 'better'
parameters to me (something I often ran into when operating VHF on
the N6GPP duplex repeater) and the people operating HF packet seem
<humor on>
to be more technically proficient, probably because they've all
had to pass code tests of greater than 5 wpm while many of the VHF
packeteers are wimpy 5 wpm technicians (I wonder what the no-code
tech will do to VHF packet).
<humor off, don't be so uptight :-) >

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

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

Date: 8 Jan 91 14:32:13 GMT
From: ubc-cs!alberta!herald.usask.ca!weyr![e-mail]  (Vernon Geddes)
Subject: info on solar panels
To: [e-mail]

does anyone know of where I can obtain infor of different solar panels
available.

panels to run a shack completely. (run furance motor, lights, etc.)


--
Vernon Geddes - via FidoNet node 1:140/22
UUCP: ...!herald!weyr!Vernon.Geddes
Domain: [e-mail]
Standard Disclaimers Apply...

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

Date: 8 Jan 91 02:38:12 GMT
From: usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: MSYS and Rose...thanks! and where?
To: [e-mail]

As quoted from <[e-mail]> by [e-mail] (Rob Mayfield, VK5XXX/ZEU):
+---------------
| Thanks Brandon, MSYS updates seemed a little out of date on the internet.
| It would be fantastic for all us *remote* sites to have ftp access to the
| latest versions ... :-)
+---------------

You're welcome.

I said I would announce it... seems Mike decided it was stable enough a bit
sooner than expected.  MSYS 1.10 has in fact just been released, apparently;
I will get a hold of it and send it to the appropriate places.

+---------------
| Does anybody know where the latest ROSE code is archived ... Was it posted
| here recently if so could someone forward it ?? Some locals here want a
| copy !?
+---------------

I believe I read here a few weeks ago that it was on SIMTEL20.

++Brandon
--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

Date: Tue, 8 Jan 91 12:04:34 EST
From: [e-mail] (Barry McLarnon DGBT/DIP)
Subject: New G8BPQ code
To: [e-mail]

I just put the latest G8BPQ code (V4.01) on tomcat.gsfc.nasa.gov.  The
file is /public/g8bpq/bpq401.zip.

Someone asked me to look for a recent version of AP-Link on the Internet,
but the only thing I can find is the old v3.93 I put on tomcat many moons
ago... anyone got a pointer to something newer?

The Internet servers are a tremendous asset for software distribution in
the amateur community, but the files available in the packet domain (with
the notable exception of TCP/IP-related software) tend to be incomplete
and outdated compared to what's available on the ham-oriented LL BBS's
and Compu$erve Hamnet.  I urge those who have recent files from these
sources, and who are fortunate enough to also have Internet access, to
take the time to upload them (to tomcat, at least), and to make note of
the fact on this mailing list/newsgroup.

Barry  VE3JF

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

Date: (null)
From: (null)
R:910109/1112z 1234@GB7NNA .......
R:910109/1105z 4567@GB7ESX .......
R:GB7MXM,GB7VLS,GB7LDI,......,GB7MUM
R:910105/2312z 9876@GB7BAD .......

This would then retain full path information for anyone who's interested.

Brian G1NNA

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

End of Packet-Radio Digest
******************************
Date: Thu, 10 Jan 91 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #11
To: packet-radio


Packet-Radio Digest         Thu, 10 Jan 91       Volume 91 : Issue  11

Today's Topics:
              56kb modem success
           applications of packet radio in aviation
              GRAPES shipments?
              Header suppression
               Icom connections
             info on solar panels
               PK-232/KW-440 Interface

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Wed, 9 Jan 91 16:16:42 EST
From: [e-mail] (Barry McLarnon DGBT/DIP)
Subject: 56kb modem success
To: [e-mail], [e-mail]

>Last weekend I finally got a pair of DSY 56kb modems interfaced to my
>computers and I'm quite happy with the result; I'm getting about
>3kbyte/sec FTP transfers between a pair of 8mhz XT-clones.

Great!
>
>I used an Eagle card for the interface on one end of the link, and an
>Ottawa PI card on the other end.  The PI card is nice, because it's DMA
>and the computer doesn't completely die during an incoming packet like
>it does with the non-DMA Eagle card.
>
>Bdale reports transfer rates of 6.5kbyte/sec or better with faster
>machines or by eliminating disk i/o, so I suspect I'm running as fast
>as I can with the slow disk systems I have.  MTU and MSS were both
>around 1k for this test; larger might be a bit better.

Yes, you will see a significant improvement if you bump the MSS up to,
say, 3000, and another jump if you put a faster machine on the server
end.  My 8 MHz XT max'ed out at about 4.8kbyte/s under those conditions,
and it has an extremely slow hard disk.

>
>Next step is to ruggedize the modems, boost the power, and interface
>something that will work dependably as a packet switch on a 5,000 ft
>mountain in lightning storms and power fails.  Once we have that, we
>can start building a real inter-city network.  Yah!

Keep on doin'!  Just don't forget the hardware remote reset for your
switch... you *will* need it.

>- Brian

Barry

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

Date: 9 Jan 91 15:07:33 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!speedy.cs.pitt.edu![e-mail]  (Bob Hoffman)
Subject: applications of packet radio in aviation
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>       Of course, after going through all of this trouble, you could
> just as well have thrown a magtape on the flight.  What's the
> bandwidth of a 747 with a reasonably sized magtape flying
> cross-country?

This discussion took place on the net several years ago when I said
something like "Never underestimate the bandwidth of a station wagon
full of magtapes," which referred to what we used to do when our microwave
link was down.  The discussion went on for much longer than I had ever
anticipated, ending up with someone asking about the bandwidth of a
747 full of CD-ROMs.  After that, it got silly!  :-)

    ---Bob.

--
Bob Hoffman, N3CVL       {allegra, bellcore, idis, psuvax1}!pitt!hoffman
Pitt Computer Science    [e-mail]    FAX: [phone]

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

Date: 9 Jan 91 10:53:41 GMT
From: rochester!kodak!uupsi!sunic!news.funet.fi!ousrvr!ousrvr![e-mail]  (Ari Husa OH8NUP)
Subject: GRAPES shipments?
To: [e-mail]

What is the expected delay between placing an order to GRAPES, INC.
for five WA4DSY full kits and their actual shipment?

I've sent my check early November - it has been two months now. Should
I be alarmed? It should take no longer than two weeks for a parcel to
reach Finland.

Does anyone have their telephone (and preferably) telefax number? I'd
like to give them a call.

    Luru


--
    ///
    o-o    Ham Radio Operators Do It In Higher Frequency
     o

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

Date: Wed, 09 Jan 91 12:50:38 PST
From: "Roy Engehausen" <[e-mail]>
Subject: Header suppression
To: [e-mail]

Best idea I got so far is to use the algorithm I proposed on bulletins
only.  Non-bulletin traffic will go thru untouched.  Any other suggestions?

Roy

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

Date: 9 Jan 91 15:58:20 GMT
From: egr.duke.edu!dukee![e-mail]  (Jonathan S. McCalmont)
Subject: Icom connections
To: [e-mail]

I guess packet people can help me here.  On an Icom (IC-2SAT), the
microphone jack (2.5mm) would seem to be a 3-conductor type, at least
from the schematic.  But this month's packet article in QST shows a
2-conductor plug being used.  The connections (from the schematic)
seem to be:

    1.  audio/PTT
    2.  +5V (for an electret mic?)

If a 2-conductor plug were used, I think it would short the +5V to ground
through a 470 ohm resistor.  True?  Is my guess for the use of this
line correct?

Also, the speaker jack (3.5mm) is also apparently a 3-conductor type;
one is obviously audio, the other is labeled "BUSY".  Does this line
go to +5V when the squelch is open?  Is this line used in packet, or
anywhere else?

Feel free to give partial answers.  Any help is appreciated!  Please
e-mail, and if I sense a big interest I'll post a summary.

73 de N4YRP
---
Scott McCalmont - N4YRP                            [phone]
Department of Electrical Engineering      [e-mail]
Duke University, Durham, NC  27706             ...mcnc!dukee!jsm1

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

Date: 10 Jan 91 04:37:39 GMT
From: swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu![e-mail]  (Harry P Bloomberg)
Subject: info on solar panels
To: [e-mail]

In article <[e-mail]> [e-mail] (Vernon Geddes) writes:
>does anyone know of where I can obtain infor of different solar panels
>available.
>
>panels to run a shack completely. (run furance motor, lights, etc.)
>
   I bought some solar panels at Dayton from the following company.  They
specialize in Solvonics marine grade panels that can output considerable power.

   12 Volt Catalog
   110 East Atlantic Avenue
   Delray Beach, Florida 33444
   Phone [phone]-VOLT

   Of course, I have no financial interest in the company.

   If there's any additional discussion, I think rec.ham-radio would be more
appropriate than this group.

73,
Harry Bloomberg WA3TBL
[e-mail] or
[e-mail]

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

Date: 10 Jan 91 03:49:11 GMT
From: usc!cs.utexas.edu!ut-emx!lad-shrike![e-mail]  (R M Kriss)
Subject: PK-232/KW-440 Interface
To: [e-mail]

       --- PK-232 AFSK DRIVE to PK-232 TIP --
KC5ZY got a new PK-232 and Kenwood TS-440 for Christmas. Thats the good
news! The bad news was the PK-232 audio output seemed too low to drive the
440 to full power. Don was using the 13 pin plug on the 440. After hours
of messing with the thing, he called AEA and they passed on a super tip.

The AEA technician suggested he should remove the AFSK input wire from the
13 pin connector and use the AFSK input RCA plug on the back of the 440.
The change was made and it works great. I may not have the technical
details correct, but the 13 pin connector on the 440 expects 300mv drive
where the AFSK input plug only needs 80mv. The PK-232 works thru the AFSK
input!

I use a FT-757 so this is a second hand posting. If you are having trouble
with your 440 and the PK-232, try it!



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

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

End of Packet-Radio Digest
******************************
Date: Fri, 11 Jan 91 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #12
To: packet-radio


Packet-Radio Digest         Fri, 11 Jan 91       Volume 91 : Issue  12

Today's Topics:
                 1270B & KISS
                  ?
              GRAPES shipments?
             Header suppression (3 msgs)
                 Homebrew TNC
        Transverters for High Speed Packet operations
               TRS-80 Mod 4/4P

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 11 Jan 91 00:09:09 GMT
From: VAX1.CC.UAKRON.EDU!mcs.kent.edu!usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: 1270B & KISS
To: [e-mail]

As quoted from <[e-mail]> by [e-mail] (Bill Gunshannon):
+---------------
| A local user here has found that his 1270B does not exit from KISS mode
| when instructed to do so.  The only way out is to disconnect the battery.
| Is this a known bug in some ROM versions or is there something he is doing
| wrong??
+---------------

Try following the "param ax0 255" with "param ax0 254".  The MFJ TNC's require
a RESTART to switch between normal and KISS modes; just as you need to send
the RESTART to get in to KISS mode, you need to send the KISS equivalent
(command 254 as above) to get back out.

At least, that's what seems to be going on.  I had problems with my 1278 going
out of KISS mode until I found a little note about this hidden somewhere in
the Fast-Start guide (but *not* in the regular manual, which I had read in
preference to the Fast-Start guide).

++Brandon
--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

Date: 10 Jan 91 12:45:12 GMT
From: bu.edu!olivea!samsung!cs.utexas.edu!enuxha.eas.asu.edu![e-mail]  (Brian Crawford)
Subject: ?
To: [e-mail]

Some months back, I found a file at the TexNet archives, dept.csci.unt.edu,
with a circuit for some basic packet hardware.  Now, it is gone.  Where can
I find such things?

-------------------------------------------------------------------------------
Brian Crawford               INTERNET: [e-mail]
PO Box 804                   FidoNet:  1:114/15.12
Tempe, Arizona  85280        Amateur:  KL7JDQ
USA
-------------------------------------------------------------------------------

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

Date: 10 Jan 91 17:40:17 GMT
From: swrinde!zaphod.mps.ohio-state.edu!wuarchive!emory!emcard!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: GRAPES shipments?
To: [e-mail]

In article <[e-mail]> [e-mail] (Ari Husa OH8NUP) writes:
>What is the expected delay between placing an order to GRAPES, INC.
>for five WA4DSY full kits and their actual shipment?
>
>I've sent my check early November - it has been two months now. Should
>I be alarmed? It should take no longer than two weeks for a parcel to
>reach Finland.
>
>Does anyone have their telephone (and preferably) telefax number? I'd
>like to give them a call.
>
>       Luru
>
>
>--
>       ///
>       o-o    Ham Radio Operators Do It In Higher Frequency
>        o

It's not normally this bad. A combination of back orders, the holidays,
and serious illness in the family of our main volunteer has caused an
excessive delay. Happily I can report to you that all pending orders have
been shipped.  You should be receiving yours in a couple of days.

We are strictly a volunteer group and have no office or employees. We
do our best, and we care, but don't expect regular commercial service
from a few volunteers. We normally don't deposit your check until
we ship, so we hope you don't feel too ripped off. Normally we ship a
batch once a month, sometimes we do better.

The most reliable way to reach Grapes is via the Post Office box on
the data sheet. We pick up the mail once a week, and we usually open
it the same day. I will try to respond to all Email sent to me and
forward it to the proper people who are actually doing the kits, but you
must give me a good reply path. I don't have a smart mailer available to
me, so I need a bang path from a well known host.

Gary KE4ZV

These email paths should work. In order of preference:
...gatech!kd4nc!ke4zv!gary
...emory!wa4mei!ke4zv!gary
...uunet!rsiatl!ke4zv!gary

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

Date: 10 Jan 91 13:13:29 GMT
From: munnari.oz.au!csc.anu.edu.au!manuel!csc.canberra.edu.au!echo![e-mail]  (Carl Makin)
Subject: Header suppression
To: [e-mail]

In <[e-mail]> [e-mail] ("Roy Engehausen") writes:

>Best idea I got so far is to use the algorithm I proposed on bulletins
>only.  Non-bulletin traffic will go thru untouched.  Any other suggestions?

Bulletins are the bulk of the problem however I think you should do the lot.

Carl.
[e-mail]              Packet Radio
[e-mail]              Internet

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

Date: 11 Jan 91 00:15:24 GMT
From: VAX1.CC.UAKRON.EDU!mcs.kent.edu!usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: Header suppression
To: [e-mail]

As quoted from <[e-mail]> by [e-mail] (Brian Lloyd):
+---------------
| From article <[e-mail]>, by [e-mail] ("Roy Engehausen"):
| > A suggestion has been made to put an upper limit on the number of
| > headers in a message.  What you would then get is the last 'N' headers
| > plus the original header.
|
| Sounds like a good idea to me - there's been a lot of discussion about the
| length of headers in the UK recently. A slightly better option might be
| to have the last N headers, followed by a line (or several!) just showing
| the BBSs that the message has been through, then the original header, e.g.
+---------------

???

All the local PBBS systems are MSYS (gee, I wonder why? ;-), which shows only
the calls.  I didn't know that there were PBBS systems that showed the full R:
lines to users.  Maybe there's room for some evolution here?

++Brandon
--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

Date: 11 Jan 91 04:43:03 GMT
From: VAX1.CC.UAKRON.EDU!mcs.kent.edu!usenet.ins.cwru.edu!ncoast!n8hsp![e-mail]  (Terry Bell)
Subject: Header suppression
To: [e-mail]

[e-mail] (Brandon S. Allbery KB8JRR) writes:

> As quoted from <[e-mail]> by [e-mail].u
> +---------------
> | From article <[e-mail]>, by [e-mail] ("Roy Engehausen
> | > A suggestion has been made to put an upper limit on the number of
> | > headers in a message.  What you would then get is the last 'N' headers
> | > plus the original header.
> |
> | Sounds like a good idea to me - there's been a lot of discussion about the
> | length of headers in the UK recently. A slightly better option might be
> | to have the last N headers, followed by a line (or several!) just showing
> | the BBSs that the message has been through, then the original header, e.g.
> +---------------
>
> ???
>
> All the local PBBS systems are MSYS (gee, I wonder why? ;-), which shows only
> the calls.  I didn't know that there were PBBS systems that showed the full R
> lines to users.  Maybe there's room for some evolution here?
>
> ++Brandon
> --
Brandon,
Next time you log on to BXN try the following command:
RH 12345 <cr>
Where 12345 is of course the message number you wish to read.
73,Terry

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

Date: 10 Jan 91 20:41:00 CST
From: "SCOOMC" <[e-mail]>
Subject: Homebrew TNC
To: "packet-radio" <[e-mail]>

Would like to build my own TNC2 compatible TNC but can not locate a
schematic for one of these critters. I have the chips the eprom software
but no knowledge of what pins go to which pins.
Doug [e-mail] [26.17.0.144]

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

Date: 10 Jan 91 23:01:03 GMT
From: sdd.hp.com!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
Subject: Transverters for High Speed Packet operations
To: [e-mail]

With the need for and apparent lack of supply of transverters for
high speed packet use, has anyone looked at the articles in the
1985 and I assume later issues of the Handbook??  There are transverters
for 220 and 1296 listed in there, Chapters 31 and 32.

Is there some particular reason why these are unsuitable??

Just curious.

bill  KB3YV



--

     Bill Gunshannon          |        If this statement wasn't here,
     [e-mail]   |  This space would be left intentionally blank

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

Date: 10 Jan 91 20:34:00 CST
From: "SCOOMC" <[e-mail]>
Subject: TRS-80 Mod 4/4P
To: "packet-radio" <[e-mail]>

I am trying to locate software for the Model 4/4P computer that allows it to
become a TNCless packet radio with only a modem being required. Bob Richardson
wrote such a program and marketed it with a manual called "Synchronous Packet Radio Using The Software Approach, Vol I & II" My contact with Mr. Richardson
was a dead end as it has not been in print for two years. Can someone please help me locate this?
You can E-MAIL me at [e-mail] (26.17.0.144)
73 Doug WB5VTA

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

End of Packet-Radio Digest
******************************
Date: Sat, 12 Jan 91 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #13
To: packet-radio


Packet-Radio Digest         Sat, 12 Jan 91       Volume 91 : Issue  13

Today's Topics:
            1270B & KISS (2 msgs)
               APLINK Question
             Header suppression (3 msgs)
               Icom connections
           Receiving corrupted packets with PASSALL
               TRS-80 Mod 4/4P

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 11 Jan 91 17:42:06 GMT
From: munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!levels![e-mail]
Subject: 1270B & KISS
To: [e-mail]

I have found that the 1274 (which is a 1270 with a tuning indicator) will
only exit kiss mode using the following sequence from NET
param z 255
param z 254
(power down-up)

z = my interface name under NET on the mac.

I think the dox say that only the '255' is needed.
give it a try anyway .... anyone else got any comments ??
73's ... Rob
--
Rob Mayfield    -  ASC Network Support, VK5XXX/ZEU, 44.136.171.1/44.136.171.2
Internet/AARNet -  [e-mail]        [AMPR_TCP/IP VK5 Co-ordinator]
Applelink       -  AUST0177
AMPR            -  VK5XXX@VK5WI.#SA.AUS.OC  [ or     VK5ZEU@VK5WI.#SA.AUS.OC]
OZPost          -  Post Office Box 46,  Henley Beach,  South Australia,  5022
Voice or Pix    -  Home : [phone]  Work : [phone]/7001 Voic/Fax
    ... one thing is for sure, the sheep is not a creatue of the air ...

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

Date: 8 Jan 91 19:01:37 GMT
From: agate!shelby!unix!synoptics![e-mail]  (Jerome Kaidor)
Subject: 1270B & KISS
To: [e-mail]

In article <[e-mail]> [e-mail] (Bill Gunshannon) writes:
>A local user here has found that his 1270B does not exit from KISS mode
>when instructed to do so.  The only way out is to disconnect the battery.
>Is this a known bug in some ROM versions or is there something he is doing
>wrong??
>
>bill    KB3YV
>--

     I have exactly the same problem with my 1278!




         - Jerry Kaidor, KF6VB

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

Date: 10 Jan 91 17:41:01 GMT
From: hpda!hpcupt1![e-mail]  (Jim Hollenback)
Subject: APLINK Question
To: [e-mail]

I read a bulletin about APLINK frequencies on one of the packet boards
locally.  Question - How does one find out more about these things?
How does one log on one of these things?

Tnx es 73's, Jim, WA6SDM
[e-mail]

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

Date: 11 Jan 91 20:08:44 GMT
From: [e-mail]  (Brian Kantor)
Subject: Header suppression
To: [e-mail]

Note that MSYS documentation states that it uses the last R: header's
timestamp as the date to determine the age of a bulletin when
calculating expirations.  I don't know what it would do in the absence
of ANY R: headers.
    - Brian

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

Date: Fri, 11 Jan 91 12:45:15 PST
From: "Roy Engehausen" <[e-mail]>
Subject: Header suppression
To: [e-mail]

The originating BBS header gives the date/time stamp for origination
as well as the information as to the originating BBS.  Most software
will also terminate header scans at a line which doesn't match the
header spec so its importnant that any change not introduce a
non-header like line before the last header.

I am going to look at an implentation this weekend which will allow
pretty fine control over max number of headers based on a lot of
different criteria so the SYSOP will have the ability to determine
what he wants to carry.

Roy

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

Date: 12 Jan 91 02:39:27 GMT
From: usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: Header suppression
To: [e-mail]

As quoted from <[e-mail]> by [e-mail] (Terry Bell):
+---------------
| [e-mail] (Brandon S. Allbery KB8JRR) writes:
| > All the local PBBS systems are MSYS (gee, I wonder why? ;-), which shows only
| > the calls.  I didn't know that there were PBBS systems that showed the full R
| > lines to users.  Maybe there's room for some evolution here?
+---------------

(Why wasn't this in mail?  It's silly for a local conversation to be posted to
the world, or even the whole U.S....)

Terry, I edited my message down from a larger one --- in which I did mention
RH.  I meant the *default* case, as no doubt the original posters did.

++Brandon
--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

Date: 11 Jan 91 15:54:10 GMT
From: pa.dec.com!shlump.nac.dec.com!regent.enet.dec.com![e-mail]  (Bob Gettys N1BRM)
Subject: Icom connections
To: [e-mail]

In article <[e-mail]>, [e-mail] (Jonathan S. McCalmont) writes...
>I guess packet people can help me here.  On an Icom (IC-2SAT), the
>microphone jack (2.5mm) would seem to be a 3-conductor type, at least
>from the schematic.  But this month's packet article in QST shows a
>2-conductor plug being used.  The connections (from the schematic)
>seem to be:
>
>       1.  audio/PTT
>       2.  +5V (for an electret mic?)
>
>If a 2-conductor plug were used, I think it would short the +5V to ground
>through a 470 ohm resistor.  True?  Is my guess for the use of this
>line correct?
>73 de N4YRP




    It turns out that Icom has set things up so that older accessories can
be used on the newer walkies. This means that you can use simple 2 conductor
plugs for both the speaker and the mike jacks and the there will be no problems
with the walkie. In fact, if the TNC has the appropriate blocking capacitor in
the audio lead (and I haven't seen one that doesn't - but check to be sure),
you don't even need the cap that most hook-up diagrams show (do you really need
to block the dc on the mike line twice???).


    /s/     Bob     N1BRM

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

Date: 11 Jan 91 20:41:09 GMT
From: hpl-opus!hpnmdla![e-mail]  (Alan Bloom)
Subject: Receiving corrupted packets with PASSALL
To: [e-mail]

There was a string here awhile back about how to read corrupted packets
in unconnected mode.  (So you can eavesdrop on what is going on on a
channel.)  The answer was to turn on your TNC's "PASSALL" mode.

Well, I have definitely confirmed that my Kantronics KPC-2 does not
have this function.  It is not in the manual, I get an error message
when I type it from the command line, and nothing like it appears when
I list all commands with the "HELP" function.

My ROM's are version 2.2.  I have just got an offer in the mail from
Kantronics to upgrade to version 3.0 for something like $25.  Does this
version include PASSALL?  Does it also include a mailbox, or do I have
to add RAM or other changes to accomplish this?  The flyer they sent
was unclear on these points.

Note I have a KPC-2, not a KAM or KPC-4.

Thanks,

AL N1AL

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

Date: 11 Jan 91 16:01:08 GMT
From: w8grt![e-mail]  (Jim Grubs)
Subject: TRS-80 Mod 4/4P
To: [e-mail]

 > From: [e-mail] ("SCOOMC")
 > Date: 11 Jan 91 02:34:00 GMT
 > Organization: The Internet
 > Message-ID: <[e-mail]>
 > Newsgroups: rec.ham-radio.packet
 >
 > I am trying to locate software for the Model 4/4P computer that allows
 > it to
 > become a TNCless packet radio with only a modem being required. Bob
 > Richardson

I know someone who may have that. I'll forward your inquiry to him.

--
Jim Grubs - via the friendly folks at UUNET
UUCP: ...!uunet!w8grt!jim.grubs
INTERNET: [e-mail]

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

End of Packet-Radio Digest
******************************
Date: Mon, 14 Jan 91 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #14
To: packet-radio


Packet-Radio Digest         Mon, 14 Jan 91       Volume 91 : Issue  14

Today's Topics:
          Getting Started in Packet-Radio ??
             Header suppression (4 msgs)
               MODS for Kenwood Tm-941
                 W3IWI ftp's

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

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

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 12 Jan 91 22:16:19 GMT
From: pacific.mps.ohio-state.edu!linac!uwm.edu!src.honeywell.com!msi.umn.edu!cs.umn.edu!kksys!edgar!brainiac![e-mail]  (Jeffrey Comstock)
Subject: Getting Started in Packet-Radio ??
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>
>  I too am interested in packet-radio. The concept sounds very great and if
>possible I would like to join in.  Unfortunately I am not familiar with
>current systems and all the terminology.  I am hoping some kind soul on the

The standard these day's is a 1200 baud TNC ( terminal node controller).
A TNC will take digital signals from your computer ( usually via a serial
port), and convert it to audio tones suitable for modulation of your xmitter.
It will also take audio from your rcvr and convert it to digital to feed back
to your cpu.  Whoops - 1200 baud is the standard on VHF.  On HF, it's 300
baud ( FCC RULE).  Most TNCS will do either 300 and 1200 baud.  Please note
that 9600 baud modems are becoming more popular.  The next step up from that
would be a 56kbs WA4DSY modem.  The fun doesnt stop there either - some
people are actually using 1 megabps and 10 megabps systems in the microwave
regions.  Look into products from AEA and Kantronics.  Maybe Bdale Garbee or
Glen Elmore will see this and tell us about Ethernet on the Air.

>net might point me in the direction of some reference material, standards etc.

I have not been too impressed with the books I have seen on packet radio.  One
that is OK is Digital Amateur Communications from Radio Shack.

>
>I am not aware of any existing packet-radio networks in my area, that doesn't
>mean to say there isn't though.  So I would be greatful if you suggest how
>I could find out, and get in touch with them.

Hmm - try ftp to ucsd.edu, and grab the AMPR.ORG database.  It will show call
signs of the stations running TCP/IP in Australia. Maybe you could talk to some
of those people.  BTW - KA9Q TCP/IP is really interesting, I would look into
it if I were you.  It will allow you to network computers over the air waves.

>
>  Rather than buy the equipment I would prefer to built it myself. So I am
>looking for pointers to the more technical aspects of how they work and not
>just what they do.

There are some kits that you can buy - the G0BSX card is pretty good.  Also,
look into the Digicomm for the Commodore 64.  It is a few chips that are the
skeleton of a TNC.  All the framing and such is done by the C64 itself.  This
is not normal - most TNC's have Z80's on board that do all of the framing.
>
>Thanks
>
>Andrew Chalmers
>
>University of South Australia

Jeff - NR0D

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

Date: 12 Jan 91 22:22:31 GMT
From: csus.edu!wuarchive!uwm.edu!src.honeywell.com!msi.umn.edu!cs.umn.edu!kksys!edgar!brainiac![e-mail]  (Jeffrey Comstock)
Subject: Header suppression
To: [e-mail]

In article <[e-mail]> [e-mail] ("Roy Engehausen") writes:
>Best idea I got so far is to use the algorithm I proposed on bulletins
>only.  Non-bulletin traffic will go thru untouched.  Any other suggestions?
>
>Roy

How about accept headers as a fact of life and tell the whiners that they are
needed ?  Ususally the people who bitch about headers are the same ones who
transmit glorious beacons about every five minutes.

Jeff

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

Date: 14 Jan 91 06:15:40 GMT
From: usc!samsung!munnari.oz.au!csc.anu.edu.au!manuel!csc.canberra.edu.au!echo![e-mail]  (Carl Makin)
Subject: Header suppression
To: [e-mail]

In <[e-mail]> [e-mail] (Brandon S. Allbery KB8JRR) writes:

>All the local PBBS systems are MSYS (gee, I wonder why? ;-), which shows only
>the calls.  I didn't know that there were PBBS systems that showed the full R:
>lines to users.  Maybe there's room for some evolution here?

I don't think the problem is with the USERS seing it.  It's more with wasted
transmit time.  Most of the information in the R: headers is useless anyway.


Carl.
[e-mail]
[e-mail]

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

Date: 14 Jan 91 06:20:50 GMT
From: usc!samsung!munnari.oz.au!csc.anu.edu.au!manuel!csc.canberra.edu.au!echo![e-mail]  (Carl Makin)
Subject: Header suppression
To: [e-mail]

In <[e-mail]> [e-mail] (Brian Lloyd) writes:

>shortened to just a list of BBSs, so if there were 24 routing lines, and
>we only want the last ten and the first one, the remaining thirteen
>routing lines would be replaced with a single line containing thirteen BBS
>callsigns.

The only information in the R: lines that is of any real use is the Date and
time stamp and the BBS Callsign. (The message number may be of use?)

Why don't we just shorten the headerlines to that?

Carl.
[e-mail]
[e-mail]

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

Date: 14 Jan 91 07:32:42 GMT
From: envy![e-mail]  (Phil R. Karn)
Subject: Header suppression
To: [e-mail]

In article <skcm.663833740@echo> [e-mail] (Carl Makin) writes:
>It's more with wasted
>transmit time.  Most of the information in the R: headers is useless anyway.

You wouldn't feel that way if you needed that information to
troubleshoot a message routing problem, or if the software uses it to
suppress loops (I don't know if it does).

I can say that in the Internet, the Received-From: lines in RFC-822
(internet standard mail) headers were considered important enough that
an explicit requirement was added to the Host Requirements RFC
(RFC-1123) that these lines not be deleted or tampered with by
downstream mail relays.

I'd haave more sympathy for the "wasted transmit time" argument if the
BBS networks were already using data compression.

Phil

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

Date: 13 Jan 91 18:19:36 GMT
From: usc!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!cc.utah.edu!cc.usu.edu![e-mail]
Subject: MODS for Kenwood Tm-941
To: [e-mail]

I am looking for MOD information on the Kenwood TM-941 Tri-band radio.
Supposedly there are mods for out of band operation and also for
cross band repeat.  I have not been able to track them down so far.
If anyone has information as to how I can find them I would appreciate
hearing from you.

Thanks;

Paul Israelsen - KB7LJC

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

Date: 14 Jan 91 02:28:08 GMT
From: snorkelwacker.mit.edu!usc!julius.cs.uiuc.edu!roundup.crhc.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu![e-mail]  (Mark J. Proulx N9EDK)
Subject: W3IWI ftp's
To: [e-mail]

Does anyone know how to ftp from W3IWI.  I had been using TOMCAT.GSFC.NASA.GOV
in the past (before xmas) but this does not work now.  Any ideas?!?!

Mark J. Proulx, N9EDK

[e-mail]   Packet

[e-mail]   EMail

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

End of Packet-Radio Digest
******************************
Date: Tue, 15 Jan 91 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #15
To: packet-radio


Packet-Radio Digest         Tue, 15 Jan 91       Volume 91 : Issue  15

Today's Topics:
              AMTOR hardware / software
              Header Suppresion
             Header suppression (2 msgs)
            Latest ROSE location?
                 W3IWI ftp's
             What happened to PR Digest.

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 14 Jan 1991 08:27:46 PST
From: [e-mail]
Subject: AMTOR hardware / software
To: [e-mail]

I am interested in giving Amtor a try. I do not want to use one of the "do all"
type of boxes like the PK232 since I have no real nead for all the other
features. (I use a DRSI board and TNC 1 & 2 for TCP-IP.) What I am realy
looking for is a simple interface board to plug into a pc-xt or the likes along
with some software. I have no problem hacking together hardware. Any ideas ?

Pete McAfee  kd6hr
internet: [e-mail]

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

Date: 15 Jan 91 02:32:19 GMT
From: usc!samsung!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!VK5TTY.#[e-mail]  ( G. Willis )
Subject: Header Suppresion
To: [e-mail]

Hello There. I have been reading with interest the discussion on headers
and suppressing them. I have a couple of points (questions) on the matter.

First as I understand it, in the US unattended HF stations (forwarding PBBS's)
were originally only allowed by the FCC because full message tracing
was provided by the BBS headers. Is this correct?

If this is the case, then just deleting headers would probably be a bad
idea. Anyway the advantage of headers is the ability (in hopefully the not
to distant future) for the BBS programs to determin their own routing of
messages from these headers (and removing one of the more tiring duties
of being a sysop).

I would like to see a development of G1NNA's idea implemented. Something
like the following.

1). Each message will always include the originating BBS's full R:etc type
header.
2). Each message should have the R:etc header from the immediately past
BBS the message passed through.
3). The rest of the BBS headers get condensed so that only the callsign
AND HIERARCHIAL ADDRESS is included (since the H-Address can help with
routing through the network also).

To maintain some degree with the current network, the order of the headers
would be,

    Immeadiately past BBS
    Originating BBS
    Path that the message has taken inbetween.

To signify the path lines, a new field could be introduced with a P:etc
type so that an example of a condensed header might be,

Subject Goes in here
R:910112\1145z @:VK5WI.#SA.AUS.OC Adelaide #:2345 Z:5037
R:900101\2356z @:W6HTH.HI.USA.OC Hawaii #:43589 Z:123445
P:VK4BBS.QLD.AUS.OC!VK2DQG.QLD.AUS.OC!VK2YDN.NSW.AUS.OC!VK2BBD.NSW.AUS.OC!...
p:VK2CKG.NSW.AUS.OC!VK2CZZ.NSW.AUS.OC!VK2XY.NSW.AUS.OC!VK2ASY.NSW.AUS.OC!...
P:VK1KCM.ACT.AUS.OC!VK2XLG.NSW.AUS.OC!VK3BSR.VIC.AUS.OC!VK5EX.#SA.AUS.OC

Test of message goes here.

As far as I can tell, that would still be completely compatible with all
existing BBS code, all path data is still retained and routing determination
could still take place. (opps, just noticed that one of my P:etc lines
had a lower case "p", ment to be an upper case).

I welcome any comments on this idea. Please do not send E-Mail. I wont
have E-Mail till late February. Post all replies to this newsgroup
or send them to me on the Packet Radio BBS Network to,

   VK5ZWI@VK5TTY.#SA.AUS.OC

Cheers de Grant VK5ZWI  -* Parkholme, SA *- SysOp @ ADELAN BBS Network
Packet Radio: VK5ZWI@VK5TTY.#SA.AUS.OC     AmPR TCP/IP: [44.136.171.11]
(Usual disclaimers apply...)

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

Date: 14 Jan 91 11:59:47 GMT
From: mcsun!ukc!axion!kitkat![e-mail]  (Brian Lloyd)
Subject: Header suppression
To: [e-mail]



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

Date: 14 Jan 91 16:20:21 GMT
From: netnews.upenn.edu!dsinc!unix.cis.pitt.edu!gvlf3.gvl.unisys.com!gvlv3.gvl.unisys.com![e-mail]  (Ed Naratil)
Subject: Header Suppression
To: [e-mail]

This is being posted for a SYSOP at N3LA who does not have access to the
Net.
===============================================================================


Hi Roy,

Rather than chop out some headers entirely, I would favor recoding to make a
typical header read as:  (fake example)

R:910110/1839 [e-mail]
vs
R:910110/1839 [e-mail] [ZANY ARC - Norristown, PA] Z:12345 N:NODE

Allow the minimum needed by hierarchical forwarding and a bit of auditing and
bag the rest (hard coded!) for a 50% saving.

I am told MBL software handles a message sent as "SP [e-mail]"
with no problem, but chokes on one sent "SB [e-mail]" until the
sysop creates a flood file for W1AW.  PRMBS handles ANYTHING.  I dunno what
yours, RLI or CBBS do, but doesn't the concept of hierarchical forwarding
dictate there should be no problem from either preceding example?

On this same general idea, why do some coders parse the H-address from left
to right and others right to left?  A message from CA to a bbs in Michelin
provence, France (a fabricated example) gets to Maine and gets bounced back
to Michigan cuz some software is more interested in the .MI. part than in
getting it to France (.FRC.), or better yet just to ".EU" to begin with.
Let those French stations worry where .MI. is after it gets to France!

My point?  A little more "common sense" in the code and some better docs so
the sysops will set up forwarding routes better and we could cut down on
circuitous forwarding and increase reliability.  With that we need less
auditing and maybe can bag all R: headers except the one from the
originating BBS.  Til then we need something to help locate the systems with
serious mail delay problems and maybe to trace a full return route for stuff
that can't deal well with H_addressing.

Definitely DON'T keep "last 'N' headers plus original; if you must, keep
first 'N' so as to have 'N-1' chances to get a return msg to a BBS which
maybe "knows" the originator.  The idea of needing a full return path in
this era of H_addressing is bad, but when the original route begins in
Maine, goes to Canada, down to Florida and arrives in Maryland ten hops
later. . . Why should it return THAT way?  Sheesh!

Let's also do something with explicit expiration dates on bulletins.  Let
the poster of a Kepplerian bulletin (as just one example) that will be stale
in two weeks flag it to expire in 10 days to 2 weeks.  If it is still plying
the ALLBBS route at that time, it dies automatically.  Why deliver stale
mail @ALLBBS or @AMSAT or ANY flood route? Of course a message to a
particular ham would not expire before delivery.

Thanks for the opportunity for input.  I am grateful to all you hard-working
programmers!  Thanks!

73 de Jim, KB3PU @N3LA.PA.USA.NA

----
Ed Naratil                                     (All standard disclaimers apply)
Amateur Packet: W3BNR@N3LA.#epa.PA.USA.NA      [e-mail]
This space intentionally left blank.

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

Date: 14 Jan 91 19:26:00 GMT
From: agate!bionet!uwm.edu!wuarchive!sdd.hp.com!apollo![e-mail]  (John Hays)
Subject: Latest ROSE location?
To: [e-mail]

What is the latest version of the ROSE software, and is there an FTPable
site (or public UUCP)?

John (KD7UW)
Salt Lake City, UT

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

Date: 14 Jan 91 16:35:46 GMT
From: idacrd![e-mail]  (Robert McGwier)
Subject: W3IWI ftp's
To: [e-mail]



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

Date: Tue, 15 Jan 91 15:17 +1030
From: "Rob Mayfield, ASC" <[e-mail]>
Subject: What happened to PR Digest.
To: [e-mail]

I used to receive Packet Radio DIgest, Anyone know what happened to it ??
73's ... Rob VK5XXX

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

Date: (null)
From: (null)
Brian

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

Date: (null)
From: (null)
Tom reported to me yesterday that he is having problems with tomcat and that
he is working them out with Phil, et. al. the authors of net.  He told me
he is running the box on straight DOS in an attempt to keep the code
from barfing DesqView.  It SHOULD be `back on the air.'

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: Wed, 16 Jan 91 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #16
To: packet-radio


Packet-Radio Digest         Wed, 16 Jan 91       Volume 91 : Issue  16

Today's Topics:
               a small version of ka9q?
         KA9Q Net or NOS for SCO UNIX SysV/386 3.2.2
              NET /KAM/HARDWARE (2 msgs)
       Q: Is packet radio hookup to internet feasible?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 15 Jan 91 21:21:38 GMT
From: ogicse!clark![e-mail]  (Adrian Miranda)
Subject: a small version of ka9q?
To: [e-mail]

I have an application where I need to run ka9q NOS along with another
program, on a fairly small ibm clone.  The problem is that ka9q is just
too large.  I have obtained the sources, and have been able to compile
it, but when I try to cut parts of it out, I can't compile it anymore.
All I need is the tcp/ip, the ethernet card support (via a packet
driver interface), ping, smtp, and (maybe) an ftp server.  I don't
need ax25, telnet, or any of the other stuff.  And I need this to run
in under 200K on an ibm pc.

Can anyone help me?  Perhaps someone has already built a very small
version of net.exe without all the bells and whistles?  Thanks in
advance.

Adrian Miranda
uunet!clark!ade  or  [e-mail]

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

Date: 16 Jan 91 00:45:28 GMT
From: csus.edu!wuarchive!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!cdin-1!cdis-1!ki4pv!ka3ovk![e-mail]  (Jon Albers)
Subject: KA9Q Net or NOS for SCO UNIX SysV/386 3.2.2
To: [e-mail]

I am looking for source code to NOS for SCO UNIX sys V 3.2.  Does anyone have
working source which will compile under this version of SCO UNIX?  I would
prefer it be available via uucp, as I do not have easy ftp access.

                                Jon Albers
                    ....uunet!media!ka3ovk


--
| Jon Albers, IRS, Information Systems Management, Support and Installation.  |
| Office Symbols: ISM:S:S:SI   voice: (202/FTS)535-3729  Packet: KA3OVK@N4QQ  |
| UUCP:(media|teemc|tcsc3b2|ki4pv)!ka3ovk!albers ARPA: JALBERS@SIMTEL20       |

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

Date: Tue, 15 Jan 91 13:07:40 EST
From: [e-mail] (ase)
Subject: NET /KAM/HARDWARE
To: [e-mail], [e-mail]

Awhile back I sent a problem into the users group on a KAM and the
STA light remaining lit. Here is an update and question(s).

Summary: I have a KAM on 2.85 (now), was using 3.0.
     Computer is clone 286 16mhz AT

Follow-up: The following cards are in the pc:
          a) Soundblaster (IRQ5)
          b) New serial card with (2) 16550 chips COM1 & 2
          c) Old serial card (contains joy,2 ser,1 par)
        I pulled out the jumpers for all except the par port.
         If I were to configure the card for com3and4 that

         would conflict sound card (irq5) as they are the

         same interrupt. I am using this card only for lpt1.

          d) Bus mouse (irq7)


Every card except the old serial card is installed. As soon as I
install this card, the STA light will remain lit at some undetermined
time.

This card does not have a called out "uart" but a programmable serial
interface. Has anybody ever run into this as a result of using net?
The card is called I/O 80 made in Taiwan.

Questions:   Can IRQ2 be used ? IRQ2 appears to be used by AT for
          direction to other interrupts. (unclear about this).


          Does anybody have concrete proof that Kam 3.0 firmware
          is faulty?

 I have heard from some IPers that it is not advisable to go beyond
 4800 baud due to limitations in NET. This sounds strange to me,
 could someone give me that straight scoop on this?

Thanks in advance for your time,

Jay Appell -KA1SNA

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

Date: 15 Jan 91 20:45:51 GMT
From: epic![e-mail]  (Phil R. Karn)
Subject: NET /KAM/HARDWARE
To: [e-mail]

In article <[e-mail].>,
[e-mail] (ase) writes:
|> Every card except the old serial card is installed. As soon as I
|> install this card, the STA light will remain lit at some
undetermined
|> time.

Sounds like you haven't really disabled your old serial card. I'd remove
it.

|> Questions:   Can IRQ2 be used ? IRQ2 appears to be used by AT for
|>               direction to other interrupts. (unclear about this).

IRQ2 works on the AT bus. But it is used by VGA (and EGA, I think)
cards to signal a vertical retrace interrupt, so I'd pick another
vector.

|>  I have heard from some IPers that it is not advisable to go beyond
|>  4800 baud due to limitations in NET. This sounds strange to me,
|>  could someone give me that straight scoop on this?

It depends on the hardware. Almost any machine with a 16550A can work
at
9600 bps, even slow CPUs like the 8088. However, if you have a plain
serial port you may have problems running 9600 bps even on faster CPUs.
Try it and see; the 'asystat' command will show you how many receiver
overruns have occurred. When a 16550A is available it will also show
the "high water mark" in the receiver FIFO. It will always be at least
4 since that's where the trigger point is set, but it can go as high as
16 before you lose characters.

Phil

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

Date: 15 Jan 91 17:10:19 GMT
From: [e-mail]  (Dave Cottingham)
Subject: Q: Is packet radio hookup to internet feasible?
To: [e-mail]

I think having my PC at home be an internet node would be quite
convenient.  I'm wondering if packet radio is a good (or legal) way of
doing this.  If anyone is doing this, how do you get an internet
address assigned to you?

Please mail replies to me, if there's interest, I'll summarize.

Thanks,
Dave Cottingham
[e-mail]

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

End of Packet-Radio Digest
******************************
Date: Fri, 18 Jan 91 04:30:06 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #17
To: packet-radio


Packet-Radio Digest         Fri, 18 Jan 91       Volume 91 : Issue  17

Today's Topics:
         2 DRSI Boards and NET/NOS? (2 msgs)
             Building a Linear Translator
               Making a DRSI card work
            Packet with the SINCLAIR Z80?
          scc driver and shared interrupts (2 msgs)
                Software TNC?
                unsubscribing

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 15 Jan 91 10:23:42 GMT
From: julius.cs.uiuc.edu!wuarchive!cs.utexas.edu!evax!utacfd!merch!cpe!techsup![e-mail]
Subject: 2 DRSI Boards and NET/NOS?
To: [e-mail]

a local ham, no newsgroup access, is trying to run nos with 2
DRSI boards.  he has the following:

drsi pcpa type 2 @ 300h
drsi pcpa type 1 @ 310h

both use int 7 (not sure if this is selectable on the board -- i
        don't own drsi boards)

he has tried several combinations of the drsi and scc drivers
with less than workable results.  is it possible to use 2 drsi
boards with net or nos?  if so, what version of net/nos?  also,
i'd appreciate a sample set of attach commands for each board to
pass along.

73 & thanks...

ken brookner, n5lpi
...!microsoft!trsvax!techsup!kenb

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

Date: 17 Jan 91 19:31:50 GMT
From: dsl.pitt.edu![e-mail]  (Ken Mitchum)
Subject: 2 DRSI Boards and NET/NOS?
To: [e-mail]

>
>he has tried several combinations of the drsi and scc drivers
>with less than workable results.  is it possible to use 2 drsi
>boards with net or nos?  if so, what version of net/nos?  also,
>i'd appreciate a sample set of attach commands for each board to
>pass along.

You can use two or more cards with the scc driver, providing they
are set up contiguously, i.e. card 1 at 0x300, card 2 at 0x310,
etc.. They can't share the same interrupt with the scc driver
(although the hardware on some boards, such as the PC100, supports
daisy chaining 8530s to a common interrupt). I will send you some
sample attach commands for the drsi.

  Ken Mitchum KY3B
  [e-mail]

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

Date: 16 Jan 91 18:11:23 GMT
From: idacrd![e-mail]  (Robert McGwier)
Subject: Building a Linear Translator
To: [e-mail]



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

Date: 18 Jan 91 06:04:06 GMT
From: [e-mail]  (Brian Kantor)
Subject: Making a DRSI card work
To: [e-mail]

I recently bought a pair of DRSI PC Packet Adaptor cards one type-1
with the built-in 1200 bps modem and a serial port, the other a type-3
with two serial ports.

I offer the following information for those of you who might be thinking
about buying one of these.

1. You don't get schematics.  They cost extra.

2. The pinout given for the 25-pin serial port on the type-1 card has
the clock in and clock out pins interchanged on the chart in the manual.

3. The pinouts given for the two 9-pin serial port connectors on the
type-3 card are wrong.  The pins are listed in 4 places, and in each
of those places, they are not only wrong, but the 4 listings disagree
with each other.

4. Check for solder splashes shorting chip pins together.

5. Check for bent-under pins on the socketed chips.

6. Be sure you have a few extra Berg jumpers in case you didn't get
enough of them with it to make the card work.

7. Before you unplug the 1488 and 1489 chips to get TTL levels on the
serial ports, be sure to write the part numbers on the board since the
diagram they tell you to refer to for chip locations does not in fact
show any chip locations.

8. The instructions for jumpering the type-1 board for external clocking
to interface it with a DSY modem are wrong.  In fact, I was never able
to get mine working with a DSY modem; I wound up using a PI board
instead.  Other people have, but they have early revisions of the PCPA
board and some of the pins and jumps must have changed in the mean time.

9. ARRGH.  For this I spent $125 each?  Next time I'll wire-wrap my own,
thank you very much.   Bleagh.
        - Brian

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

Date: 16 Jan 91 22:47:08 GMT
From: hpl-opus!hpnmdla![e-mail]  (Don Montgomery)
Subject: Packet with the SINCLAIR Z80?
To: [e-mail]

Hello Net Users

I have a friend that has a box full of SINCLAIR Z80 computers that is
interested in getting his feet wet on packet and doesn't have a whole
lot of money to spend.

Does anyone know of any easy way of turning one of these beasties into
a dumb terminal?  Is there a ROM available to replace the existing BASIC
firmware?  How about an RS-232 interface?

Also, short of wrapping the thing in aluminum foil, has anyone ever rid
one of these dinosaurs of its terrible RFI?

If you have anything for the good of the net, please post a reply, other-
wise email.  Any info appreciated...

                 Don Montgomery, K6LTS
                  [e-mail]

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

Date: 17 Jan 91 21:11:27 GMT
From: dsl.pitt.edu![e-mail]  (Ken Mitchum)
Subject: scc driver and shared interrupts
To: [e-mail]

Oops! In my previous posting, I misspoke myself: The scc driver assumes
multiple boards share the same interrupt. This has to be supported by
the boards' hardware, i.e. to use the daisy-chained 8530 interrupt
scheme, with only one board actually causing the interrupt. The PC100
supports this; I don't know about the DRSI. Two boards on a PC or AT
bus cannot share interrupts otherwise, as the interrupt lines are not
open-collector.

The PC100 has a jumper for the chip interrupts so that you can chain
the interrupts across boards, with only the first board providing the
actual hardware interrupt to the bus.

Sorry for any confusion this might have caused.

 Ken Mitchum KY3B
 [e-mail]

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

Date: 18 Jan 91 05:46:19 GMT
From: [e-mail]  (Brian Kantor)
Subject: scc driver and shared interrupts
To: [e-mail]

The software supplied with the DRSI card for use as a DED TNC will
support multiple cards on a single interrupt.
    - Brian

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

Date: 17 Jan 91 11:56:21 GMT
From: mcsun!ukc!newcastle.ac.uk!turing![e-mail]  (A. French)
Subject: Software TNC?
To: [e-mail]

For some years now computer programs have existed to decode RTTY, CW and the
like. Would it not be possible to implement a packet TNC in software in order
to avoid the need for an expensive off-the-shelf TNC? After all, a TNC merely
consists of a microprocessor bolted to a radio modem. It would be necessary to
built a hardware radio modem but that should be no real problem.

Has anyone out there written TNC software, or know of anyone who has? If anyone
can supply me with detailed info on the packet protocol (AX-25?), and details
of the radio modulation (I assume FSK, if so, what shifts?), I'd quite like to
tackle the project myself.

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

Date: Thu, 17 Jan 91 10:56 CST
From: [e-mail]
Subject: unsubscribing
To: [e-mail]

Please take this account off the mailing list or send information to this
account [e-mail].

The account has been reassigned to Shane Holder.

Thanks in advance.

Shane Holder
CSE University Texas at Arlington

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

Date: (null)
From: (null)
Bill:

I believe the complete plans for several of the Mode A transponders are
in the Davidoff's "Satellite Experimenter's Handbook."  You should check
there.

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: Sat, 19 Jan 91 04:30:08 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #18
To: packet-radio


Packet-Radio Digest         Sat, 19 Jan 91       Volume 91 : Issue  18

Today's Topics:
             Are DRSI still in business?
           scc driver and shared interrupts
             Software approach to packet.

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Fri, 18 Jan 91 17:11:52 GMT
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: Are DRSI still in business?
To: [e-mail]

Someone recently said that DRSI had filed for bankruptcy under chapter 11.
Can anyone confirm/deny this rumor? Should we still consider buying DRSI
cards?

       Pete Lucas [e-mail]  [e-mail]

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

Date: 18 Jan 91 22:39:06 GMT
From: usc!zaphod.mps.ohio-state.edu!know!tegra![e-mail]  (Johnathan Vail)
Subject: scc driver and shared interrupts
To: [e-mail]

In article <[e-mail]> [e-mail] (Ken Mitchum) writes:

   Oops! In my previous posting, I misspoke myself: The scc driver assumes
   multiple boards share the same interrupt. This has to be supported by
   the boards' hardware, i.e. to use the daisy-chained 8530 interrupt
   scheme, with only one board actually causing the interrupt. The PC100
   supports this; I don't know about the DRSI. Two boards on a PC or AT
   bus cannot share interrupts otherwise, as the interrupt lines are not
   open-collector.

Is this really true?  There are several instances of shared interrupts
in the PC/AT on different boards without hardware chaining.  The
software just polls the devices to see who really interrupted.

jv


Law of Stolen Flight: Only flame, and things with wings.
              All the rest suffer stings.
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

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

Date: Fri, 18 Jan 91 17:08:36 GMT
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: Software approach to packet.
To: [e-mail]

Someone was asking about this recently. Well, it *is* possible, though
you still need a modem to convert the bits to tones.
If you have an IBM-PC or compatible, there is a program called BAYCOM that
is being written by two German guys. Currently the program exists but its
documentation (and error messages) are in DL-sprach, there is an effort
going on to translate the manuals & messages to English.
BAYCOM is a shareware product - you send the authors a 20-Deutschmark
note if you use the program.
I must admit to having reservations about generating all the HDLC
framing etc. in software.... i remember some of the very first implementations
of X25 that did this, and the frequency with which incomplete frames
appeared at the output...    ..... :-(  <LINK DOWN!>   :-(  :-(
Chips like the 8530 are not expensive; i can see a demand for a really
low-cost (sub-70-dollar) single-port 1200-baud VHF-only version of the
DRSI PC*PA card to get people started in packet.
Not everyone wants to fork out hundreds of dollars on PK-232's etc.

       Pete Lucas [e-mail]  [e-mail]

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

End of Packet-Radio Digest
******************************
Date: Sun, 20 Jan 91 04:30:11 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #19
To: packet-radio


Packet-Radio Digest         Sun, 20 Jan 91       Volume 91 : Issue  19

Today's Topics:
                Software TNC?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

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

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 19 Jan 91 19:09:14 GMT
From: timbuk!cs.umn.edu!kksys!edgar!brainiac![e-mail]  (Supreme Weenie)
Subject: Software TNC?
To: [e-mail]

In article <[e-mail]> [e-mail] (A. French) writes:
>For some years now computer programs have existed to decode RTTY, CW and the
>like. Would it not be possible to implement a packet TNC in software in order
>to avoid the need for an expensive off-the-shelf TNC? After all, a TNC merely
>consists of a microprocessor bolted to a radio modem. It would be necessary to
>built a hardware radio modem but that should be no real problem.
>
>Has anyone out there written TNC software, or know of anyone who has? If anyone
>can supply me with detailed info on the packet protocol (AX-25?), and details
>of the radio modulation (I assume FSK, if so, what shifts?), I'd quite like to
>tackle the project myself.

This would be a nice project, and I am sure it would keep you very busy.  You should check
out the Digicom for the Commodore 64.  This is a small card that is really the modem, and
it dumps raw data to the Commodore 64.  ALL of the packet is processed by the C64 in
software. As far as I know, the source code for this software is not available.  It uses
an AM7910 as the modem.

You may also be interested in the KISS protocol. This makes the computer responsible for
all AX25 header processing ( and timing functions too).

KA9Q TCP/IP uses this, and the source code is available to the public. There is a nice
AX25 protocol processing package in the source code.  The author, Phil Karn, keeps the
latest version on thumper.bellcore.com. It is also available on quite a few other machines
on the network. The MSYS bbs also uses KISS to process incoming packets.

Jeff  NR0D

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

End of Packet-Radio Digest
******************************
Date: Mon, 21 Jan 91 04:30:10 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #20
To: packet-radio


Packet-Radio Digest         Mon, 21 Jan 91       Volume 91 : Issue  20

Today's Topics:
             Are DRSI still in business?
       DRSI & MSYS : Has anyone tried this combination?

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 20 Jan 91 20:24:16 GMT
From: cunixf.cc.columbia.edu!cunixa.cc.columbia.edu![e-mail]  (Meir)
Subject: Are DRSI still in business?
To: [e-mail]

In article <18.Jan.91.17:12:32.GMT.#[e-mail]> [e-mail] ("Pete Lucas, NCS-TLC, Holbrook House, Swindon") writes:
>Someone recently said that DRSI had filed for bankruptcy under chapter 11.
>Can anyone confirm/deny this rumor? Should we still consider buying DRSI
>cards?
>
>           Pete Lucas [e-mail]  [e-mail]

An update states that DRSI will remain in business, but their 800 # is being
dropped and they are dropping direct sales and may drop Amateur card sales.

 * * * * * * *  ======================= Meir Green
* * * * * * * * ======================= [e-mail]
 * * * * * * *  ======================= N2JPG

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

Date: 19 Jan 91 22:38:38 GMT
From: munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!levels![e-mail]
Subject: DRSI & MSYS : Has anyone tried this combination?
To: [e-mail]

Following the release of MSYS version 1.10, which added the support for DRSI
cards..... we have been considering running our local BBS system using 2 of
these for our 4 VHF/UHF ports.

Has anyone tried this, just interested to hear of any relevant comments b4
we buy ...

73's Rob VK5XXX

--
Rob Mayfield    -  ASC Network Support, VK5XXX/ZEU, 44.136.171.1/44.136.171.2
Internet/AARNet -  [e-mail]        [AMPR_TCP/IP VK5 Co-ordinator]
Applelink       -  AUST0177
AMPR            -  VK5XXX@VK5WI.#SA.AUS.OC  [ or     VK5ZEU@VK5WI.#SA.AUS.OC]

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

End of Packet-Radio Digest
******************************
Date: Tue, 22 Jan 91 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #21
To: packet-radio


Packet-Radio Digest         Tue, 22 Jan 91       Volume 91 : Issue  21

Today's Topics:
                   BB V2.1F
              Best 73 de HB9CMB
               Looking for N2WX
            MBBIOS and 16550 chips

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 21 Jan 91 18:41:20 PST
From: "Roy Engehausen" <[e-mail]>
Subject: BB V2.1F
To: [e-mail]

I have loaded a test version of my BBS program into the TOMCAT server
for people to try.  Improvements are many including multiple language
support, automatic clean up of message files (eg: keep last AMSAT
orbital info), messages into files, automatic rejection of messages,
etc. The file is BB21F.ZIP.  I tend to replace this test versions
every one to two weeks.

Roy, AA4RE

P.S.  I also uploaded G8BPQ Node V4.02A into TOMCAT too.

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

Date: 21 Jan 91 18:06
From: Hanspeter Pfander <[e-mail]>
Subject: Best 73 de HB9CMB
To: [e-mail]

Hello OM,s,
Just saw ur ean adress on monitoring some packet radio messages
last weekend. Thought I could write you some lines and send best
wishes for 1991. Maybe you may have some useful packet radio or
any ham news to tell? Best 73 es best 73 de
Pascal, HB9CMB

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

Date: 21 Jan 91 18:55:44 GMT
From: swrinde!zaphod.mps.ohio-state.edu!caen!uflorida!mlb.semi.harris.com!trantor.harris-atd.com!x102c.ess.harris.com![e-mail]  (Gary Bastin 60293)
Subject: Looking for N2WX
To: [e-mail]

I am looking for an e-mail, phone number, or other address, for
Howie Goldstein, N2WX.  He formerly lived here on the east coast
of FL in Palm Bay, but left the area about a year or two ago.  He
is the author of the original TAPR tnc firmware, as well as of the early
switch software.  Any information would be greatly appreciated.
Thanks in advance!  73, Gary

Gary Bastin, WB4YAF      /-/-/      Internet: [e-mail]
Mail Stop 102-4826         |        phone: [phone]
Harris Corporation GASD    |
P.O.B. 94000, Melbourne FL 32902    Speaking from, but not for, Harris!

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

Date: Mon, 21 Jan 91 18:20:59 PST
From: "Roy Engehausen" <[e-mail]>
Subject: MBBIOS and 16550 chips
To: [e-mail]

I have a version of MBBIOS which should support the 16550A buffered UART.
Any volunteers for testing?

Roy, AA4RE

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

Date: 21 Jan 91 14:56:18 EST
From: [e-mail]
To: [e-mail]

I am scratching my head over how to get NOS to speak to my H.A.P.N. board.
The last version that I was running was Jon Bloom's varient, aka NOS_KE3Z.
At that point, at least the software would complain bitterly at the command
line in autoexec.net. Now, the G8EMM versions which I have been using (1.7
& 2.3) don't recognize the configuration commands at all, i.e. the interface
is missing.

While I am willing to back up to John's version, I would appreciate suggestions
as to what needs to go into my autoexec file--the suggested command line from
the manual doesn't work at all--and what to do (if anything) about getting it
returned to the varient I am now using, i.e. EMM82823.



de Dave, KC1PR
[e-mail]
KC1PR @ WA1PHY.MA
44.56.4.88  aka kc1pr.ampr.org
44.56.0.85  aka w1tkz.ampr.org

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

End of Packet-Radio Digest
******************************
Date: Wed, 23 Jan 91 04:30:05 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #22
To: packet-radio


Packet-Radio Digest         Wed, 23 Jan 91       Volume 91 : Issue  22

Today's Topics:
            List over BBS's on HF
          PACKET->Internet Gateway (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

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

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 22 Jan 91 19:06:41 GMT
From: eru!hagbard!sunic!isgate!krafla![e-mail]  (Saemundur Thorsteinsson)
Subject: List over BBS's on HF
To: [e-mail]

Does anybody have a list over BBS's on HF or can point
out a source for such a list.
73's  de
TF3UA   ([e-mail])

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

Date: 22 Jan 91 20:55:03 GMT
From: sdd.hp.com!usc!ucselx!steer![e-mail]  (Robert S. Radvanovsky KC6ONL)
Subject: PACKET->Internet Gateway
To: [e-mail]

Don't know if the other message/article was posted here, so I'll request again.
Does anyone know if a PACKET (either AX.25 and/or TCP/IP) gatewaye exists
between PACKET radio and Internet?  If so, could someone please state where it
is located?  If not, why has this not been performed?  Additionally, what would
be needed in getting set up?

Robert S. Radvanovsky, KC6ONL

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

Date: 22 Jan 91 21:33:10 GMT
From: sun-barr!cs.utexas.edu!helios!photon![e-mail]  (Willis Marti)
Subject: PACKET->Internet Gateway
To: [e-mail]

In article <[e-mail]>, [e-mail] (Robert S. Radvanovsky KC6ONL) writes:
|> Don't know if the other message/article was posted here, so I'll request again.
|> Does anyone know if a PACKET (either AX.25 and/or TCP/IP) gatewaye exists
|> between PACKET radio and Internet?  If so, could someone please state where it
|> is located?  If not, why has this not been performed?  Additionally, what would
|> be needed in getting set up?
|>
|> Robert S. Radvanovsky, KC6ONL
To the best of my knowledge (as an about-to-be ham), there is *no*
gateway (router) between net 44 and the rest of the Internet.  While
there may be some political & legal questions, the major reason I'd say
is technical.
IP routing between networks assumes each network is fully interconnected
internally.  That implies that any node advertising a path to a net 44
system (say, in NY) can also pass packets to any other net 44 node (say,
in Montana).  At this date, that assumption is badly broken.  Correcting
it would mean some kind of complete connectivity between AMPR sites
*world-wide*, or a rather drastic change in IP routing technology.  The
latter is more likely.  8-)
That's not to say there aren't other ways...

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

End of Packet-Radio Digest
******************************
Date: Thu, 24 Jan 91 04:30:07 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #23
To: packet-radio


Packet-Radio Digest         Thu, 24 Jan 91       Volume 91 : Issue  23

Today's Topics:
                 Packet Maps

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 23 Jan 91 07:10:15 GMT
From: swrinde!zaphod.mps.ohio-state.edu!samsung!umich!umeecs!msi.umn.edu!cs.umn.edu!kksys!edgar!brainiac![e-mail]  (Jeffrey Comstock)
Subject: Packet Maps
To: [e-mail]

I am interested in getting current packet maps of the various states (especially
the upper midwest).  What do you people think of posting maps on a regular
basis to the newsgroup?  If that doesn't sound too good, how about someone
setting up a server that would send a map on reciept of a mail message ?
I will even do the server, but I need fresh maps for a database.  It would
be nice to get bbs lists and callsign info from a server too.  If you
are interested in a project like this, please post here or send email
to [e-mail] .

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

End of Packet-Radio Digest
******************************
Date: Fri, 25 Jan 91 04:30:16 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #24
To: packet-radio


Packet-Radio Digest         Fri, 25 Jan 91       Volume 91 : Issue  24

Today's Topics:
              doc of ax25 needed
           ka9q NOS on an AT&T 3b1 unix-pc
          PACKET->Internet Gateway (4 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

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

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 24 Jan 91 17:52:48 GMT
From: usc!sdd.hp.com!spool2.mu.edu!news.cs.indiana.edu!ux1.cso.uiuc.edu!uxh.cso.uiuc.edu![e-mail]  (Gabriel Perez)
Subject: doc of ax25 needed
To: [e-mail]

Hi,
   I would like to know where I can get a technical description of the ax25
protocol. Thank you very much in advance.

--
fernando aversa ([e-mail]) <-- please reply to this address

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

Date: 25 Jan 91 04:00:10 GMT
From: sun-barr!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!news.cs.indiana.edu!maytag!xenitec!iguana![e-mail]  (Jim Mercer)
Subject: ka9q NOS on an AT&T 3b1 unix-pc
To: [e-mail]

would anyone who has ka9q NOS (or hyprids thereof) running under unix (sysV)
please email me?

i would also be interested in anyone running it on AT&T 3B2's.

thanx
--
[ Jim Mercer   work: [e-mail]  home: [e-mail]  [phone] ]
[                "Clickity-Click, Barba-Trick" - The Barbapapas               ]

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

Date: 24 Jan 91 15:14:07 GMT
From: usc!samsung!caen!ox.com!b-tech![e-mail]  (Jon Zeeff)
Subject: PACKET->Internet Gateway
To: [e-mail]

>IP routing between networks assumes each network is fully interconnected
>internally.  That implies that any node advertising a path to a net 44
>it would mean some kind of complete connectivity between AMPR sites
>*world-wide*, or a rather drastic change in IP routing technology.  The
>latter is more likely.  8-)

As has been thought of and discussed many times, a solution would be a
standard for wrapping ip packets in ip packets.  The destination machine
would unwrap the packet and then route it like any other ip packet.
It would allow some very flexible routing.

--
Jon Zeeff (NIC handle JZ)        [e-mail]

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

Date: 24 Jan 91 18:27:21 GMT
From: wuarchive!cs.utexas.edu!helios!photon![e-mail]  (Willis Marti)
Subject: PACKET->Internet Gateway
To: [e-mail]

In article <B#1+ZF=@b-tech.uucp>, [e-mail] (Jon Zeeff) writes:
|> >IP routing between networks assumes each network is fully interconnected
|> >internally.  That implies that any node advertising a path to a net 44
|> >it would mean some kind of complete connectivity between AMPR sites
|> >*world-wide*, or a rather drastic change in IP routing technology.  The
|> >latter is more likely.  8-)
|>
|> As has been thought of and discussed many times, a solution would be a
|> standard for wrapping ip packets in ip packets.  The destination machine
|> would unwrap the packet and then route it like any other ip packet.
|> It would allow some very flexible routing
Such a standard would mean changing *all* the machines we might want to
talk to on the Internet -- if I understand one interpretation of what
you said.  Define "destination machine".
A possiblity would be for "gateway" machines to receive net 44 AMPR
packets, redo the network addresses, send the packet on the Internet,
and when receiving packets, change back to net 44 according to some
table.  That might work for most applications.

Maybe I missed the discussion of viable solutions, but I think the
bigger question is why don't we do it right (e.g., fully connect net 44
or go to class C/B nets for different areas.

Willis Marti

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

Date: 24 Jan 91 20:50:44 GMT
From: usc!samsung!think.com!news![e-mail]  (Bruce Walker)
Subject: PACKET->Internet Gateway
To: [e-mail]

In article <[e-mail]> [e-mail] (Robert S. Radvanovsky KC6ONL) writes:

   Don't know if the other message/article was posted here, so I'll request again.
   Does anyone know if a PACKET (either AX.25 and/or TCP/IP) gatewaye exists
   between PACKET radio and Internet?  If so, could someone please state where it
   is located?  If not, why has this not been performed?  Additionally, what would
   be needed in getting set up?

   Robert S. Radvanovsky, KC6ONL

I am not expert, being in the newcomer limbo state of having passed my
first exams (Tech) but waiting for my ticket, but I assumed this hadn't
been done because it would be illegal, for the same reasons reverse
autopatch is illegal: traffic initiated by non-hams would cause the
"gateway" to transmit without control.  Perhaps a mail-only store-and-forward gateway would
work, but then some poor soul would have to manually screen and forward
each message.  Am I way off base here?

Getting the routing right is just a technical difficulty which we could
solve.
--
--Bruce Walker
  Thinking Machines Corporation, Cambridge, MA
  [e-mail]; [phone]

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

Date: 24 Jan 91 14:54:06 GMT
From: hpda!hpcupt1!hprnd!hpsmeng1![e-mail]  (Eric Struble)
Subject: PACKET->Internet Gateway
To: [e-mail]

/ hpsmeng1:rec.ham-radio.packet / [e-mail] (Willis Marti) /  1:33 pm  Jan 22, 1991 /
In article <[e-mail]>, [e-mail] (Robert S. Radvanovsky KC6ONL) writes:
|> Don't know if the other message/article was posted here, so I'll request again.
|> Does anyone know if a PACKET (either AX.25 and/or TCP/IP) gatewaye exists
|> between PACKET radio and Internet?  If so, could someone please state where it
|> is located?  If not, why has this not been performed?  Additionally, what would
|> be needed in getting set up?
|>
|> Robert S. Radvanovsky, KC6ONL
To the best of my knowledge (as an about-to-be ham), there is *no*
gateway (router) between net 44 and the rest of the Internet.  While
there may be some political & legal questions, the major reason I'd say
is technical.
IP routing between networks assumes each network is fully interconnected
internally.  That implies that any node advertising a path to a net 44
system (say, in NY) can also pass packets to any other net 44 node (say,
in Montana).  At this date, that assumption is badly broken.  Correcting
it would mean some kind of complete connectivity between AMPR sites
*world-wide*, or a rather drastic change in IP routing technology.  The
latter is more likely.  8-)
That's not to say there aren't other ways...
-

a
******************************************************************************

I think you will fing a legal question when it involves access to the
packet network. It has to do with non-hams accesing the airwaves. If you
would read the article in December,1990 QST, page 79, on "Reverse Autopatch"
it goes through and talks about the legality of accessing the repeter. It
would be nice if mail could be forwarded through the Internet/Packet network.


73's.....

Eric@ hp Roseville,Ca

N6PYF

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

End of Packet-Radio Digest
******************************
Date: Sat, 26 Jan 91 04:30:08 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #25
To: packet-radio


Packet-Radio Digest         Sat, 26 Jan 91       Volume 91 : Issue  25

Today's Topics:
       Determining IP hosts in your (geograhical) area
              doc of ax25 needed
          PACKET->Internet Gateway (3 msgs)
        Summary - how to make home PC an internet node

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 25 Jan 91 18:24:31 GMT
From: mejac!orchard.la.locus.com!prodnet.la.locus.com![e-mail]  (Eric Peterson)
Subject: Determining IP hosts in your (geograhical) area
To: [e-mail]

    In my area there seem to be a reasonable amount of hosts runnning
    "standard" (ie. ax25) packet, but very few (if any) running TCP/IP
    packet.  How does one reasonably determine IP hosts/gateways within
    your transmission radius?  I have been turning on "packet monitoring"
    to look for IP packets, but this so far has been unsuccessful; it
    certainly seems to be a poor method of doing things.

    I even tried (no flames please :-) pinging a broadcast address
    (yes, I know it's an awful thing to do) but _it_ didn't work
    either.

    Would it be reasonable to implement something akin to "rwho"
    broadcasts so a host could determine other hosts that are out
    there, or even better: a "route" broadcast that would list
    all the hosts a particular host/gateway could talk to (even
    "transparently" gatewayed via ax25 or "wormholes"), and a
    "preference" value for each of those hosts.

    If the above is unreasonable, are there "maps" describing the
    topology of the AMPR IP net?

    All I want to do is connect to _someone_ via IP...

--
Eric Peterson    WB6PYK
Locus Computing Corporation    [phone]
[e-mail]     {randvax,ucbvax}!ucla-se!lcc!eric
{oblio,gryphon,turnkey,attunix}!lcc!eric

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

Date: 25 Jan 91 15:18:02 GMT
From: hpda!hpcupt1![e-mail]  (Jim Hollenback)
Subject: doc of ax25 needed
To: [e-mail]



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

Date: 25 Jan 91 14:25:54 GMT
From: sdd.hp.com!samsung!umich!ox.com!b-tech![e-mail]  (Jon Zeeff)
Subject: PACKET->Internet Gateway
To: [e-mail]

>|> >IP routing between networks assumes each network is fully interconnected
>|> >internally.  That implies that any node advertising a path to a net 44
>|>
>|> As has been thought of and discussed many times, a solution would be a
>|> standard for wrapping ip packets in ip packets.  The destination machine
>|> would unwrap the packet and then route it like any other ip packet.
>|> It would allow some very flexible routing

>Such a standard would mean changing *all* the machines we might want to
>talk to on the Internet -- if I understand one interpretation of what

It would just have to be implemented on certain gateway machines.

>A possiblity would be for "gateway" machines to receive net 44 AMPR
>packets, redo the network addresses, send the packet on the Internet,
>and when receiving packets, change back to net 44 according to some
>table.  That might work for most applications.

Effectively, this is what I'm talking about.  But given the
possibilities of inconsistant tables and the number of possible net 44
addresses, it is better to replace "redo" with "add" in your
paragraph.  You don't want gateways to have to reserve large blocks of
address space.

--
Jon Zeeff (NIC handle JZ)        [e-mail]

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

Date: 25 Jan 91 15:41:54 GMT
From: usc!cs.utexas.edu!helios!photon![e-mail]  (Willis Marti)
Subject: PACKET->Internet Gateway
To: [e-mail]

In article <[e-mail]>, [e-mail] (Jon Zeeff) writes:
[stuff deleted]
|> It would just have to be implemented on certain gateway machines.
|>
|> >A possiblity would be for "gateway" machines to receive net 44 AMPR
|> >packets, redo the network addresses, send the packet on the Internet,
|> >and when receiving packets, change back to net 44 according to some
|> >table.  That might work for most applications.
|>
|> Effectively, this is what I'm talking about.  But given the
|> possibilities of inconsistant tables and the number of possible net 44
|> addresses, it is better to replace "redo" with "add" in your
|> paragraph.  You don't want gateways to have to reserve large blocks of
|> address space.
But *where* are you going to "add" things in an IP packet that *each*
destination machine doesn't have to know about?  I can see your scheme
working if it only concerns using the existing Internet to interconnect
net 44, but I also see BIG problems in using that scheme and trying to
'talk' from net 44 to the rest of the Internet.  What's the functionality
desired?
|>
|> --
|> Jon Zeeff (NIC handle JZ)     [e-mail]
Cheers,
 Willis Marti   [e-mail]

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

Date: Fri, 25 Jan 1991 18:50:37 EST
From: Steven L. Johnson <[e-mail]>
Subject: PACKET->Internet Gateway
To: [e-mail]

> Jon Zeef writes:
>
> As has been thought of and discussed many times, a solution would be a
> standard for wrapping ip packets in ip packets.  The destination machine
> would unwrap the packet and then route it like any other ip packet.
> It would allow some very flexible routing.

If I understand you correctly, the same might be accomplished by IP
loose source routing, which is standardized and wouldn't require
breaking existing routing code in intermediate systems.  The routing
algorithm on the machine on the Internet would have to have additional
smarts to determine the correct path from the 44.x.x.x address.

-Steve

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

Date: 25 Jan 91 22:19:47 GMT
From: agate![e-mail]  (Dave Cottingham)
Subject: Summary - how to make home PC an internet node
To: [e-mail]

I recently posted a question on these newsgroups asking for what
people knew about getting the home PC on the internet, and one on
rec.ham-radio.packet asking what the scoop is on using amateur packet
radio for this purpose.  I`d like to thank all the people who took the
trouble to respond.  There were a fair number of me-toos as well, so I
made up a summary of what I understood on the subject from the
responses and elsewhere, but due to the fact that a) some of the
responses had some considerable detailed info that might be of
interest to people and b) my knowledge of networking in its thousand
forms has sizeable holes in it I decided it would be a good idea to
append all the responses.  The resulting file is 100K, so I'm not
posting it.  You can get it by sending a message to
[e-mail] with a line in the body (not the subject!)
that says "sendme ip_hookup".  It will arrive in two parts.

Here is the micro-summary:

Q: how do you get an internet address, and how do you
make the physical connection?

A: The affordable option is to work for a university or other
organization that has an internet hookup, or have a buddy at same, and
convince the relevant authorities to attach you to one of their
existing nets.  You use a modem and phone line to connect to one of
their computers, running SLIP protocol.  Said computer acts as router
for you between its LAN and the phone line.  If you're lucky you might
even get the thing to work with dial-up connections instead of a
permanent leased line and save a buck.  As far as the outside world
knows, your home PC is one of their computers.

Q: Suppose I'm willing to settle for news and mail?

A: There are thousands of ways, including uunet, nixpub, fidonet, or
picking someone at random from comp.mail.maps.

Q: How do I get a registered domain name?  And what software should I
use?

A: I didn't ask these question, but I got lots of replies to them
anyhow.  Get the longer summary for the answers.

Dave Cottingham
[e-mail]

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

Date: (null)
From: (null)
cost is $8 (?)

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

End of Packet-Radio Digest
******************************
Date: Sun, 27 Jan 91 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #26
To: packet-radio


Packet-Radio Digest         Sun, 27 Jan 91       Volume 91 : Issue  26

Today's Topics:
            Attn. New Packeteers, Part 1/7
            Attn. New Packeteers, Part 2/7
            Attn. New Packeteers, Part 3/7
            Attn. New Packeteers, Part 4/7
            Attn. New Packeteers, Part 5/7
            Attn. New Packeteers, Part 6/7
            Attn. New Packeteers, Part 7/7
       Determining IP hosts in your (geograhical) area

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Sat, 26 Jan 91 22:41:35 CST
From: [e-mail] (Paul W. Schleck KD3FU)
Subject: Attn. New Packeteers, Part 1/7
To: [e-mail]

Repy-to: [e-mail]

The following is the first in a series of a very good beginners guide
to packet put out by a MD packet BBS sysop, Pete KA3RFE.  He has given
me permission to pass it along to this forum.  He considers it
required reading for all who got new TNC's this X-mas and as a
refresher course for those of us who sometimes forget the basics.

You know who they are, the ones with "PK-232" in their callsign field?
Pete determined that "PK" was an old prefix for the Dutch West Indies.
We wrote the ARRL to see if we could get DXCC credit for working them.
So far no response :-).

Remember, the following is KA3RFE's, not my own.  Replies and criticisms
should be sent to AMPR [e-mail].

73, Paul W. Schleck, KD3FU


MSG # TR  SIZE TO     FROM   @BBS   DATE    TITLE
 4673 B#  3444 ALL    KA3RFE MDCBBS 910106 ATT: New Packeteers
Forwarding path: W3IWI N4QQ N2GTE KA3RFE
This is for those of you got new tncs for Christmas and are just starting
out in the Wonderful World of Packet. There are some things you should know
that your tnc manual may not have mentioned.

Some terms which get people confused:

1) Home BBS: A "home BBS" does not refer to the mailbox program which your
   tnc may have in it's guts. It refers to a full-service BBS which handles
   personal mail, bulletins, and file transfers. Your "home BBS" would be
   a full-service BBS which you might check into often to read bulletins
   and to pick up any personal mail which might be held for you. If you
   have arragned for a full-service BBS to forward your personal mail to
   your mailbox, your home BBS still remains that full-service BBS.

   This term is important as several BBS programs will ask you to enter
   a "home BBS" the first time you connect to it.

2)  Node: You can figure a "node" to be something of a packet switchboard
    which has the ability to operate on several frequencies. A node
    differs from a digipeater in the sense that it handles all of the
    packet housekeeping chores within its program. Most nodes have more
    than one operating frequency and they can shuttle packets back and
    forth via any number of intermediate nodes. The benefit of using a
    node over a digipeater is that the node will find the quickest way
    to make the connection whereas a digipeater will only try to connect
    you to the station you tell it to connect to, regardless of whether
    the digipeater can hear it or not.

    You cannot send mail to a node. It is not a mailbox or a BBS.

3)  Network BBS: A network BBS is a full-service BBS which is operating
    under a special node-compatible software program. Network BBSs will
    show up in node broadcasts and can be connected to over the node
    network by entering a connect request to the network BBS alias.

    Generally, a network BBS will have an alias in which either BBS
    or BB is part of the alias. For example: ANNBBS is the alias for
    KA3RFE BBS in Annapolis; BWIBBS is the alias for WB3V BBS in
    Severn. BBJ9X is the alias for AJ9X's tcp/ip BBS in Westminister.

    The network BBS alias is ONLY FOR CONNECTING. You should not use
    the network BBS alias as an entry for "home BBS" when your are
    asked to enter your home BBS. Use the callsign of the BBS and
    not its alias as your home BBS when asked to enter it.

    The same goes for sending mail to a netowrk BBS. If you enter a
    message to KA3RFE @ ANNBBS, the message will never get there since
    ANNBBS is only an alias for use in connecting to it over the node
    network. IF you enter a message to KA3RFE @ KA3RFE, the message
    will be forwarded without much hassle.

I strongly suggest that you throurghly read your tnc manual and also
suggest that you get a copy of "Your Gateway to Packet Radio" from
somewhere. Its the best book yet written on the ins and outs of
packet radio.
               73, Pete, sysop KA3RFE (ANNBBS)
                   Annapolis, Md.


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

Date: Sat, 26 Jan 91 22:42:35 CST
From: [e-mail] (Paul W. Schleck KD3FU)
Subject: Attn. New Packeteers, Part 2/7
To: [e-mail]

Reply-to: [e-mail]

MSG # TR  SIZE TO     FROM   @BBS   DATE    TITLE
 4813 B#  1760 ALL    KA3RFE MDCBBS 910110 Att New Packeteers pt.2
Forwarding path: W3IWI N4QQ KA3DXX WA7NTF KA3RFE
This bulletin is being re-sent at the request of several people:
"GARBAGE CHARACTERS"
You may see some very strange-looking characters flitting across your
moniter's screen from time-to-time. Those funny-looking things are
symbols for binary data being transmitted. There are several sources
which use binary data instead of text. Net/Rom nodes use binary data
in their nodes broadcasts. The purpose of the node broadcasts are
to inform other nodes within range what nodes they can connect to.
The data is binary for reasons of accuracy.

Another source of garbage characters is binary file transfers from a
BBS to a user. These transfers are generally executable programs which
the BBS might have stored for downloading by users. These differ from
text files in that the binary code contains control characters and
computer programming commands which cant be sent as text files.

A third source of garbage characters is tcp/ip packets being sent
between two stations using that protocol to exchange files or mail.
Tcp/ip is a protocol which has several different layers to it and
can be used to interface with some of the major computer networks
such as those used by colleges and government computers.

So, if you see funny-looking symbols on your monitor, dont panic, its
just binary traffic going by.

              73, Pete KA3RFE @ KA3RFE BBS


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

Date: Sat, 26 Jan 91 22:44:10 CST
From: [e-mail] (Paul W. Schleck KD3FU)
Subject: Attn. New Packeteers, Part 3/7
To: [e-mail]

Reply-to: [e-mail]

MSG # TR  SIZE TO     FROM   @BBS   DATE    TITLE
 4766 B#  3742 ALL    KA3RFE MDCBBS 910108 ATT: New Packeteers pt 3
Forwarding path: W3IWI KA4USE N4QQ N2GTE KA3RFE
SENDING MAIL/BULLETINS

Most BBS programs use the same commands to send mail and bulletins. One
of the most common mistakes in sending messages of any type is the
confusion between what is mail, and what is a bulletin. The issue gets
further confusing when trying to determine how to send a bulletin meant
for all BBSs is a given bulletin distribution scheme.

Generally, there are three commands for sending mail and bulletins:
A) S.....Most BBS programs treat the S command as a command to send a
      PRIVATE message. For instance: entering S KA3RFE will send a
      private message to KA3RFE...but only on the BBS you enter the
      message on. If KA3RFE does not use the BBS you are entering the
      message on, the BBS program will try to forward the message to
      KA3RFE...but ONLY if that BBS has KA3RFE listed in its forwarding
      file.

      If  you try to send a bulletin using S alone, the BBS will still
      treat that message as a private message. So, entering a bulletin
      using "S ALL @ MDCBBS $" will result in a private message to
      NOBODY at MDCBBS except for SYSOPS, because a private message
      to "ALL" could only be read by sysops or a ham who's callsign
      is "all". Since "all" is not a legal callsign, nobody else can
      read the message

      Did you notice the "$" in the example above? To send a bulletin
      out to other BBSs, the address has to include the $. This tells
      the BBS that the bulletin should be forwarded out to other BBSs.
      So, you must include that $ if you want the bulletin to be sent
      to other BBSs.

B) SP......The SP command means "Send Private". This tells the BBS that
       the message you are sending is "eyes only" for the addresssee.
       The sysop will be able to read that message but no one else
       will be able to read it. This is the same command as the
       plain S command. To avoid confusion, you should always send
       your private messages to another ham using the SP.

C)  SB.....This command means "Send a Bulletin". There are two types of
       bulletins you might send. One type would be only for users of
       the same BBS you are entering the bulletin on. If you were
       connected to KA3RFE BBS and you sent a bulletin reading
       "SB ALL", the BBS will treat it like a local bulletin and
       it will only stay on KA#RFE. If you sent a bulletin titled
       "SB ALL @ MDCBBS" the bulletin will still be considered a
        local bulletin on KA3RFE. Why????? To send a bulletin
        which you want forwarded to  "ALL @ MDCBBS" you have to
        tell the BBS you want it forwarded.....THATS WHAT THE
        "$" IS FOR. So, if you want your bulletin sent to every
        BBS which accpets the MDCBBS distribution scheme, you have
        to add that $. The correct way is "SB ALL @ MDCBBS $".

So, to sum up....use S and SP for PRIVATE messages. ("Mail"), and
SB for BULLETINS. Dont forget the "$" in the address if you want
your bulletin to get forwarded.

Try it out! Send me a private message to KA3RFE @ KA3RFE.md.usa. If it
gets here, I'll send you a reply.

                73, Pete KA3RFE sysop KA3RFE BBS


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

Date: Sat, 26 Jan 91 22:45:11 CST
From: [e-mail] (Paul W. Schleck KD3FU)
Subject: Attn. New Packeteers, Part 4/7
To: [e-mail]

Reply-to: [e-mail]

MSG # TR  SIZE TO     FROM   @BBS   DATE    TITLE
 4894 B#  1594 ALL    KA3RFE USA    910113 Att: New Packeteers pt 4
Forwarding path: W3IWI W3ZH N4QQ N2GTE WB3V KA3RFE
In Part 3 I stated that a dollar-sign symbol must be appended to
any bulletin which you want to have forwarded out from the BBS
you entered it on.

I've gotten information that entering the dollar sign is not
required on CBBS and RLI bbs systems for the forwarding-out to
take place. At this point, to the best of my knowledge, the
dollar sign is required on MBL, MSYS, and REBBS systems. There
are other systems which may not require the dollar sign.

Your best course of action is to ask your sysop if you need to append
the dollar sign to your bulletins for them to be forwarded-out.

Those of you who are sysops: I want to make this series helpful, so
correct me if I dont have it correct! I dont know how BQE's system
handles bulletins, nor FISBBS, and maybe I'm wrong with MSYS and
AA4RE...(I ran both MSYS and AA4RE, but I've forgetton and dont have
the docs any more...getting senile...)

The dollar-sign IS required for the WA7MBL bbs and with another
BBS system being beta-tested in Anne Arundel County MD called
"GTEPMS".

Part 5 will deal somewhat with tnc settings....look for it soon!

              73, Pete KA3RFE @ KA3RFE.md.usa


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

Date: Sat, 26 Jan 91 22:46:29 CST
From: [e-mail] (Paul W. Schleck KD3FU)
Subject: Attn. New Packeteers, Part 5/7
To: [e-mail]

Reply-to: [e-mail]

MSG # TR  SIZE TO     FROM   @BBS   DATE    TITLE
 4968 B#  3405 ALL    KA3RFE MDCBBS 910114 Att: New Packeteers pt 5
Forwarding path: W3IWI WA3ZNW NB3P KA3RFE
SETTINGS:

Nothing generates more frustration than trying to set up a tnc to operate
effectively when you dont understand the language. This is a short run-
through of the more important parameters which enable your tnc to work
properly with minimum hassle.

FRACK:     FRACK is short for FRame ACKnowledge. It is the timer which
       tells the tnc how long to wait for an acknowledge frame from
       the other station before re-sending a frame. Typically, tncs
       come with a default value of 4, which is adequate. However,
       if you are operating on a very busy channel, you may want to
       increase FRACK to 6, or even 8. A short FRACK value can lead
       to retrying-out, so dont set it below 4 or so.

RETRY      RETRY tells the tnc how many times to keep sending a packet
       that does not get ACK'ed by the other station. This usually
       defaults to 10 from the factory. After the 10th retry, the
       tnc "times out" and the connection is broken. A value of
       10 is just fine. Some people say a shorter value is better
       but 10 will do. If you set your tnc retry value to 0, the
       tnc will NEVER time-out! This is NOT a good idea!

DWAIT      DWAIT enters a pause in-between transmitted packets to let
       digipeaters to transmit first. This is usuallly set by local
       agreement. Ask around to find out what your DWAIT should be.

TXDELAY    This determines how soon the packet will be transmitted after
       the tnc keys the radio. The purpose of TXDEAY is to insure
       that the first few parts of the packet dont get chopped off
       by a slow-keying transmitter. You will have to set this
       based on what sort of transmitter you are using. Good
       values range from around 30 to 50. Longer TXDELAY values
       just take up air time.

       You can figure that TXDELAY works the same way that you
       do on voice....you wait a second or so after keying the
       mic before you start talking....well, thats TXDELAY!

There are more settings which control your tnc, but the above are the
ones that make the difference. There are also two settings for your
RADIO which are important:

DEVIATION: W3IWI reccomends a deviation of no more than 3 percent for
       optimum packet operation. A too-wide deviation will reult
       in lots of retries and timing-outs.

VOLUME:    Your volume-control is the most important setting on your
       radio insofar as receiving packets is concerned. If you
       have the volume too loud, the tnc will not be able to
       decode the packets, and, of course, if the volume it soo
       low, the tnc wont hear the packets. The best method of
       setting your volume control is to open your squelch and
       increase your volume control until you see the DCD light
       on the tnc come on. That's your setting.

                  73, Pete KA3RFE @ KA3RFE


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

Date: Sat, 26 Jan 91 22:50:32 CST
From: [e-mail] (Paul W. Schleck KD3FU)
Subject: Attn. New Packeteers, Part 6/7
To: [e-mail]

Reply-to: [e-mail]

MSG # TR  SIZE TO     FROM   @BBS   DATE    TITLE
 5029 B#  4630 ALL    KA3RFE MDCBBS 910116 Att: New Packeteers Pt 6
Forwarding path: W3IWI KA4USE N4QQ WA3ZNW NB3P KA3RFE
SETTINGS CONTINUED

There are two more setting which you must consider when setting up your
tnc. These settings have much to do with how well your RETRY rate is.

PACLEN:     PACLEN is short for PACket LENgth. It tells the tnc how many
        letters, numbers, and spaces should make up the length of the
        packet your tnc sends out. Most people use a PACLEN of 128
        characters, which is ok under most circumstances, I suppose,
        but that depends highly upon how good the path is between
        stations, how crowded the channel is, and a couple other
        factors. On my BBS and node ports here, I use a PACLEN
        of 80 on my UHF port (when its operating....) as I dont have
        all that great of a path to the more distance stations, while
        my 2 meter port has a PACLEN of 180 and my 220 port runs a
        PACLEN of 120. The differences are due to channel loading,
        distance, and radio/antenna performance factors.

BY THE WAY: PACLEN is NOT a substitute for inserting carriage returns in
your transmitted signals. All PACLEN does is tell the tnc to transmit a
packet after X number of characters have been inputted. If you make up a
 long message on a word processor and dont insert any carriage returns in
the text, the message will scroll right off the screen of anyone trying to
read the message! I am inserting carriage returns as I type this message. If
I didn't, you wouldnt be able to read the bulletin! I put my carriage returns
at the end of each line I type. When this bulletin gets forwarded out, the
PACLEN setting will send X characters out, carriage return and all, and the
finished product when you read it, will be exactly as I typed it.

MAXFRAME:    This is the last setting you need to worry about right now.
         MAXFRAME works with PACLEN to determine how much information
         your tnc will send out at any one time and will consult with
         RETRY to give you the bottom-line total thruput. (Thruput?
         ....all thruput means is how fast the job it getting done...
         when packets are just zipping along and being acked real
         fast, that's high thruput...)

         MAXFRAME means how many packets you want to have out un-
         acknowledged before more packets are sent. On a nice
         quiet channel where you are in within spittin distance
         of the station you are communicating with, MAXFRAME can
         be as high as 4 or 5. However, hardly anyone is on a nice
         quiet channel, so your MAXFRAME setting has to be set to
         reflect conditions. If the channel is real crowded and
         noisy, or if you time-out a lot with a high MAXFRAME, you
         might want to consider setting a MAXFRAME of only 1 or 2.

         On my UHF port, the channel is both busy and I have a poor-
          to-fair path to most of the stations I connect to. So, I
          set a MAXFRAME of 1. On my 2 meter and 220 ports, I set
          MAXFRAME to 2.  I probably could get away with a setting
          of 4 on 2 meters and 220, but the channels are busy.

A NOTE ON THE "$" IN SENDING BULLETINS

I've heard from many sysops and two BBS software authors on the use of
the dollar sign in sending bulletins which are to be forwarded out from
the BBS you're entering it on. The info is being passed on here, somewhat
modified to reflect the possibility that you may not know which sort of
system you are using.....

The WA7MBL BBS requires that you send bulletins to be forwarded out in
this manner:
         SB ALL @(USA, etc) $
Other BBS systems dont require it, but if you are not sure which type of
BBS you are using, you can enter the $ with no harm done. In fact, it
may be a good idea to use the $ anyhow. It wont hurt, and wont make
any difference if the BBS does not need it.

(Thanks to all you sysops who sent me the info I needed to clear that up,
and a special "thank you" to the two BBS software authors who were kind
enough to respond.)

              73, Pete KA3RFE @ KA3RFE BBS



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

Date: Sat, 26 Jan 91 22:51:41 CST
From: [e-mail] (Paul W. Schleck KD3FU)
Subject: Attn. New Packeteers, Part 7/7
To: [e-mail]

Reply-to: [e-mail]

MSG # TR  SIZE TO     FROM   @BBS   DATE    TITLE
 5026 B#  2411 ALL    KA3RFE MDCBBS 910116 Att: New Packeteers, pt 7
Forwarding path: W3IWI KA3T WA3ZNW NB3P KA3RFE
THE DIFFERENCE BETWEEN MAIL AND FILES

When you log onto a full-service BBS, there are two separate things you
can get into: Mail and Files. Some people get confused about what the
two of them are. I know I did when I first got on packet. I thought a
file was a file, whether it was a file or whether it was that long list
of messages you get when you enter an "L" command.

Well, as I found out, they aint the same animal.

When a BBS refers to a "file", it's talking about a separate entry which
is being stored apart from "mail".

I guess I better define "mail" before I get into "files"....its easier.

"Mail" means messages from one ham to another, or bulletins which the
BBS has open. If ham A sends ham B a message, that's "mail". If a ham
sends a message to be read by many people, that's called a "bulletin"
but the BBS still calls it "mail".

A "file" is not mail, nor is it a bulletin; although some bulletins might
be converted to files by the sysop. A file is a permanent part of a BBS.
The file might contain text, or it might be a binary file. (WHAT? I
THOUGHT EVERYTHING IN PACKET WAS BINARY!) Not to worry...everything
packet-ized is binary, but there is a difference in how the information
is kept in the BBS.

Binary files are those which are actually executable programs which can
be downloaded from the BBS. These files require that you have a compatible
binary file downloading program in order to get them from the BBS.

Text files are those which are plain text and you can download them without
needing any sort of special file downloading program. In most BBSs you
can get into a text file area in which the documentation is kept with
all the commands used by the BBS.

So, MAIL is stuff from ham A to ham B, bulletins are from ham A to
a selected audience, but still MAIL. FILES are the more permanent
information on a BBS and come in two flavors: text and binary.
Text files are sent in simple plain old English, while binary files
look like the BBS has got the runs.

              73, Pete KA3RFE @ KA3RFE BBS



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

Date: 26 Jan 91 16:25:17 GMT
From: VAX1.CC.UAKRON.EDU!mcs.kent.edu!usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: Determining IP hosts in your (geograhical) area
To: [e-mail]

As quoted from <[e-mail]> by [e-mail] (Eric Peterson):
+---------------
|       Would it be reasonable to implement something akin to "rwho"
|       broadcasts so a host could determine other hosts that are out
|       there, or even better: a "route" broadcast that would list
|       all the hosts a particular host/gateway could talk to (even
|       "transparently" gatewayed via ax25 or "wormholes"), and a
|       "preference" value for each of those hosts.
+---------------

Sufficiently recent versions of NOS have this, in the form of "rip" and "rspf"
protocols.  "rspf" is the most useful; your node gets routing from RSPF
Routing Update packets, and other nodes find out about yours from its RSPF RRH
packets.  There are various mechanisms to verify connections, like an
automatic ping of hosts that are about to expire from the routing table.
However, not everyone runs recent NOS, because many NOS versions tend to be
rather unstable (read: crash and burn).

Also, especially in "crowded" areas, TCP/IP is generally not found on the
standard packet frequencies.

Your best bet is to talk to the "local" (usually, state) IP coordinator.
He can usually point you to any local TCP/IP operators.

++Brandon
--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

End of Packet-Radio Digest
******************************
Date: Mon, 28 Jan 91 04:30:02 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #27
To: packet-radio


Packet-Radio Digest         Mon, 28 Jan 91       Volume 91 : Issue  27

Today's Topics:
       Determining IP hosts in your (geograhical) area
           ka9q NOS on an AT&T 3b1 unix-pc
               mail problem MSYS vs NOS
                  msys help
          PACKET->Internet Gateway (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

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

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 27 Jan 91 13:15:38 GMT
From: timbuk!cs.umn.edu!kksys!edgar!brainiac![e-mail]  (Jeffrey Comstock)
Subject: Determining IP hosts in your (geograhical) area
To: [e-mail]

In article <[e-mail]> [e-mail] (Eric Peterson) writes:
>
>       In my area there seem to be a reasonable amount of hosts runnning
>       "standard" (ie. ax25) packet, but very few (if any) running TCP/IP
>
>  Eric wants to know a way to figure out where the IP traffic is...
>
>

Here are a couple of ways that might work:

1) The MSYS bbs has a command J T, which will display all TCP/IP stations
   it has heard.  MSYS is pretty popular, you can probably find some in
   your area. Note that MSYS will handle TCP/IP, SMTP, FTP and you can
   telnet to the sysop.

2) Connect to a NETROM node, and issue the 'n *' command.  Alot of IP
   stations will have the characters IP as their alias, at least in
   this area.  For example:
   IPD:NR0D-9  IPMPLS:G1XRL  IPTOSH:G4JEC-9  #IPBUU:N0BUU-9

3) Snatch the AMPR.ORG database from uscd.edu .  You might recognize
   some callsigns.

Hope this helps...

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

Date: 27 Jan 91 15:29:22 GMT
From: att!mcdchg!ddsw1!proxima![e-mail]  (Lucio de Re)
Subject: ka9q NOS on an AT&T 3b1 unix-pc
To: [e-mail]

In article <[e-mail]> [e-mail] (Jim Mercer) writes:
>would anyone who has ka9q NOS (or hyprids thereof) running under unix (sysV)
>please email me?

and me (if available for the 3b1, of course), pretty please!

Lucio de Re.

[e-mail]
...!uunet!ddsw1!proxima!lucio

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

Date: 27 Jan 91 00:40:17 GMT
From: zaphod.mps.ohio-state.edu!samsung!umich!sharkey!bnlux0!bnlls1.nsls.bnl.gov![e-mail]  (Bob Foxworth)
Subject: mail problem MSYS vs NOS
To: [e-mail]

Begin forwarded message from kc2fd:
---------------

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

Date: Sat Jan 26 22:44:49 1991
From: KC2FD in [Coram, NY] 11727
Subject: msys help
To: K2EUH

Could you put a msg out on the internet about a problem with msys version
1.10?  The problem is that mail will not forward to an IP station if
it is left on or forwarded to the msys bbs by another station (other
than the sysop).   If the sysop leaves mail, it forwards fine.  AX.25
outgoing mail is not affected.  Have asked the author (wa8bxn) for help
but have not received a reply yet.

BTW, there is still an incompatibility between NOS and Msys with
ax.25 forwarding into the NOS mailbox.  NOS does not seem to send a
line feed (or CR?) after the "Subject:" prompt and the msys station
just sits and waits for the LF which never comes.  Result - msys
just hangs up and does nothing until the sysop aborts forwarding.
MBL and RLI forward OK into NOS however MSYS forwards just fine
into NET.  It's a standoff and sounds like the NOS guys are pointing
the finger at BXN and BXN is pointing the finger at NOS.  Any help?

I'd like to know if any other MSYS sysops or users are experiencing
these problems.  Thanks  Rick kc2fd @kc2fd.ny

---end forwarded message---

You may post any replies here on this group. I will circulate them to
Rick and the other guys on the local LAN.
73 Bob k2euh

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

Date: 27 Jan 91 15:25:49 GMT
From: magnus.ircc.ohio-state.edu!zaphod.mps.ohio-state.edu!caen!ox.com!b-tech![e-mail]  (Jon Zeeff)
Subject: PACKET->Internet Gateway
To: [e-mail]

>But *where* are you going to "add" things in an IP packet that *each*
>destination machine doesn't have to know about?  I can see your scheme

This is for net 44 sites piggybacking on the internet.

You add a complete additional ip header at the gateway and strip it at the
other gateway.  Destination machines see only 100% normal ip packets.

Someone pointed out that loose source routing should be able to do this
already.

>working if it only concerns using the existing Internet to interconnect
>net 44, but I also see BIG problems in using that scheme and trying to
>'talk' from net 44 to the rest of the Internet.  What's the functionality
>desired?

The suggestion was only a way to do the former.  There are no problems
with the rest of the internet, the gateway would not do any
encapsulation when sending a packet to the rest of the internet.

The problems with routing from random internet sites to net 44 sites
is independant of this.

If I (a net 44 site) initiate a connection with site foo.com, is there
any way to tell it to use loose source routing to my gateway bar.com
(and then to me, 44.xx.xx.xx) to get packets back to me?  Can this be
done securely?

--
Jon Zeeff (NIC handle JZ)        [e-mail]

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

Date: 27 Jan 91 16:19:47 GMT
From: zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!helios![e-mail]  (Willis Marti)
Subject: PACKET->Internet Gateway
To: [e-mail]

In article <#[e-mail]> [e-mail] (Jon Zeeff) writes:

{stuff deleted}
>
>The suggestion was only a way to do the former.  There are no problems
>with the rest of the internet, the gateway would not do any
>encapsulation when sending a packet to the rest of the internet.
>
>The problems with routing from random internet sites to net 44 sites
>is independant of this.
So I think we have gateways that "know" other gateways to net 44 (this would
have to be independent of the current gateway protocols, but could be done).
Any packet w/ DST=44.x.y.z gets encapsulated & sent to an appropriate
gateway; all other packets get sent via normal routing mechanisms.  And now
we get to the hard part:
Somehow we have to be able to hndle traffic to/from 'random' internet sites.
>
>If I (a net 44 site) initiate a connection with site foo.com, is there
>any way to tell it to use loose source routing to my gateway bar.com
>(and then to me, 44.xx.xx.xx) to get packets back to me?  Can this be
>done securely?
RFC 1122 (Host Requirements) says the IP implementations MUST be able to
generate Source Routing (btw, i think you want strict vs loose) and fwd
packets according to it. And TCP implementations MUST retain a source route
for a session and use that route in replies.
So, in theory the problem is solved -- except for two minor details:
(1) How do you propose to generate that source route in the first place; it's
possible, but not readily automated, nor robust {Hmmm. Might be able to see
a way ->gateways that ping non-44 destinations w/ record route; too bad that's
not a MUST implementation);
(2) How many hosts are RFC1122 compliant?  {Phil, does NOS support it? Or
should I check the code...} Anybody know of a TELNET that lets you specify a
source route?
--
Jon has suggested the *possibility* of some work-arounds; is there anyone out
here that wants to try (besides me) these or try finding another way?

Willis Marti
>
>--
>Jon Zeeff (NIC handle JZ)       [e-mail]

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

End of Packet-Radio Digest
******************************
Date: Tue, 29 Jan 91 04:30:05 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #28
To: packet-radio


Packet-Radio Digest         Tue, 29 Jan 91       Volume 91 : Issue  28

Today's Topics:
                bootp for ka9q
              doc of ax25 needed
              Help! What is it?
           ka9q NOS on an AT&T 3b1 unix-pc
           Omni vs beam antennas. (3 msgs)
          PACKET->Internet Gateway (3 msgs)
                 PK232 vs KAM

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 28 Jan 91 23:56:14 MET
From: "Vincenzo G. Capuano" <[e-mail]>
Subject: bootp for ka9q
To: Packet Radio <[e-mail]>

Is it available a bootp server for net.exe ?

Thanks,
=-=-=-=
Vincenzo G. Capuano                     E-mail: [e-mail]
Via Dante Alighieri, 9                          [e-mail]
57036 Porto Azzurro (LI)
Italy

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

Date: 27 Jan 91 15:41:54 GMT
From: sdd.hp.com!samsung!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: doc of ax25 needed
To: [e-mail]

In article <[e-mail]> [e-mail] (Gabriel Perez) writes:
>Hi,
>   I would like to know where I can get a technical description of the ax25
>protocol. Thank you very much in advance.

The ARRL publishes a book titled "AX25 Link Layer Protocol" that is the
official formal description of the protocol. $8 member price from the
League or your better ham bookstores.

Gary KE4ZV

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

Date: 28 Jan 91 15:46:21 GMT
From: s.ms.uky.edu![e-mail]  (Peach)
Subject: Help! What is it?
To: [e-mail]

I have discovered a packet radio signal, locally, on 412.875 MHz.
While it is not in the ham band, it sounds very similar to 1200
baud packet.

The preamble or flag is higher pitched than 1200 baud ham packet.
To the ear, the preamble sounds like a 2400 Hz tone.  The data
burst sounds like 1200 baud.

I have tried to decode this signal using my KPC-2 with PASSAll set
to on and using all possible combinations of the CCITT, HF, and HFTones
commands.  I was not successful.

We tried looking at the signal here at work using a 'scope, but
the bursts are too short to do much with.

Any comments or suggestions would be appreciated!

73, Harold
------------
Harold Peach
Ag Data Center
University of Kentucky
[e-mail]

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

Date: 28 Jan 91 18:16:48 GMT
From: agate!shelby!bu.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
Subject: ka9q NOS on an AT&T 3b1 unix-pc
To: [e-mail]

In article <[e-mail]>, [e-mail] (Lucio de Re) writes:
>
> and me (if available for the 3b1, of course), pretty please!
>

There is a version of NET (older than NOS) available from OSU.
It works well, I have had it running here for a couple of months now
with out a problem.  I also was abel to get it to run on an ATT 3B2 and
a SUN without any real problems.

I am currently working on getting a current version of NOS to work.  I
need the routing and all.  I will make it available as soon as I have
something reasonably stable.

bill    KB3YV



--

     Bill Gunshannon          |        If this statement wasn't here,
     [e-mail]   |  This space would be left intentionally blank

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

Date: Mon, 28 Jan 91 17:04:40 GMT
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: Omni vs beam antennas.
To: [e-mail]

Hi. I recently had a 'discussion' with another packeteer as to whether
it was better to use omni-directional antennas or beams for accessing
BBS's and the like. He argued that using beams results in less mutual
interference; i argued that the CSMA model ceases to work if there are
nodes that cannot hear each other yet can interfere with each others
working.
This discussion got quite 'inflamed';  What say you good people? Theres
an evening of free drinks (for me!) in the balance here.

       Pete Lucas [e-mail]  [e-mail]

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

Date: 28 Jan 91 19:46:47 GMT
From: deccrl!news.crl.dec.com!shlump.nac.dec.com![e-mail]  (Paul Koning)
Subject: Omni vs beam antennas.
To: [e-mail]

|>Hi. I recently had a 'discussion' with another packeteer as to whether
|>it was better to use omni-directional antennas or beams for accessing
|>BBS's and the like. He argued that using beams results in less mutual
|>interference; i argued that the CSMA model ceases to work if there are
|>nodes that cannot hear each other yet can interfere with each others
|>working.

Sure, CSMA requires/assumes you hear the other participants.  That's why
packet radio only faintly (at best) resembles CSMA: often you can't hear
other participants, and/or you hear non-participants.  The use of beams
aggrevates the former problem, while helping the latter.  Which one is the
bigger effect is likely to vary.

To put it bluntly, how much MORE broken could it get when you use beams?
Or when you don't, for that matter?

    paul

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

Date: 28 Jan 91 22:33:38 GMT
From: mejac!orchard.la.locus.com!fafnir.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Omni vs beam antennas.
To: [e-mail]

In article <28.Jan.91.17:05:26.GMT.#[e-mail]> [e-mail] ("Pete Lucas, NCS-TLC, Holbrook House, Swindon") writes:
>Hi. I recently had a 'discussion' with another packeteer as to whether
>it was better to use omni-directional antennas or beams for accessing
>BBS's and the like. He argued that using beams results in less mutual
>interference; i argued that the CSMA model ceases to work if there are
>nodes that cannot hear each other yet can interfere with each others
>working.

   If one really had a toplogy where the CSMA model actually worked
(a very unusual situation in packet radio), then the use of directional
antennae would reduce the overall efficiency of the topology.

  Since most packet radio topologies are poorly interconnected, I suspect
the CSMA model works poorly anyway, and the use of directional antennae
would not hurt very much.

   If a topology was in use where a central node was serving a number
of remotely located nodes, and these nodes could not hear each other
anyway, and the remote nodes have poor signals into the central node, then
using beams at the remote nodes would probably make sense, though the
efficiency of this topology would never be as good as a completely
interconnected topology.

>This discussion got quite 'inflamed';  What say you good people? Theres
>an evening of free drinks (for me!) in the balance here.

   Goodness, Pete, a discussion that you were in became inflamed? Musta
been the other guy :-) :-)

   I'd say you two get pissed trading rounds like normal over this.

Dana

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

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

Date: 28 Jan 91 13:36:19 GMT
From: zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
Subject: PACKET->Internet Gateway
To: [e-mail]

The idea of using Source Routing and the INTERNET to "connect" all of Net 44
is a very interesting concept.  But it doesn't solve the real problem.  There
are still going to be parts of Net 44 that are no/can not be connected.  Unless
someone can foresee a time (in the near future?) when this will not be the
case, then I still feel that moving in that direction is pointless if you are
looking at towards a time when we will take our rightful place on the INTERNET
with all the other people who are currently doing networking research.  I also
believe this was the intent of the early developers of AMPR.  If not, why did
they bother to get a legitimate IP Address block in the first place.  I just
think we have learned enough by this point that we should admit the short-
comings of the system and work towards correcting them.

bill    KB3YV

--

     Bill Gunshannon          |        If this statement wasn't here,
     [e-mail]   |  This space would be left intentionally blank

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

Date: 28 Jan 91 19:11:59 GMT
From: sdd.hp.com!caen!ox.com!b-tech![e-mail]  (Jon Zeeff)
Subject: PACKET->Internet Gateway
To: [e-mail]

>>If I (a net 44 site) initiate a connection with site foo.com, is there
>>any way to tell it to use loose source routing to my gateway bar.com
>>(and then to me, 44.xx.xx.xx) to get packets back to me?  Can this be
>>done securely?
>RFC 1122 (Host Requirements) says the IP implementations MUST be able to
>generate Source Routing (btw, i think you want strict vs loose) and fwd
>packets according to it. And TCP implementations MUST retain a source route
>for a session and use that route in replies.
>So, in theory the problem is solved -- except for two minor details:
>(1) How do you propose to generate that source route in the first place; it's
>possible, but not readily automated, nor robust {Hmmm. Might be able to see
>a way ->gateways that ping non-44 destinations w/ record route; too bad that's
>not a MUST implementation);
>(2) How many hosts are RFC1122 compliant?  {Phil, does NOS support it? Or
>should I check the code...} Anybody know of a TELNET that lets you specify a
>source route?

Sounds good, if it works this way and if ka9q supports the generation
of source routes, then you (being 44.x.y.z) should be able to specify
that traffic should travel 44.x.y.z->gateway->destination and then the
destination should reverse the route to get back to you.  Everything
works fine.

For a 44.x.x.x->gatewayA->gatewayB->44.y.y.y situation, 44.x.x.x does
need to know (somehow) that 44.y.y.y should be reached via gatewayB.

That leaves the problem of internet sites that don't know how to reach
44. sites initiating connections but I'm not as interested in that
(because of the problems with non hams broadcasting).

Source routes could be very useful for other things if it is in NOS ka9q.

I believe you want loose source routing used.  You don't care how gatewayA
gets to gatewayB, just that it does.

Any comments from the networking wizards?

--
Jon Zeeff (NIC handle JZ)        [e-mail]

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

Date: 29 Jan 91 00:32:56 GMT
From: epic![e-mail]  (Phil R. Karn)
Subject: PACKET->Internet Gateway
To: [e-mail]

My code supports source routing in that it will obey IP source route
options in incoming packets. There is, however, currently no "hook" to
allow the local user to specify the source route at the transport or
application layer.

If there is sufficient interest I could add a facility to specify IP
source routes. It would probably work similarly to the way AX.25
source routing is already implemented.

Phil

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

Date: 28 Jan 91 21:07:31 GMT
From: netnews.upenn.edu!eniac.seas.upenn.edu![e-mail]  (Jeff DePolo)
Subject: PK232 vs KAM
To: [e-mail]

Our school ARC will be getting an all-mode TNC next semester, and I'm
having a hard time deciding between the KAM and PK232.  Any pros and
cons from those who know?

                                --- 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: Wed, 30 Jan 91 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #29
To: packet-radio


Packet-Radio Digest         Wed, 30 Jan 91       Volume 91 : Issue  29

Today's Topics:
       Determining IP hosts in your (geograhical) area
              Help! What is it?
             ka9q source code for Mac (?)
           Omni vs beam antennas. (2 msgs)
               PACKET->Internet Gateway
           Problem with NET and another TSR
             Quo Vadis? (3 msgs)
         Summary - how to put home PC on the internet

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 29 Jan 91 02:43:45 GMT
From: usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: Determining IP hosts in your (geograhical) area
To: [e-mail]

As quoted from <[e-mail]> by [e-mail] (Jeffrey Comstock):
+---------------
| 2) Connect to a NETROM node, and issue the 'n *' command.  Alot of IP
|    stations will have the characters IP as their alias, at least in
|    this area.  For example:
|    IPD:NR0D-9  IPMPLS:G1XRL  IPTOSH:G4JEC-9  #IPBUU:N0BUU-9
+---------------

Another common trick is to use the hex representation of the IP address, minus
the "44" prefix (which is a given).  Thus, my node is 460458 (= [44.]70.4.88).
Private nodes sometimes use only the last two, since they're unlikely to cross
state lines:  local IP'er N8MPX's node was #0452 for a few months.

++Brandon
--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

Date: 29 Jan 91 17:00:03 GMT
From: idacrd![e-mail]  (Robert McGwier)
Subject: Help! What is it?
To: [e-mail]



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

Date: 30 Jan 91 03:40:21 GMT
From: usc!zaphod.mps.ohio-state.edu!caen!ox.com!umich!terminator![e-mail]  (Shadow)
Subject: ka9q source code for Mac (?)
To: [e-mail]

Greetings all,
   I am currently in the process of learning C and porting ka9q over to the
Macintosh...(quite a first-time project, eh?) Well, I'm using LightSpeed C
from Symantic and it seems that the debugger keeps flipping out when I try to
compile the code into an application.
   What I really need is the source code that someone is using or has actually
used to compile ka9q to the Mac.  I'd like to get the Mac version up to what
the IBM-ers have: NOS.
   Does anyone have this that they would like to share with me?  There are a
lot of changes I'd like see done to the Mac version.  I'm no new puppy to Mac
programming - just C.


Thanks in advance!

Shadow


      /____________________________________________________________/
    /____________________________/                               /
/
    /William D. Burns            / InterNet:                     /
   / (906) 482-FIXX             /   [e-mail]   /
  /____________________________/   Bitnet:                     /
 /  Michigan Tech University       WDBURNS%MTUS5.BITNET       /
/____________________________________________________________/
"On daze like this, in times like these...I feel an animal deep inside..."
                             -Sisters of Mercy

------ Posted using NetFeed, THE Macintosh <====> UseNet Interface Program ----

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

Date: 29 Jan 91 17:07:59 GMT
From: [e-mail]  (David Engle)
Subject: Omni vs beam antennas.
To: [e-mail]

>Hi. I recently had a 'discussion' with another packeteer as to whether
>it was better to use omni-directional antennas or beams for accessing
>BBS's and the like. He argued that using beams results in less mutual
>interference; i argued that the CSMA model ceases to work if there are
>nodes that cannot hear each other yet can interfere with each others
>working.
>
While not I am not sure what exactly the theory says for each case of
a "hidden" transmitter, I can relate some of my experiences (Which tend
to support the omni approach).

First, the situation; in the greater south San Francisco bay area there is
a (several actually) DX spotting net on a two meter frequency.  There are
usually 15 users connected to the announcing node.  My antenna can "see"
the central node antenna (on a clear day) directly.  My guess is that
I have good connectivity to about 50% of the other users.  I was using an
omni antenna and running about 10 watts.  Signals at both ends were full
scale on the s-meters.  The central node runs 25 watts.

When the quantity of users went over ~20, I would get dropped off the
node by my controller for re-try time out (i.e., my TNC tried to reply
to a message N times and failed to do so, my TNC thinking the node went
away dropped the connection).

I tried putting up a relatively short beam aimed at the central node.  My
acks from central seemed (not measured!) to come quicker when the system
was lightly loaded (i.e., less than ~15 users).  However, when the user
community went to more than ~20 users, I was dropped more frequently.
Following the normal way of trouble shooting, I got a bigger hammer.
I got an amplifier and used that with the beam.  I did not notice any
significant difference in my drop out rate with the amplifier.

Next I put up an omni gain antenna, outside, higher and in the clear.
I disconnected the amplifier and ran just this configuration for a
while.  This configuration stayed connected longer (when a greater quantity
of users came on) that that of the beam.  I now found I would get dropped
only when the user community went to more than ~22 users.

Next I rolled out the bigger hammer again.  Presto, I now stay connected
substantially longer that ever before (even up to ~25 users).  Reflection
shows that my station needed to heard by others to keep from being
collided with, rather than just having the loudest signal at the central
node.  This is just what the theory says, nice huh?

I found the answer to keeping connected in the face of an "overloaded"
system to be going to more power with the omni gain antenna.  The beam
was definitely a detraction in my situation.  Now, if a station were in
a "hole" and truly isolated from the rest of the community, this
would probably not be the optimum situation.

Hope this gets you a beer.

Regards, Dave KE6ZE
--
David Engle, KE6ZE - [e-mail] - 408/473-4419 @ work
Facts, what facts?  I don't got to show you no stinking facts.
These are opinions expressed here.

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

Date: 29 Jan 91 16:34:28 GMT
From: mcsun!ukc!axion!uzi-9mm.fulcrum.bt.co.uk!beta.its.bt.co.uk![e-mail]  (John Trickey)
Subject: Omni vs beam antennas.
To: [e-mail]

In article <28.Jan.91.17:05:26.GMT.#[e-mail]> [e-mail] ("Pete Lucas, NCS-TLC, Holbrook House, Swindon") writes:
>Hi. I recently had a 'discussion' with another packeteer as to whether
>it was better to use omni-directional antennas or beams for accessing
>BBS's and the like. He argued that using beams results in less mutual
>interference; i argued that the CSMA model ceases to work if there are
>nodes that cannot hear each other yet can interfere with each others
>working.

The problem of hearing is true whether omni or a beam is in use.
As in **all** communications the more signal you can direct to the
recipient or the more you can hear from the sender the better it
is for you.  However that advantage is gained at the expense of
the other stations on the channel.

The big problem with packet is that all the stations are on one
channel & not organised, as they should be, on a cellular principle.
The result is I can hear stations over 100 miles away but I cannot
work my local BBS!!

My local node is on the top of next hill to me instead of where it should
be, in the valley.  Trunking *only* should be on hill tops & should
not have user access, perhaps then we may have a workable system.

>This discussion got quite 'inflamed';  What say you good people? Theres
>an evening of free drinks (for me!) in the balance here.

Don't know bout the drinks, but should keep the arguement going. 8-)
73.
--
John Trickey <[e-mail]> || ..!mcsun!ukc!axion!its
          G4REV @ GB7SUT      Voice: [phone]
#include <std/disclaimer>

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

Date: 29 Jan 91 14:17:31 GMT
From: pacific.mps.ohio-state.edu!linac!uwm.edu!spool2.mu.edu!sdd.hp.com!caen!ox.com!b-tech![e-mail]  (Jon Zeeff)
Subject: PACKET->Internet Gateway
To: [e-mail]

>If there is sufficient interest I could add a facility to specify IP
>source routes. It would probably work similarly to the way AX.25
>source routing is already implemented.
>
>Phil

I'd like to see it.  Even in a non internet situation, it would be
very useful.  If I understand it corectly, it effectively allows one
to use some intermediate site as a repeater (ie, 44.a.a.a can't reach
44.c.c.c, but 44.b.b.b can).  With no operator intervention on the
part of 44.b.b.b or 44.c.c.c, a and c can communicate.

--
Jon Zeeff (NIC handle JZ)        [e-mail]

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

Date: 30 Jan 91 01:01:15 GMT
From: deccrl!news.crl.dec.com!shlump.nac.dec.com!regent.enet.dec.com![e-mail]  (Bob Gettys N1BRM)
Subject: Problem with NET and another TSR
To: [e-mail]

    I'm having a problem wich I hope someone on the net can help with. I'm
running the KA9Q Internet Protocol Package, v890421.1i.tl DS=7a57 with NET/ROM
support added by Dan Frank, W9NK and Window support by Frank Knight, KA1SYF.
I'm also trying to run the WXDATA program for the Heath ID-5001 weather
computer. They have a definite interaction that hurts only the KA9Q net
program. Without the WXDATA TSR running, the net program runs just fine. With
the WXDATA program running, the net program gets many bad checksum packets to
the point that communications is immpossible. I've tried numerous programs to
separate the two such as Double Dos, DesqView, MS Windows V3 all with no luck
or significant change in the results. The computer is a clone 386sx with 4 meg
of memory. I'm also running DOS 4.01. I wonder if anybody has any ideas?? I've
just about run out of them. (Short of using two computers, of course.)


    The two programs communicate with their respective external stuff via
serial ports. the ID-5001 is on comm1 and the TNC is on comm4 using irq 5.
There is nothing else running on the computer.

    /s/     Bob  N1BRM

p.s. I've elimnated interaction with other programs by running the minimum
possible configurations of each of the above as well as some more complicated
combinations.

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

Date: Tue, 29 Jan 91 07:32:41 -0800
From: brian (Brian Kantor)
Subject: Quo Vadis?
To: info-hams, packet-radio

As you may have noted from earlier messages posted by Jay Maynard, it
seems that his scheme to reorganize the Usenet newsgroups associated
with these mailing lists has been approved by the Usenet proletariat.

Rest assured that the mailing lists will continue, but it is still an
open question as to with which, if any, of the Usenet news groups they
will be gatewayed.  This question is, in part, posed by the splitting
of the single Usenet newsgroup 'rec.ham-radio' into a multiplicity of
more restricted-interest groups.

It may be that the best scheme would be to have one mailing list for
each of the new groups, although that's sort of a maintenance pain
for me to keep running.

Alternatively, we could funnel all the new Usenet groups into one
mailing list, thus restoring the status quo ante.  That would not work
well when people on the mailing list post back to Usenet, as their
postings would have to be cross-posted to all the new newsgroups - not
difficult, but likely to be judged unfriendly by the Usenet people.

A third alternative, and one that represents the least work for me, is
simply to retain the existing newsgroups on Usenet as 'inet' groups,
explicitly for the purpose of gatewaying to and from the mailing
lists.  Usenet people would likely use them to make sure that their
postings reach the thousands of subscribers to the lists on the various
non-Usenet networks.  This would undoubtedly lead to a good deal of
cross-posting as well.

Unfortunately, the Usenetters apparently chose to disregard the entire
question of the mailing lists (from which the Usenet groups actually
originated) in their headlong rush to reorganization, so assuming that
the reorganization is actually achieved, and not simply ignored, we
are left with the question of what to do with the lists.

Suggestions?
    - Brian

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

Date: 29 Jan 91 16:12:34 GMT
From: lib![e-mail]  (Jay Maynard)
Subject: Quo Vadis?
To: [e-mail]

In article <[e-mail]> [e-mail] (Brian Kantor) writes:
>As you may have noted from earlier messages posted by Jay Maynard, it
>seems that his scheme to reorganize the Usenet newsgroups associated
>with these mailing lists has been approved by the Usenet proletariat.
(...)
>Unfortunately, the Usenetters apparently chose to disregard the entire
>question of the mailing lists (from which the Usenet groups actually
>originated) in their headlong rush to reorganization, so assuming that
>the reorganization is actually achieved, and not simply ignored, we
>are left with the question of what to do with the lists.

Actually, if you look at the reorganization, there's only one splitting of
content relevant to Info-Hams and Packet-Radio: that of rec.ham-radio into
rec.radio.amateur and rec.radio.amateur.policy. This was intended to help
cut down on the flamage rampant in rec.ham-radio (and Info-Hams, to which
I subscribed for a while before getting rec.ham-radio at the office). As
such, I was working on the second-hand assumption that Info-Hams would be
gatewayed into rec.radio.amateur.misc, and nothing else would change; this
was perceived as a Good Thing from the comments I got. I _never_ got any
direct comments from Brian, but my experience with subscribing to Info-Hams
was considered while I was formulating the proposal. I resent being accused
of ignoring the mailing list types, especially when my opposition to a .tech
group was based mainly on considering just what such a group would do to
Info-Hams.

My suggestion is simple: Gateway Info-Hams to rec.radio.amateur.misc,
Packet-Radio to rec.radio.amateur.packet, and institute a Ham-Policy list
if and when demand for it warrants.

Please do not continue the current groups as inet groups; that will only lead
to mass confusion, especially since the procedures for the reorganization
call for the current names to be aliased to the new names.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
[e-mail]  | adequately be explained by stupidity.
"Today is different from yesterday." -- State Department spokesman Margaret
Tutwiler, 17 Jan 91, explaining why they won't negotiate with Saddam Hussein

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

Date: 30 Jan 91 03:30:05 GMT
From: w8grt![e-mail]  (Jim Grubs)
Subject: Quo Vadis?
To: [e-mail]

 > From: [e-mail] (Brian Kantor)
 > Date: 29 Jan 91 15:32:41 GMT
 > Organization: The Internet
 > Message-ID: <[e-mail]>
 > Newsgroups: rec.ham-radio.packet
 >
 > Unfortunately, the Usenetters apparently chose to disregard the entire
 > question of the mailing lists (from which the Usenet groups actually
 > originated) in their headlong rush to reorganization, so assuming that
 > the reorganization is actually achieved, and not simply ignored, we
 > are left with the question of what to do with the lists.
 >
 > Suggestions?

I move we adopt a resoution to table reorganization and send the proposal back
to committee.

--
Jim Grubs - Support OPERATION DESERT STORM - the 9th Crusade!
UUCP: ...!uunet!w8grt!jim.grubs
INTERNET: [e-mail]

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

Date: 29 Jan 91 20:32:12 GMT
From: agate![e-mail]  (Dave Cottingham)
Subject: Summary - how to put home PC on the internet
To: [e-mail]

Some folks who were having difficulty getting the summary of info on
putting the home PC on the internet sent me mail, so I checked and
sure enough, the file server had gone down in flames Monday morning.
So here's the scoop:  requests that were received between 7am and noon
PST 28 Jan 1991 have been lost.  The rest will be shipped tonight.  I
would advise waiting until tomorrow before sending another request --
longer if your mail is typically delayed by a day.  This file server
doesn't notice multiple requests, so you're liable to get multiple
copies.

Please send me any bizarre responses you get from the file server; I'm
putting together a bug report.

For those who missed it the first time, you can get the summary by
sending a message to <[e-mail]> with a line in the
body of the message that says "sendme ip_hookup".

 - Dave Cottingham
   [e-mail]

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

Date: (null)
From: (null)
Send me a tape.

Bob McGwier
15 Cherry Brook Lane
East Windsor, NJ.


Since I demodulated the `Start Trek' packets, I have been looking for a
similar challenge.

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: Thu, 31 Jan 91 04:30:06 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #30
To: packet-radio


Packet-Radio Digest         Thu, 31 Jan 91       Volume 91 : Issue  30

Today's Topics:
              2 DRSI Boards and NET/NOS?
                <None>
              Help! What is it? (2 msgs)
           Need 56 Kbps info from .ba folks
                Omni vs Beam?
           Omni vs beam antennas. (4 msgs)
               PACKET->Internet Gateway
                Piccolo info.
           Problem with NET and another TSR
              Procomm Bug in Packet Use
             Shareware on Packet
              TCP/IP over long distances
               Trolling for suggestions

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise 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".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 17 Jan 91 20:39:07 GMT
From: pacbell.com!tandem!Tandem.COM![e-mail]  (Stuart Phillips)
Subject: 2 DRSI Boards and NET/NOS?
To: [e-mail]

In article <958400001@techsup>, [e-mail] writes:
|>
|>
|> a local ham, no newsgroup access, is trying to run nos with 2
|> DRSI boards.  he has the following:
|>
|> drsi pcpa type 2 @ 300h
|> drsi pcpa type 1 @ 310h
|>
|> both use int 7 (not sure if this is selectable on the board -- i
|>                 don't own drsi boards)
|>
STUFF DELETED
|> ... isit possible to use 2 drsi
|> boards with net or nos?  if so, what version of net/nos?  also,
|> i'd appreciate a sample set of attach commands for each board to
|> pass along.

The DRSI driver will only support one card; its not too difficult to change
but (as the author of the driver) I don't intend to make the change.  You
would be well advised to have separate interrupts for each board.

You should be able to configure the scc driver to handle two boards but
you will need two interrupts.  Unfortunately I dont have any example of
how this would be configured.

The interrupt is switch selectable on the board.

Good luck !
Stu N6TTO

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

Date: 17 Jan 91 20:34:34 GMT
From: att!pacbell.com!tandem!Tandem.COM![e-mail]  (Stuart Phillips)
Subject: <None>
To: [e-mail]

In article <[e-mail]> [e-mail] (Robert McGwier) writes:
>Howdy:
>
>Is there anyone on this net that can answer from first hand knowledge
>whether or not DRSI has closed its doors?
>

I saw an earlier posting asking the same question and so phoned DRSI this
morning.  Andy DeMartini assured me that he and his company were very much
still in the land of the living and doing well.  Seems I was the third person
to call and ask.

DRSI are 100% still in business - Mr D. is interested in discovering the
source of the rumor !

Stuart N6TTO

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

Date: 29 Jan 91 21:57:45 GMT
From: pacbell.com!tandem!tandem![e-mail]  (Kevin J. Rowett)
Subject: Help! What is it?
To: [e-mail]

In article <[e-mail]>, [e-mail] (Peach) writes:
|> I have discovered a packet radio signal, locally, on 412.875 MHz.
|> While it is not in the ham band, it sounds very similar to 1200
|> baud packet.

More than likely it is your local police department using AR packet
technology (DRSI may very have well sold it to them, Sunnyvale, CA
bought theirs from DRSI).  The modem frequencies aren't the same
to keep the obviously uneducated out, but it's not even encrypted.

N6RCE

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

Date: 30 Jan 91 16:17:56 GMT
From: sun-barr!cs.utexas.edu!evax!utacfd!letni!rwsys!kf5iw!k5qwb![e-mail]  (Lyn R. Kennedy)
Subject: Help! What is it?
To: [e-mail]

[e-mail] (Peach) writes:

> I have discovered a packet radio signal, locally, on 412.875 MHz.
> While it is not in the ham band, it sounds very similar to 1200
> baud packet.
>
Most likely this is a wind shear system at your local airport.
Signal strength should confirm that.
It's probably not anything similar to ax.25 but I have not examined
one, however I've never found x.25 signals in this band.

lrk

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

Date: 30 Jan 91 01:43:27 GMT
From: hpl-opus!hpnmdla!hpsadle![e-mail]  (Mike Ferrara)
Subject: Need 56 Kbps info from .ba folks
To: [e-mail]

We're working on a 2Mb/s one here. Expect the first hardware to
be running late '91. We'll be using either 3400MHz or 5700 MHz.


  Mike Ferrara M/S 2LRR
  HP Signal Analysis Div R&D
  1212 Valley House Drive
  Rohnert Park, CA 94928
  [phone]
  [e-mail]
  [e-mail]

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

Date: Wed, 30 Jan 91 15:03:05 GMT
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: Omni vs Beam?
To: [e-mail]

To all of you who have entered the above discussion...

Thanks!     you've just earned me a beer!!

       Pete Lucas [e-mail]  [e-mail]

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

Date: Wed, 30 Jan 91 11:45:18 EST
From: [e-mail] (Barry McLarnon DGBT/DIP)
Subject: Omni vs beam antennas.
To: [e-mail]

One situation in which I think it makes sense to use directional antennas
is a CSMA LAN with a full-duplex repeater.  The repeater typically has a
central location and uses an omni antenna (or separate omni receive and
transmit antennas).  If the users have directional antennas aimed at the
repeater site, there are several benefits: they are less likely to have
interference (from out-of-band sources causing intermod, or in-band sources
that the repeater can't hear), they radiate less energy away from the
intended coverage area, and the higher link margins allow the repeater ERP
and/or antenna heights to be reduced.  In essence, the gain antennas help
to define a "tighter" coverage area for the LAN, so the frequencies can
be re-used with less geographical spacing.  Of course, users near the
repeater can use omni antennas if they wish - it's more important for the
users on the fringes to use gain antennas, so as not to extend the
coverage (in terms of susceptibility and interference-causing potential)
of the LAN beyond that defined by the repeater itself.

Barry

| Barry McLarnon     Communications Research Center, Ottawa, ON, Canada |
| Internet: [e-mail]                                           |
| Packet BBS: VE3JF@VE3JF        AMPRnet: [e-mail]3jf [44.135.96.6] |

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

Date: 29 Jan 91 17:54:41 GMT
From: hpl-opus!hpnmdla![e-mail]  (Glenn Elmore)
Subject: Omni vs beam antennas.
To: [e-mail]

> In rec.ham-radio.packet, [e-mail] (Paul Koning) writes:
>
>
>     Sure, CSMA requires/assumes you hear the other participants.  That's why
>     packet radio only faintly (at best) resembles CSMA: often you can't hear
>     other participants, and/or you hear non-participants.  The use of beams
>     aggrevates the former problem, while helping the latter.  Which one is the
>     bigger effect is likely to vary.
>
>     To put it bluntly, how much MORE broken could it get when you use beams?
>     Or when you don't, for that matter?

CSMA is not an efficient architecture to implement over a divergent
( radio ) environment. It indeed is "broken" when applied to radio.
Multiple Access does not coexist with efficient information (energy)
transfer in a radio environment. This is one of the points I attempted
to make in my paper in the 9th ARRL Computer Networking Conference
proceedings.
  However, if we are to exchange a large amount of information among a
large number of users over a wide area we *must* use directed beams.
Fortunately for amateur radio the fact that CSMA doesn't suit a network
of directed beams doesn't preclude other solutions.
For a comparison of a network of omni with one of directed beams and
some practical implications in an amateur radio environment please see
the paper.

73
Glenn Elmore n6gn

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

Date: 31 Jan 91 04:35:18 GMT
From: snorkelwacker.mit.edu!usc!cs.utexas.edu!uwm.edu!rpi!clarkson!@bloom-beacon.mit.edu  (Tadd, KA2DEW, ,3152621123)
Subject: Omni vs beam antennas.
To: [e-mail]



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

Date: 31 Jan 91 01:46:44 GMT
From: usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KB8JRR)
Subject: Omni vs beam antennas.
To: [e-mail]

As quoted from <[e-mail]> by [e-mail] (Dana H. Myers):
+---------------
|    If a topology was in use where a central node was serving a number
| of remotely located nodes, and these nodes could not hear each other
| anyway, and the remote nodes have poor signals into the central node, then
| using beams at the remote nodes would probably make sense, though the
| efficiency of this topology would never be as good as a completely
| interconnected topology.
+---------------

This is *exactly* the situation on 144.99 in NE Ohio; we have one central site
in Chardon, a few of us in Mentor and Painesville, and two outlying nodes (one
in the southern part of Geauga County and one near Youngstown).  The Chardon
node used a beam for a few months, then was switched to an omni.

In our particular case, the omni improved things for the Mentor and
Painesville nodes but didn't lose the "DX" nodes:  we (M/P) were working the
back of the beam, which was aimed at the distant nodes, and packets from the
northern end got lost quite often.  The DX nodes are still in the network
because they both have beams pointed at Chardon.

In this particular case, complete interconnection is rather difficult --- as
an example, I live in an apartment, which limits the height of antennas I can
put up (it's a real coup that I was permitted my Ringo at 25ft.!), but the two
remote nodes would require me to put up an antenna high enough to go over a
freeway overpass and a Finast superstore, respectively.  :-(  The other M/P
nodes have similar problems, and the DX nodes would have to drill signals
through hills to get to anything other than the Chardon node.  In this
particular case, therefore, beams are a win for the distant nodes but a loss
for the local ones.

++Brandon
--
Me: Brandon S. Allbery                      VHF/UHF: KB8JRR on 220, 2m, 440
Internet: [e-mail]                Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR                      AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

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

Date: 31 Jan 91 06:20:54 GMT
From: julius.cs.uiuc.edu!rpi!uwm.edu!spool.mu.edu!sdd.hp.com!hp-pcd!hp-vcd![e-mail]  (Carl Peterson)
Subject: PACKET->Internet Gateway
To: [e-mail]

Although I know of know gateway/routers for connecting from amateur
TCP/IP or AX.25, I don't think that it would be very difficult to
create on; especially given that many internet connected machines
run Phil's TCP/IP code in preference to their original vendor
supplied code.

If you set up a gateway/router you would have to take a great
deal of care about what addresses could access which services.
Obviously, you could not allow a non 44. address to initiate
a connection to a 44 address.  This is doable.  Within HP we
restrict or gateways so that non-HP addresses cannot access our
subnet.  As the trustee of such a gateway I would be very nervious
about someone making such a connection.  I'd also be nervious
about the type of traffic going across my gateway/router, but
all amateur node operators suffer from that.  The SMTP handler
code would have to be configured to allow periodic trys to forward
over several days before bouncing mail to account for most
stations not being on the air at all times.  The only real problem
is registering the 44 address for routing purposes within internet.
Couldn't we set up an open internet name/domain server for 44
addresses across the country?

I've been thinking about a more limited system for AX.25 traffic.
Hosts could be set up for AX.25 which would act as a worm holes.
The interface would be like any of the popular packet BBS systems,
except that some of the nodes accessable would actually be similar
systems in distantly located cities.  The AX.25 packets would be
completely encapsulated in standard TCP/IP.  No access would be
given to internet at large thus protecting the trustees of the
nodes from problems about non-amateur access.  One of the biggest
frustrations I have with packet is not being able to connect 'live'
to friends in distant cities (no I don't have HF packet, and that's
not very reliable).  Think how this could substatually improve
the throughput of mail and emergency messages (assuming that
normal packet nodes are up and connect to an internet worm hole
host that is up).

            Carl Peterson N6RZA

+------------------------------------------------------+
|   Carl Peterson       [phone]                 |
|   Hewlett-Packard                                    |
|   Vancouver Division (R&D Lab)                       |
|   P.O. Box 8906                                      |
|   Vancouver, WA 98668-8906                           |
|   HPDesk: Carl Peterson/HPD300/04                    |
|   Unix to Unix: [e-mail]                  |
|      {your path}!ucbvax!hplabs!hp-vcd!carlp          |
|   or {your path}!ucsd!hp-sdd!hp-vcd!carlp            |
|   CompuServe:  71301,2532                            |
+------------------------------------------------------+

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

Date: 31 Jan 91 11:10:46 GMT
From: mcsun!cernvax![e-mail]  (frode weierud)
Subject: Piccolo info.
To: [e-mail]

I recently posted a reply to a few of the articles that
delt with the multi-tone telegraphy system Piccolo.
Unfortunately I think I forgot to specify the distribution
and it was only posted locally so I will redistribute the
earlier posting.  Here comes ...


There has recently been some interest in the British
PICCOLO system and its French derivative COQUELET.

PICCOLO was developed back in 1957 by a team lead by
J.D. Ralphs at the Diplomatic Wireless Service, which
today is called the Communication Engineering Department
of the British Foreign and Commonwealth Office.  The
PICCOLO equipment has gone through several complete
redesigns.  The first equipment occupied a major part of
a standard 19 inch rack, while today's unit, PICCOLO Mk 6,
which is made by RACAL and is commercially available as
LA 1117 is a rather small unit by comparison.

PICCOLO is still in use by the British Foreign Office as
its main HF communication mode and several frequencies
are daily active for this purpose on HF bands.

PICCOLO and its development has been described in detail
in several publications, the first article appeared in 1963.

1)   H.K. Robin, D. Bayley, T.L. Murray and J.D. Ralphs,
     "Multitone signalling system employing quenched
     resonators for use on noisy radio-teleprinter
     circuits", Proceedings of I.E.E., Vol. 110, No. 9,
     September 1963, pp. 1554-1568.

2)   D. Bayley and J.D. Ralphs,
     "Piccolo 32-tone telegraph system in diplomatic
     communication", Proceedings of I.E.E., Vol. 119, No. 9,
     September 1972, pp. 1229-1236.

3)   J.D. Ralphs,
     "The application of m.f.s.k. techniques to h.f.
     telegraphy", The Radio and Electronic Engineer,
     Vol. 47, No. 10, October 1977, pp. 435-444.

4)   J.D. Ralphs,
     "An improved 'Piccolo' m.f.s.k. modem for h.f.
     telegraphy", The Radio and Electronic Engineer,
     Vol. 52, No. 7, July 1982, pp. 321-330.

5)   J.D. Ralphs,
     "Principles and practice of multi-frequency
     telegraphy", (book), Peter Pelegrinus on
     behalf of The Institute of Electrical Engineers,
     Peter Pelegrinus Ltd., London 1985,
     ISBN 0-86341-022-7.

There have as well been a few non-technical articles on
PICCOLO and COQUELET in Monitoring Times.

6)   Jack Albert,
     "Just When You Thought It Was Safe to Turn on the
     Radio", Monitoring Times, February 1989, page 47.


7)   Jack Albert,
     "U.S. Hobbyist First to Copy Piccolo",
     Monitoring Times, July 1989, page 47.

8)   Jack Albert,
     "Piccolog", Monitoring Times, August 1989, page 47.

9)   Jack Albert,
     "A New Piccolo System", (The French Coquelet System)
     Monitoring Times, March 1990, page 47.


The only decoder available on the market that can decode
both PICCOLO and COQUELET is CODE3 from HOKA Electronics,
The Netherlands, equipped with the PICCOLO and COQUELET
options.

73 de Frode, LA2RL/HB9CHL

**************************************************************************
*       Frode Weierud           Phone   :       [phone]            *
*       CERN, SL                Fax     :       41 22 7823676            *
*       CH-1211 Geneva  23      E-mail  :       [e-mail]    *
*       Switzerland                        or   [e-mail]   *
**************************************************************************

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

Date: 31 Jan 91 03:06:51 GMT
From: epic![e-mail]  (Phil R. Karn)
Subject: Problem with NET and another TSR
To: [e-mail]

In article <[e-mail]>, [e-mail] (Bob
Gettys N1BRM) writes:
>
>I'm having a problem wich I hope someone on the net can help with. I'm
>running the KA9Q Internet Protocol Package, v890421.1i.tl DS=7a57 with
NET/ROM
>support added by Dan Frank, W9NK and Window support by Frank Knight,
KA1SYF.

That is a *really* old version.

>I'm also trying to run the WXDATA program for the Heath ID-5001
weather
>computer. They have a definite interaction that hurts only the KA9Q
net
>program. Without the WXDATA TSR running, the net program runs just
fine. With
>the WXDATA program running, the net program gets many bad checksum
packets to
>the point that communications is immpossible.

Offhand, I suspect that your WXDATA TSR is taking over the machine
with interrupts disabled for long periods of time, starving the
interrupt handlers in NET that handle the serial port. This results in
lost characters and corrupted packets.

Your best bet is to a) upgrade to a recent version of NOS and b)
replace your 8250 or 16450 serial chips with NS16550A chips. These
chips provide 16-byte FIFO buffering on both transmit and receive
which substantially reduces interrupt latency requirements; hopefully
this will give you the margin you need to run WXDATA and NOS at the
same time.

NOS is required here because the 16550A chips require a little extra
software to enable FIFO mode that is not in the old NET versions.
However,
the 16550As will work fine with your other communication programs, even
those that don't know about them, because they come up in 8250
compatibility
mode by default.

Phil

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

Date: 30 Jan 91 21:02:18 GMT
From: sdd.hp.com!samsung!rex!uflorida!mlb.semi.harris.com!trantor.harris-atd.com!x102c.ess.harris.com![e-mail]  (Gary Bastin 60293)
Subject: Procomm Bug in Packet Use
To: [e-mail]

In the process of debugging a packet AX.25 LAN, an obscure bug was
discovered in Procomm Version 2.4.X, as well as Procomm Plus.
Namely, if there is a busy channel, with collisions, the XON/XOFF
function of Procomm doesn't work properly.  Procomm, all versions,
has a built-in timer of ~20 seconds that times the duration from
the last XOFF.  If, within this 20 seconds, XON is not performed,
then after 20 seconds, Procomm assumes that a noise burst caused
the XOFF.  Data is then dumped anyway.  For the case of sending a
file, and if collisions occur, then the tnc may not be ready to
receive more data within 20 seconds.  If this is the case, then
the tnc buffer is overflowed!  This was the case on a military
AX.25 LAN!

As for the fix, Datastorm Technology has a patch program called
DT_PATCH which can patch the Procomm Plus executible to set the
timer from 20 seconds up to 18 hours.  As received out of the box,
though, Procomm Plus has the 20 second feature/bug.  The patch
program must be run to fix the problem.  No patches exist for the
older shareware versions 2.4.X, and Datastorm plans no future
patches to these versions.  Fortunately, an upgrade from the
shareware versions 2.4.X to the new Procomm Plus is available for
$39.00.  This is better than the full retail price of $119.

Hopefully, knowledge of this feature/bug in Procomm, all versions,
may save someone else some grief!  73, Gary


Gary Bastin, WB4YAF      /-/-/      Internet: [e-mail]
Mail Stop 102-4826         |        phone: [phone]
Harris Corporation GASD    |
P.O.B. 94000, Melbourne FL 32902    Speaking from, but not for, Harris!

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

Date: 31 Jan 91 04:40:34 GMT
From: sdd.hp.com!uakari.primate.wisc.edu!umriscc!maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]  (Steve Schallehn)
Subject: Shareware on Packet
To: [e-mail]

A question was posed to me by an amateur who is interested in getting
into packet.  It seems he has a large collection of shareware on his
land-line BBS and he was wondering if he could legally set up his
BBS on packet and allow shareware downloads.

I know about the avoiding business in amateur radio, but does
shareware count?

-Steve Schallehn, KB0AGD
 Kansas State University

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

Date: 31 Jan 91 04:56:22 GMT
From: maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]  (Steve Schallehn)
Subject: TCP/IP over long distances
To: [e-mail]

In the last issue of QEX magazine, the "Gateway" had a listing
of finger and mail services for TCP/IP.  A question popped into my
head as why such a list was given in a national magazine.

Since we do not have a nationwide TCP/IP network in the USA, is
connectivity to these services a problem or is it
possible for ANY TCP/IP'er to use these services.


-Steve Schallehn, KB0AGD
 Kansas State University

PS:  I just got my IP address and I don't have anyone to talk to! :-(

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

Date: 31 Jan 91 05:28:20 GMT
From: usc!ucselx!petunia!csuchico.edu![e-mail]  (John Kennedy)
Subject: Trolling for suggestions
To: [e-mail]

  How is this for getting my feet wet?

  I've just got my license (sent in the paperwork near Xmas, got the license
today -- KC6RCK).  What I'm looking to do is latch a packet radio onto a UNIX
machine.  The goal is to get all the advantages of packet TCP/IP without
actually having to resort to an IBM.  (-:

  I do have the UNIX machine.  I've yet to get the transceiver, but I'm
thinking about a Kantronics KAM (lots of goodies to use, some overkill, but
a few that I'd like to take advantage of eventually, with a bay for an extra
modem).  Then it's off to scrounge for the rest.

  If anybody's already done this, I'd be interested in hearing from them, as
well as any commonts from other people.
--
Warlock, AKA            +-----------------------------------------------+
John Kennedy            |    internet:     [e-mail]    |
 CSU Chico              +-----------------------------------------------+
   KC6RCK                        IBM, You BM, We All BM for IBM!

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

Date: (null)
From: (null)
Pete,
  Using omni directional antennas would only be better if it was your
intention to have all of the stations on the frequency able to hear
each other.  That means that there could only be one LAN on the frequency
in your whole region.  This might be greedy, depending on where you were.
  Using beams puts you in a classic hidden transmitter syndrome situation.
One of the solutions to that situation occurs when there is only one
station that does 95% of the transmitting.  In that case all you must make
sure of is that the one station is heard by everybody else.  Thus the beams.
In that senario the one station is -more or less- controlling the
frequency.  It actually works.  What you have to do is keep the other
stations from transmitting alot of data.
  One application of this is where a BBS has it's user access port on a
2m channel.  The users access the BBS on that channel and perhaps route
through the BBS using the G8BPQ driver to the network.  THe BBS MUST do
its forwarding and network linking on another, non-interfering frequency.
                     Tadd - KA2DEW

[ North East Digital Association - Editor             Tadd Torborg ]
[ Clarkson University, Potsdam NY                     Box 330      ]
[ [e-mail]                         Colton NY    ]
[                                                     315-262-1123 ]
[ Remember, if you win the rat race, you're still a rat            ]

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

End of Packet-Radio Digest
******************************