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

Text File | 1993-12-31 | 197.2 KB | 4,760 lines

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


Packet-Radio Digest         Fri,  1 Feb 91       Volume 91 : Issue  31

Today's Topics:
          Amprnet services listing (2 msgs)
           FREE Kantronics KPC-II Firmware.
              Help! What is it?
           ka9q NOS on an AT&T 3b1 unix-pc
            Omni vs beam antennas.
               PACKET->Internet Gateway
             Shareware on 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: Thu, 31 Jan 91 09:45:41 -0500
From: [e-mail] (Charlie Ross, Jr.)
Subject: Amprnet services listing
To: "maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]"@gte.com

  > 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.

I was the person who compiled the list.  It was originally published in two
regional newsletters, "The Wireless Bitstream" (newsletter of the Boston
Computer Society A/R SIG) and "The New England TCPer" (newsletter of the
New England TCP Association.  I didn't hear about it appearing in QEX/Gateway
until people received their copies and started mentioning it.

I'm currently unclear as to why it was published in a national newsletter.
A copy is "in the mail" to me and I want to see it before pursuing it further
with Stan Horzepa (Gateway's editor).

Yes, indeed--connectivity would be a "problem" unless you're linked into
the New England subnet.  I do feel that similar listings would be useful
for each regional net, particularly for the sake of newcomers in each area.
To that extent, perhaps it was published as an example--I don't know, I'll have
to see what wrap-around Stan wrote for it.

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

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

Date: 31 Jan 91 16:04:47 GMT
From: att!cbnewsj![e-mail]  (thomas.kenny)
Subject: Amprnet services listing
To: [e-mail]

In article <[e-mail]> [e-mail] (Charlie Ross, Jr.) writes:
>  > 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.
>I was the person who compiled the list.  It was originally published in two
>regional newsletters, "The Wireless Bitstream" (newsletter of the Boston
>Computer Society A/R SIG) and "The New England TCPer" (newsletter of the
>New England TCP Association.  I didn't hear about it appearing in QEX/Gateway
>until people received their copies and started mentioning it.
>
>I'm currently unclear as to why it was published in a national newsletter.
>A copy is "in the mail" to me and I want to see it before pursuing it further
>with Stan Horzepa (Gateway's editor).

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

Date: 30 Jan 91 15:59:17 GMT
From: swrinde!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!felix![e-mail]  (Oscar S. Alonso)
Subject: FREE Kantronics KPC-II Firmware.
To: [e-mail]

Free firmware to the first person to send me email with there mailing
address can obtain Kantronics KPC II packet communcator firmware revision 2.82.

I just upgraded to version 3.00.

Oscar S. Alonso
uunet!ccicpg!felix!alonso

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

Date: 31 Jan 91 11:18:40 GMT
From: public![e-mail]  (Bob Vaughan [e-mail])
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.

This is probably US Army or USAF packet. 412 Mhz is a federal government
frequency. My Hollins book lists the assignment as US Army, and USAF.



--
Welcome My Son, Welcome To The Machine
Bob Vaughan     - [e-mail] {apple,pacbell,hplabs,ucbvax}!well!techie
1-415-856-8025  - [e-mail]       {fernwood,decwrl,mips,sgi}!btr!techie
I am me, I am only me, and no one else is me. What could be simpler?

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

Date: 31 Jan 91 03:17:18 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!msuinfo!sharkey!fmsrl7!hpftc!slimer![e-mail]  (Mark C. Otto)
Subject: ka9q NOS on an AT&T 3b1 unix-pc
To: [e-mail]

In article <[e-mail]> [e-mail] (Lucio de Re) writes:
>In article <[e-mail]> [e-mail] (Jim Mercer) writes:
>>would anyone who has ka9q NOS (or hyprids thereof) running under unix (sysV)
>and me (if available for the 3b1, of course), pretty please!
>Lucio de Re.

Me too, please!


Mark Otto



--
Mark C. Otto   EMail: mco@slimer, {teemc | hpftc}!slimer!mco
Voice: 1-313-441-4264    USnail: 5133 Heather #208, Dearborn, MI. 48126
Quote: "Yeah. Right. Kermit my a*s." - Mark C. Otto, '90

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

Date: 30 Jan 91 11:12:52 GMT
From: mintaka!ogicse!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
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.
>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]

The correct answer is that it depends on the RF topology of your particular
network. If we assume that the bbs or node is forced to use omni antennas,
a necessity in most cases, then the use of a beam by a user station may
reduce total thruput on the channel. The reason being that your signals
arriving at the bbs will be interfered with by other packeteers' signals
because the beam prevents either you or the other packeteer from hearing
each other and performing the normal channel hold off function. If,
however, all user stations are using beams, and the beams are good enough
that the capture effect is significantly enhanced at the bbs so that the
desired station's signal overrides all other users on the channel while
at the same time being so weak at the other users' sites as to not bother
their transmissions, then the beams create a form of spatial reuse similar
to cellular and thruput is enhanced. However, with the generally random
physical distribution of stations in the network that wish to communicate
with each other at any given time, the probability of this case occurring
is relatively small. Therefore, use of beams generally worsens channel
collisions even though there are special cases where the beams can
help.

Gary KE4ZV

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

Date: 31 Jan 91 18:51:09 GMT
From: swrinde!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]

In article <[e-mail]>, [e-mail] (Carl Peterson) writes:
>
> 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.

OK. Enough is enough.  It is time to bring this one out in the open
and resolve it once and for all.

I have heard numerous times that because the remote station would be
controlling the transmitter and he is (possibly) a non-ham that this
would be illegal.  Now lets look at this from a practical technical
aspect.

If I put up a 10M <-> 2M cross-band repeater, a TECH can come on 2M
and initiate a contact on 10M.  This is not considered illegal although
the TECH is initiating the contact.  I have heard that this is OK under
the rules covering 3rd Party traffic cause the TECH isn't the control
operator of the 10M station.  Well, I'm sorry, but that doesn't wash
either.  Cause then all the 10M contacts with G-land AND DL-land etc.
are illegal cause we don;t have 3rd party agreements with them.  The
fact of the matter is that the TECH on 2M never has control of the
signal generated on 10M and that is why the FCC allows it.  I think
the time has come to look at possible INTERNET<->AMPR gateways the same
way.  If it takes letters to the FCC to convince them then so be it.
If I put up such a gateway, I am controling the emissions of the transmitter
not the guy in Odessa, TX who sent a message to one of the hams on the
local LAN.

As long as all other rules are abided by, I can't see where there is any
kind of legal problem.  I don't see a lot of difference between this and
NTS traffic which is non-ham (Happy Birthday, Merry Christmas etc.) put is
placed into the amateur system at one point by a ham.  Basicly the same
should apply to gateways.  I would be considered the ham putting the traffic
into the amateur system.
The potential gain would be great.  Hams would be able to exchange ideas
and colaborate with hams and non-hams alike in their technological projects.

And just to add a little fuel to the fire, all this talk of setting up
wormholes accross the INTERNET is very interesting.  And according to
The Acceptable Use Policy for PrepNET (other NSFNET members will probably
find the same is true for them) these wormholes would (IMHO) be in
violation.

So, would someone out there care to show me the error of my ways??  :-)
I'm not interested in "Well, it you just can't do it, so there."
I want concrete evidence that shows that the arguments that apply to one
type of technology (cross-band repeaters) can't be applied to a new
technology.

bill   KB3YV


--

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

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

Date: 31 Jan 91 15:12:59 GMT
From: julius.cs.uiuc.edu!zaphod.mps.ohio-state.edu!know!tegra![e-mail]  (Johnathan Vail)
Subject: Shareware on Packet
To: [e-mail]

In article <[e-mail]> [e-mail] (Steve Schallehn) writes:

   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 would argue that it is not legal.  Shareware (begware, crippleware,
etc) is software that depends on being distributed in order to
generate revenue for its creator.  Using amateur radio as a means of
distribution is conducting business on amateur radio.

   I know about the avoiding business in amateur radio, but does
   shareware count?

Of course, since most hams don't bother to pay for their shareware
maybe it isn't business after all...


I personally don't like shareware and use very little.  It is the
primary means of propogating viruses.  I much prefer public domain
sources, freeware and copyleft software.  In addition to being safer
and more useful, distributing source code that people can improve upon
and modify is more apropos to amateur radio.


73s and happy hacking, jv

"....say you're thinking about a plate of shrimp...
..and someone says to you `plate,' or `shrimp'......"
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

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

Date: (null)
From: (null)
--
Tom Kenny, KB2GLO
uucp:   att!lzatt!tek          internet: [e-mail]
packet: [e-mail]  ampr: [e-mail] [44.64.0.10]

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

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


Packet-Radio Digest         Sat,  2 Feb 91       Volume 91 : Issue  32

Today's Topics:
            Shareware over packet?
              Undeliverable 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: Fri, 01 Feb 91 14:17:53 GMT
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: Shareware over packet?
To: [e-mail]

Surely its only 'business use' if the ham is making money out of it!
If i send someone directions to their local HRO or something by means
of packet, its not 'business use' because i receive no financial
reward from it. Likewise distributing shareware. Now if *I* was the
*AUTHOR* of the shareware........   (maybe this discussion thread should be
mapped over to rec.ham-radio.legal ??)

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

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

Date: Fri, 1 Feb 91 17:34:17 +0100
From: [e-mail]
Subject: Undeliverable mail
To: [e-mail], [e-mail]

Hello all,

Sorry for this unusual message, but someone has tried to send me a mail,
which had a wrong header. Usually mail from 'strangers' is mail from
readers of this bulletin, that's why I'm posting this here.

The mail came from: <cis.ohio-state.cis.ohio-state.edu>@cis.ohio-state.edu>
which clearly has a syntax-error in it.

To the writer of this mail: try sending it to: [e-mail]
                       or: [e-mail]

You may have added something like @cunyvm.xxx.xx and I've seen one more
case in which it failed. I'll confirm receipt as soon as it gets to me!

73 de Adam PA2AGA

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

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


Packet-Radio Digest         Sun,  3 Feb 91       Volume 91 : Issue  33

Today's Topics:
         HELP with compiling Xenix SysV NET.
               PACKET->Internet Gateway
               recommended NOS version?
             Shareware on 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: 3 Feb 91 01:44:31 GMT
From: munnari.oz.au!manuel!csc.canberra.edu.au!echo![e-mail]  (Carl Makin)
Subject: HELP with compiling Xenix SysV NET.
To: [e-mail]

Hi,
I got a copy of the System V version of Net from TOMCAT for the house
Xenix system here and am having a REAL problem compiling it.  The code seems
to compile OK but before I actually get to compiling it the MAKE program
falls over screaming "out of memory". :-(

Now I'm reasonably new to Xenix/Unix and C but as far as I can see the
only solutions would be either to compile it manually (urk) or split the
makefile.

Has anyone else had this sort of problem?

The machine I'm trying to compile it on is a 12Mhz 80286 running SCO Xenix
2.2.3 in 2.5Mb of RAM and 105Mb of Hard disk.

(Hopefully in a couple of weeks we can borrow 8Mb of RAM for a couple of days
but I'm not sure that will help. :-( )

Carl.

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

Date: 2 Feb 91 20:43:50 GMT
From: zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun![e-mail]  (Jon Bloom)
Subject: PACKET->Internet Gateway
To: [e-mail]

In article <[e-mail]>, [e-mail] (Bill Gunshannon) writes:
>
> I have heard numerous times that because the remote station would be
> controlling the transmitter and he is (possibly) a non-ham that this
> would be illegal.  Now lets look at this from a practical technical
> aspect.
>
> If I put up a 10M <-> 2M cross-band repeater, a TECH can come on 2M
> and initiate a contact on 10M.  This is not considered illegal although
> the TECH is initiating the contact.  I have heard that this is OK under
> the rules covering 3rd Party traffic cause the TECH isn't the control
> operator of the 10M station.  Well, I'm sorry, but that doesn't wash
> either.  Cause then all the 10M contacts with G-land AND DL-land etc.
> are illegal cause we don;t have 3rd party agreements with them.  The
> fact of the matter is that the TECH on 2M never has control of the
> signal generated on 10M and that is why the FCC allows it.  I think

The reason this doesn't fall under the normal third-party rules is that
the FCC has made explicit exceptions in the case of repeaters.  While
third-party traffic normally requires a control operator to be
present at the control point (see 97.109), automatic control of a
repeater is explicitly allowed [see 97.205(d)].  In the case of the
cross-band repeater with an output on 10m, the Technician cannot be
the control operator.  Fortunately, since a repeater is allowed to
be under automatic control, no control operator is needed.  But if
the originating signal is not coming from an amateur station, as would
be the case with Internet-originated data, the station is not, by
definition, a repeater [see 97.3(a)(34)].  So the analogy between cross-
band repeaters and an Internet gateway is false.

> the time has come to look at possible INTERNET<->AMPR gateways the same
> way.  If it takes letters to the FCC to convince them then so be it.
> If I put up such a gateway, I am controling the emissions of the transmitter
> not the guy in Odessa, TX who sent a message to one of the hams on the
> local LAN.

But you are *not* controlling the content of the messages being transmitted
by your station.  No ham is controlling that, and therein lies the problem.

> As long as all other rules are abided by, I can't see where there is any
> kind of legal problem.  I don't see a lot of difference between this and
> NTS traffic which is non-ham (Happy Birthday, Merry Christmas etc.) put is
> placed into the amateur system at one point by a ham.  Basicly the same
> should apply to gateways.  I would be considered the ham putting the traffic
> into the amateur system.
> The potential gain would be great.  Hams would be able to exchange ideas
> and colaborate with hams and non-hams alike in their technological projects.

I completely agree with your last statement.  But there *is* a legal
difference between the gateway and the NTS example.  See below.

[...Internet legalities deleted]

> So, would someone out there care to show me the error of my ways??  :-)
> I'm not interested in "Well, it you just can't do it, so there."
> I want concrete evidence that shows that the arguments that apply to one
> type of technology (cross-band repeaters) can't be applied to a new
> technology.

At the risk of (once again) being accused of being a technology-bashing,
Luddite, ARRL old fart, let me try to (once again) explain how it is that
the existing rules unfortunately prohibit unattended Internet->AMPR
gateways.

97.109(e) allows packet stations operating above 50 MHz to pass third-
party traffic under automatic control, but "The retransmitted messages
must originate at a station that is being locally or remotely controlled."
Even worse, messages originated by non-hams (where the notion of a control
operator can't possibly be stretched to cover the originator) surely come
under the requirements of 97.115(b) which states in part:

(b) The third party may participate in stating the message where:
   (1) The control operator is present at the control point and is
       continuously *monitoring* and supervising the third party's
       participation.  [Emphasis mine.]

This means that, under the current rules, you have to monitor (read)
the data being sent by the Internet participant.  A bit difficult in
an IP gateway!

Once again... cross-band repeaters are repeaters and fall under the
repeater rules.  An Internet gateway is *not* a repeater and does
*not* fall under these rules.  The reason the repeater rules were
created in the first place was to provide relief from the third-
party rules when only relay of *amateur* signals was involved.  Trying
to interpret these rules in some way that would allow automatic relay
of nonamateur signals violates both the spirit and letter of the repeater
rules.  Sorry.

--
Jon Bloom, KE3Z                              | American Radio Relay League
Internet: [e-mail]         |
Snail:    225 Main St., Newington, CT 06111  | "I have no opinions."

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

Date: 2 Feb 91 21:17:02 GMT
From: modcomp![e-mail]  (Dan Grostick)
Subject: recommended NOS version?
To: [e-mail]

Can anyone recommend their favorite NOS version and where to get
it from. I have access to uunet but not directly to internet -
except via a ftp-request mechanism that requires internet address
and file names.

Thanks

-Dan

N4IXP

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

Date: 2 Feb 91 17:10:00 GMT
From: zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!wa4mei!ke4zv![e-mail]  (Gary Coffman)
Subject: Shareware on Packet
To: [e-mail]

In article <[e-mail]> [e-mail] (Steve Schallehn) writes:
>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?

Shareware authors ask for and expect money for their product just like
any other business. They're just freeloading their marketing dept off
on to the public access systems. While shareware is probably the most
often pirated software, it's still a commercial product. Therefore it
would certainly be illegal to distribute it over amateur radio. Think
of shareware as digital pizzas. :-)

On the other hand, true freeware and public domain software are perfectly
ok to send over amateur radio.

Gary KE4ZV

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

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


Packet-Radio Digest         Mon,  4 Feb 91       Volume 91 : Issue  34

Today's Topics:
               Amprnet services listing

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 Feb 91 22:29:36 GMT
From: maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]  (Steve Schallehn)
Subject: Amprnet services listing
To: [e-mail]

>> From time to time I've corresponded to people that were qutoed or wrote
>> orignal material which was written for other publications and then appeared
>> in Gateway. It appeared in most cases that the original author had now idea
>> it was going to be in Gateway. Many did not get Gateway and a fair amount
>> didn't even know what Gateway was so was rather surprised when they got
>> my packet message.... I guess they don't ask permission to republish
>> or just clear it through the other publications editor and the author is
>> never told. Seems to be common practice in Gateway from my experience.
>>
>All of the noncommercial amateur radio publications I receive have a statement
>that typically goes like this... "the contents of this publication may be
>republished as long as credit is given to the original source."  I have never
>used an article from another publication without following this rule.

>Stan Horzepa, WA1LOU
>Gateway Editor

The original question of why the listing was in Gateway was purely a
technical one as I just did not know if I could get to these services.

Personally, I can't wait to get my QEX every month and read Gateway.
It is good to hear about what others are doing around the country.

Thanks for taking the time to compile Gateway!


-Steve Schallehn, KB0AGD
 Kansas State University

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

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


Packet-Radio Digest         Wed,  6 Feb 91       Volume 91 : Issue  35

Today's Topics:
            'To:' field anarchy! (3 msgs)
          Internet->packet Gateway (3 msgs)
        KA9Q NOS for the Commodore Amiga availability
          PACKET->Internet Gateway (3 msgs)
         The FCC, the rules, and us (longish)

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, 04 Feb 91 13:58:20 GMT
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: 'To:' field anarchy!
To: [e-mail]

Greetings; i have recently been having a battle of wits :-) with a lot of
users in the UK who seem intent on addressing their messages to 'ALL@GBR'
or some similarly uninformative destination. I have done a count  of the
messages on several BBS; something around 30-40% of messages are sent to
'ALL' !!!
I rarely bother to read those messages addressed to 'ALL' from users
who further alienate their intended audience by putting something totally
uninformative (like 'HELP') as the only thing in the 'Subject:' field.

I have been trying to draw up a list of preferred 'To:' fields so that
people can make best use of the limited addressability they have in headers,
and so obtain the best targetting of their messages to the intended
audience. Nothing i am doing is aimed at producing a 'restricted'
list, purely a list showing common usages for the benefits of others.
Also note that my list will include popular European variants of 'All'
depending on national language variations.
I was wondering - what is the normal procedure in the States and the rest
of the world for these sorts of thing.... Do you have the usual 'to' fields
anarchy, or are there 'preferred' ones as well as ALL ????
And what do you do to those users who send 'local' news  (regarding club
meets etc) to ALL@WWW. (you know, it arrives in Tasmania six weeks after the
event took place)    There must be a special place in Hell for these people.

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

(Please reply via the List, or via Internet/Bitnet; my mailer has just been
   attacked by the Data Loss Monster who eats anything with a '!' in the path)

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

Date: 6 Feb 91 03:37:43 GMT
From: elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!news.cs.indiana.edu!ux1.cso.uiuc.edu!maverick.ksu.ksu.edu!matt.ksu.ksu.edu![e-mail]  (Steve Schallehn)
Subject: 'To:' field anarchy!
To: [e-mail]

In the 9th Amateur Radio Networking Conference (Sorry, I don't remember the
official name), there was a paper presented on using netnews for packet
radio.  Perhaps someone could post a copy if they have a chance.

I feel this sort of 'segmentization' is going to be extremely important
for message distribution continuing in packet radio.

-Steve Schallehn, KB0AGD
 Kansas State University

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

Date: 5 Feb 91 13:37:31 GMT
From: mcsun!ukc!acorn![e-mail]  (Adrian Godwin)
Subject: 'To:' field anarchy!
To: [e-mail]

In article <04.Feb.91.14:12:43.GMT.#[e-mail]> [e-mail]
  ("Pete Lucas, NCS-TLC, Holbrook House, Swindon") writes:
>Greetings; i have recently been having a battle of wits :-) with a lot of
>users in the UK who seem intent on addressing their messages to 'ALL@GBR'
>or some similarly uninformative destination. I have done a count  of the
>messages on several BBS; something around 30-40% of messages are sent to
>'ALL' !!!

You hero!

However, I feel the real problem is due to the use of a mail-like interface
for bulletin traffic. It isn't sufficient just to reduce the use of ALL,
but also (as you show by your suggestion of a preferred list) to limit
bulletin 'destinations' to a number of names that are universally
recognised, rather than using the field as a sort of summarised subject.

It surprises me that this hasn't already happened, as many packet users
(and more especially packet BBS writers) must also be familiar with telephone
BBSs and surely appreciate the advantages of grouping bulletins in an
_intentionally_ restricted list of areas.

I'd therefore suggest that you tackle the BBS writers to provide categories
to which bulletins may be addressed. In order to provide maximum anarchy -
if that's how the users like it - I'd suggest that a message _could_ be
written to a previously unknown group, but it would result in a warning
to the effect "Nobody's ever heard of this subject. Post somewhere else if
you want your bulletin to have a fighting chance of being read".

When all the poorly-directed dross falls into the ALL area, it will become
so boring that nobody will read it. Enterprising BBS writers might care to
time out subjects that are either never written to or never read ...


--
--------------------------------------------------------------------------
Adrian Godwin                                        ([e-mail])

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

Date: 6 Feb 91 00:11:57 GMT
From: drago.tgv.com![e-mail]  (Sam Sjogren)
Subject: Internet->packet Gateway
To: [e-mail]

In article <[e-mail]>, [e-mail] (Brian Kantor) writes...
>They way I plan (someday, in my copious free time) to implement an
>internet<->packet mail gateway is actually rather simple:  traffic from
>the ham side to the internet is not restricted, except for the odd
>callsign on the idiot list.  Traffic from the internet to the ham side
>is filtered; it must be from a mailbox (i.e., contents of the FROM
>line) that is on my list of known hams, which is built by observation
>and registration.

It's terribly trivial to create fake mail.  I can send mail to you
with just about anything in the From: line, using SMTP over TCP.
Perhaps this would be a case where we'd need authenticated mail,
with some sort of public-key crypto-authentication system being
used.  A conversation I had in December with Phil seemed to indicate
that using cryptography for the purpose of authentication, as opposed
to hiding the meaning of the message thru encryption of a message's
contents, was not illegal under FCC rules, so the authentication
data could even be conveyed along with the text of the message to
provide end-to-end authentication even across the packet link(s).
Of course, the strength of the authentication is only as secure as
the person's private key's secrecy, but it may provide a high enough
degree of authentication to make the FCC happy.  I could see an
Internet->Ampr gateway allowing someone to log in over the Internet
and then hop out over packet, with the person logged in having to
be a ham to be allowed by the software to do this.  Direct TCP
connections, or the passing of random IP packets, from Internet to
packet are a bit harder, as I guess that you'd have to make the
superuser of a particular machine (as designated by the IP address
of a packet) be considered the control operator; you'd want to
have control on that machine of just who was able to send IP
packets to the Internet->packet gateway, and the gateway would
have to restrict the routing of IP packets to radio links to those
from an approved list of ham-operated Internet hosts.  It looks
doable, but probably would be messy to implement.

-Sam, WB6RJH

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

Date: 6 Feb 91 06:08:55 GMT
From: [e-mail]  (Brian Kantor)
Subject: Internet->packet Gateway
To: [e-mail]

<description of forging mail, encryption, etc included by reference>

I would hope that it's only necessary to make a good-faith effort to
ensure that the sender is a ham.  There is no way to be absolutely sure;
it's only a question of how much effort you have to put forth to keep
the pharisees happy.
    - Brian

P.S.  There's a wonderful invention called the paragraph.  People who
employ it often find that readers enjoy their writings more.

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

Date: 6 Feb 91 06:08:47 GMT
From: tgv.com![e-mail]  (Sam Sjogren)
Subject: Internet->packet Gateway
To: [e-mail]

In article <[e-mail]>, [e-mail] (Brian Kantor) writes...
><description of forging mail, encryption, etc included by reference>
>
>I would hope that it's only necessary to make a good-faith effort to
>ensure that the sender is a ham.  There is no way to be absolutely sure;
>it's only a question of how much effort you have to put forth to keep
>the pharisees happy.

I'd love to be able to operate on this basis, in general.  I'm a
big fan of honour systems.  However, if the asshole bureaucrats
are going to be, well, assholes, it's good to know that you can
come up with the technology to allow connectivity to continue
despite the legal requirements.  We have the technology, let's
hope that we're not forced to use it.

Btw, I find the FCC BBS citations offensive and scary.  I hope
that they're overturned.

>       - Brian
>

-me

>P.S.  There's a wonderful invention called the paragraph.  People who
>employ it often find that readers enjoy their writings more.

Well excuuuuuse my train of thought, and I'll excuse your pedancy!  >B-}

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

Date: 5 Feb 91 05:05:41 GMT
From: haven!ni.umd.edu!sayshell.umd.edu![e-mail]  (Louis A. Mamakos)
Subject: KA9Q NOS for the Commodore Amiga availability
To: [e-mail]

Contrary to what is published in this month's QST in the Packet
Perspectives column, I am NOT a source for the KA9Q NOS for the Amiga.
Heck, I'm not an ARRL member and don't even receive QST.  Imagine my
suprise when I started getting these mysterious phone calls "about the
packet article in QST."

I am selling off my Amiga system, and no longer have facilities for
copying Amiga disks.  Can only support one computer toy (now a
NeXTstation) at a time...

I've already received a number of phone calls from amateurs who read
that article, and I'm hoping to save others spending a few dollars in
long distance charges to talk to my answering machine.

I wish authors would try to check this type of information before
publishing it, as I have NEVER offered to to diskette distribution of
the code that I ported even when I did have the facilities to do so..
I suspect people will "discover" this incorrect information in the
article for years to come.  Oh well.

As far as I know, the latest work being done on the Amiga version of NOS
is being done by John Heaton, G1YYH, who started with my version and
added his own changes.  I point folks at thumper.bellcore.com in the
anonymous FTP directory /pub/ka9q/amiga for the distributions.  Or, you
might try to contact the author:

    John Heaton, G1YYH

    Janet:     [e-mail]           MCC Network Unit (g111)
    DARPA:     [e-mail]           The University
    AX.25:     g1yyh @ gb7nwp.gbr.eu        Oxford Road
          or   g1yyh @ gb7crg.gbr.eu        Manchester       M13 9PL
    Ampr:      amiga.G1YYH.ampr.org         England
           [44.131.1.71]

for other information about his version.

73,
Louis Mamakos
WA3YMH

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

Date: 4 Feb 91 18:52:24 GMT
From: cs.utexas.edu!helios!photon![e-mail]  (Willis Marti)
Subject: PACKET->Internet Gateway
To: [e-mail]

Jon,
  You gave a relatively reasoned response and I'd like to respond.  But
before I do, let me say why I believe Internet gateways (i.e., routers)
can be legal, even assuming you're 100% correct.

First, there are three major services (among many) that are part of the
TCP/IP suite that we'd like to use:
--TELNET {connection to a host}
--FTP {file transfer}
--SMTP {email}
For all except SMTP, it is easy to configure a router so that no one on the
Internet side can initiate a connection.  I then claim that since an
amateur would be initiating the host session and/or file transfer, that
passing traffic back and forth thru the router is within the rules.
For SMTP, one needs a cooperating host on the Internet (a POPmail server)
and the ham can initiate reception of his own email.
If the routing is done by a host, then only one machine is necessary --
though most hosts don't, by default, support the kind of filtering
necessary to prevent Internet initiated connections.

Is that satisfactory?
   Willis Marti
----------------------------------------------------------------------------
In article <[e-mail]>, [e-mail] (Jon Bloom) writes:
[much quoted material deleted, mostly asserting that repeater operation
  is not comparable to Internet gateway operation - wfm]

|> repeater is explicitly allowed [see 97.205(d)].  In the case of the
|> cross-band repeater with an output on 10m, the Technician cannot be
|> the control operator.  Fortunately, since a repeater is allowed to
|> be under automatic control, no control operator is needed.  But if

I'll go back and read, but are you saying the rules explicitly say that an
amateur operator can work frequencies on which he doesn't have
privileges, as long as he goes through a repeater belonging to someone else?
Or is that your interpretation?

[more things deleted]

|>
|> At the risk of (once again) being accused of being a technology-bashing,
|> Luddite, ARRL old fart, let me try to (once again) explain how it is that
|> the existing rules unfortunately prohibit unattended Internet->AMPR
|> gateways.

I'd recommend a couple of books that might help you understand the
differences in technology, and what can be done to alleviate concerns
instead of just saying "It can't be done.":

_Internetworking with TCP/IP_ (1st or 2d edition) by Douglas Comer
_Computer Networks_ (2d edition) by Andrew S. Tanenbaum

|> 97.109(e) allows packet stations operating above 50 MHz to pass third-
|> party traffic under automatic control, but "The retransmitted messages
|> must originate at a station that is being locally or remotely controlled."
|> Even worse, messages originated by non-hams (where the notion of a control
|> operator can't possibly be stretched to cover the originator) surely come
|> under the requirements of 97.115(b) which states in part:
|>
|> (b) The third party may participate in stating the message where:
|>    (1) The control operator is present at the control point and is
|>        continuously *monitoring* and supervising the third party's
|>        participation.  [Emphasis mine.]

I think you're stretching it here, unless you consider retrieval of stored, machine readable data to be the same as a live person talking into the mike.

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

Date: 4 Feb 91 23:33:15 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cunixb.cc.columbia.edu![e-mail]  (Meir)
Subject: PACKET->Internet Gateway
To: [e-mail]

In article <[e-mail]> [e-mail] (Jon Bloom) writes:
>
>This means that, under the current rules, you have to monitor (read)
>the data being sent by the Internet participant.  A bit difficult in
>an IP gateway!
>
Unfortunately, also impossible on high speed AMATEUR data links.
I forsee many legal problems related to that in the near future.
>--
>Jon Bloom, KE3Z                              | American Radio Relay League
>Internet: [e-mail]         |
>Snail:    225 Main St., Newington, CT 06111  | "I have no opinions."

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

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

Date: 5 Feb 91 18:11:38 GMT
From: [e-mail]  (Brian Kantor)
Subject: PACKET->Internet Gateway
To: [e-mail]



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

Date: 5 Feb 91 04:53:40 GMT
From: snorkelwacker.mit.edu!usc!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!fafnir.la.locus.com![e-mail]  (Dana H. Myers)
Subject: The FCC, the rules, and us (longish)
To: [e-mail]

   As many other amateurs are, I'm concerned about the recent
report of citations issued to the operators of automatic Bulletin
Board Systems which automatically forwarded a message with illegal
content. The issue I am concerned about is NOT that of freedom of
speech and selective enforcement of the law by the FCC.

[ For those not aware, several operators of packet BBSes on the
  East coast were recently reported to be cited for the content of
  a message soliciting business for an anti-war organization. Though
  the operators of the BBSes did not originate the message, their
  stations transmitted it ]


  I see several issues at play:

-> The message appears to be a truly illegal solicition of money.

    The content of the message, as described by a trustworthy source,
  appears to be solicitation of business for a non-amateur radio
  related organization. The rules have always been clear with regards
  to business activity on amateur radio - it is illegal. I don't wish to
  raise the issue of "what is business activity?" here; I think it is
  clear the content of the message in question is outside the bounds
  of what is acceptable. (Frankly, I'm surprised at how many advertisments
  I see on packet where someone has several radios at a time for sale....).

-> The message appears anti-war in nature

    Granted. The message appears anti-war. The reported citations are not
  for 'treasonous activity' or the like; the poster can pretty much say what
  he wants as long as he doesn't cuss or ask for money.

-> It appears the FCC is cracking down on anti-war activity

    I doubt the FCC normally cares. I doubt the FCC normally monitors
  packet radio (or any other amateur service).  The FCC appears to want
  amateur radio to 'take care of itself'. My guess is that some *RADIO
  AMATEUR* read that illegal message, and that *RADIO AMATEUR* didn't
  like the commercial nature, and that *RADIO AMATEUR* called the FCC
  up. Furthermore, my guess is that the FCC official who reviewed this
  case decided the message path indicated this illegal message had been
  transmitted from a multiple number of stations. The rules do not
  distinguish between 'originate' and 'transmit'; therefore, everyone
  who transmitted this message is technically in violation of the
  law.

-> The FCC rules are deficient.

    Currently, the FCC rules do not distinguish between what an operator
  does and a machine does. In all cases, the operator is responsible for
  what is transmitted from a station, though automatic operation is
  allowed. We've had automatic stations for years; conventional repeaters
  are no different than packet BBSes with regards to the ability to
  transmit illegal traffic. What has been different, however, is the
  response of the FCC; when was the last time a repeater operator was
  cited for the activities of a jammer? While I am certain such a thing
  is possible, I've never heard of this case.

-> The rules need to relax.

    The notion of origination in automatic service needs to be
  formalized. Originators of illegal traffic should be held liable;
  operators of automatic stations who make a 'good faith' effort
  to prevent illegal operation should not be held liable. Origination
  the intentional transmission of a message. Forwarding is the
  automatic re-transmission of a message. In general, a human
  originates; for instance, playing a tape of an illegal message
  over the local repeater would be origination; the repeater in
  question would be forwarding the message (an intermediate issue
  is that of a human who knowingly allows illegal traffic to be
  forwarded - I would think, in the case this is proved, this would
  count as origination).

-> Amateurs need to relax

    We are basically our own police. If we can't handle things on
  our own, there is no reason to believe the FCC can handle things
  any better. If you see an illegal message on a BBS, CONTACT THE
  INVOLVED PARTIES **BEFORE** CALLING THE FCC!!  Don't just run
  off and call Big Brother! I'm certain some ham thought he was
  doing amateur radio a favor to report the anti-war solicitation of
  money. Think, for a moment, about a parent who really doesn't want
  to be bothered. Consider, for a moment, the errant child and the
  righteous sibling. We've all see this; the righteous sibling goes
  to tattle and the parents, annoyed at the irritation, punish BOTH
  children. THIS WILL HAPPEN TO US!


  Think this over. We can help shape the amateur radio service of the
next millenia if we act now to petition the FCC to modernize the concepts
used in the rules. If we just squabble and act self-righteously, we'll
ALSO shape our service; likely the same way 220-222 Mhz is shaped.


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

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

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


Packet-Radio Digest         Thu,  7 Feb 91       Volume 91 : Issue  36

Today's Topics:
            'To:' field anarchy! (2 msgs)
     a few random thoughts about channel access (3 msgs)
  Has Part 97 changed THAT much? (was Re: PACKET->Internet Gateway)
          Internet->packet Gateway (3 msgs)
        Painfully long FTP transfers (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: 6 Feb 91 18:06:42 GMT
From: shelby![e-mail]  (paulf)
Subject: 'To:' field anarchy!
To: [e-mail]

In article <[e-mail]> [e-mail] (Steve Schallehn) writes:
>I feel this sort of 'segmentization' is going to be extremely important
>for message distribution continuing in packet radio.

I couldn't agree more.  The thing that differentiates netnews from mailing
lists is the existence of outstanding filter tools to get at what you
want, and to dump all the chad...

-=Paul Flaherty, N9FZX      | Without KILL files,
->[e-mail] | life itself would be impossible.

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

Date: 6 Feb 91 17:43:20 GMT
From: netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
Subject: 'To:' field anarchy!
To: [e-mail]

In article <[e-mail]>, [e-mail] (Steve Schallehn) writes:
> In the 9th Amateur Radio Networking Conference (Sorry, I don't remember the
> official name), there was a paper presented on using netnews for packet
> radio.

I suggested that right here in this group over 6 years ago.  I even tested
the idea of using UUCP 'g' protocol with TNC's.  It all worked really well.

Of course, I was told that the BBS concept worked perfectly well and there
was no need for anything like NEWS.  I think it would have been a lot easier
to change things before we had as many BBSes as we now do.

bill   KB3YV

--

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

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

Date: Wed, 6 Feb 91 08:00:56 -0800
From: brian (Brian Kantor)
Subject: a few random thoughts about channel access
To: packet-radio, tcp-group

Whilst having packet-radio nightmares again last night, a couple of
thought about channel access methods came to mind.  Here I go,
challenging assumptions again.

1. CSMA/CA is what we do to avoid collisions - we watch the channel and
wait until it's clear.  Most sophisticated people do it with
p-Persistance.  However, I think that a small variation in pP methods
would help throughput.

Simply, most of the pP implementations I've played with ALWAYS use
the roll-a-die-in-this-slot method - so when they go to transmit a
packet, they could conceivably wait one or more slottimes before they
transmit even though the channel is clear.  I think that if there is no
channel activity present the first time you have a packet ready to
transmit, you should simply go for it.  If the channel IS active, you
wait until it's clear, then you start doing the slot-delays.

This variation has the win that you'll never unnecessarily slot-delay
on a clear channel, but you will still gain the pP advantage of
avoiding the "lets all jump on the channel now that he's done" syndrome
which non-pP channel access methods exhibit.  Implicit in this is
that the generation of packets ready-to-transmit is somewhat random;
with maxframe set to one, even a high-volume data source like a BBS or
a sending FTP will exhibit this behaviour, since the next packet is, by
definition, not ready to transmit until the previous one has been
ack'd.

Problem with this one is implementing it; it probably means firmware
changes in everyone's TNC.  Arrgh.  Only the on-the-bus people can do
this in software.  Still, if you've got a DRSI card, you might give it
a shot and see if it helps.

2. Backoff.  Exponentially backing off when you don't get an ACK for a
packet has one tacit assumption that may be fatally flawed: that the
packet or its ack were lost due to congestion that can be cured by
reducing traffic density.  Yet on a packet radio network where packets
are lost randomly due to non-congestion-related causes (like static
crashes and passing Volkswagens), this assumption, if applied purely,
leads to backing off a lossy channel when in fact the right thing to do
is to be more aggressive!  (I recall one FTP session that had backed
off to an 8-hour retry time because I'd not limited backoff times and
it was a really lossy (50% or more dropped) channel.)

Some technique for noticing the degree of congestion and adjusting the
retry time is needed - perhaps something can be done along the lines of
noting other traffic on the channel and adjusting the exponent in the
backoff formula accordingly.  Algorithms which give greater weight to
the round trip time of successful (i.e., ack'd) packets are also a good
idea for combating the pathological-backoff problem that simpler
methods might generate.  Gotta think more on this one.

3. p-Persistance slottimes.  I'm wondering if we aren't really using
far too short a slottime.  On a network which has hidden stations (i.e,
90%+ of all ham packet radio networks), waiting a few milliseconds
because your coin didn't come heads-up in the current slot isn't going
to help - you're still going to stomp on the hidden station's packet
that he began transmitting those few milliseconds ago.  It seems to me
that you'd want the slottime to be more on the order of the
transmission time of the average packet, if indeed not of the
transmission time of the MAXIMUM packet.  That way, when you toss the
coin and lose in this slottime, the other guy gets a clear channel for
the whole packet, not just the beginning of it.  Implicit in the
use of short slottimes is the idea that you'll hear him and back off,
which simply isn't the case a really high proportion of the time.

Using slottimes on the order of one to five seconds (for a 1200 bps
channel) demands that you use technique #1 above; you'd really NOT want
to randomly wait some multiple of seconds on a clear channel.  It might
be smart to do this dynamically - if you're seeing packets but not
their acks, or acks but not the packets they're for, you've got hidden
stations and you should be using long slottimes.  Otherwise you're just
fine with slottimes on the order of the DCD response time of your
demodulator.  Again, this requires quite a bit of smarts, so the
on-the-bus people have an advantage, but the this one CAN be done with
KISS implementations, since the computer is getting all the packets and
can make the determination as to whether there are hidden stations
present or not, and adjust the TNC's slottime parameter accordingly.

Comments?
    - Brian

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

Date: 6 Feb 91 23:48:37 GMT
From: epic![e-mail]  (Phil R. Karn)
Subject: a few random thoughts about channel access
To: [e-mail]

Brian's first two points (decreasing p only when the channel is busy
and limiting backoffs) are well taken. It seems to me that both can be
set automatically by estimating the number of active stations on the
channel.  For example, if you see eight active stations on the
channel, then p should be 1/8 and the retransmission backoff should be
limited to 8.  Note that it's the number of active stations and not
the actual amount of traffic that matters.

There are two problems to be solved here. One is estimating the number
of hidden stations on the channel and the other is picking an interval
during which a station is considered to be "active". One possible way
to find hidden terminals is to watch destination as well as source
addresses on the channel.

As far as slot times go, I think it's best to keep them short. There's
really no way to detect hidden terminals by just listening to channel
activity - you have to interpret it. One way is to watch the control
fields in the packets themselves - if you see someone send an I frame,
you know that its recipient will be sending an ACK soon, even if you
can't hear it. This is the basis of the "prioritized ACK" scheme invented
by N7CL. I have devised a more general scheme of my own called CSMA/CA
(collision avoidance) that is based on the Apple Localtalk channel
access protocol; it was described in last year's ARRL conference proceedings.

Phil

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

Date: 7 Feb 91 00:52:45 GMT
From: [e-mail]  (Brian Kantor)
Subject: a few random thoughts about channel access
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>...  For example, if you see eight active stations on the
>channel, then p should be 1/8 and the retransmission backoff should be
>limited to 8.  Note that it's the number of active stations and not
>the actual amount of traffic that matters.

A quibble: I contend that it's the number of stations ready to transmit,
not the number of active stations.  Assuming point-to-point communications,
which is common, and no simultaneous data exchange in both directions,
which is rare, the actual number in your scenario would be 4, leading to
a pP of 1/4.
        - Brian

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

Date: 6 Feb 91 00:28:04 GMT
From: sdd.hp.com!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!fafnir.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Has Part 97 changed THAT much? (was Re: PACKET->Internet Gateway)
To: [e-mail]

In article <[e-mail]> [e-mail] (Willis Marti) writes:
>----------------------------------------------------------------------------
>In article <[e-mail]>, [e-mail] (Jon Bloom) writes:
>
>|> repeater is explicitly allowed [see 97.205(d)].  In the case of the
>
>|> 97.109(e) allows packet stations operating above 50 MHz to pass third-
>|> party traffic under automatic control, but "The retransmitted messages
>|> must originate at a station that is being locally or remotely controlled."
>|> Even worse, messages originated by non-hams (where the notion of a control
>|> operator can't possibly be stretched to cover the originator) surely come
>|> under the requirements of 97.115(b) which states in part:
>|>
>|> (b) The third party may participate in stating the message where:
>|>    (1) The control operator is present at the control point and is
>|>        continuously *monitoring* and supervising the third party's

    [remainder deleted]


  My copy of Part 97 is in the ARRL "The FCC Rule Book". None of these
paragraphs (a) exist or (b) say the same thing. Has Part 97 really changed
that much since November 1, 1987?


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

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

Date: 6 Feb 91 15:36:07 GMT
From: magnus.ircc.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!helios!photon![e-mail]  (Willis Marti)
Subject: Internet->packet Gateway
To: [e-mail]

Summary (for those quick with the 'n' key): More comments on Internet<->AMPR
connectivity, with quotes from a couple of postings.

(Jon Bloom) writes:
I think it is.  It has much the same characteristics as a phone patch, in
fact.  But it's not quite what I understood that people wanted.  To the
extent that hams are willing to accept those limitations, it seems like
a good approach to me.
(reply)
The 'limitations' mean that someone on the Internet can not *start* a
connection/session to AMPR.  For hams, there is little limitation.  When
I finish my 'munged' router, I'll have a way for me to initiate from the
Internet.
Also to clarify, I *don't* see AMPR being used to connect other Internet
sites to each other...

(Bruce Walker) writes:
Careful.  While it is quite possible to configure a router so that no one
can successfully inititate a connection to some or all TCP ports
(services), it isn't generally possible to configure a router to not
forward packets which look like part of an established connection but might
not be.  Such bogons would be discarded at their final destination, but if
they had already crossed the airwaves, the damage would have been done.
(reply)
Correct on the router capabilities.  Incorrect, I believe, on the second part.
See other comments below.

(-Sam, WB6RJH ) writes:
packet are a bit harder, as I guess that you'd have to make the
superuser of a particular machine (as designated by the IP address
of a packet) be considered the control operator; you'd want to
have control on that machine of just who was able to send IP
packets to the Internet->packet gateway, and the gateway would
have to restrict the routing of IP packets to radio links to those
from an approved list of ham-operated Internet hosts.  It looks
doable, but probably would be messy to implement.
(reply)
Interesting idea about superuser==control operator.  But you can't restrict
packets to those hosts with ham owners -- what if the ham initiates the
connection? Remember, gateways are (must be) two-way.  It doesn't make sense
to talk about "Internet->packet" instead of "Internet<->packet".
BTW, if you want to look at non-messy ways to implement some kind of access
control, look at cisco, inc.'s router manual.

In article <[e-mail]>, [e-mail] (Sam Sjogren) writes:
|> In article <[e-mail]>, [e-mail] (Brian Kantor) writes...
|> ><description of forging mail, encryption, etc included by reference>
|> >
|> >I would hope that it's only necessary to make a good-faith effort to
|> >ensure that the sender is a ham.  There is no way to be absolutely sure;
|> >it's only a question of how much effort you have to put forth to keep
|> >the pharisees happy.
|>
|> I'd love to be able to operate on this basis, in general.  I'm a
|> big fan of honour systems.  However, if the asshole bureaucrats
|> are going to be, well, assholes, it's good to know that you can
|> come up with the technology to allow connectivity to continue
|> despite the legal requirements.  We have the technology, let's
|> hope that we're not forced to use it.
|>
(reply)
To quote Brian, "There is no way to be absolutely sure;".  There are lots
of repeaters out there that can't guarantee non-hams are denied access. And
the ones that do restrict in some way are a lot less secure that any scheme
proposed so far.
And for both of y'all, remember there are other applications besides email
that people want & must be considered in gateway/access design.


Cheers,
 Willis Marti

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

Date: 6 Feb 91 18:28:49 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!cci632![e-mail]  (Just another hired gun (n2hkd))
Subject: Internet->packet Gateway
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>big fan of honour systems.  However, if the asshole bureaucrats
                         ^^^^^^^

Sorry, if this looks like I'm picking on someone, but
THIS is a prime example of why rec-ham.* can't be routed to
the packet system. I have devised ways of automatically handling
the list of BAD words and such, but then there's always the
doubting Thomas that says it won't happen here.

As in the case of this area, doing something new and experimenting
and prototyping, etc will not happen. All of those ideas and the
people who have them, don't want to take the risk of being wrong,
and therefore rather give lipservice than to attempt to fix the
problem.

Those of us who post here, might want to consider keeping soem of these
newsgroups as to the specification of the FCC, after all I might
be one of those automatic stations that is passing the traffic,
through the Radio system. It would be quite embarassing to get a
citation from Big brother and not even be able to figure out how
you deserved it :-).

As far as passing traffic I would consider having a call sign look
up function to match the addressor [ and  the addressee ] for
verification and thus putting the burden on the orginator.
The call sign info is available and should be deemed accurate,
afterall didn't the FCC have something to do with it?
other mail would be considered third part mail and be handled
separately...

yet another thought on this subject...
--

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

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

Date: 6 Feb 91 23:32:56 GMT
From: usc!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cunixb.cc.columbia.edu![e-mail]  (Meir)
Subject: Internet->packet Gateway
To: [e-mail]

In article <[e-mail]> [e-mail] (Gary A. Morris) writes:
>In <[e-mail]> [e-mail] (Sam Sjogren) writes:
>
>>In article <[e-mail]>, [e-mail] (Brian Kantor) writes...
>>>They way I plan ... to implement an
>>>internet<->packet mail gateway is actually rather simple:  ...
>>>...  Traffic from the internet to the ham side
>>>is filtered; it must be from a mailbox (i.e., contents of the FROM
>>>line) that is on my list of known hams, which is built by observation
>>>and registration.
>
>>It's terribly trivial to create fake mail.  I can send mail to you
>>with just about anything in the From: line, using SMTP over TCP.
>>Perhaps this would be a case where we'd need authenticated mail,
>
>Sounds like overkill to me.  Couldn't we just say that any unlicensed
>person who sends fake email is illegally operating a amateur radio
>transmitter without a license?
>--GaryM
>--
>Gary Morris                    Internet: lescsse![e-mail]
>Lockheed, Houston, Texas       UUCP:     lobster!lescsse!gamorris
>Space Station Freedom          Internet: [e-mail]
>N5QWC/W5RRR                    Phone:    [phone]

Yes;  But the FCC will accept this only if you have put a lock on your
system.  Some sort of authentification/verification is needed as well as
reasonable checks for illegal traffic.  Otherwise, get ready to read ALL of
the traffic first!

(yes; how many of us lock our cars but not our transmitters?
Maybe this is OK if the room gets locked :-)

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

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

Date: 6 Feb 91 03:20:05 GMT
From: sdd.hp.com!samsung!munnari.oz.au!uniwa!vax7![e-mail]
Subject: Painfully long FTP transfers
To: [e-mail]

   I am running NOS version 900828 on an XT clone, and I find that FTP
sessions, long Telnet sessions and so on can be so slow that I'm likely
to be collecting the old-age pension before they finish.
   I tracked down one problem. I was running TNC2 ROM version 1.1.7 in
my TNC, and it seems that the KISS defaults in this version were
wrong. For example, SLOTTIME was set to 50: presumably meaning 500mS.
The KISS v4 source I have used 5 (50 mS). Changing mine to this value
meant that I actually transmitted a packet now and then on a mediumly
crowded channel (sometimes it would take up to 30 seconds on an uncrowded
channel. Is there a good way of determining how SLOTTIME and PERSISTENCE
should be set?
   That's not the whole of the problem, however. It seems that the
recovery timer can take ridiculous values. If something goes wrong (e.g.
the receiver misses a packet or the transmitter misses the ACK), it
can take ages before the transmitter polls the receiver. I was doing
a transfer last night, on a frequency with nobody else around, and
I had one timer value of five minutes. This means that absolutely nothing
happened for five minutes, and I'd just got a packet from the receiver
not long before.
   It seems to me that this is *FAR* too long. Have I set up something
wrong? Is there a default setting that I've missed? And how are these
values determined anyway (I could dive into the sources and find out,
but it's easier to ask someone who knows).
   Suggestions would be greatly appreciated. You might even save the
TCP/IP situation here in Perth!
....Ron

--
 Internet: [e-mail]                | "This brain is
 ACSnet: [e-mail]                      | intentionally
 Bitnet: [e-mail]    | left blank"
 UUCP  : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ |

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

Date: 7 Feb 91 00:01:29 GMT
From: epic![e-mail]  (Phil R. Karn)
Subject: Painfully long FTP transfers
To: [e-mail]

If you're using AX.25 connected mode, try setting "ax25 blimit" to an
estimate of the number of active stations on the channel. Set the
kiss slottime to the keyup delay of the modem, and set the p value
to 256/n, where n is the estimate of active stations on the channel.

You might also set the ax25 irtt to a closer estimate in order to speed
convergence to the true round trip time.

Phil

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

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


Packet-Radio Digest         Fri,  8 Feb 91       Volume 91 : Issue  37

Today's Topics:
             'To:' field anarchy!
                 infomation

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: Thu, 7 Feb 91 12:28:36 EST
From: [e-mail] (Barry McLarnon DGBT/DIP)
Subject: 'To:' field anarchy!
To: [e-mail]

Adrian Godwin writes:
>In article <04.Feb.91.14:12:43.GMT.#[e-mail]> [e-mail]
>("Pete Lucas, NCS-TLC, Holbrook House, Swindon") writes:
>>Greetings; i have recently been having a battle of wits :-) with a lot of
>>users in the UK who seem intent on addressing their messages to 'ALL@GBR'
>>or some similarly uninformative destination. I have done a count  of the
>>messages on several BBS; something around 30-40% of messages are sent to
>>'ALL' !!!
>
>You hero!
>
>However, I feel the real problem is due to the use of a mail-like interface
>for bulletin traffic. It isn't sufficient just to reduce the use of ALL,
>but also (as you show by your suggestion of a preferred list) to limit
>bulletin 'destinations' to a number of names that are universally
>recognised, rather than using the field as a sort of summarised subject.

There is a 'preferred list' which has circulated around the NA BBS network,
at least.  I checked several hundred bulletins on my BBS last night, and
found that 48% of them were addressed to ALL.  Of the remaining two dozen
or so different To: field entries, many, but by no means all, were from
the preferred list.  I don't think the majority of sysops do much to
encourage their users to make use of the list.  As you point out, even if
use of such a list were universal, it doesn't really address the problem,
which is the monolithic mail-like interface.

>It surprises me that this hasn't already happened, as many packet users
>(and more especially packet BBS writers) must also be familiar with telephone
>BBSs and surely appreciate the advantages of grouping bulletins in an
>_intentionally_ restricted list of areas.

It surprises me too, since it's so glaringly obvious that this is *major*
shortcoming of BBS software.  I wrote an article on this topic a little over
a year ago, which was fairly widely circulated (I think) and reprinted in
Gateway.  I had quite a few enthusiastic comments from users, but I got no
reaction from BBS software authors (with one exception, but his software is
not widely used).

>I'd therefore suggest that you tackle the BBS writers to provide categories
>to which bulletins may be addressed. In order to provide maximum anarchy -
>if that's how the users like it - I'd suggest that a message _could_ be
>written to a previously unknown group, but it would result in a warning
>to the effect "Nobody's ever heard of this subject. Post somewhere else if
>you want your bulletin to have a fighting chance of being read".

Good luck.  At least one of the BBS writers reads this list/newsgroup -
perhaps he would offer up some comments.

Personally, I think the packet BBS will eventually go the way of the dodo.
Instead of beating on the BBS writers to get them to transform their sow's
ears into something useable, let's concentrate our efforts on building a
proper NNTP-based news and SMTP-based mail network.  Then put *real* mail
and newsreading tools in the hands of the users, and get some nice servers
for files, callbook, etc, up and running.  They'll never go back to the
BBS... :-)

Barry VE3JF


Barry McLarnon                  |  Internet: [e-mail]
Communications Research Centre  |  PBBS: [e-mail]
Ottawa, Canada  K2H 8S2         |  AMPRnet: [e-mail]3jf [44.135.96.7]

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

Date: 7 Feb 91 13:21:31 CST (Thu)
From: ssi!tao![e-mail] (gdk)
Subject: infomation
To: [e-mail]

hello,

would you send me some information on joining the packet-radio
mailing list?

thanks.

    gary kline

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

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


Packet-Radio Digest         Sat,  9 Feb 91       Volume 91 : Issue  38

Today's Topics:
  Has Part 97 changed THAT much? (was Re: PACKET->Internet Gateway)
               PACKET->Internet Gateway
      Tandy 100/102 series and packet radio - need hints

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 Feb 91 21:07:08 GMT
From: hpl-opus!hpnmdla![e-mail]  (Alan Bloom)
Subject: Has Part 97 changed THAT much? (was Re: PACKET->Internet Gateway)
To: [e-mail]

In rec.ham-radio.packet, [e-mail] (Dana H. Myers) writes:

>       [remainder deleted]


>  My copy of Part 97 is in the ARRL "The FCC Rule Book". None of these
>paragraphs (a) exist or (b) say the same thing. Has Part 97 really changed
>that much since November 1, 1987?

Yes.  There was a complete rewrite a couple years ago.

AL N1AL

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

Date: 5 Feb 91 19:18:26 GMT
From: hsdndev!think.com!news![e-mail]  (Bruce Walker)
Subject: PACKET->Internet Gateway
To: [e-mail]

In article <[e-mail]> [e-mail] (Willis Marti) writes:
    ...
   For all except SMTP, it is easy to configure a router so that no one on the
   Internet side can initiate a connection.  I then claim that since an
   amateur would be initiating the host session and/or file transfer, that
   passing traffic back and forth thru the router is within the rules.

Careful.  While it is quite possible to configure a router so that no one
can successfully inititate a connection to some or all TCP ports
(services), it isn't generally possible to configure a router to not
forward packets which look like part of an established connection but might
not be.  Such bogons would be discarded at their final destination, but if
they had already crossed the airwaves, the damage would have been done.


--
--Bruce Walker
  Thinking Machines Corporation, Cambridge, MA
  [e-mail]; [phone]

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

Date: 8 Feb 91 03:21:35 GMT
From: uhccux!munnari.oz.au!manuel!csc.canberra.edu.au!echo![e-mail]  (Carl Makin)
Subject: Tandy 100/102 series and packet radio - need hints
To: [e-mail]

In <[e-mail]> [e-mail] (Scott Wood) writes:

>I am looking for help, and input from anyone that has used the tandy
>100/102 laptops with their amateur radio set-ups.  Especially with
>packet or station management.

A tandy 100 was used in the first mobile and portable packet experiments
here in Canberra. :-)  Friend of mine had it setup in the car.  Somebody
connected to say hello and was rather confused when Doug typed back "not
now I'm driving". :-)

We use that same m100 quite a bit when we go to a remote digipeater site as
the terminal end of a TNC-2/HH portable station configuration.

There is also a BBS available for the m100 written in basic that seems to
work ok over packet however with the growing number of PMSs it's not really
worthwhile.  Most TNC's now have more processing power than a m100.

Carl.

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

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


Packet-Radio Digest         Sun, 10 Feb 91       Volume 91 : Issue  39

Today's Topics:
              Packet BEGINNER needs info
            Shareware over 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: 9 Feb 91 04:12:00 GMT
From: hpcc05!hpdmd48![e-mail]  (Bob Davidson)
Subject: Packet BEGINNER needs info
To: [e-mail]

> I am an Electrical Engineer and would like to set up my own
> packet radio data communications system (preferably with a laptop).

Shouldn't be a problem for an EE in Seattle.

> I don't have a radio license yet or know much about the procedures
> to go about getting one.  Could you give me some items to take care of
> so I can get started?

Will try.

> Example information needed:
>
>       all hardware required, suggested items to buy ( <$500 )

It's a bit hard to do if you purchase new.  Basically you will need a
VHF transciever.  The cost new ranges from $300 to $400 for a basic FM
transciever on the ham 2mtr band.  You will find packet activity around
145 MHz typically.  A modem will run another $300.  If you already have a
laptop, then you are ready to go.  Most of the modems for ham packet handle
the packet protocol on board so the laptop can function as a "dumb" terminal.
On the other hand, I understand there are a number of programs available to
control ham packet modems that make life quite a bit nicer than the "dumb"
terminal version.  There are several good ham radio stores in the Seattle
area (see the yellow pages) where you could visit.  There is a lot of packet
and other ham activity in the Seattle area as well.  It would be worth your
while to check on the UofW ham club as I am sure there must be some hams
there involved in packet that would be a good local resource for you.
You could get setup for a fraction of $500 if you attend one of ham swap
meets and purchased used equipment.  The club members should be able to tell
when one will be held in the Seattle area.  It's also possible to build
equipment, but usually it is a losing proposition if you only have cost
as you reason for building something.  The big companies can take advantage
of economies of scale that the individual can't when it comes building
equipment.

>       required and suggested reading materials

At the mentioned above ham stores and possibly the U bookstore there are a
number of publications by a group called the ARRL (American Radio Relay League).Among these are license manuals and introductory operating manuals.  The range
of the publications of the ARRL is fairly great, from very basic to reasonably
sophisticated.  The best known is the "Amateur Radio Handbook".

>       steps necessary to get a license (can I simply take the
>               technician class test or do I have to take the novice
>               first and work up to technician class?...should I
>               even opt for a higher class than technician?)

Basically to get a license, you will need to take an exam, certified by the
FCC but given by other hams.  I would guess that the UofW ham club gives exams
or people in it know others who do.  Luckily, there is a non-code license
available.  It consists only of technical questions and legal questions.  Any
EE should have no problem passing it, but it is worth looking at one of the
above mentioned license manuals before taking the exam.  There is no sequence
that you have to follow in license classes.  If you are ready, you could
take the top grade license exam (amateur extra class) first.

>       access to the Internet/UUCP networks

Access outside of ham circles is pretty limited.  I expect that will change
but currently there are limitations, imposed by the FCC to prevent ham
competition with commercial services, that severly restrict ham to non-ham
communications.

>       typical/maximum data rates possible

typically 1200 baud on VHF, but some work done with higher rates.   In the
Seattle area, there must be a lot of activity at the higher rates.

>       is a completely portable unit possible?

yes, the main limitation would be owning a portable computer.  Most ham
trancievers and modems are designed for 12V.

>       what kinds of connections are possible with what countries?

It's fairly easy to work other countries for ham (noncommercial) purposes.
In fact, there is an award for working 100 countries.  Hundred, if not
thousands, have qualified.

Regards,

Bob Davidson, WA7IUT
Eagle, Idaho

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

Date: 10 Feb 91 05:55:50 GMT
From: ucivax![e-mail]  (Clark Turner)
Subject: Shareware over packet?
To: [e-mail]

In article <[e-mail]> [e-mail] (Gary Coffman) writes:
>In article <01.Feb.91.14:22:10.GMT.#[e-mail]> [e-mail] ("Pete Lucas, NCS-TLC, Holbrook House, Swindon") writes:
>>Surely its only 'business use' if the ham is making money out of it!
>
>I wish! This has been covered at extreme length in the pizza wars of yore.
>The FCC issued an official opinion on this type of activity orignially in
>conjunction with the Eye Bank Net. The ruling said that you cannot use
>Amateur Radio to further the business activities of any entity whether you
>personally profit from it or not. It doesn't matter if the entity whose
>interests you are furthering is nonprofit or profit. It doesn't matter
>if your aid is direct or indirect. It's still forbidden.

Gary:

I have just tuned in to this net and am quite curious about this ruling
you refer to.  Do you have a reference to it?  I am obviously interested
in RACES and CD use of amateur radio (clearly on the right side of the
ruling) vs. shareware which certainly may be "business" in nature BUT
does the term exclude software I place into the public domain (give up
all business rights to)?

This concerns me since I am a beginning attorney and very interested in
the field of amateur rules and regulations...and if I get called upon I
want to have the basic information before I go out and comb the field.

----------
Clark S. Turner                        "The Buddha, the Godhead, resides
WA3JPG                                  quite as comfortably in the circuits
[e-mail]                      of a digital computer or the gears
----------                              of a cycle transmission as he does
                    at the top of a mountain or in the
                    petals of a flower."
                                 - Robt. Pirsig
----------
714 856 2131    1514 Verano Pl., Irvine, CA. 92715
admitted to practice law in NY, MA, and CA.
----------

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

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


Packet-Radio Digest         Mon, 11 Feb 91       Volume 91 : Issue  40

Today's Topics:
              computer/radio RFI
            Shareware over 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: 10 Feb 91 16:43:00 GMT
From: zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cunixb.cc.columbia.edu![e-mail]  (Meir)
Subject: computer/radio RFI
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>
><Posted for a friend>
>
>As many readers of this group obviously have had to deal with this to some
>degree, I suppose this is the right group to post this...?
>
>
>I plan to use my computers in conjunction with my ham radio activities, both
>for digital comms and for logging, etc, but there is a problem..
>
>I have two machines, and hope to use both. One is a 12 Mhz AT clone, and the
>other is a Leading Edge XT clone. Currently Im using a borrowed Hallicrafters
>
>SX-122 just to listen in until I purchase a Kenwood 440 or perhaps 850. For
>now, my antenna consists of a random-wire fed directly into the rcvr. With the
>new radio will come a new antenna, obviously fed with coax. With thesetup
>as-is, both computers drown out both the hallicrafters and my scanner.
>
>Questions:
>1) will the new antenna, being fed with coax, eliminate, or significantly
>reduce the noise levels?

Yes.  Get your antenna as far above your setup as possible.
Ground everything to an excellent earth ground.

>2) If not, are there any relatively cheap/easy mods that can be done to the
>rig or computers to reduce their RFI output?

I'll ignore the "if not."
Put lots of chokes on your cables; especially your monitor cables.
Shielding your monitor may help most of all!

>Thank you
>Robert J Miskines
>V127P9XG @ ubvms.cc.buffalo.edu

You're welcome.  73

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

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

Date: 10 Feb 91 15:13:53 GMT
From: swrinde!cs.utexas.edu!helps!bongo![e-mail]  (Julian Macassey)
Subject: Shareware over packet?
To: [e-mail]

In article <[e-mail]> [e-mail] (Clark Turner) writes:
>
>I have just tuned in to this net and am quite curious about this ruling
>you refer to.  Do you have a reference to it?
   Stuff deleted
>This concerns me since I am a beginning attorney and very interested in
>the field of amateur rules and regulations...and if I get called upon I
>want to have the basic information before I go out and comb the field.

    Looks like this guy is going to fit right in. He has managed to
combine his profession (ambulance chasing) with his hobby (radio). He
will be happy to find that all too many of the denizens here share
his hobby and have his profession as their hobby too.

    This is going to give much more milage to the "Can I order a
pizza if I refuse to pay the delivery boy" questions.

    My understanding of amateur radio is that 70 years ago, the old
farts just wanted to sit around and talk about radio theory while the
young Turks wanted to build radios and transmit with them (using CW
even). Now we seem to be at a stage in our history where the old
farts want to sit around and discuss radio rules and regs while the
young Turks want to build radios and transmit. Things haven't changed
much, but I think they have changed for the worse.

--
Julian Macassey, n6are  [e-mail]  ucla-an!denwa!bongo!julian
N6ARE@N6YN (Packet Radio) n6are.ampr.org [44.16.0.81] voice [phone]

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

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


Packet-Radio Digest         Tue, 12 Feb 91       Volume 91 : Issue  41

Today's Topics:
          FT736 Tx problem with G3RUH modem
            New to HAM. need info.
    packet<--->internet<--->packet gateway - my proposal (3 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: 12 Feb 91 06:21:37 GMT
From: sdd.hp.com!caen!uflorida!rex!rouge!pc.usl.edu![e-mail]  (Dugal James P.)
Subject: FT736 Tx problem with G3RUH modem
To: [e-mail]

I am having trouble with high bit-error rates with my FT736 and G3RUH modem
(from PacComm).  I receive UO-14 perfectly (DCD doesn't flicker at all),
but when I try a terrestrial connect to other hams with identical equipment,
we take maybe 6 tries to get a packet across!  The DCD flickers while
receiving the unsuccessful packets.  I suspect that the impedance match
may not be optimal.  Can anyone comment on how they have solved this problem?
I used G3RUH's tips to connect TxAudio to R32 in the TX unit, at 800 mV.
Thanks & 73 de James, N5KNX
--
-- 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.

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

Date: 11 Feb 91 21:31:19 GMT
From: sun-barr!newstop!eastapps!suncan![e-mail]  (Ron Winacott - Product Support Specialist)
Subject: New to HAM. need info.
To: [e-mail]

Hello all,
    I am new to HAM radio, and packet radio, so please go easy on me. :-)
I have a couple of questions that I really could use an answer for. From
followinf the traffic on the news group, I have not seen the answers.

    1 : Over packet radio, is tcp/ip used, or just ip and some other
        protocal ?
    2 : Who assigns ip address, and what class are they ?

Thanks,
    ron.

PS : Thanks to Bob Davidson, your reply to : Packet BEGINNER needs info was
    GREAT !!!


--

_____________________________________________________________________

Ron Winacott (ronw@suncan)
                Inet  : [e-mail]
Sun Microsystems of Canada. Uucp  : uunet!attcan!utzoo!suncan!ronw
Product Support Specialist. Voice : [phone] X2705.
---------------------------------------------------------------------

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

Date: 10 Feb 91 19:57:50 GMT
From: usc!snorkelwacker.mit.edu!shelby!msi.umn.edu!cs.umn.edu!uc!nachos.SSESCO.com![e-mail]  (Chris Elmquist)
Subject: packet<--->internet<--->packet gateway - my proposal
To: [e-mail]

In article <[e-mail]> [e-mail] (Dave Tiller N2KAU) writes:
>Regardless of the other brouhaha over the legalities of internet<->packet
>gatewaying, here's something that I'll be writing and trying out in the
>near future:
>
>
>
>TNC-----Internet Node-----------//----------Internet Node-----TNC
>145.01     running                            running        144.97
> NJ        socket                             socket       'elsewhere'
>            prog                               prog
>
    [some instructions on use deleted]

>Any comments, good or bad?  I'm looking for someone (out of local range)
>with an internet node handy to try it with me. Any takers?  (Phil Karn, are
>you listening?)

yes! I've been thinking about this same scheme.  Could the socket
program be something as simple as TELNET and the TNCs just be NET/ROM
(or other digi of your choice) sending data out their serial ports
to the internet node?  Some magic would have to be implemented to
restart the telnet session whenever the net breaks... but this
concept has been proven in the past between Minneapolis and
Maryland.  I think they called it the Gofar hole...  It used
a Sun workstation at Cray Research in Minneapolis and something
similar in Maryland.  It worked great-- except it didn't automatically
restart whenever the net broke... so, it was down alot.

I'd be willing to play with this extensively.  We need outside
world connectivity for our packet network here in Minnesota--

Chris
--
Chris Elmquist, N0JCF
Internet: [e-mail]
   AMPRN: [e-mail]
 BellNet: [phone]

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

Date: 11 Feb 91 18:30:06 GMT
From: [e-mail]  (Brian Kantor)
Subject: packet<--->internet<--->packet gateway - my proposal
To: [e-mail]

[e-mail] (Bill Gunshannon) writes:
>is really the case, I again state my belief that we should be working on
>setting up operations as a lot of Class C nets rather than holding to the
>dream that a Packet Radio Class A is doable.

No one is stopping you from requesting a class-C network from the NIC.
Maybe you can even get connected status.  But endlessly crepe-hanging
about how network 44 is never going to work is just damn annoying,
especially to those of us who are trying hard to make it work.

Chase your own dream.  You don't have to scuttle mine in the process.
    - Brian

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

Date: 11 Feb 91 15:19:42 GMT
From: usc!cs.utexas.edu!hellgate.utah.edu!csn!ub!dsinc!netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
Subject: packet<--->internet<--->packet gateway - my proposal
To: [e-mail]

Although the utility of this approach (usually refered to as a wormhole) is
obvious, it does have one problem.

In the case of PrepNet, it would be a definite violation of the Acceptable
Use Policy.  I am also quite certain (although I have not read the applicable
papers) that this would apply to The NSFNET and any other regional connected
to it.  The rules might be different for commercial connections, but that
greatly limits the possible connection points.

I would really rather see the legalities of really connecting to the
INTERNET resolved rather than using the INTERNET to connect random
pockets of NET 44.  This concept of WORMHOLES seems to afirm my claim
that NET 44 cannot be expected to become a real network using technology
currently available or likely to be available in the near future.  If this
is really the case, I again state my belief that we should be working on
setting up operations as a lot of Class C nets rather than holding to the
dream that a Packet Radio Class A is doable.

bill   KB3YV



--
     Bill Gunshannon          |        If this statement wasn't here,
     [e-mail]   |  This space would be left intentionally blank
     [e-mail]    |         #include <std.disclaimer.h>

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

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


Packet-Radio Digest         Wed, 13 Feb 91       Volume 91 : Issue  42

Today's Topics:
           FTP transfer times MUCH improved
             Need 736/PSK-1 help
    packet<--->internet<--->packet gateway - my proposal (3 msgs)
            Shareware over 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: 13 Feb 91 01:35:09 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!uniwa!vax7![e-mail]
Subject: FTP transfer times MUCH improved
To: [e-mail]

   The main problem which caused FTP transfers, Telnet sessions etc. to take
inordinate amounts of time seems to have been the KISS code in the v1.1.7
TNC2 ROM. Thanks to several people for pointing this out.
   I gather that a newer version of the 1.1.7 ROM is in the works, and also
that 1.1.8 is due out soon. Hopefully these will fix the problem: for now, I
have transplanted the KISS v4 code from thumper into the 1.1.7 ROM, whereupon
my file transfer rates went from around 12 chars/sec (and down to -infinity
if you counted the fact that I'd usually abort it after the first half hour)
up to 45-50 chars/sec, which is much more reasonable.
   Please mail me if you need any more details.

....Ron
--

===============================================================================
 Internet: [e-mail]                | "You can lead a horse to
 ACSnet: [e-mail]                      | water, but if you can
 Bitnet: [e-mail]    | get him to float on his
 UUCP  : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got
Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC       | something"
           TCP/IP: 44.136.204.14, 44.136.204.19  |    -- Murphy's Law I
===============================================================================

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

Date: 13 Feb 91 05:05:50 GMT
From: unmvax!ariel.unm.edu!hydra.unm.edu![e-mail]  (Ollie Eisman N6LTJ)
Subject: Need 736/PSK-1 help
To: [e-mail]

Hi.  I'm in the middle of hooking up a Tiny-2 TNC, PSK-1, and a Yaesu
FT-736R for Microsat work.  I'm a bit confused about the UHF and VHF
radio ports on the back of the PSK-1.  I see how this would work if one
had two separate rigs, but what should I do if I'm using a 736?
I'm guessing that all lines will run to the microphone port, and that
I'll need a little extra cable to run out back to the speaker jack.
Do the UHF and VHF ports share RX audio?

Also, with trying to piece together what the cryptic manual and oops
sheets from Paccomm say, should I modify the 736 for "perfect"
modulation?  (This is the part where they mention mods for
a better signal on FO-20)  Do these apply to the microsats as well?

Help...


--
Ollie Eisman (N6LTJ)    [e-mail]     [phone]
3505 Lafayette Rd. NE #3, Albuquerque, New Mexico  87131, USA

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

Date: 12 Feb 91 15:58:06 GMT
From: usc!zaphod.mps.ohio-state.edu!rpi!clarkson!@ucsd.edu  (Tadd,KA2DEW, ,3152621123)
Subject: packet<--->internet<--->packet gateway - my proposal
To: [e-mail]



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

Date: 12 Feb 91 16:30:09 GMT
From: timbuk![e-mail]  (Andy Warner)
Subject: packet<--->internet<--->packet gateway - my proposal
To: [e-mail]

In article <[e-mail]>, [e-mail] (Chris Elmquist) writes:
|> In article <[e-mail]> [e-mail] (Dave Tiller N2KAU) writes:
|> >Regardless of the other brouhaha over the legalities of internet<->packet
|> >gatewaying, here's something that I'll be writing and trying out in the
|> >near future:
|> >
|> >
|> >
|> >TNC-----Internet Node-----------//----------Internet Node-----TNC
|> >145.01     running                            running        144.97
|> > NJ        socket                             socket       'elsewhere'
|> >            prog                               prog
|> >
|>      [some instructions on use deleted]
|>
|> >Any comments, good or bad?  I'm looking for someone (out of local range)
|> >with an internet node handy to try it with me. Any takers?  (Phil Karn, are
|> >you listening?)
|>
|> [gofar hole stuff deleted]
|>
|> I'd be willing to play with this extensively.  We need outside
|> world connectivity for our packet network here in Minnesota--

OK - I've been thinking about an idea for a while now ... I was trying to
write the code before I had to go public, but life's been too short recently.
Basically, it's implementation would go something like this (in NOS) :-

If we get an incoming AX25 packet which we're going to digipeat, check the
next callsign against a hashed table mapping callsigns onto IP addresses. If
a match was found - encapsulate the whole AX25 packet in UDP and send it
off to that IP address. On the other end there is a server which receives
these encapsualted packets, checks the sender's IP address against it's list
of IP <-> callsign mappings (as a crude check). If all is well, it figures out
which interface to send the AX25 packet out of. The routes would be bi-directional
and would require positive intervention by the sysops at BOTH ends before a
link could be used.

There are some benifits that fall out ..

1)      The minimal case means that you can cross-band digi through your own
    machine - by specifying the loopback interface.

2)      You could have (for instance) two machines in your shack with radio
    ports on both and be able to provide xband between ALL the ports. This
    might be especially useful if one was running high speed, and didn't
    need to be bothered with interrupts from a 1200/2400 baud metro channel...

3)      Providing the link at the digipeat level means that NET/Wrong and AX25
    users can exploit this easily.

4)      You could (appropriate use of networks permitting) span huge distances
    very quickly [if you doubt this try pinging some machines 1000 miles away!]

I've not thought through ALL the ramifications yet, and it would probably require
the use of SSID's which has been shunned so far.

Having already written cross-band digi code for NOS, I know this should be
straight-forward to implement - I just haven't got round to it yet :-) :-)

Any thoughts.
--
andyw.  (W0/G1XRL)

[e-mail]    Andy Warner, Cray Research, Inc.        [phone]

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

Date: 13 Feb 91 01:18:09 GMT
From: usc!zaphod.mps.ohio-state.edu!rpi!masscomp!ocpt!tsdiag![e-mail]  (Dave Tiller N2KAU)
Subject: packet<--->internet<--->packet gateway - my proposal
To: [e-mail]

In article <[e-mail]> [e-mail] (Chris Elmquist) writes:
-In article <[e-mail]> [e-mail] (Dave Tiller N2KAU) writes:
->here's something that I'll be writing and trying out in the
->near future:
->TNC-----Internet Node-----------//----------Internet Node-----TNC
->145.01     running                            running        144.97
-> NJ        socket                             socket       'elsewhere'
->            prog                               prog
->Any comments, good or bad?  I'm looking for someone (out of local range)
->with an internet node handy to try it with me. Any takers?  (Phil Karn, are
->you listening?)
-yes! I've been thinking about this same scheme.  Could the socket
-program be something as simple as TELNET and the TNCs just be NET/ROM
-(or other digi of your choice) sending data out their serial ports
-to the internet node?
-I'd be willing to play with this extensively.  We need outside
-world connectivity for our packet network here in Minnesota--
-Chris Elmquist, N0JCF
-Internet: [e-mail]
-   AMPRN: [e-mail]
- BellNet: [phone]

Yes, it can be that simple.  Take two KISS TNC's, add a little socket code,
and you've got a nifty-keen router.  Since the end to end protocol will still
be handled be the user TNC's, all the socket prog has to do is be able to
recognize it's own AX.25 nodename in the AX.25 header (trivial). In fact I
wrote a KISS/Ax.25 parser today to test the theory. It was cake. (Note: if
anyone wants the code, just ask - it's yours.)  Perhaps you and I should
continue this via E-mail and see where it leads. I think we could have a
really useful thing here!  Eventually I'd like to add real X.25 support,
since I have that capability locally (via telenet). Thanks for the response -
you're Alpha test site #1 !
--
David E. Tiller         [e-mail]  | Concurrent Computer Corp.
FAX:  [phone]      Ph: [phone] (w) | 2 Crescent Place, M/S 117
UUCP: ucbvax!rutgers!petsd!tsdiag!davet        | Oceanport NJ, 07757
ICBM: 40 16' 52" N      73 59' 00" W           | N2KAU @ NN2Z

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

Date: 13 Feb 91 06:18:42 GMT
From: usc!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu![e-mail]  (Phil Howard KA9WGN)
Subject: Shareware over packet?
To: [e-mail]

[e-mail] (Clark Turner) writes:

>I have just tuned in to this net and am quite curious about this ruling
>you refer to.  Do you have a reference to it?  I am obviously interested
>in RACES and CD use of amateur radio (clearly on the right side of the
>ruling) vs. shareware which certainly may be "business" in nature BUT
>does the term exclude software I place into the public domain (give up
>all business rights to)?

If the software so much as suggests sending money to the author... then it
is business.  If the software is public domain and has no hint of such a
suggestion, it might not be business.  If it is being distributed for the
purpose of hams to use, I see no problem with it whatsoever.  If it is
being distributed by some form of agreement (whether money is exchanged
or not) then it is likely "business" in the legal sense that matters in
this case.

>This concerns me since I am a beginning attorney and very interested in
>the field of amateur rules and regulations...and if I get called upon I
>want to have the basic information before I go out and comb the field.

Well then it should be obvious.  What constitutes a "business" activity
in any legal sense?  Apply the answer as a test to any proposed ham radio
activity.

If the purpose of the rule helps, there are probably many, including:

1. Ham radio is not to be a substitute for eligible uses of any other radio
   service, whether licensed or via common carrier, nor any other common
   carrier communications means.

2. Such activities don't fall under the basic purposes of ham radio anyway.
--

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

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

Date: (null)
From: (null)
Well said Brian.  The way I figure it our network here in the north east
is 350 miles of good solid hidden transmitter free backbones.  THe network
in the west is growing.  We're at least a 10th of the way there.  That
doesn't even take into account the good work going on in ohio and around
chicago.  I think that it's about time that we keep a national tally
sheet going on this newsgroup!
          - Tadd


[ KA2DEW @ KA2JXI.#NNY.NY.USA.NA                - Tadd Torborg             ]
[ [e-mail]                   - 26 Maple St - PO Box 330 ]
[ NEDA (North East Digital Association) Editor  - Colton, NY 13625         ]
[ Clarkson University                           - 315-262-1123             ]

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

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


Packet-Radio Digest         Thu, 14 Feb 91       Volume 91 : Issue  43

Today's Topics:
             Beginner's Questions
           Shareware over packet? (3 msgs)
      Tandy 100/102 series and packet radio - need hints
               TCP/IP on 128 K

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: 14 Feb 91 04:33:16 GMT
From: usc!wuarchive!rex!uflorida!bikini![e-mail]  (Tyng-Jing Yang)
Subject: Beginner's Questions
To: [e-mail]

By reading this newsgroup for two weeks, it seems I can read/post news
to usenet and do ftping by packet radio.(correct me if I'm wrong)

It make me very interested to setup packet radio if I can access
internet by radio instead of telephone line. I already ordered books
about packted-radio from ARRL(or ARL).

1. How can I have/apply a Internet connection with packet radio ?
   I mean in Florida state.
2. Can I have Radio-Internet connetion in Asis (Taiwan) ?
   I might go back to Taiwan after I finish my MS degree.

If I have positive answers I'll setup packet radio with my NeXT
computer( there will be a SoftPC for NeXT soon).

Thanks

Jing

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

Date: 13 Feb 91 13:14:53 GMT
From: julius.cs.uiuc.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!boingo.med.jhu.edu!haven!ni.umd.edu!sayshell.umd.edu![e-mail]  (Louis A. Mamakos)
Subject: Shareware over packet?
To: [e-mail]

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

>If the software so much as suggests sending money to the author... then it
>is business.  If the software is public domain and has no hint of such a
>suggestion, it might not be business.  If it is being distributed for the
>purpose of hams to use, I see no problem with it whatsoever.  If it is
>being distributed by some form of agreement (whether money is exchanged
>or not) then it is likely "business" in the legal sense that matters in
>this case.

This misses a very large amount of software; that which is most
definately NOT public domain software, but which carries a copyright
notices that limits the uses and further distribution of the software
to specific terms.

For example, Phil Karn's KA9Q software is not public domain and
carries a copyright notice to the effect that "you can't sell this
software or call it your own, but you can give it to anyone that you
want for free." Most of the software that I write carries a very
similar notice which prohibits the software from being included in a
commercial product without specific prior approval.

The larger problem, I suspect, is that most folks don't understand what
"Public Domain" really means, If they wanted to ensure that their
software got the widest possible distribution and didn't get gobbled up
by commerical products, they would attach a Copyright notice.

louie
WA3YMH

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

Date: 13 Feb 91 17:40:40 GMT
From: ucivax![e-mail]  (Clark Turner)
Subject: Shareware over packet?
To: [e-mail]

In article <[e-mail]> [e-mail] (Louis A. Mamakos) writes:
>In article <[e-mail]> [e-mail] (Phil Howard KA9WGN) writes:
>
>>If the software so much as suggests sending money to the author... then it
>>is business.  If the software is public domain and has no hint of such a
>>suggestion, it might not be business.  If it is being distributed for the
...(stuff deleted)...
>
>The larger problem, I suspect, is that most folks don't understand what
>"Public Domain" really means, If they wanted to ensure that their
>software got the widest possible distribution and didn't get gobbled up
>by commerical products, they would attach a Copyright notice.
[to the effect that no one may use it for commercial purposes, it may ONLY
be distributed for free....]

Good point.  To refer to Phil's previous advice, your looking to the purposes
of Amateur radio is a good start, but I am looking for specific references
to see how things play out for the FCC (or in a court).  Determining what
is and is not a "business activity" in a legal sense can be quite a
complicated issue in a commercial case.  To act as an [informed] attorney,
I need to know the language used, the relevant definitions, and the
standards laid down by the relevant ruling agency.  If anyone has such things
--- I would love the references.  I am building a file of Amateur radio
legal information so that if called upon by my local club or friend [who
is not about to spend thousands of dollars just to improve the ARS], I may
be of some service.

The point made here appears to be a "gray" area.  I would clearly see the
copyright restriction you append to software as taking the work out of the
commercial realm - but who knows what the FCC would do, or a Federal court?

AND, I agree that there is confusion about putting works into the public
domain...and that your restrictive copyright notice makes an important
statement at the very least.

Clark

----------
Clark S. Turner                        "The Buddha, the Godhead, resides
WA3JPG                                  quite as comfortably in the circuits
[e-mail]                      of a digital computer or the gears
----------                              of a cycle transmission as he does
                    at the top of a mountain or in the
                    petals of a flower."
                                 - Robt. Pirsig
----------
714 856 2131    1514 Verano Pl., Irvine, CA. 92715
admitted to practice law in NY, MA, and CA.
----------

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

Date: 14 Feb 91 04:00:14 GMT
From: agate!bionet!uwm.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!wells![e-mail]  (Dave Heller)
Subject: Shareware over packet?
To: [e-mail]

In article <[e-mail]>, [e-mail] (Clark Turner) writes:
> In article <[e-mail]> [e-mail] (Louis A. Mamakos) writes:
> >In article <[e-mail]> [e-mail] (Phil Howard KA9WGN) writes:
> >>If the software so much as suggests sending money to the author... then it
> >>is business.  If the software is public domain and has no hint of such a
> >>suggestion, it might not be business.  If it is being distributed for the
> ...(stuff deleted)...
> of Amateur radio is a good start, but I am looking for specific references
> to see how things play out for the FCC (or in a court).  Determining what
> is and is not a "business activity" in a legal sense can be quite a
> complicated issue in a commercial case.  To act as an [informed] attorney,
> I need to know the language used, the relevant definitions, and the
> standards laid down by the relevant ruling agency.  If anyone has such things
> --- I would love the references.  I am building a file of Amateur radio
> legal information so that if called upon by my local club or friend [who
> is not about to spend thousands of dollars just to improve the ARS], I may
> be of some service.
> WA3JPG                                  quite as comfortably in the circuits



This sounds like a lawyer talking.
Your call indicates you've been an
amateur for at least 25 years, and
presumably you've kept up with the
popular literature, read QST regularly,
etc.
So you should know that any attempt by
the Amateurs openly to attempt to defy
the Great God FCC leads to problems that
have a nasty habit of doing far more harm
than good.

A little common sense tells one whether a
subject is business or not, and if it is
the rules say "lay off".

Experience shows that for the FCC there's no
Gray Area.  Ask them a question on some
ill-defined subject and the answer is always
NO.

If a subject looks questionable (and this one
about shareware vs public domain certainly
fills the definition) and you really want an
intelligent, and probably informed, answer,
go to the League.

The best you can accomplish by pestering FCC
is to screw things up for everyone else.

Don't we have enough problems as it is already?
Look at that crap coming from Norfolk to such
as W3IWI and some others who rank with the
best Amateur Radio can call its own.

Don't stir up problems where none exist.  Read
the rules, Part 97, and try hard to abide with
their spirit, and all will (or should) be fine.

If you want some lawyer business, go chase an
ambulance.  Leave Amateur Radio out of it.

K3TX

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

Date: 7 Feb 91 06:00:14 GMT
From: att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!caen!ox.com!umich!terminator!terminator.cc.umich.edu![e-mail]  (Scott Wood)
Subject: Tandy 100/102 series and packet radio - need hints
To: [e-mail]

I am looking for help, and input from anyone that has used the tandy
100/102 laptops with their amateur radio set-ups.  Especially with
packet or station management.

Any and all input is helpful (how, why, and what)

thanks
swood

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

Date: 13 Feb 91 15:30:43 GMT
From: agate!bionet!uwm.edu!spool.mu.edu!samsung!umich!vela![e-mail]  ( EVENSONG)
Subject: TCP/IP on 128 K
To: [e-mail]

OK, I have a computer with 128K (expandable) RAM, and 128K disk space.  How
hard would it be to actually get it set up for TCP/IP or is that too small
of memory??

swood

--
 ---- Insert favorite .signature here ----      | [e-mail]
                        | [e-mail]
Bitnet:         swood@Oakland                   | [e-mail]
  UUCP:         ...!uunet!umich!{vela, argo, unix, nucleus}!swood

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

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


Packet-Radio Digest         Fri, 15 Feb 91       Volume 91 : Issue  44

Today's Topics:
             'To:' field anarchy!
                   budlist
             Converse Node EPROM for TNC2
     packet<--->internet<--->packet gateway - my proposal
         Packet BEGINNER needs info (2 msgs)
            Shareware over 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: 7 Feb 91 12:27:16 GMT
From: munnari.oz.au!manuel!csc.canberra.edu.au!echo![e-mail]  (Carl Makin)
Subject: 'To:' field anarchy!
To: [e-mail]

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

>be a good place to work out something better. I've added an LG command
>(List Group) to my software which lists all the TO `groups' and the number
>of messages in each group. You can also type LG group_name (eg LG RAYNET)

This sounds like a good idea but I wonder at how much use it will get.
You always have your intelligent user who is interested in getting
the most out of the command set (I have perhaps 3 out of 60 users. :-( )
but the general amateur population seem to learn (perhaps) 4 commands
and stick to them.  The commands seem to be L, LL n, R n and K n.  Putting
up another command, while it would be usefull, will probably be wasted.

>had hoped to tighten things up as people got used to the idea. If anyone's
>got any better ideas, though, I'd be interested to hear them.

For the present we have to maintain some compatability with the present
structure (as painful as that is).  This shouldn't be too hard.

I would like to see a simple menuing system similar to OPUS telephone BBSs.
ie;
VK1KCM BBS Main Menu
M)essage Areas  F)iles Areas  S)ystem Bulletins
C)hange User Parameters  B)ye (Logoff)
and so on.
The same for the File and Message menus.  Some form of "Tagging"
messages for later reading.  Nothing I'm saying here is new.  It's been around
for years on OPUS Telephone BBSs and in various News readers.

I have played about with placing telephone BBSs on packet.  QuickBBS (once
I disabled the hotkeys. :-) and Maximus.  They both worked reasonably well
despite the keys being echoed and I had quite favourable comments from
those users who noticed I had a second BBS beaconing away and tried it. :-)

Carl
[e-mail]
[e-mail]
3:620/241.7
(There may be another .sig at the end.  If there is then sorry.  I'm new. :-)

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

Date: 7 Feb 91 12:57:39 GMT
From: munnari.oz.au!manuel!csc.canberra.edu.au!echo![e-mail]  (Carl Makin)
Subject: budlist
To: [e-mail]

In <[e-mail]> [e-mail] (Mike Curtis [phone]) writes:

>Most of these postings aren't worth the ether they use up, id est
>"for sale - 100 foot tower - you remove", etc., or "for sale - 50
>Icom H-T's - call Joe at the Ham Store" (well, he might as well word
>it as such - it's obvious to all of us what's going on here :-).

Absolutely NO disposals or for sales are allowed in Australia.  We have
had similar problems with our ALL@VKNET and @ASIA destinations though.

>If the user were prompted to "register" before being permitted to
>send multi-destination mail, and were forced to read through some
>common-sense rules and AGREE TO ABIDE BY THEM, a lot of these
>problems would be eliminated.  Look at how many @allus messages
>are sent out of simple ignorance.

This I agree with.  I'd love the ability to assign security levels to
users with attendant differing help levels and privledges.

Perhaps this should be included in our definitation of a new user interface
discussion that has been going on.  We've been talking about segregating
groups (areas/newsgroups etc) and slapping destination controls on would
be simplicity itself to this sort of interface.

Perhaps this just highlights how inadequate the current BBS system really is.

Carl.
[e-mail]
[e-mail]
3:620/241.7

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

Date: 7 Feb 91 02:55:26 GMT
From: ubc-cs!alberta!alberta!adec23!aunro!ve6mgs![e-mail]  (Mark Salyzyn)
Subject: Converse Node EPROM for TNC2
To: [e-mail]

Can anyone provide me with information about the Converse Node. A local
Gentleman (VE6HIM) asked me and I could not provide him with any information.
E-mail replies to ...!aunro!ve6mgs!ve6him or ...!alberta!adec23!mark would be
appreciated. Thanks in Advance, 73 de VE6MGS/Mark -sk-

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

Date: 13 Feb 91 06:28:58 GMT
From: emory!samsung!spool.mu.edu!uwm.edu!src.honeywell.com!msi.umn.edu!cs.umn.edu!kksys!edgar!brainiac![e-mail]  (Jeffrey Comstock)
Subject: packet<--->internet<--->packet gateway - my proposal
To: [e-mail]

In article <[e-mail]> [e-mail] (Bill Gunshannon) writes:
>
>
>In the case of PrepNet, it would be a definite violation of the Acceptable
>Use Policy.  I am also quite certain (although I have not read the applicable
>papers) that this would apply to The NSFNET and any other regional connected
>to it.  The rules might be different for commercial connections, but that
>greatly limits the possible connection points.

Who says ?  It sounds like some very hardcore networking research, and it's
non profit ( by law ) to boot.  What more can you ask for ?

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

Date: 7 Feb 91 10:22:40 GMT
From: milton![e-mail]  (John Siemion)
Subject: Packet BEGINNER needs info
To: [e-mail]

Hi,

I am an Electrical Engineer and would like to set up my own
packet radio data communications system (preferably with a laptop).

I don't have a radio license yet or know much about the procedures
to go about getting one.  Could you give me some items to take care of
so I can get started?

Example information needed:

    all hardware required, suggested items to buy ( <$500 )
    required and suggested reading materials
    steps necessary to get a license (can I simply take the
        technician class test or do I have to take the novice
        first and work up to technician class?...should I
        even opt for a higher class than technician?)
    access to the Internet/UUCP networks
    typical/maximum data rates possible
    is a completely portable unit possible?
    what kinds of connections are possible with what countries?


Thanks in advance.   :-)

Please respond by email if you can.

John Siemion    Internet:  [e-mail]
        FidoNet:   1:343/15  (John Siemion)

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

Date: 7 Feb 91 15:10:28 GMT
From: munnari.oz.au!manuel!coombs![e-mail]  (Daniel Carosone)
Subject: Packet BEGINNER needs info
To: [e-mail]

[e-mail] (John Siemion) writes:
[novice questions]
>Please respond by email if you can.

Please post, or at least email me too. I am also interested in these questions.
--
Dan.
    email best site: [e-mail]
     or try:              [e-mail]
               [e-mail]

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

Date: 15 Feb 91 04:04:58 GMT
From: ucivax![e-mail]  (Clark Turner)
Subject: Shareware over packet?
To: [e-mail]

In article <[e-mail]> [e-mail] (Dave Heller) writes:
>In article <[e-mail]>, [e-mail] (Clark Turner) writes:

...(deleted stuff)...

>> is and is not a "business activity" in a legal sense can be quite a
>> complicated issue in a commercial case.  To act as an [informed] attorney,
>> I need to know the language used, the relevant definitions, and the
>> standards laid down by the relevant ruling agency.  If anyone has such things
>> --- I would love the references.  I am building a file of Amateur radio
>> legal information so that if called upon by my local club or friend [who
>> is not about to spend thousands of dollars just to improve the ARS], I may
>> be of some service.
>> WA3JPG                                  quite as comfortably in the circuits
>
>
>
>This sounds like a lawyer talking.

Indeed.  I have been a lawyer for a miniscule part of my life.  Otherwise,
I am a good and kind, and semi-intelligent human being.  I support ham radio
wherever and whenever I can for free.

>Your call indicates you've been an
>amateur for at least 25 years, and

Yes.  I have been licensed for quite nearly that amount of time.  I have
not been active for all that time.  I have not had the money to keep up
with the latest, and for most of the time, have not been able to afford
any equipment at all.  I have been employed as a teacher (of math and
computer science) and researcher basically.  Currently I am a software
engineering researcher and make enough to feed myself and maintain one
HT that I got by doing side work in network research.

>presumably you've kept up with the
>popular literature, read QST regularly,
>etc.

Not so.  I have had other duties call, and have, on occasion, even shied
away from the hobby because it was so hard to get a decent conversation
other than about someone's new Japanese radio equipment, or I had too hard
a time with QRM.  Not like it used to be.

>So you should know that any attempt by
>the Amateurs openly to attempt to defy
>the Great God FCC leads to problems that
>have a nasty habit of doing far more harm
>than good.

This is patently false.  I have seen some good come from challenging the
FCC, albeit only occasionally.  Ask the League.  They have accomplished
some things.

>
>A little common sense tells one whether a
>subject is business or not, and if it is
>the rules say "lay off".

Again, this may be a good rule of thumb, but if MY FRIEND or NEIGHBOR ham
is hauled in by the FCC with a challenge to his "business use" of ham radio
- I intend to be quite ready to help him/her with the relevant rules and
be able to cite similar cases where they exist.  This is how America runs.
It is not necessarily opposed to "common sense", complicated or expensive.
It frequently is not any of these.  I work this way.,

>
>Experience shows that for the FCC there's no
>Gray Area.  Ask them a question on some
>ill-defined subject and the answer is always
>NO.

Again, I don't find this true or helpful.

>
>If a subject looks questionable (and this one
>about shareware vs public domain certainly
>fills the definition) and you really want an
>intelligent, and probably informed, answer,
>go to the League.

This is probably a good thing to do, since I am getting no helpful responses
here, and am getting a lot of the opposite for my mere interest in the
topic.

>
>The best you can accomplish by pestering FCC
>is to screw things up for everyone else.
>
No one here suggests pestering the FCC.  I don't understand where you got
this.  I want to be able to advise the local, naive amateurs in matters
that may be solved simply with some informed common sense, which is what
I am after.

>Don't we have enough problems as it is already?
>Look at that crap coming from Norfolk to such
>as W3IWI and some others who rank with the
>best Amateur Radio can call its own.

I am not familiar with the case.  It sounds as though I wouldn't be involved.

>
>Don't stir up problems where none exist.  Read
>the rules, Part 97, and try hard to abide with
>their spirit, and all will (or should) be fine.

I don't do this and I resent the automatic assumption that I was about to,
sir.  I seek to do just the opposite, and ANY person who knows me will
attest to.  The advice to read part 97 and common sense is, of course,
a good start.  I already knew that part.

>
>If you want some lawyer business, go chase an
>ambulance.  Leave Amateur Radio out of it.

Your characterization of "lawyer business" is that of a naive person who
doesn't know much except the popular incantations of uninformed people.
Ambulance chasing is not what I do, sir, and, again, your insinuation is an
insult.  I have done very little lawyering, mostly for free for amateurs
who have local ordinances to deal with for antenna restrictions.   I am
damned proud of that.  I intend to continue.  I do not cause problems, I
am called upon AFTER they arise and try to solve them quickly (outside the
legal process first), but if someone is being trampled, I will use the
force of the law to help them.  That, again, is what America is about.

If, perhaps, you wish to correspond on this topic, we should probably
do it outside the net here in the future.  Write me via e-mail or even
snail if you wish.  I would be happy to discuss the general issues further.


Clark

----------
Clark S. Turner                        "The Buddha, the Godhead, resides
WA3JPG                                  quite as comfortably in the circuits
[e-mail]                      of a digital computer or the gears
----------                              of a cycle transmission as he does
                    at the top of a mountain or in the
                    petals of a flower."
                                 - Robt. Pirsig
----------
714 856 2131    1514 Verano Pl., Irvine, CA. 92715
admitted to practice law in NY, MA, and CA.
----------

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

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


Packet-Radio Digest         Sat, 16 Feb 91       Volume 91 : Issue  45

Today's Topics:
          please add me to the mailing list
            Shareware over 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: 15 Feb 91 15:45:19 CST (Fri)
From: ssi!tao![e-mail] (gdk)
Subject: please add me to the mailing list
To: [e-mail]

Attn: Keith Petersen.


Hello,

Would you kindly add me to the packet-radio mailing list.

Thanks.

Gary D. Kline

    ...uunet!ssi!tao!gdk

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

Date: 15 Feb 91 17:25:58 GMT
From: usc!wuarchive!zaphod.mps.ohio-state.edu!know!tegra![e-mail]  (Johnathan Vail)
Subject: Shareware over packet?
To: [e-mail]

In article <[e-mail]> [e-mail] (Clark Turner) writes:

   In article <[e-mail]> [e-mail] (Louis A. Mamakos) writes:
   >In article <[e-mail]> [e-mail] (Phil Howard KA9WGN) writes:
   >
   >>If the software so much as suggests sending money to the author... then it
   >>is business.  If the software is public domain and has no hint of such a
   >>suggestion, it might not be business.  If it is being distributed for the
   ...(stuff deleted)...
   >
   >The larger problem, I suspect, is that most folks don't understand what
   >"Public Domain" really means, If they wanted to ensure that their

   The point made here appears to be a "gray" area.  I would clearly see the
   copyright restriction you append to software as taking the work out of the
   commercial realm - but who knows what the FCC would do, or a Federal court?

   AND, I agree that there is confusion about putting works into the public
   domain...and that your restrictive copyright notice makes an important
   statement at the very least.

There is a general lack of understanding between the difference
between shareware (and derivitives like crippleware) and public domain
as well as freely distributable "copyleft" software.

I don't see "shareware", which solicits funds and depends on its
distribution through networks for generating revenue to be anything
other than commercial.  If it is transfered over amateur radio you are
using amateur radio to further their business and commercial interests.

The fact that it is done and as far as I know tolerated doesn't make
it legal.

jv


"Honesty without Fear" -- Kelvinator
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

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

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


Packet-Radio Digest         Sun, 17 Feb 91       Volume 91 : Issue  46

Today's Topics:
            'To:' field anarchy! (2 msgs)
Has Part 97 changed THAT much? (was Re: PACKET->Internet Gateway) (2 msgs)
               Internet->packet Gateway

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 Feb 91 14:16:52 GMT
From: mcsun!ukc!acorn![e-mail]  (Adrian Godwin)
Subject: 'To:' field anarchy!
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>Well, a fair few of us BBS writers read this newsgroup, so maybe this would
>be a good place to work out something better. I've added an LG command
>(List Group) to my software which lists all the TO `groups' and the number
>of messages in each group. You can also type LG group_name (eg LG RAYNET)

This sounds good, but the main point I wanted to make was that there should be
some encouragement whilst actually posting - so users are gently reminded that
they're posting outside the currently accepted set of topics. I don't think
educating users is sufficient - there will always be new users who don't know
the netiquette, and don't RTFM.
Gentle prompting towards a more conveniently organised system seems much more
likely to work, provided that such a system is seen as good by most users.

Aliases might be used to remap common TO errors into the more accepted set.

It seems wrong to treat one group name differently from others, but perhaps an
entry to ALL should result in an additional prompt to try and obtain a more
specific subject from the user - there's likely to be so many users posting to
ALL that an automatic offer to create a group called that would soon be taken up,
and no more warnings would be produced. (Yes, I know I argued differently
previously - I'm just thinking it through :-))

I suspect that having a concept of a 'current group' as used by most other
newsreading software means less typing to select a batch of related news items -
but perhaps that's just my prejudice.
I certainly find the requirement to remember a whole list of 'interesting'
article numbers, then typing them in 6 at a time fairly irritating - but then
I'm used to a network terminal where it's often quicker to read every article,
hitting the 'junk' key after reading a few lines, than selecting subjects from
a list.

I imagine that the user information stored on current BBSs is quite small, and
would be vastly increased by tracking the articles read in each group, rather
than globally. Is this likely to be a problem ? Do packet BBSs have much larger
user bases than telephone BBSs ?

I'm not especially interested in a religious argument about the merits of using
TCP/IP for news distribution - though I would be interested to read a balanced
summary of any previous discussions. It may well be that news will eventually be
distributed between BBSs and TCP/IP users by another method, and fixed TO
groups would certainly assist that. If you feel inclined to start that war,
consider this discussion to be about user interfaces to newsreaders/posters,
regardless of whether that interface runs locally or on the BBS.

--
--------------------------------------------------------------------------
Adrian Godwin                                        ([e-mail])

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

Date: 7 Feb 91 21:59:57 GMT
From: shelby![e-mail]  (paulf)
Subject: 'To:' field anarchy!
To: [e-mail]

There is an easier solution to all of this.  With the conversion of most
minicomputing lines to RISC architectures (SUN, DEC, SGI et al), there are
a ton of surplus unix boxes appearing on the market, at prices far less than
the typical 386 box.

Has anybody written the equivalent of G protocol KISS code?


-=Paul Flaherty, N9FZX      | Without KILL files,
->[e-mail] | life itself would be impossible.

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

Date: 7 Feb 91 16:45:29 GMT
From: pa.dec.com!shlump.nac.dec.com![e-mail]  (Paul Koning)
Subject: Has Part 97 changed THAT much? (was Re: PACKET->Internet Gateway)
To: [e-mail]

|>
|>  My copy of Part 97 is in the ARRL "The FCC Rule Book". None of these
|>paragraphs (a) exist or (b) say the same thing. Has Part 97 really changed
|>that much since November 1, 1987?
|>

It certainly has!  Part 97 was completely rewritten last year.  Throw out
your ancient copy and get a new one...

    paul

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

Date: 7 Feb 91 17:07:38 GMT
From: idacrd![e-mail]  (Robert McGwier)
Subject: Has Part 97 changed THAT much? (was Re: PACKET->Internet Gateway)
To: [e-mail]



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

Date: 7 Feb 91 21:39:41 GMT
From: att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!clarkson!@ucbvax.Berkeley.EDU  (Tadd,KA2DEW, ,3152621123)
Subject: Internet->packet Gateway
To: [e-mail]



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

Date: (null)
From: (null)
What if the guy originating the message IS a ham but is typing something
that he/she doesn't expect to go over ham radio packet?
                   Tadd - KA2DEW

[ KA2DEW @ KA2JXI.#NNY.NY.USA.NA                - Tadd Torborg             ]
[ [e-mail]                   - 26 Maple St - PO Box 330 ]
[ NEDA (North East Digital Association) Editor  - Colton, NY 13625         ]
[ Clarkson University                           - 315-262-1123             ]

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

Date: (null)
From: (null)
Yes Dana:

There was a rewrite in 1988, with some other changes made in 1990.  The
ARRL asked that the very paragraphs used in this citation be made more
explicit and less vague and open to interpretation and the FCC rejected
the request.  The ARRL has tried to make changes that would help but many
times their efforts have gone awry.  The most egregious are the codification
and sanctification of AX.25L2V2 in Part 97 after we were explicitly
promised that this would NOT occur and the rewrite in 1988 that included
more confusing language, and in some cases contradictory language on
bits, bauds, spectral occupancy, and more.  I do wish they would take
the time to ask people with some expertise/interest to look things over
and to comment in a timely fashion.


These opinions notwithstanding, I am supportive of a strong effort, if not
by us, then by the FCC to clean up ALL@USA which is in a gray area in Part
97 AT BEST IMHO.  The ARRL (the general manager in particular) will have
a policy statement in the NEXT QST which attempts to address this problem
and call for a solution.  Too bad we had to have FCC action before our
own folks got in behind the problem.

AMSAT-NA, a large use of packet networks for distribution of news, has
taken an extremely conservative stance of late (the last several months)
after we had one of our officers, W2RS, point out to us that new bulletins
containing our telephone number, or announcing software availability, etc.
was, at best, not in the spirit of those portions of Part 97 concerned
with business communications.  We told WEBER that they could NOT do their
planned mission (having paid employees do experiments on their satellite)
using amateur radio frequencies and more.  If others don't take similar
stands, and exercise similar restraint, then the FCC can AND SHOULD step
in.  It is my opinion that they have gone too far with this particular
set of citations but there is NO ONE to blame buts ourselves.

Bob N4HY

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

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

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


Packet-Radio Digest         Tue, 19 Feb 91       Volume 91 : Issue  47

Today's Topics:
               New version of F6FBB BBS
               Tjp Octopus Diode Matrix

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: Tue, 19 Feb 91 03:32:13 CST
From: [e-mail]
Subject: New version of F6FBB BBS
To: [e-mail]

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


I have uploaded for ftp the lastest version of the multi-users,
multi-languages BBS of F6FBB on both tomcat and nic.funet.fi

the files are :

fbb512d1.zip  zip of disk1
fbb512d2.zip  zip of disk2
fbb512d3.zip  zip of disk3

the files are in bbs/f6fbb on tomcat and in pub/ham/incoming on nic.funet.fi

You have to pkunzip each file on a floppy. then you add pkunzip.exe on
disk1.

An automatic installation is provided for disk C: (only disk c:).
The disk3 contains a simplified BBS without dos servers. This disk
is not needed except if you want the simplified BBS.

This version includes a compressed forwarding which provides a gain of
about 40% on the channel.

The distribution is coming directly from the author.

The author can be contacted on packet at f6fbb@f6fbb.

I can also forward him  Emails.

or directly answer to your questions.

73s from fe6cnb Remi

PS: Due to hardware problem on our Internet gateway, if you can not contact
me at this address you can use [e-mail]

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

Date: 17 Feb 91 18:03:41 GMT
From: pacific.mps.ohio-state.edu!linac!uwm.edu!rpi!clarkson!@tut.cis.ohio-state.edu  (Tadd,KA2DEW, ,3152621123)
Subject: Tjp Octopus Diode Matrix
To: [e-mail]

About 2 years ago one John Painter (THE john painter or Tjp) created
a 8x8x2 diode matrix board for matrixing 8 RS232 ports together at
the request of KA2DEW and WA2WNI for the purpose of making TheNET
nodes of greater than 2 ports.  After about 9 months John left
the area of DEW and WNI in search of greener pastures.  Eventually
the boards ran out.  John traded the rights and his remaining stock
to NEDA and said remaining stock is now gone.  NEDA has created
a slightly improved version that they are calling the Hexipus.
  For more details send a S.A.S.E. to NEDA, Box 563, Manchester NH 03105.
  (NEDA is a non-profit organization which promotes amateur radio packet
networking)

[ KA2DEW @ KA2JXI.#NNY.NY.USA.NA                - Tadd Torborg             ]
[ [e-mail]                   - 26 Maple St - PO Box 330 ]
[ NEDA (North East Digital Association) Editor  - Colton, NY 13625         ]
[ Clarkson University                           - 315-262-1123             ]

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

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


Packet-Radio Digest         Thu, 21 Feb 91       Volume 91 : Issue  48

Today's Topics:
           HF Packet a Silly Idea! (2 msgs)
             Info for homebrewing
               Info for homebrewing TNC
                  MSYS HELP
               Nosnet for atari st????
               tcp/ip on dec rainbow ??

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 Feb 91 16:19:14 GMT
From: hpcc05!hpdmd48![e-mail]  (Bob Davidson)
Subject: HF Packet a Silly Idea!
To: [e-mail]

After having a chance to compare packet on HF to Amtor on HF, I can't
understand why people fool with packet on HF.  It seems like a misapplication
of technology.  I suspect the reason it is not effective is that the
channel on HF is so different than VHF (more noise and qrm for one thing and
signal dispersion due to propagation effects for another).  It seems like
the reliability of Amtor more than makes up for the 100 baud rate vs 300
baud of packet.   Perhaps a rethinking of HF packet and a system of
interconnects based upon Amtor is what is needed.  I've fooled a bit with
Aplink and that seems like a move in the right direction, but not a perfect
solution either.

Is anyone aware of a serious technical comparison of the the two?  I haven't
found any commerical packet operations on HF, which leads me to think that
hams haven't thought out this one.

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

Date: 20 Feb 91 23:11:26 GMT
From: hpl-opus!hpnmdla![e-mail]  (Glenn Elmore)
Subject: HF Packet a Silly Idea!
To: [e-mail]

In rec.ham-radio.packet, [e-mail] (Bob Davidson) writes:

>
>  After having a chance to compare packet on HF to Amtor on HF, I can't
>  understand why people fool with packet on HF.  It seems like a misapplication

>
>  Is anyone aware of a serious technical comparison of the the two?  I haven't
>  found any commerical packet operations on HF, which leads me to think that
>  hams haven't thought out this one.

I think 300 bps FSK packet probably is a pretty severe misapplication
but that isn't all that is going on. The several millisecond variability
in multipath signal arrival times makes signalling much faster than
"old fashioned" baudot pretty unattractive... particularly below 14 MHz.

  Take a look at the 9th ARRL Computer Networking Conference proceedings.
Ray Petit, w7ghm has a pair of articles related to his "cloverleaf"
HF data communications system. This is, in Ray's words " a modulation and
coding scheme which offers very worthwhile improvements over HF packet,
AMTOR and even CW". It is an adaptive scheme which is quite spectrally
efficient. Channel width is 100 Hz with no guard band and data rate can be
more than 100 bps under the best conditions.

  Also take a look at Tom Clark's, w3iwi, papers "Comments on HF Digital
Communications", Parts 1 and 2. Tom comments as a member of "SKIPNET"
and addresses some of the fundamental issues.

73

Glenn Elmore -N6GN-

N6GN @ K3MC
[e-mail]
[e-mail]

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

Date: 19 Feb 91 21:44:04 GMT
From: petunia![e-mail]
Subject: Info for homebrewing
To: [e-mail]

    I'm interested in homebrewing a TNC and associated cicuitry
for packet to interface with the IBM machine.  I will most likely
use the serial com port (RS232) but may consider a bus card.
This project is for the required Senior Project for my B.S. in
Electronic Engineering here at CalPoly San Luis Obispo.  Any info
concerning chips, schematics, protocalls(sp?), ideas, or just helpful
tips about homebrewing for packet would be greatly appreciated.
               Thanks in advance!
                        Jim Fellows
Please e-mail to [e-mail]

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

Date: 19 Feb 91 21:57:05 GMT
From: dog.ee.lbl.gov!hellgate.utah.edu!caen!zaphod.mps.ohio-state.edu!usc!ucselx!petunia![e-mail]
Subject: Info for homebrewing TNC
To: [e-mail]

    I'm interested in homebrewing a TNC and associated cicuitry
for packet to interface with the IBM machine.  I will most likely
use the serial com port (RS232) but may consider a bus card.
This project is for the required Senior Project for my B.S. in
Electronic Engineering here at CalPoly San Luis Obispo.  Any info
concerning chips, schematics, protocalls(sp?), ideas, or just helpful
tips about homebrewing for packet would be greatly appreciated.
               Thanks in advance!
                        Jim Fellows
*****>Please e-mail to [e-mail]********

          Sorry about the repost! but the address is wrong!

E-mail is at [e-mail]    OR
for bangers....
           batman.elee.calpoly.edu!jfellows
It's in the header anyways.  Thanks again!

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

Date: 18 Feb 91 17:07:46 GMT
From: [e-mail]  (Scott R. Weis KB2EAR)
Subject: MSYS HELP
To: [e-mail]

I am having problems with MSYS Version 1.10, I am tring to set up this
system as an TCP/IP node and also a netrom node.  The problem I am
haveing is that when an ip station connects it send a sys req and my
side ignores it.

My info:
netrom call kb2ear-8
tcp/ip call kb2ear-8
id call     kb2ear-8

Tnx,
--
Scott R. Weis KB2EAR
Internet:       [e-mail]
Packet:         KB2EAR @ NN2Z.NJ.USA.NA
Snail Mail:     10 Palmer Rd., Kendall Park NJ, 08824-1228
Phone:          [phone]

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

Date: 20 Feb 91 04:11:44 GMT
From: bu.edu!xylogics!samsung!umich!vela![e-mail]  ( EVENSONG)
Subject: Nosnet for atari st????
To: [e-mail]

Is there a version of the newer net (nosnet) that has been ported down for
the atari?  I downloaded the net file off of atari.archive.umich.edu, and I
have not as of yet found the nosnet

swood


--
 ---- Insert favorite .signature here ----      | [e-mail]
                        | [e-mail]
Bitnet:         swood@Oakland                   | [e-mail]
  UUCP:         ...!uunet!umich!{vela, argo, unix, nucleus}!swood

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

Date: 20 Feb 91 15:43:52 GMT
From: hpfcso!hpfcdj![e-mail]  (Bill Morrison )
Subject: tcp/ip on dec rainbow ??
To: [e-mail]

    I would like to know if anyone has attempted or accomplished porting
the ka9q code for tcp/ip to the dec rainbow.  It seems like a reasonable
machine to do it with as they can be had very cheap.

    I guess the access to communication ports is quite different and
that part would have to be redone.  Since I have aquired two of these
machines for the grand total of $33 I am interested in dong this.

    One thing I guess I need is the technical documentation to do this
If anyone has it please contact me.

    Is anyone else interested???

        Bill Morrison n0kma or [e-mail]

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

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


Packet-Radio Digest         Fri, 22 Feb 91       Volume 91 : Issue  49

Today's Topics:
                  HF Packet
           HF Packet a Silly Idea! (2 msgs)
          INTERNATIONAL TRAFFIC HELP REQUEST
              Nodes in Venzuela
             Packet-radio without a TNC.
               tcp/ip on dec rainbow ??

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: Thu, 21 Feb 91 23:42:50 GMT
From: toth!dave (David B. Toth)
Subject: HF Packet
To: [e-mail]

If you set paclen to 1, and retries to 0, you have changed AX.25 in
a very coarse way to mimic AMTOR ...
And AMTOR deletes (i.e.converts) lower-case ...
the real problems are:
1) we need better modems - DSP stuff being worked on by N4HY and others.
2) we need a better  HF protocol ...

I listen to this nonsense re how bad HF packet is - listen boys, we move
a lot of mail this way - a satellite link would be much better, but we DO
move mail.

Our real problem at the moment is channel congestion ...

And CLOVER does not really offer an advantage over vanilla AX.25 ...
if you put 24 stations on freq with CLOVER, you WILL degrade throughput.
Hank Oredson (W0RLI) told me the figures they obtained with 300 baud
AX.25 with 2 stations on a freq were at least as good if not better, and
you didn't have to lock receivers together with WWV ...

According to N4HY, he has achieved a thruput improvement with a new DSP
modem simply by having the modems shift the Receive freq to lock the two
stations on-frequency ... works even with stations that start 80 Hz apart.

Hope that reveals the PRACTICAL side of HF packet .. I know, I run it
and supervise it every day on 14.109 ...

73, Dave VE3GYQ

ria.ccs.uwo.ca!toth!dave

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

Date: 21 Feb 91 14:17:00 GMT
From: deccrl!news.crl.dec.com!shlump.nac.dec.com!ryn.mro4.dec.com!ultnix.enet.dec.com![e-mail]  (Patrick St. Joseph Teahan Taber)
Subject: HF Packet a Silly Idea!
To: [e-mail]

In article <[e-mail]>, [e-mail] (Bob
Davidson) writes:

|>After having a chance to compare packet on HF to Amtor on HF, I can't
|>understand why people fool with packet on HF.  It seems like a misapplication
|>of technology.

Look in the oft-quoted "basis and purpose of amateur radio."  People
fool with it because that's part of what amateur radio is about --
experimentation.  (Since we're non-commercial, experiemtation doesn't
have to be confined to "what's most efficient" or previously unexplored
areas.)  Likewise, the experimentation is personal -- it doesn't have to
be justified to a commitee. If you like HF packet and can find other
people who share your interest, everything is cool.

|>
|>Is anyone aware of a serious technical comparison of the the two?  I haven't
|>found any commerical packet operations on HF, which leads me to think that
|>hams haven't thought out this one.
|>

Again, we don't have the same constraints as commercial radio.  We can
use modes in places that it doesn't make sense just because we feel like
it (let's not revive the code wars.) We have thought it out -- our goals
are just different.

In reference to an article, I believe there was one in a recent (within
two years) QEX that addressed the question to some extent.

--
                         >>>==>PStJTT
                     Patrick St. Joseph Teahan Taber, KC1TD

If I was authorized to speak for my employer, I'd be too important to
waste my time on this crap....

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

Date: 22 Feb 91 04:59:06 GMT
From: pacbell.com!tandem!netcom![e-mail]  (James Paul)
Subject: HF Packet a Silly Idea!
To: [e-mail]

In article <[e-mail]> [e-mail] (Bob Davidson) writes:
>
>After having a chance to compare packet on HF to Amtor on HF, I can't
>understand why people fool with packet on HF.  It seems like a misapplication
>of technology.  I suspect the reason it is not effective is that the
>channel on HF is so different than VHF (more noise and qrm for one thing and
>signal dispersion due to propagation effects for another).  It seems like
>the reliability of Amtor more than makes up for the 100 baud rate vs 300
>baud of packet.   Perhaps a rethinking of HF packet and a system of
>interconnects based upon Amtor is what is needed.  I've fooled a bit with
>Aplink and that seems like a move in the right direction, but not a perfect
>solution either.
>
>Is anyone aware of a serious technical comparison of the the two?  I haven't
>found any commerical packet operations on HF, which leads me to think that
>hams haven't thought out this one.

Without getting into a discussion of how amateur radio is intended partly
for experimentation and personal interest, here's a couple objective
comparison points between AMTOR and PACKET. (I am _very_ familiar with
packet, but no expert on AMTOR. If I'm in error, I have no doubt it will
be pointer out! :-)

Both modes use similar bandwidth.
Both modes employ data integrity protocols.
Packet allows multiple conversations on a single channel without
  coordination between parties.(I don't think AMTOR does.)
Packet keys the TX only when a packet is sent. (I believe AMTOR,
  being synchronous, keys the TX even when no data is being sent.)
Packet on HF is 300 bps. Amtor is generally 100 bps.

I think there are solid arguments for packet being more efficient than
AMTOR. Packet uses a network protocol, making multiple connections and
unattended operation simple, where it would be perhaps impossible with
AMTOR. If you only ragchew on HF, it's one argument. If you run a
chat RT or BBS, it's quite another. One ham's boredom is another ham's
quivering excitement. Each to his/her own mode, I say. Many of us are
in this for the fun of it!

73 de James N6SIW

--
James L. Paul

UUCP: [e-mail]        | AppleLink: D1231 | America Online: JLPaul
Packet: [e-mail] | GEnie: J.PAUL    | CompuServe: 72767,3436
Voice: 415 377 1981 w/machine | Delphi: JLPaul   | Work FAX: n/a
Disclaimer? I won't take credit for any such thing!

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

Date: Thu, 21 Feb 91 13:12:04 PST
From: Eric Westreich <[e-mail]>
Subject: INTERNATIONAL TRAFFIC HELP REQUEST
To: ALL <[e-mail]>

After learning how the National Traffic Service (NTS) works, I am wondering how
 to send international traffic to a non-HAM. Also, are there internet/bitnet pa
cket connections?

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

Date: 21 Feb 91 15:58:45 GMT
From: psuvm![e-mail]
Subject: Nodes in Venzuela
To: [e-mail]

     Does anyone know if there are any nodes in Venzuela, and if so, could
you send me a list of the nodes?  We have a student here who would like to
talk to her friends there, and there don't seem to be any sites Bitnet
can access.

                              Thanks!

                                 [Tim]

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

Date: Thu, 21 Feb 91 09:53:44 GMT
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <[e-mail]>
Subject: Packet-radio without a TNC.
To: [e-mail]

>From : G6FCL @ GB7DUG._32121.GBR.EU
>To      : BAYCOM @ GBR.EU
>Date    : 910216/1128
>Msgid   : BF 230@GB7DUG, 31894@GB7SDN $230_GB7DUG
>Subject : BayCom - Packet without a TNC
>Path    :
GB7IMB!GB7TCM!GB7TIC!GB7ZEN!GB7BIL!GB7ZPU!GB7HXA!GB7DDX!GB7WNM!GB7TLH!GB7VLS!GB7CFB!GB7MXM!GB7ESX!GB7ZAA!GB7SEK!GB7HSN!GB7DUG


>From : G6FCL @ GB7DUG._32121.GBR.EU
Hello,

BayCom has been with us for a couple of months now and has proved very
popular with it's new users. BayCom 1.20 is much like Digicom, it gives
you all of Packet Radio's facilities, but without the need for a TNC!

BayCom runs on most IBM (tm) and true clones, in fact there are very few
PC's that it will not run on. Hardware requirements are simple: Any PC
be it XT or AT with either a serial port set as COM1 or COM2 (most PC's
have a single COM1 port as standard) added to this is a very simple
modem that plugs into the serial port. The basic modem supports VHF/UHF
packet, but you can of course use an alternative design, if you wish to
use both VHF/UHF and HF Packet Radio, oh yes! and a transceiver of course!

The software is supplied free to anyone who supplies the following items:
3.5" 720K or 5.25" 360K formatted disk, return mailer (addressed and
stamped for return) - If you want copies of circuits and PCB details, then
please include a small payment to cover photocopying costs.

BayCom 1.20 is the work of two German radio amateurs DL8MBT and DG3RBU
both are commited to keeping amateur radio a hobby, this is the reason
Digicom and BayCom are distributed freely, it is stronly recommended that
a small donation of 20DM (about 7 pounds) be sent either direct to the
authors or via myself (if via myself, please obtain a 20DM note from any
branch of Thomas Cook's or a UK Bank) - All monies are used to promote
the design and continued programming of both BayCom and Digicom, any
excess is used to finance the German Node system.

In addition, I require a commitment from you that you will not alter the
code in any way and distribute such altered code, and should you pass on
copies to others, that you will pass on only copies of the original disk
so a new user has all the original files on his/her disk.

BayCom is Public Domain, but the authors retain copyright, therefore if
you see BayCom being sold in any shape or form, it is breach of this
copyright, BayCom is free, you don't have to make the donation, but
if you don't make a donation, you'll be one of very few!

Copies are obtained from:

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

Please do not forget the disk mailer and postage.
----- End of message 31894 from G6FCL @ GB7DUG._32121.GBR.EU -----

>Via       Pete Lucas [e-mail]  [e-mail]

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

Date: 21 Feb 91 16:40:16 GMT
From: rochester!kodak!eastman!b56vxg.dnet%kodak.com![e-mail]  (JON HARDING)
Subject: tcp/ip on dec rainbow ??
To: [e-mail]

In article <[e-mail]>, [e-mail] (Bill Morrison ) writes...
>the ka9q code for tcp/ip to the dec rainbow.  It seems like a reasonable
>               Bill Morrison n0kma or [e-mail]
I might be confused but I think the Rainbow we have at work runs MS-DOS. That
being the case, I would think the IBM stuff would run with out too much pain.
N 2 K Z J N 2 K Z J N 2 K Z J N 2 K Z J N 2 K Z J N 2 K Z J N 2 K Z J N 2 K Z J
|       Jon Harding, N2KZJ      email: [e-mail]          |
|               * I don't represent KODAK by word or deed. *                  |
N 2 K Z J N 2 K Z J N 2 K Z J N 2 K Z J N 2 K Z J N 2 K Z J N 2 K Z J N 2 K Z J

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

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


Packet-Radio Digest         Sat, 23 Feb 91       Volume 91 : Issue  50

Today's Topics:
                 BAYCOM Again
                  HF Packet
               Packet-Radio Digest V91

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, 22 Feb 91 15:33:04 PLT
From: Robert Giden <[e-mail]>
Subject: BAYCOM Again
To: Packet Radio <[e-mail]>

Sent this note to I-PACRAD.  Looks like I sent it to a log file
instead of the packet group - if I doubled the message, I apologize.
Just want to make sure the message gets out.
- - - - -
>
>Enjoyed hearing about BAYCOMM (a TNC program for IBM-PC and IBM clones)
>from an entry by Jim Mahoney, G6FCL.
>
>I agree with submitting "contributions" to the authors for this piece of
>public domain software.  I would like to know of an address in the
>states where money can be sent and the software obained.  Sending SASE'd
>disk mailers to England or Germany is not an automatic chore. I needed to
>send Swedish krowns to Sweden once and was charged for a telephone call
>from one Bank's branch to another for them to find out how they should do
>their own business.  International banking is not a rural USA strongpoint.
>
>Where can BAYCOMM be had in the US and what are the names and addresses of
>DL8MBT and DG3RBU who developed this package?
>
>Thanks and 73's -
>
>                                               The "OTHER" Washington
>                                           ____________________________
>ROBERT GIDEN, N7KCG                        \   /\/\             /\  /\|
>Sys-Analyst & Programmer        P   ______  |  /\/\               /\  |
>Collete of Ag & Home Ec         aO \      / \   /\          Spokane + |
>Washington State University     cc \  /\ \   |+Seattle                |
>PULLMAN, WA 99164-6230          IE  |  /\ \ /    /\                   |
>U.S.A.                          fa   \     |     /\                   |
>                                in   |          /\      Pullman/WSU->*|
>TELEPHONE: [phone]         C     \        /\          ____________\
>Fax: [phone]                      ----\   /\    _____/
>BITnet: GIDEN@WSUVM1                        \-------/

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

Date: Fri, 22 Feb 91 10:23:32 -0800
From: Doug Faunt N6TQS 415-688-8269 <[e-mail]>
Subject: HF Packet
To: toth![e-mail]

Since there's been some discussion of PICCOLO, has any hams tried that?
Is it legal?  Is there now or planned support for it in either the AEA
boxes, or the TAPR DSP boards?

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

Date: Fri, 22 Feb 91  12:04:09 MST
From: "J. Richard Haefer" <[e-mail]>
Subject: Packet-Radio Digest V91
To: "Packet-Radio List" <[e-mail]>

From: J. Richard Haefer
I'D LIKE TO HEAR FROM OTHER  USERS OF MACINTOSH SYSTEM COMPUTERS WITH PACKET
RADIO, I.E, TYPES OF SOFTWARE AVAILABLE, HARDWARE CONNECTIONS.
ddn ucsd.edu(Packet-Radio)
SEND RESPONSE VIA NET OR INDIVIDUALLY TO: ICRJH@ASUACAD

THANKS!

   Mariachi Diablos del Sol, School of Music,
   Arizona State University, 85287-0405
   [phone], message at 965-3371
   <><><><><><><><><><><><><><><><><><><><><>
In-Reply-To:  note of 02/22/91 06:17

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

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


Packet-Radio Digest         Sun, 24 Feb 91       Volume 91 : Issue  51

Today's Topics:
                  HF Packet
               HF Packet a Silly Idea!
            International Traffic via NTS
                   packett
                   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: 23 Feb 91 07:08:04 GMT
From: hpcc05!hpdmd48![e-mail]  (Bob Davidson)
Subject: HF Packet
To: [e-mail]

>If you set paclen to 1, and retries to 0, you have changed AX.25 in
>a very coarse way to mimic AMTOR ...

I am not sure I believe this as you would also have to change the signaling
rate. I also think the protocol is a bit different, but I will accept what
you say about protocol for now.

>And AMTOR deletes (i.e.converts) lower-case ...

this is a problem but not one that I am concerned with.  I expect that
any alphabet can be adapted to any protocol.  Of course, you may not
be able to stay with a 8 bit character on the communications channel level
but that shouldn't pose a problem either.

>the real problems are:
>1) we need better modems - DSP stuff being worked on by N4HY and others.

That's nice but I understand that there are ~45000 pk232's and I don't
know how many Kantronics boxs out there that work great on amtor and lousy
on HF packet, at least in my experience.  The DSP may help but the
implementations I've seen are pricey ($1000 US. vs. $300 US.) Maybe that
will come down with volume though.  A better solution might be to come up
with a system that would allow all those non-DSP boxes to work better and
still tie into the VHF packet system.

>2) we need a better  HF protocol ...

AMTOR.....just kidding!

>I listen to this nonsense re how bad HF packet is - listen boys, we move
>a lot of mail this way - a satellite link would be much better, but we DO
>move mail.

I didn't say it didn't work, I just said it worked poorly.  I've tried to
"read the mail" on HF packet and usually lose patience and move on to
something else before I get much read.  Rather, much new read, I do read
a lot, over, and over, and .......  I expect a satellite would be better
because the channel is more benign with respect to noise and signal
dispersion, although I suppose it has its own set of problems, doppler, etc.

On the other hand, I frequently monitor Amtor communications with much
success.  Then the only thing that limits my listening in the message
content.

BTW.  most (99%) of my impression is based upon monitoring, not actual
communications with other stations.  I guess it's a habit I picked up
DXing many moons ago.   As I mentioned in my first posting, I would
like to hear of actual data.  If I don't, I guess I will have to make it
up myself.  :)

Regards,

Bob

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

Date: 23 Feb 91 16:07:47 GMT
From: netcom![e-mail]  (James Paul)
Subject: HF Packet a Silly Idea!
To: [e-mail]

In article <[e-mail]> [e-mail] (99700000) writes:
>
>In article <[e-mail]> [e-mail] (James Paul) writes:
>>...1
>>Both modes use similar bandwidth.
>...
>>Packet on HF is 300 bps. Amtor is generally 100 bps.
>>
>I believe the original contention was that under fairly typical HF band
>conditions - multipath and fading and QRM - the probability of getting
>a packet through is pretty low, due to the higher baud rate and packet
>length.  Packet clearly has a lot of additional functionality over
>AMTOR, but it's only functional if the packets get through.

True. Of course, at 300 bps, transmission time is less, so some types
of fading and QRM might be less likely to affect Packet. I agree that
AMTOR might be more resilient to poor path conditions, though. You
make a good point.

--
James L. Paul

UUCP: [e-mail]        | AppleLink: D1231 | America Online: JLPaul
Packet: [e-mail] | GEnie: J.PAUL    | CompuServe: 72767,3436
Voice: 415 377 1981 w/machine | Delphi: JLPaul   | Home Fax: [phone]

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

Date: Sat, 23 Feb 91 15:29 EDT
From: <[e-mail]>
Subject: International Traffic via NTS
To: [e-mail]

spawn edit pack.txt
Original message:
From: Eric Westreich <[e-mail]>
Subject: INTERNATIONAL TRAFFIC HELP REQUEST
To: ALL <[e-mail]>

After learning how the National Traffic Service (NTS) works, I am wondering how
 to send international traffic to a non-HAM. Also, are there internet/bitnet pa
cket connections?

------------------------------
*** Reply:
The Atlantic Region Net (ARN) is the one that would handle international
third-party traffic.  On NTS, it is routed to EAN and from there to ARN.  Good
luck!--73,

      Betsey Doane, K1EIC STM CT.  <[e-mail]>

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

Date: 23 Feb 91 19:49:01 GMT
From: n8emr!cmhgate!f170.n226.z1.FIDONET.ORG![e-mail]  (Ron France)
Subject: packett
To: [e-mail]

I have a xt-clone computer with 640 k..i would like to be able to call my
copmputer at home an enter a password and be able to run my packett
station remote.Does anybody know how i can do this?
tnx De Ron N8LPX

--
Ron France via cmhGate - Net 226 fido<=>uucp gateway Col, OH
UUCP: ...!osu-cis!n8emr!cmhgate!170!Ron.France
INET: [e-mail]

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

Date: Sat, 23 Feb 91 15:53:06 GMT
From: toth!dave (David B. Toth)
Subject: Piccolo
To: [e-mail]

In response to [e-mail] re use of PICCOLO :
have heard of no plans re an implementation ...
However, it IS obvious that we do need work on protocols optimized
for the kind of links we use ... we could in fact use better protocols
for point to point links when the identities of the 2 stations remain
a constant ...

Dave VE3GYQ
ria.ccs.uwo.ca!toth!dave

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

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


Packet-Radio Digest         Mon, 25 Feb 91       Volume 91 : Issue  52

Today's Topics:
                 AmigaNOS 2.5
             Beginner's Questions
                  HF Packet
             Packet-radio without a TNC.

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

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 Feb 91 06:08:34 GMT
From: portal!cup.portal.com![e-mail]  (John L Ferguson)
Subject: AmigaNOS 2.5
To: [e-mail]

WA2KDL mentions in a packet message the version 2.5 of AmigaNOS is in the
U.S.A.  Where can I get this version?  GEnie has version 1.9 (which
gurus my machine or other bizzare things).   Thanks.

73, John  KF0OU

 /fancy-sig off                [e-mail]

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

Date: 24 Feb 91 17:11:46 GMT
From: zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!asuvax!stjhmc!f8.n720.z6.fidonet.org![e-mail]  (Jimmy Tsai)
Subject: Beginner's Questions
To: [e-mail]

In an article of <14 Feb 91 04:33:16 GMT>, [e-mail] (Tyng-Jing
Yang) writes:

 TY>1. How can I have/apply a Internet connection with packet radio ?
 TY>   I mean in Florida state.
 TY>2. Can I have Radio-Internet connetion in Asis (Taiwan) ?
 TY>   I might go back to Taiwan after I finish my MS degree.

Very happy to meet you, Happy new years....
You must have a licence of amateur radio to operate packet-radio,
so that you can have a Call-sign,.... Do it in U.S.A., I suggest it.

Here in Taiwan, some Sysops of BBS pass the Ham-examination hold in
last year, trying to build up their Packet-radio network, we operate
MBL514CC (in Chinese) on 145.80, 145.20 mhz (FM mode) using 1200 bps
TNC (mainly TASCO TNC-22) , for mail-exchanging service between BBSs
, and some sysop (like BV5AF, B-L Lin) ,  join the ASIA-NET on
14.101 mhz using 300 bps TNC,....

Our next step is to operate Satellite communication, it's a difficult
job because of lacking imformation and document...

Any way, we make the first step, welcome your come back and join us,
good luck to you.....

73 de BV2AC, Jimmy Tsai, sysop of 6:720/8@Fidonet








--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!6!720!8!Jimmy.Tsai
Internet: [e-mail]

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

Date: Sun, 24 Feb 91 06:53:39 PST
From: [e-mail] (RICHARD HAREL)
Subject: HF Packet
To: "[e-mail]"@HERMES.intel.com

With all the talk recently on this digest re: HF Packet vs. AMTOR
I would just like to add that the International Red Cross and all
of the U.N. organizations have opted to use AMTOR as their standard
HF digital communications protocol. (At least in Europe, the Middle East
and Africa). According to my source in the U.N. (Pat - K0OO) they did this
after extensive testing between RTTY - 50 baud, Packet, and AMTOR on
frequencies much LESS congested than our amateur bands.
No doubt that Packet does have some advantages over
AMTOR such as lower case, the ability to transfer binary characters,
APLINK commands are somewhat limited etc. In any case, most of the
traffic that flows over Europe still chooses HF Packet under circumstances where
they can't use VHF and higher. When the path is very good, it works very well.
Most of the major transfer points use beams and only 100 watts.
It would be great to see the Packet protocol incorporate some kind of
"Dynamic PACLEN" which would automatically vary the "PACLEN" from say 16
to 512 depending on the quality of the path (determined by amount of retries +
other statistical data based on the framing).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
E-Mail:                  |Pigeon:          |Land Line:  |Packet:
[e-mail] |P.O. BOX 6457    |972-2-785578|4X1DA @4Z4SV.ISR.EU
             |JERUSALEM, ISRAEL|            |(SYSOP @4Z4SV)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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

Date: 24 Feb 91 20:03:32 GMT
From: dagorlad![e-mail]  (Andrew Robinson)
Subject: Packet-radio without a TNC.
To: [e-mail]

Is BayCom available via anonymous FTP?  If not, I would like to suggest that
somebody who has the program should upload it.  Maybe the circuit diagrams
could be put in a file and uploaded along with the program.  If someone does
upload the program, please inform us by posting to this newsgroup.  Thank you.

     -- Andy

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

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


Packet-Radio Digest         Tue, 26 Feb 91       Volume 91 : Issue  53

Today's Topics:
               Alinco DJ160 and MFJ TNC
             Beginner's Questions
              NOS Documentation
             Packet-radio without a TNC.
             Packet via the phone
              RUDAK II activated

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 Feb 91 19:26:02 GMT
From: beguine![e-mail]  (Jeffrey Perry)
Subject: Alinco DJ160 and MFJ TNC
To: [e-mail]

Has anyone connected this HT to the MFJ TNC. Do you know which wires connect
to which wires? Of particular interest is the mic wire from the HT.

Any help would be greatly appreciated. It should would be nice to save a
Long distance call to Alinco!

    Thanks in advance!  N1ILY -  Jeffrey Perry

Please respond to this email address. I will summarize if needs be.
I may read it sooner if you send it to [e-mail]

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

Date: 25 Feb 91 20:18:41 GMT
From: sdcc6![e-mail]  (Jung Ching Ho)
Subject: Beginner's Questions
To: [e-mail]

 Hi Mr. Tsai,

Happy new year.  I am very glad that I can see more ham information
from Taiwan.  Presently, I am a grad. student from Taiwan and
holding a US ham license.  I like to get in touch from Taiwna from
the HF band.  I am usually on the 10 m band and I like to hear some
current status of the ham radio in Taiwan.  I am appreciated that
you can provide some information for me.  TNX

Only once have I heard a weak signal from Taiwan at 21.265MHz, I
think I have heard Tim Chen, BV2A, and never again.

Now I am using a KENWOOD TS-440S/AT with a dipole antenna and hope
that I can hear your voice from 10 m band.

            73 de JC HO, N6YEI

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

Date: 25 Feb 91 13:55:57 GMT
From: zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!helios!tamsun.tamu.edu![e-mail]  (William Hobson)
Subject: NOS Documentation
To: [e-mail]

I am vainly trying to install G1EMM's version of NOS.  There are quite a few
undocumented features that are giving me fits.  Does anyone have a source for
documentation on basic installation and about the extra EXEcs?  How good is the
Leagues packet book in reqard to installing and using NOS?  Any comments would
be appreciated!

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

Date: 25 Feb 91 18:27:22 GMT
From: xanadu![e-mail]  (Jeff Crilly N6ZFX)
Subject: Packet-radio without a TNC.
To: [e-mail]

In article <[e-mail]> [e-mail] (Andrew Robinson) writes:
>
>Is BayCom available via anonymous FTP?  If not, I would like to suggest that
>somebody who has the program should upload it.  Maybe the circuit diagrams
>could be put in a file and uploaded along with the program.  If someone does
>upload the program, please inform us by posting to this newsgroup.  Thank you.
>
>     -- Andy

Or make it available on comp.binaries.ibm.pc.  Or maybe someonw could
upload it to a landline BBS.

Jeff Crilly (N6ZFX)
AMIX Corporation  2345 Yale Street  Palo Alto, CA  94306
[e-mail], {uunet,sun}!markets!jeff, N6ZFX@N6IIU.#NOCAL.CA.USA

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

Date: Sun, 24 Feb 91 10:16 EST
From: "CHARLES LAYNO (WB4WOR)" <[e-mail]>
Subject: Packet via the phone
To: [e-mail]

In responce to Ron France's desire to run packet from a telephone, here is
something that works for me. I run pcANYHWERE on the computer at home. I have
Com1 and Com2 set for 2 different tncs. These Com's are running standard
interups. I bought an internal phone modem (2400 baud, fo those inquirering
minds) and set it up for Com3 interup 2. Setting the pcANYHWERE to run custom
for Com3. I use the companion pcATERM to give even more security, (without
ATERM, you don't get in at all! But it is configurable for stand term
programs.) I then bring up my usual packet term program ans away I go.
pcANYWHERE gives me FULL control of the system, including remote booting of the
PC. pcANYWHERE seems to take abt 60k of high memory so it isn't excessive. I
also run this setup on my packet BBS, which is remoted at the digipeater site,
8 miles from home. Makes it nice that I can dial in and have full local control
over the phone line. There is also a file transfer module for uploading and
downloading programs remotely.

It has helped me and I am sure it will work for you. I too run 8088 640k
systems, so it seems tobe real good on not hogging the memory.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Charles Layno             BITnet: [e-mail]
P.O. Box 8252             Internet: [e-mail]
Greensboro, NC            CompuServe: 71441,1562
27419-0252                Packet Radio Mail: WB4WOR @ WB4WOR.#GSO.NC.USA.NA
         "REALITY..................WHAT A CONCEPT!"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Date: Mon, 25 Feb 91 13:55:07 +0100
From: Stefan Eckart <[e-mail]>
Subject: RUDAK II activated
To: [e-mail]

RUDAK II, subtenant on the Russian scientific research satellite GEOS,
also termed AMSAT OSCAR 21, has been activated this weekend.

RUDAK II is part of a joint venture of AMSAT-U, ORBITA and AMSAT-DL. It is
a digital transponder and mailbox system, comprising a 65SC02 based computer
with 56 KB of RAM (identical to the failed RUDAK onboard AMSAT OSCAR 13),
a 1 MB static RAM-disk and a second general purpose computer with an RTX-2000
CPU, 128 KB of fast (10 Mio accesses per second) error corrected CMOS RAM and
AD and DA converters which will be used primarily for digital signal processing
applications.
RUDAK II is accessible through four uplinks using different types of modulation:
1200 bps FSK (like JAS and PACSAT)
2400 bps BPSK biphase-S (like the AO13 downlink but at sixfold speed)
4800 bps biphase rectangle spectrum modulation (RSM)
9600 bps RSM (not the G3RUH FSK modulation)

The downlink is capable of a variety of modulations. Presently it is 1200 bps
NRZI BPSK and 400 bps AMSAT telemetry (like AO13, for engineering purposes
only). Further modulation types (e.g. FSK and 9600 bps RSM) will be used in
future. FM speech on the downlink is also possible.

Both processors were loaded last weekend. The 6502 computer (called R2) is
running packet radio digipeater software on top of the IPS operating system. A
preliminary mailbox will be loaded soon. It also continuously checks the
degradation of a 32 kB EPROM which replaces one of the RAM-disk RAMs.
The RTX is also running IPS and some DSP routines for speech generation and
'FM repeater mode'.

The following modes were tested this weekend:
- packet digipeater with 1200 and 2400 bps uplinks
- FM repeater (uplink is the 1200 bps receiver)
- speech generation

Due to an automatic cycling through different telecommand modes, initiated
by the main payload, the RUDAK downlink was not available all the time
this weekend. The downlink is on 145.981 MHz and is very strong. The digitized
speech could be heared virtually noise free with a handheld.
The 1200 bps uplink is at 435.015, the 2400 bps uplink at 145.155 MHz.

The following two-line Keps are not the latest but still VERY accurate:

1991 006A
1 21087U          91 32.47108372  .00000525  00000-0  54376-3 0    53
2 21087  82.9490 334.1385 0034162 277.8354  81.8925 13.74338076   400

73s from the AMSAT-DL RUDAK group:

Hanspeter (DK1YQ), Peter (DB2OS), Gerhard (DG2CV), Stefan (DL2MDL),
Hermann (DK8CI), Knut (DF8CA) and many others.

and, of course,
Leo (UA3CR).



Stefan, DL2MDL, [e-mail]

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

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


Packet-Radio Digest         Wed, 27 Feb 91       Volume 91 : Issue  54

Today's Topics:
             Packet-Radio Digest V91 #53

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, 27 Feb 91 08:46
From: "Olaf Erb"                                  <[e-mail]>
Subject: Packet-Radio Digest V91 #53
To: [e-mail]

I read about '9600 RSM'... what is it? I only know FSK PSK and MSK.
Is there any information about this modulation? (or schemes for a
modem :-)
73s
Olaf
[e-mail]
[e-mail]

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

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


Packet-Radio Digest         Thu, 28 Feb 91       Volume 91 : Issue  55

Today's Topics:
               info request Bitnet, ect

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: Thu, 28 Feb 91 06:38:56 EDT
From: [e-mail]
Subject: info request Bitnet, ect
To: [e-mail]

Hans-J}rgen

You may want to sub and ask your questions to a list called Help-Net

this list is a HELP RESOURCE for questions concerning BITNET/CREN/ and
Internet

Its address is as follows

to SUB:

TELL LISTSERV@TEMPLEVM SUB HELP-NET <YOUR NAME>

with your name being your correct name

to submitt a question send to:

Help-Net@TEMPLEVM

The persons on this list will, if they can't right off, research your
questions and will reply back to the list with your answer.

This list is very informational....

Hope this helps

Tim Wright
WRIGHT@morekypr

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

End of Packet-Radio Digest
******************************